Issue in performing SMI calls

Claret_Ivin · April 2, 2024, 11:20am

Hi,

We’re attempting to make an SMI call during app initialization. However, we’re encountering an error during the process.

Code:

    try {
      const token_response = await client.request.invoke("getNewToken", {});
      token = token_response.response.token;
    } catch (e) {
      console.error(e, "------->iparams error");
      throw new Error("Failed to generate token");
    }

Response:

{
    "requestID": "a547806f-a784-4c97-916f-f8983b4e9334",
    "status": 500,
    "message": "Failed to generate token",
    "errorSource": "APP"
}

It’s worth noting that we tried this locally, and we were able to perform the call successfully.

Could you please assist us in resolving this matter?

Raviraj · April 2, 2024, 11:35am

Hi @Claret_Ivin,

Could you log the original error from the platform and share the error message and code? I think this error is not from the platform but a custom error from the app code.

Also, share the SMI function code to replicate the issue.

What is the FDK version?
Is the Issue happening in the local simulation or production environment?
Which product/modules?

Claret_Ivin · April 2, 2024, 12:44pm

Hi @Raviraj ,

I’ve attached a screenshot of the error for reference. Upon reviewing the code, I couldn’t find any instances where such an error code is written.

SMI function code:
iparams.js

    try {
      const token_response = await client.request.invoke("getNewToken", {});
      token = token_response.response.token;
    } catch (e) {
      console.error(e, "------->iparams error");
      throw new Error("Failed to generate token");
    }

server.js

  getNewToken: async function () {
    try {
      const token = await getJWTToken();
      renderData(null, {
        token: token,
      });
    } catch (e) {
      renderData(e);
    }
  },

async function getJWTToken() {
  const api_url = `authenticate`;
  params = {
     username: config_data.username,
     password: config_data.password,
   };

  try {
    const response = await $request.invokeTemplate("postRequest", {
      context: {
        path: api_url,
      },
      body: JSON.stringify(params),
    });
    console.log(response);
    return response.headers.authorization;
  } catch (e) {
    console.error(e, "----->error");
    throw new Error("Failed to generate token");
  }
}

requests.json

  "postRequest": {
    "schema": {
      "method": "POST",
      "host": "intune.techaffinity.us",
      "path": "/intune/<%= context.path %>",
      "headers": {
        "Content-Type": "application/json"
      }
    }
  },

What is the FDK version?
“fdk”: “9.0.8”
Is the Issue happening in the local simulation or production environment?
The issue is happening in production environment
Which product/modules?
Freshservice

Claret_Ivin · April 5, 2024, 6:30am

Hi @Raviraj

Just a quick follow-up on my previous email regarding the error in making SMI calls. Could you please provide an update on this ?

Raviraj · April 10, 2024, 7:03am

@Claret_Ivin In the app, you have the code, throw new Error("Failed to generate token"); in the catch handler for the $request.invokeTemplate() method. The same error is passed in the SMI and in the app.js file, which is what is thrown in the UI. It is expected.

Please troubleshoot what is failing in the API and causing the flow to go into the catch block. That would be your right direction to troubleshoot the failure.

The error I see comes from your code in the catch block. Check why the API fails and fix it.

Claret_Ivin · April 10, 2024, 11:53am

Hi Raviraj,

We removed the code that throws a new error (“Failed to generate token”) and made the API call again, but unfortunately, we received an empty response.

We tested the API using Postman and were able to perform the call successfully.

The problem seems to arise when publishing the app as a custom app. Interestingly, the same functionality works fine in the local environment.

I’m attaching a screenshot for your reference.

Thank you,
Claret Ivin

Raviraj · April 10, 2024, 1:29pm

@Claret_Ivin The API response directly comes from your/third-party API service if the error code is not 5xx.

Could you share the complete response with the response code and body in both the FW app and from Postman/cURL?
Just in case, to find if the context is placed fine, could you test once with the path completely hard coded? After it works, it can be moved back to the context.
Could you check if the request’s URL, headers, and body are sent fine in the network tab?
Where does the config_data come from? Could you hard-code it and test it as well?

Claret_Ivin · April 11, 2024, 4:22pm

Hi Raviraj,

The complete response:


{
"requestID": "81982ec5-b889-44f1-b9d1-dcb73e612cd2",
"response": {}
}

Despite attempting to hardcode the complete path and ensuring correct passing of the URL, headers, and body, we’re still receiving an empty response. Even after hardcoding the config_data values, the issue persists. However, when we tested the API call with the Axios method, we were able to receive a response.

Raviraj · April 15, 2024, 12:49pm

@Claret_Ivin Unsure why the response is empty from SMI.
Could you share the app ID and approximate time of the request along with the request ID for us to check the logs and investigate further?

Claret_Ivin · April 16, 2024, 7:27am

Hello Raviraj,

I’ve shared the response along with the timestamp.

Response:

{
"requestID": "80dd931c-adfd-4109-9de9-a8dc1c710d3e",
"response": {}
}

Time: Tue, 16 Apr 2024 07:18:14 GMT

Please find the app IDs below. I’ve published the apps using both the request method and the Axios method.

10742 - Intune Demo (Request method)
13622 - Intune (Axios method)

Thank you,
Claret Ivin

Raviraj · April 17, 2024, 7:50am

@Claret_Ivin We have analyzed the logs at our end. The SMI is getting successful for the app with ID 10742 at the mentioned timestamp.
We see status code 200 for the SMI, which means the SMI was successful.

The payload has what has been sent from the Serverless function. Could you check by sending a plain variable in the success payload? Then, the issue only occurs with the Request Method made in the Serverless.

The response can be completely logged to find what is being received in the Serverless logs. Then it can be fixed.

Please share the Request Method code and the request template for further help. Thanks.

Claret_Ivin · April 17, 2024, 1:41pm

Could you please clarify this suggestion **Could you check by sending a plain variable in the success payload? **

requests.json

  "authenticate": {
    "schema": {
      "method": "POST",
      "host": "intune.techaffinity.us",
      "path": "/intune/authenticate",
      "headers": {
        "Content-Type": "application/json"
      }
    }
  },

iparams.js

   try {
      const token_response = await client.request.invoke("getNewToken", {});
      console.log(token_response, "------>token response");
      token = token_response.response.token;
    } catch (e) {
      console.error(e);
      // throw new Error("Failed to generate token");
    }

server.js

  getNewToken: async function () {
    try {
      const token = await getJWTToken();
      renderData(null, {
        token: token,
      });
    } catch (e) {
      renderData(e);
    }
  },

async function getJWTToken() {
  const api_url = `authenticate`;
  // const api_url = `${base_url}/authenticate`;
  const params = {
    username: config_data.username,
    password: config_data.password,
  };
  // const headers = { headers: { "Content-Type": "application/json" } };
  try {
    const response = await $request.invokeTemplate("authenticate", {
      context: {
        path: api_url,
      },
      body: JSON.stringify(params),
    });
    // const response = await axios.post(api_url, params, headers);
    console.log(response);
    return response.headers.authorization;
  } catch (e) {
    console.error(e);
    // throw new Error("Failed to generate token");
  }
}

Raviraj · April 18, 2024, 2:21pm

@Claret_Ivin Since this transaction is happening in the installation step, it’s hard to watch the Serverless logs.

Add more logs to the API response to find what exactly is received from the API, handle the error, pass it on to the SMI, and fail it if the API fails.

Let the app installation go through even if the API fails so that the serverless logs can be read after the app installation. If the app installation fails, you don’t have a way to find the serverless logs for the app.

Let us know if you can find the issue.