Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
Hello everyone! I’ve decided to write this blogpost as I would like to share some insights on how you can use the SAP Alert Notification service for SAP BTP and SAP Automation Pilot in order to setup an instant health-check monitoring solution for your SAPUI5 Web App deployed into SAP Business Technology Platform (SAP BTP) Cloud Foundry. This experience was quite interesting to me considering that the use case is based on a real customer need and demands.


As already mentioned, this use case came to our desk from a client who reported the following issue: sometimes there are disruptions / outages with their SAPUI5 Web App deployed on SAP BTP Cloud Foundry. The app is consumed through the SAP Launchpad service which provides a central entry point with an access to this application for the business users. However, for a certain duration the app becomes inaccessible randomly for different users even though that in the Cloud Availability Center (CAC) the Launchpad service is marked in “green status” and therefore there are no notifications / alerts sent out. That results in situation when the client comes to know about an issue with their app only when the business users start reporting issues themselves. Considering our team provides monitoring and automation services within the SAP BTP portfolio, we were contacted by the SAP Customer Success Partner who were seeking for any recommendation or  a solution to be offered to the client.

Challenge to be solved

Before proposing any solution, we decided to dig into the details trying to identify the root cause of the issue described. After looking into different support tickets and incidents reported we concluded that the application disruptions had been caused by different issues such as networking outages, downtime in SAP Launchpad dependent services and potential app scalability issues. This is why, it has been made clear for us that we need to think in a direction on how to setup a more generic, reliable and near real-time monitoring setup for the Web App deployed into SAP Business Technology Platform (SAP BTP) Cloud Foundry. Ideally, we had to be able to build it with no custom resources but with already available and natively consumed BTP services. Of course, knowing our services' capabilities we wee confident that we had the needed tools to do so!

Proposed solution

The solution build and demonstrated to the customer has been based on a synergy and a native integration between the SAP Alert Notification Service and  SAP Automation Pilot. 

 SAP Alert Notification Service and  SAP Automation Pilot capabilities at a glance.

The architecture in place has been designed covering the assumptions as listed below:

  • There is an application health-check endpoint that to be called regularly

  • SAP Automation Pilot is to be automation engine that triggers periodically health-check status calls to the app health-check end points

  • Based on the responses received by the SAP Automation Pilot, there will be a condition within the SAP Automation Pilot so that:

    • If the http response status code is “200” – then the application is considered accessible

    • If the http response status code is different than “200” – the application is considered not to be accessible an alert is to be sent out to the DevOps team

The expected use case (positive and negative application responses) can be visualized as shown underneath:  

SAPUI5 Web App is up and running

Diagram explained:

1.     There is a command build via the SAP Automation Pilot UI which calls the application health-check endpoint each 5 minutes.

2.     The application health-check endpoint returns http response status code: “200”

3.     Based on a condition set within the SAP Automation Pilot command, if the response is “200” there is no need of further actions.


SAPUI5 Web App not accessible

Diagram explained:

1.     There is a command build via the SAP Automation Pilot UI which calls the application health-check endpoint each 5 minutes.

2.     The application health-check endpoint returns http response status code that is NOT “200”

3.     Based on a condition set within the SAP Automation Pilot command, if the response is different than “200” then the SAP Automation Pilot should notify the SAP Alert Notification service.  there is a custom event to be produced by the SAP Automation Pilot which is to be consumed by the SAP Alert Not....

4.     In the SAP Alert Notification Service there is a subscription which is configured to filter events received by the service so that in case there is an event which falls into predefined conditions, a specific action is to be fired - in our case that is an email to be sent out to the DevOps team.



There are couple of notes related to the implementation of the solution described which I believe is worthy to be shared.


1.  SAPUI5 Web App - health-check endpoint:

a.     For our proof of concept (POC) what we have built is an html file which is to be requested regularly by the Automation Pilot and which is to serve as a Web App health-check endpoint, please see the example below:

b.     In order to be possible for the Automation Pilot to access / call the specific html5 file I’ve also included the following settings within the xs-app.json file:

2.     SAP Automation Pilot - health-check command:

a.     To set up a health-check command I’ve reused already provided command which exists within the SAP Automation Pilot commands catalogue, please see HttpRequest where I’ve just modified the method and the URL (which is the html5 health-check file already described):


b.     Conditions within the SAP Automation Pilot which will fire the custom event:


c.     The data object for the custom event that is to be produced by the SAP Automation Pilot in case the condition is met:
{ "eventType": "CUSTOM-ALERT", "severity": "WARNING", "category": "ALERT", "subject": "Alert Sent by SAP Automation Pilot: SAPUI5 Web App Is Not Accessible", "body": "IMPORTANT! SAPUI5 Web App cannot be accessed by the Automation Pilot health check request.", "resource": { "resourceName": "App #2", "resourceType": "application" } }


d.     The regular and repetitive health-checks calls are performed via the Automation Pilot built-in job scheduler, currently set to execute the command each 5 mins.


3.     SAP Alert Notification Service - Subscription setup: 

a.     The events filtering logic within the Alert Notification Service is setup based on the event type received as shown underneath:


b.     The expected action is configured to fire an email alerting the DevOps team:

Final output & conclusion

At the end of the whole POC I am quite satisfied to get to the conclusion that this architecture and setup described turned out to be a quite successful story as the 3 components in question: Web App health check endpoint, Automation Pilot (automation engine) and Alert Notification Service (alerting engine) work well together and can deliver a reliable web app monitoring solution.

As a result, the app health check commands are fired regularly as configured and these are checking the Web App accessibility so that there is an email sent out to the DevOps team in case of an issue identified (see the example shared below):


After running a demo in front of the client our team also received a very positive feedback and the client was more than excited to move forward and implement the proposed solution.

Overall, it was yet another proof for our team that the tools we have in place (such as SAP Alert Notification Service and SAP Automation Pilot) cover almost unlimited set of scenarios and potential use cases. Of course, in case you have any potential ideas for other use cases or any  questions and comments, please do not hesitate to contact me.



Credits also goes to Eyyub Demirbüken (Customer Success Partner) who introduced me to the client and the use case itself.