Using Thresholds, SLAs and Alerting in Process Observer (POB)
In the previous blog post Create KPI Definitions for Business Process Monitoring & Analytics for Business Suite Processes (POB) I have shown how to create KPI definitions for Process Observer. I will now extend this topic by showing how to create thresholds and how to set up the related alerting. While this is only a small addition to Process Observer, I believe it deserves its own blog post, because thresholds are basic building block of a significant number of uses cases around process KPIs. Please check the previous blog posts for details on process and KPI definitions.
Since I have mentioned SLAs in the title, I need to add a word on SLAs here; actually Process Observer does support SLAs, but only through thresholds. So you can do analytics on process data to find out how often you may have missed a threshold or send an alert before you break a process KPI related SLA; I think this is a vital part of SLA handling, particularly in the process management space, but full handling of SLA handling may encompass much more.
The basic idea of thresholds in Process Observer you can see below. The application events drive Process Observer and trigger the KPI calculations. Thresholds against the KPIs are monitored. If the thresholds are reached, a threshold violation alert event is raised that can be consumed by the SAP Alert Management, SAP Business Workflows or, through Event Type Linkages, almost anything else.
Since thresholds are in the context of Process Observer just an extension to KPIs, they are defined as part of the KPIs. This is done using Maintain Process Definition (POC_MODEL). The transaction is part of the standard user role (SAP_POC_BPX). When you drill down to your KPI definition, you will find a (maybe new) view called “Count Thresholds” or “Duration …”, “Classification…” respectively.
For count you enter the threshold as shown below.
The threshold violation alert event is triggered when the figure entered here is reached, so in the case of the example above, there will be an event once when the count reaches five; there will be no further event, e.g. when the count goes up to six. And even if the view shown above hints at something else, you can only create one threshold; you will not be able to save here with multiple thresholds (maybe this will be there later, but maybe not).
If you want to define a threshold that depends on the process instance, you can use BRFplus rules. The BRFplus rule is called once the first time the KPI is calculated to determine the threshold value. That allows you to calculate threshold based on the business data and complex rules.
For duration KPIs you have to define a value and a unit (seconds to days). Note that while the monitoring of a count KPI looks quite simple and straight forward, the duration threshold violation alert has effectively to be raised when an event is missing, which is more comlex. The report POCR_TRACK_THRESHOLD monitors the duration thresholds; it is run by the report POCR_MAIN_QUEUE, which should be scheduled to run in regular intervals; this report it scheduled automatically by report POC_JOB_SCHEDULER. This needs to be mentioned , because the precision of the alerts depends on the frequency the report is run; if you run it every minute, an alert may be raised up to one minute after the threshold is reached, if you run it once per hour, the alert may lag up to one hour. Thus you have to schedule depending on your needs. In a test situation it can be very helpful to not schedule the report to run automatically, but to execute it manually using the Program Execution (SA38).
Count and category thresholds are monitored when the KPI is calculated.
The category threshold has one distinction from the thresholds mentioned before; here the alert is raised when the value is reached exactly,there is no „greater than“ comparison.
So what happens when the threshold is reached? The BOR (Business Object Repository) event POCPROCESS.Threshold_Reached is raised. This event has all relevant information of the threshold either as an attribute or as an event parameter available for easy consumption, including the process instance, definition and version, and KPI and threshold value; for more details see the definition in the Business Object Builder (SWO2).
If and when the event was raised is shown in the Process Monitor (POC_MONITOR) on the KPI tab of the Process Details, see below. You can also see if any threshold was reached on the top of the screen, and for each KPI what threshold values are defined.
In the Process Monitor using the Advanced Search you can also search for process instances where the threshold has been violated and a threshold violation is indicated on the initial list screen of process instances.
The thresholds and their violations are available in the data sources, so they can easily be extracted to a BW system; the data source to use is 0POC_THR_EXEED_ATTR (Threshold Exceeded). For SAP_BS_FND 731, see also the Search and Analytics Model 0POC_KPI here: Process KPI – Process Observer (CA-EPT-POC) – SAP Library.
The easiest way to consume the alert event is using the SAP Alert Management, which is completely independent of Process Observer, but it serves as a perfect addition for threshold handling. It allows you to easily send e-mails, fax, pager and text messages. To use it you have to first create an Alert Category (ALRTCATDEF), where you
- Press the <Create Alert Category> icon on the table control on the top right
- Enter an abritrary ID, ZJCN in this example, for the alert category, which you will need for the receiver type in Event Type Linkage (SWE2) below
- Optionally enter an application package ($TMP for testing) and the original language
- Choose the Long and Short Text tab and enter some message title and text
- Press <Fixed Recipients> and enter the user who should receive the e-mail
You have now set up an alert category. You now need to link the threshold violation alert event to the alert category.
- Call the Event Type Linkages (SWE2)
- Enter the event for BOR Object Type POCPROCESS and event Threshold_Reached.
- Set the receiver type to the alert category to be used, in this examle ZJCN
- Use receiver function module SALRT_CREATE_VIA_EVENT to use the alerting (make sure you are using the function module shown here and not the one with the similar name starting with S_ALERT…)
- Make sure you activate the linkage
You can test this by raising events using Create Event (SWUE).
Naturally SAP Alert Management offers many more features; you can find much more about it here in SCN in Alert Management with SAP NetWeaver Application Server.
Another way to consume the threshold violation alert event is to use the Event Type Linkages (SWE2) with other event consumers. Most commonly you can use SAP Business Workflow. I cannot even start with the options you have here, but with some proficeny in the area you can easily set up workflows that send notifications, wait for those notifications to be confirmed and if not confirmed, send out further notifications to managers etc., or generally pretty much all you can think of.
And while SAP Business Workflow does allow for ABAP extensions, it may be more convenient for you to put your own implementation of a method or a function module right against the event and essentially do anything, including forwarding the event to some external consumer. This may be more appropriate if you don’t want to use any of the native capabilities of workflow.
The main reason why the initial article on KPIs did not cover this area is simple: With the initial delivery thresholds were not supported, they are, as such, a functional extension of the KPIs. The functional limitation should be valid only for SAP_BS_FND 702, where Process Observer was initially delivered with SP07, but thresholds are available only with SP08. With SAP_BS_FND 731 and SAP_BS_FND 701 thresholds are in the initial delivery, i.e. SP02 and SP11 respectively, so if you have Process Observer in those releases, you have threshold functionality. There may be slight deviations between the support packages and releases, but they should not affect anything relevant.
And to close things off, let me point out the home page of Process Observer.
As always, please contact me if you have further questions – particularly with regards to availability, which can be quite confusing – or other remarks or comments. I’m very interested to hear if you have scenarios or use cases that could benefit from the use of thresholds as described above.