In todays corporate world, there is an emphasis on quality assurance that is connected with selected business processes. In this environment, quality metrics often involve Service Level Agreements (SLA). This blog will examine one aspect of process SLAs the timely execution of either entire processes or particular process steps. Usually, such SLAs are based on an established due date and the requirement that a task is finished before this deadline. If a task isnot finished on time, then certain activities (sending an email or creating a new process for escalation purposes) is necessary.
This blog will look at active measures to deal with such violations. In this context, active refers to actions that must be taken to deal with such problems. A future blog will examine passive aspects of the same topic and will describe a web-service that returns a list of overdue processes that provides the basic data necessary or service provision reporting.
In Guided Procedures (GP), there are two possibilities to add SLA-related functionality concerning due-dates: at the process and at the action level. There is a good description of the available functionality use the appropriate SAP Help links but no references to its usage regarding SLAs and other quality-related measures.
At the action level, you can add a due date (either based on a particular date or on duration – for example, initiation plus 3 days) and then two notifications.
At the process level, the User Interface is similar with the exception that the number of measures is unlimited.
After selecting whether you want duration or date based measures, you can select a Callable Object (CO) that should be executed when a process / action is overdue. It is also possible to map parameters from the process context to the selected CO instance.
It is exactly at this point that things get complicated inasmuch as not all CO Types can be used. I have only found two CO Types that can be used: Miscellaneous/Send Notification and Service/Composite Application Service. There might be other possibilities but I didnt want to create example CO from every CO type to discover exactly which types can be used. Thus, depending on the functionality required when SLA violations occur, the processdesign could get very complicated.
For example, the use case where a particular user should be informed via when an SLA violation takes place can be covered with the SendNotification CO Type. However, if the use case requires that a new process should be started for example, an escalation process then things get difficult.
For example, I could use a Composite Application Service CO for an escalation process but I need the process instance id to perform certain tasks in CAF Core. The problem is: how do you get the process instance id in CAF Core. It is relatively easy in Web Dynpro (for example in a background task) but the CAF Core API is largely undocumented. So, we had another idea.
We created a Web Dynpro Background CO that returns the Process Instance ID which is then available for other elements in the process.
The code is below (Thanks again to Claudiu Tatulea in Rumania).
With this information, we can now use the published GP API to perform the necessary tasks (terminate the late process, throw an exception for the late process, change individual actors in the role, assign the process or action to another individual, etc.)
Thus, through a combination of development work in CAF Core and the use of standard GP functionality regarding notifications, an organization can support its process-related quality measures with IT tools in a dynamic and efficient manner.