Wednesday, June 24, 2015

Groovy Time! How to use XML dateTime and duration in BPM 12c

In this article I show some examples of handling XML dateTime and durations in Groovy in the context of a Oracle BPM 12c application.

Working with dates and durations in Java has always been painful. Mainly because date and time is a complex thing, with different formats and time zones and all, but I sometimes wonder if it has not been made overly complex. Anyway. Working with XML dates is even more complex because the limited support by XPath functions. Too bad because in BPM applications that work with dates this has to be done very often, and as a result I very often see the need to create all kinds of custom XPath functions to mitigate that.

This issue of complexity is no different for Groovy scripting in Oracle BPM 12c. And let handling of dates be a typical use case for using Groovy scripting because of this limited support by XPath. Therefore, to get you started (and help myself some next time) I would like to share a couple of Groovy code snippets for working with XML dates and durations that may be useful. These example are based on working with the XML dateTime type, and do not handle with the complexity of time zones and different formats. In my practice this is 99% of the use cases that I see.

In my opinion you still should limit using Groovy to handle dates and to the minimum, and rather use custom XPath functions, or create a Java library which you can can import in Groovy. But when you have to, this just might come in handy.

Instantiate an XML Date

If you have an XML element of type dateTime, you use an XmlCalender object. An XmlCalender object with the current time can instantiated as shown below:

Date now = new Date()
GregorianCalendar gregorianNow = new GregorianCalendar()
XmlCalendar xmlDate = XmlCalendarFactory.create(gregorianNow)

Instantiate a Duration and Add it to the Date

To instantiate a duration you use an XmlDuration object. In the code below a duration of one day is added to the date:

XmlDuration xmlDuration = new XmlDuration("P1D")

The string to provide is of type ISO duration.

The imports to use can also be a pain to find. That actually took me the most time of all, but that can just be me. The ones needed for the above are shown in the following picture (you can get to it by using clicking on Select Imports on the top-right corner of the Groovy script.

Monday, June 22, 2015

Oracle BPEL & BPM 12c Set Flow Instance Title

In this article I describe how to set the instance title for a composite in Oracle BPEL or BPM 12c.

Sometimes little, annoying things that are fixed with a new release can give great joy. With 11g you could set the composite instance title using the (advanced) XPath function setCompositeInstanceTitle(). This helps to find or identify instances in Enterprise Manager. However, for high volume composites you may want to configure in-memory-optimization as well by adding the following properties to the BPEL process in the composite.xml:

The problem is that when you configure in-memory-optimization, that setCompositeInstanceTitle() fails because there is a relation with auditing.

In 12c the composite instance does no longer have such a prominent role in the SOA/BPM Suite. Instead the flow instance now has that role. And with that setCompositeInstanceTitle() has been deprecated, and setFlowInstanceTitle() should be used instead:

You can set the flow instance title by adding a script activity right after the Receive with assign to some dummy string variable, using the setFlowInstanceTitle() as show above. To make it work I had to wrap the string variable in a string function.

Unlike the setCompositeInstanceTitle(), with the setFlowInstanceTitle() you can configure in-memory-optimization and still display the title in Enterprise Manager:

Setting the title for a BPM flow instance can be done using the same XPath function and use it in an assignment to some dummy variable in the start event.

Tuesday, June 16, 2015

Oracle and Adaptive Case Management: Part 2

This posting is the second of a series about Oracle Adaptive Case Management. The first one can be found here. I discuss the different options to define an activity, and the setting you can use to configure when and how activities are started.

There are two ways to implement an activity in ACM. The first one is by creating a Human Task and then "promote" it (as it is called) to an activity. The other way is to create a business process and promote that as an activity. As far as I know there are also plans to use a BPEL process to implement an activity, but that option is not there yet.

When using a Human Task the limitations of it (obviously) are that of a human task, meaning that the means to do some to do some pre- or post-processing for the activity are very limited. There are only a few hooks for Java call outs and XPath expressions, but as processing of that happens on the Human Workflow Engine this won't show up in Enterprise Manager, and error handling will be hard if not impossible. So, when you for example need to call a service before or after a human task (like sending a notification email) you better use a process.

So unless you are sure that such pre- or post-processing will be not necessary, the safest option is to use a process with a human task instead. That will give you all the freedom you have with a BPMN process. The disadvantage is that you will not be able to expose the UI of the task on the Case tab in workspace. However, as for any case management application of a reasonable size you probably will have one or more human activities in a process anyway, and as from a user experience perspective it probably is confusing to have tasks on Task tab, and some of them also on the Case tab, I don't expect this to be a practical issue in most cases. Meaning that in practice you probably handle all tasks from the Task tab only and on the Case tab show only some overview screen.

In ACM activities can be Manually Activated or Automatically Activated. Furthermore you can specify if an activity is Required, Repeated, and/or Conditionally available.

The difference between manually and automatically activated is that in the first case the user explicitly starts an activity by choosing it from a list of available activities. Automatically activitated activites are for example used for some case pre- and post-processing, and for activities that always have to start at some point, and (optionally) given some specific conditions (like some milestone being reached or some other activity being completed). An example is that once a claim has been entered, it has to be reviewed before anything else can happen.

Required activities should be completed before a stage is completed. Be careful though, as nothing is preventing you from closing the stage even though a required activity has not yet finished. If the user has the proper rights, he/she can complete an activity event even when no actual work has been done. There is no option to prevent that. However, in case of an automatically activated activity you can use business rules to reschedule it. For example, if the Review Complaint activity is required, and by that the complaint must have been given a specific status by the Complaints Manager you can use a rule to reactivate the activity if the user tries to close it without having set the status.

Repeatable activities can be started by the user more than once. There is no point in checking automatically activated activities as being repeatable. An example of a repeatable activity can be one where the Complaints Manager invites some Expert to provide input for a complaint, and he/she may need to be able to involve any amount of experts.

Conditionally available activities are triggered by some rule. Both manually as well as automatically activated activities can be conditional. If automatically activated, the activity will start as soon as the rule conditions are satisfied. In case of manually activated activities the rule conditions will determine whether or not the user can choose to from the list of available activities.

Tuesday, June 02, 2015

Oracle and Adaptive Case Management: Part 1

In this blog posting I address four key concepts that are used in Oracle Adaptive Case Management, or ACM for short. This article is the first in a series on ACM.

Recently I was involved in an Oracle Adaptive Case Management (ACM) project. Although some people involved knew about case management in general, it turned out that not everyone immediately understood how case management works with Oracle ACM. As you may be one of them, I will walk you through some of the concepts, using a format that differs from what I have seen so far, and seemed to work well for my audience.

I will not discuss the more general concept of case management. There are sufficient other references that probably do a better job than I could (for example Case Management Model and Notation, or CMMN for short, as defined by the Object Management Group ). For this article I will restrict myself to explaining that, unlike a "normal" BPMN process, case management supports a much more flexible "flow" of a process, for example supporting paths (flows) that were not thought of before, activity types that were not identified before, as well as stakeholders that were not known yet during the initial design. The "A" of Adaptive in ACM refers to the fact that some of this behavior can be configured run-time (after the system is out of development).

A typical example used in the context of case management is a complaints management process. Depending on the nature of the complaint, such a process can go back and forth a couple of times when more information about the complaint becomes available, coming from the filer or after consultations of experts that were not yet recognized.

Case Life Cycle

The first concept to discuss is that of a Case Life Cycle. A case can have the state open, suspended and closed. Unlike a BPMN process, after being closed a case can be reopened again (if required).

Mile Stones

The second concept is that of Milestones. In real life, you probably are used to defining 1 single milestone for every phase or "stage" (as it is called in CMMN) of a case, marking a significant result reached at the end of the it. With case management there may be milestones that are not always applicable, and therefore one should be able to skip them, or even close them halfway. It may also be necessary to revoke a previously reached milestone.

For Oracle ACM it therefore typically works best to identify the beginning and end of a stage as a milestone. So instead of defining 1 milestone "Complaint Evaulated" you define 2 milestones "Complaint Evaluation Started" and "Complaint Evaluation Ended". With Oracle ACM one can flag a milestone as being reached at any point during the stage.

Especially unpredictable behavior concerning the way milestones are reaches, it something that is very hard to model in BPMN.


As a third concept there are the Activities to discuss. From the perspective of the case, an activity is an atomic step that happens within a stage (in CMMN this is called a "task"). Normally, during its execution the case manager is not interested in the way the activity is executed, only in the result. Think for example about the consultation of an external expert: the only thing the complaints manager should be interested in, is the expert's report.

Within a stage an activity can be mandatory (Activity 1), for example the Initial Complaints Assessment, or optional (Activity 5), for example Request Info from Filer. Some activities may happen more than once within a stage (Activity 4), for example Request Expert Input. An activity may also apply to more than one stage (Activity 3), for example Update Complaints Manager. Activities may be sequential (Activity 1 and 2) or parallel (Activity 3 is parallel with 1 and 2). There can also be ad-hoc activities, like for example notifying some external party that turns out to be a stakeholder of the complaint.

As I will explain in the next article, an activity can be anything from a simple human task to perform, to a complete and even complex business process of its own.


The fourth and last concept that I would like to discuss in this article, is that of Stakeholders. In real life a stakeholder is anyone that has some interest in the case, but may not always be involved as a case worker (someone doing something for the case) or case reviewer.

In Oracle ACM however, you are only interested in stakeholders that are case workers or case reviewers (very similar to the CMMN notion of case workers, except for that CMMN does not recognize case reviewers). As I will explain later, with Oracle ACM there can still be people that play a part in case while not being defined as a stakeholder.