Skip to Content

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

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.


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.

You must be Logged on to comment or reply to a post.
  • Hi Richard,

    Thanks for one more interesting blog. I was wondering how useful it would be in the real world to have some kind of rules engine working on such events and on having a event aggregation engine for later analysis and recommendations?  Looking forward to more insightful blogs.

    • Hi,

      I’m assuming this is probably possible using the ABAP-based API. Metrics on such process-related exceptions would also be very useful to discover where processes have certain limitations that have a tendency to repeat themselves.

      Thanks for your comment.


  • Hi Dick,
    I see this concept useful when the alert and more specifically its follow-up action is not really a part of the process and just an outcome of one of the process actions. If we use the ALM alert then the alert follow-up action is not really captured in the process. As a result from the process point of view we don’t have any visibility what has happened after the alert is raised. In that case I feel modeling the alerting and follow-up action in the process itself as UI callable objects is a more useful. Each action of the GP though not really an alert but ofcourse a task for the processor and can be configured to be appeared in the UWL (alert also appear there).


    • Hi Dipankar,

      An excellent point. As you suggest, the question is whether the alert in the ALM environment is just be considered part of the process or does the process end at the callable object. If the alert is considered part of the process, then it should be included in some larger picture of the proces that includes more than just the Guided Procedure.  If it is not part of the process, then process-related metrics will be incomplete, because they probably will not include alert-related data.  I’m not sure which view is correct. What do you think?



      • Hi Dick,
        Though it should depend on the specific process design but I feel from process modeling and monitoring point of view it’ll be useful to capture the alert and it’s follow-up actions. If that’s not captured as part of the process I don’t think the ALM alert follow-up action flow can be captured in some other way for later reference/monitoring. So I feel the alert can be a built-in callable object but follow-up action should refer to a task of the same process. My feeling is these features will get much enhanced in Galaxy, which will be a focused and high-end BPM tool. We can’t expect much more from GP as the enhancements of GP has been stopped and eventually it’ll be phased out to make way for Galaxy.