Oracle released Adaptive Case Management (ACM) in 2013 as part of the BPM stack. One of the functionality we needed in a project recently, was the handling of deadlines in the context of a case. There is (currently) no out-of-the-box solution to, for example, escalate or reassign a case when a specific deadline has expired. In this blog we describe how this functionality can be created with the out-of-the-box functionality of Oracle Case Management.
Dealing with deadlines
Consider the situation that a case needs to be automatically transferred from an employee to a supervisor after 24 hours and from the supervisor to the manager after 48 hours. Of course, when a case is closed while the deadline has not expired yet, the timer keeping track of the deadline should be terminated.
A solution to this use case would be to implement an interaction between the case manager and a dedicated timer process as depicted in Figure 1. In this figure the Case Manager initiates the timer process. When the timer expires (e.g. the first 24 hours), the data associations are updated and an internal case event is thrown to give control back to the case manager. The case manager analyses the incoming data, performs some tasks and eventually re-launches the timer process to wait for the next 24 hours.
Figure 1: Timers expires after 24 hours after which a new deadline check is started
The other scenario is depicted in Figure 2. Here the timer process is stopped by the case because the case has ended before the deadlines expires.
Figure 2: The Timer needs to be interrupted, because the case is closed
Building this functionality with a combination of Oracle Case Management and BPM would be to implement the timer with a BPM process as shown in Figure 3. This very straightforward process only has one component that keeps track of the deadline and an event sub-process that terminates the process in case of an incoming event. The crucial part of the solution is to use case data to let the Case Manager decide what to do next via the embedded business rules engine.
Figure 3: straightforward BPM process that keeps track of our deadline including an event sub-process to terminate the process
Looking at Figure 4, you see that the input and output for this process is a case data object. This data will be known by the case and hence will be available for the business rules to reason about. When promoting this BPM process to a Case activity, the configuration of the case will automatically be updated, as shown in Figure 5 and Figure 6.
Figure 4: configuration of the input and output arguments for our BPM process
In this example, the input argument for our timer will be used as an expression in the implementation of the timer component. When the timer expires it writes an expression to the caseData object saying that the first deadline has expired.
Figure 5: configuration of the Case activity
Figure 6: Configuration of the case itself
When the timer activity has finished, control is given back to the Case Manager. By means of the business rule engine the Case manager can decide what to do next (Figure 7).
- Activity “Process” finishes and,
- The case data attribute “DeadlineType.name” is set to “deadlineOne” and,
- The case data attribute “DeadlineType.outcome” is set to “expired”
Then we can launch a new activity. For example, we launch an activity that computes the next deadline that updates the “DeadlineType”. Afterwards we can launch the process again that starts the timer.
Figure 7: Configuration of the business rules
This blog is created together with Marc Kuijpers, SOA/BPM consultant at Capgemini