Cross-application alerts in processes: An example based on Guided Procedures

[richard_hirsch]

If you look at Guided Procedures, you will see that there is some difference between its runtime environment and that of other workflow and ERP-related SAP products. Although the GP environment provides excellent support for the creation and design of processes, there are certain shortcomings dealing with the monitoring of processes. I've created a few Guided Procedures Explorations: Thoughts on Service Level Agreement Metrics – Active Measures dealing with the metrics associated with Guided Procedures-based processes but this custom functionality really doesn't fit into an existing corporate landscape that includes various SAP-based environments (CRM, etc).

For those situations where events - usually dealing with process-related exceptions, require immediate attention, the current GP environment has some shortcomings. Ideal would be the use of existing SAP functionality to deal with such events in a similar fashion as in other corporate applications

The Alert Framework (ALM) provides an excellent avenue to bring Guided Procedures into the corporate environment. A recent Alert Management - the Ideal Solution for Monitoring Your System provides a great overview of this functionality.

Within ALM, conditions for critical situations are predefined. When an alert is triggered in ALM that meets these conditions, the system determines responsible or interested parties and informs them immediately. ALM helps to prevent delays in the processing of critical situations, because the time between discovering and responding to such situations is reduced considerably.

Note: If you want more detailed information on ALM, there is an excellent description here.

Of course, things are never easy and unfortunately, such alerts are usually created by calling a function module via ABAP.

The function module in question is called "SALRT_CREATE_API" and the alert category (IP_CATEGORY) is the only mandatory import parameter. The parameters IP_EXPIRATION_TIME and IP_EXPIRATION_DATE are optional import parameters for an expiry time and date. The optional import parameter IP_WAIT_ON_COMMIT is used to control whether an alert is triggered immediately or with the next commit. The default setting is to wait for the application's commit.

Avoiding the question of why this isn't supported out-of-box, let's look at the various integration options. I think the obvious integration point in Guided Procedures occurs when process exceptions occur. The decision when an exception should lead to an alert and when some other activity (starting another process, etc.) is a design issue and won't be discussed further.

Of course, it might be possible to access the function module directly in Guided Procedure (see here for details), this would be short-sighted. A more appropriate scenario is that an exception in a Guided Procedure leads to a call to the function module SALRT_CREATE_API via a web-service. The details of the process exception should be passed to the function call via the it_container table in the function call. The web-service could be based on the back-end or could be located on the portal (for example in a application service created via CAF Core using custom code).

Caveat: The ideas in this blog haven't been tested in a real test environment. There are certain things that must still be tested (for example, the ability to add contextual information from the process via the web-service interface) - maybe in a later blog.

Conclusion

Once this alert web service was present, other applications (Visual Composer, SharePoint, etc.) could use it as well; thus, there would be one central service for corporate usage that is used not only in SAP back-ends but also in other corporate applications as well.

 

This centralization would lead to processes that are more efficient in that cross-application alerts could de defined in one place and used throughout the entire process irregardless of the application platform.