Hi everyone and welcome to the second part of our article on implementing Case Management (CM) patterns with Oracle Process Cloud Service (PCS).
On the first part, we learned a bit about the concepts around Case Management and we (barely) started a process on PCS. We’ll use this process now as a container to implement the ad-hoc nature patterns.
The First Rule of Fight Club
“We do NOT try to implement Case Management on PCS!” – That’s the first rule. What we will do is implement a small subset of behaviors, which will offer some of the advantages of Case Management.
The second rule is that we have two buddies that can help us in this quest: Database Cloud Service (DBCS) and Integration Cloud Service (ICS). Some of the behaviors will need a bit of persistence, which implies placing a lot of case metadata in some control tables, hence the DBCS, with the ICS being used to handle all integrations. ICS may not be necessary but makes integration easy as peach. Use them extensively!
As we’re trying to “hammer a screw”, things will not be pretty. This is a workaround. Please take it as a way to implement these behaviors.
Regarding the first rule, the set of behaviors which we’re going to implement is the following:
- Ad-hoc Task and Process Invocation
- Milestone and Stage Trigger/Set
- Event Listeners
So, last time we created a message based process
Again, the process must be created with messages events, as these will allow it to be called by other cases in an asynchronous way.
The first thing we do is get a case ID. This ID should come from another system (for instance, a database) and will be used to guarantee correlation between all elements of the case. We’ll get into to that further ahead.
Then, what we typically do is set up a business rule (decision table) or a database table, in which we predefine some configurations, such as Overall Process SLA, Milestone SLA’s, etc… This will allow you to change the way a process/case behaves, without actually having to change the process model.
Centralized Control – The Case Main UI
Now, we’re going to need a UI, from which we should be able to invoke whatever actions I want, in the order that I want them.
For that, we’ll build a Human Task and implement the respective form, using the Web Form technology. In fact, you can build your UI in whatever technology you want and then use the REST API’s to perform the task actions, but in this case, we did it with the web forms.
Here is an example of a Custom UI, using Oracle’s Alta UI, and delivered by Link Consulting’s BPM Framework (Very cool product! Ask for a demo at linkconsulting.com/oracle :))
No matter what technology you use, you should guarantee that it contains the following information:
- All business relevant data
- Access to documents to view, upload or download.
- A list of all available milestones, their status and moment in which the last status was set
- A list of all previous actions in the case, including the famous “Who did what and when?”
- A selector of all possible actions available at that moment
- Typically you’ll want to restrict the actions you can do at any moment, based on the actions performed before and the milestones reached, i.e. the case state
- The list of possible actions is determined through one of two options:
- either we implement this logic outside and then invoke it as a web service, for instance in the database
- or we implement it by using Business Rules.
- In both cases, the set of possible actions must be determined prior to entering the Human Task
Main Case Loop Handler
The idea of having a centralized control is complemented with a loop handler. This will ensure that the process keeps coming back to the Case Main UI with each action taken.
We do this by creating a container, in this case, an embedded subprocess and then placing both the activity that determines the allowed actions and the Case Main UI. Then you evaluate the action taken and the case state, determining if the case is now resolved, canceled or if it still continues, looping back to the embedded subprocess in this case.
With each loop iteration, and because this is a case, we must check if the changes in the case state or milestone state will trigger automatically any actions. For instance, resolving a dispute in customer service by offering the customer some money should trigger automatically a bank transfer and a notification by e-mail both to the customer and to the support supervisor.
So we need to implement this verification into the Main Case Handler. First, we validate if the last iteration generates any automatic action. We do this by invoking a service that implements this logic. In our example, we did the validation in the Database, through a stored procedure that checks the case data and understands if any automatic action is to be taken. Then we have a branch: If there are any automatic actions to be taken, the process just takes them. If not, the process collects the user allowed actions based on the current case state and them spawns a new instance of the human task Case Main UI.
Do notice that the automatic actions may change the case state or milestone state, in which case there may be further automatic actions to be taken, and so on. This may lead to infinite loops, so be careful when setting the conditions that lead to automatic actions.
The Case Action Controller
After the process/case determines that an action is to be taken, either automatic or manual, we then need to take it in such a way that the process/case doesn’t stop there waiting for the action to be completed. In a normal case management scenario, a user can trigger multiple new tasks without needing to finish the previous ones. So we need to allow multiple actions to run in parallel.
Also, we may want to have some restrictions on how a given task is invoked. Let’s say that, for instance, you want to ask your supervisor for his approval on a compensation for a customer. So you trigger the Action “Superior Approval”. Now you want to be able to do other actions, for instance, to contact the customer, but you don’t want the system to allow the user to trigger another “Superior Approval” action until the last one was completed.
This is what your Case Action Controller does. It controls the actions that can be taken and in what conditions it can take them.
Right now you’re probably asking “Huuummmm, but isn’t that what the ‘Get Automatic Actions’ and the ‘Get Allowed Actions’ do?” Well, kind of… We use the case main controller to do a few specific things:
- Control the cardinality of the execution of actions – This is done with a Service Task
- Allow parallel tasks to happen – We use an inclusive gateway, and we model all possible actions inside it.
- Set Case Stage status – This is done with a Service Task
Our Case Action Controller looks like this, in a very simplified way
Notice that we use Throw Message Events to trigger the actions. This allows the process/case to trigger this, but then immediately follows to the end of Case Action Controller, without waiting for that action to be concluded. This is how we implement the semantics of an ad-hoc invocation of a process or task, as many times we want, in the order that we want, and not using a predefined, well-structured process.
Implementing our tasks and processes
To implement our tasks and processes that are to be called inside our Case Action Controller, we use the exact same pattern. A task is implemented with a message-based process that only has that task in it.
For processes is exactly the same, but instead of having a single task inside the process, the whole process logic is in it.
Milestone and Stage Trigger/Set
In regards to updating the Milestone and Stage states, we do it through web service invocation and directly update the underlying database. We build a table for Milestones and one for Stages, which include who did what and when. Every time we need to update a Milestone or a Stage state, we just send it to the DB, through the use of REST web services (DBCS features ORDS). This is done by placing service tasks where we want them to be updated.
Updating Milestones and Stages is the way we can understand how a case is progressing and what actions can be taken at any moment, manual or automatic.
There may be times in which you would want to listen to events and trigger a case activity based on those events. This is implemented in CMMN with the use of Event Listeners, and are represented like this.
The first one is a human event listener. In this case, it triggers a task called “Request Help from Colleague”. In PCS we implement this behavior as we mentioned before: invoking a message based process that only has this task inside. It’s like invoking an Ad-Hoc task.
The second one is a timer event listener and it’s a bit trickier to implement because PCS doesn’t offer that many tools to calculate dates and times. Sometimes you would want to do date/time calculations, and PCS isn’t very cooperative in this subject. Comparing with the on-premise product (Oracle BPM), it’s very limited. There are workarounds for this (think of business rules), but we should try and avoid them.
What we typically do is we create a boundary timer event and attach it to either the Main Case embedded subprocess or a given task, and set the timer using the interval condition.
In the case shown here, the timer is attached to the embedded subprocess in a non-interrupting way. When it triggers, it just sets a given milestone. As the event is non-interrupting, the execution stays where it is.
Putting it all together
Adding all of this into a PCS application will render your case-like processes. We built an example on a small project to handle baggage damage claims for airline and airport handlers. The corresponding CMMN model was something like this:
And the corresponding PCS main process was this one.
So we hope this article helps you build some less-structured processes using Oracle Process Cloud Service, and that the limitations of not having case management (at least at the moment of publication) may be overcome, to deliver more value to your organizations.
As always, feel free to reach us with your comments and questions. We’ll try to answer that as quickly as possible.
More articles are in the pipeline and you’ll definitely hear from us in the next few weeks.
Maverick (José Rodrigues)
post header image by Alden Jewell