API Apps
  • 25 Nov 2021
  • 4 Minutes to read
  • Dark
    Light
  • PDF

API Apps

  • Dark
    Light
  • PDF

Article Summary

In this article, we will take a detailed look at 2 different capabilities of API App monitoring:

  • Expected State monitoring
  • Endpoint availability monitoring

Expected State monitoring

Let's say we have an API app that is up and running in the Azure Portal. The API app has multiple URL endpoints associated. You can set up monitoring only on the API app and get updates from BizTalk360 when the API app is in a different state (disabled). Follow the steps as shown below to monitor the health of the API app.

  • Log in to the BizTalk360 application
  • Select the 'Environment'
  • Click 'Monitoring' in the navigation panel
  • Click the expand button against the 'Manage Mapping' tab and select the 'Azure Services' link
  • Select the Alarm name (Manage Alarms) from the drop-down for which you would like to associate the alerts
  • Choose the Azure subscription from the drop-down

If there are no Azure subscriptions mapped to your environment, you will see a warning message as "No Azure Subscriptions Found/Enabled". In that case, from the landing page, you can go to Settings > General to Add/Enable an Azure subscription
  • Select the 'API Apps' tab. This will list the API Apps that are created under the selected subscription. Let's say, we want to monitor the CalculateRestApiTest API app from the list of available API Apps
  • Select the check box against the 'CalculateRestApiTest' API app. From the 'Expected State' drop-down, choose the expected state of the API app in order to set up monitoring. Let's say, we expect the API app to be 'Enabled' at all times

Setting the expected state will automatically start monitoring the API app. BizTalk360 monitoring service will automatically compare the current state of the API app with the expected state and display the status (as Healthy or Error). If the expected state matches with the current state, you will notice the status of the API app as Healthy (in green color). If there is a state mismatch, the status of the API app will be displayed as Error (in red color).

In order to receive email notifications from BizTalk360 on the threshold violation alerts (and auto-correction alerts), you need to configure the SMTP settings under BizTalk360 Settings. Follow the steps in this article to be able to configure the SMTP settings in BizTalk360. You will receive an email notification with the exact details of the status of the API app.

  • The monitoring dashboard will reflect the health of the Azure services as shown in the image below

Endpoint availability monitoring

For this scenario, let's monitor the API based on the return code and response time alerts. If the API endpoint is in a healthy state, the URL will return a 200 return code. If we do not get the 200 return code, the status of the monitoring will be displayed as Error. Let's set a Warning alert that if we do not receive a response from the endpoint in 2 seconds and an Error alert if we do not receive the response from the endpoint in 7 seconds.

For the above scenario, let's assume the following results vs. the actual values.

Return Code SettingReturned ValueSet Value
Return Code Alerts200200
Response Time Alerts< 2 seconds

Follow the steps as shown below to monitor API app endpoints.

  • Log in to the BizTalk360 application
  • Select the 'Environment'
  • Click 'Monitoring' in the navigation panel
  • Click the expand button against the 'Manage Mapping' tab and select the 'Azure Services' link
  • Select the Alarm name (Manage Alarms) from the drop-down for which you would like to associate the alerts

  • Choose the Azure subscription from the drop-down
If there are no Azure subscriptions mapped to your environment, you will see a warning message as "No Azure Subscriptions Found/Enabled". In that case, from the landing page, you can go to Settings > General to Add/Enable an Azure subscription
  • Select the 'API Apps' tab. This will list the API Apps that are created under the selected subscription. Let's say, we want to monitor the CalculateRestApiTest API app from the list of available API Apps
  • Select the check box against the corresponding API of the CalculateRestApiTest API app, say, /Api/Add/. Click the 'Configure API App Endpoints' button. This will open a new blade.

The Friendly Name and Endpoint URL fields will automatically be pre-populated with the information about the API. Enable Monitoring (by toggling the Enable Monitoring toggle bar) for the API app web endpoint.

  • Click 'Next' to navigate to the next section
  • In the Web Endpoint Monitoring - Optional Details blade, since the API requires a payload input (for the "id" field), let's define the payload information in the Payload section. Enter the key as 'id' and value as '1'. This means that were are executing the API to retrieve (GET) the first record from the list of values.

  • Click 'Next' to navigate to the Response alert configuration screen
  • Choose the response format as 'JSON' and toggle the 'Return Code Alerts' to an active state. Set the 'Return status code' to '200', 'expected status' to 'must be Present', and 'Else' to 'Throw Error'. The Response Time Alerts will be enabled by default. You can leave it to the default values of 2 seconds (warning) and 7 seconds (error) respectively, or you can modify the values based on your requirement. As per our scenario (since it matches the default setting), let's leave it in the default setting.

  • Click 'OK' to start monitoring the endpoint

  • The monitoring dashboard will reflect the health of the Azure services as shown in the image below

In this case, the Current Status of the web endpoint will be displayed as Unhealthy. This is because the return code value doesn't match the set value and the response time was well within the warning and error level. The endpoint summary will display the state as Unhealthy for Return Code Alerts and Healthy for Response Time Alerts.

How to Remove Orphaned API Apps

By chance when you rename or delete the API Apps that you are monitoring within an alarm will become Orphaned API Apps. Hence it will be shown as Orphaned in the User Interface and the status will become unhealthy. 

To resolve this unhealthy alarm state, you can remove the Orphaned API Apps, by selecting the "Remove Orphaned" option.



Was this article helpful?

ESC

Eddy, a super-smart generative AI, opening up ways to have tailored queries and responses