Adaptive Case Management series – an overview – part 3

In this 3rd part of the overview in our Adaptive Case Management series, we continue exploring the capabilities of the ACM functionality in the Oracle BPM Suite using the WABO case we introduced before in part 1 and part 2.

Case Model and WABO

A case consists of the following primary components:

• Case
• Milestones
• Case Activities
• Data/Documents
• Stakeholders
• User Events
• Business Rules

Case

The Case is the heart of ACM. The status and progress of the case is stored in here. In WABO the permit application is what defines the case. The WABO case for example knows the applicant of the permit and the current state of the permit application process.

Milestones

The milestones of a case define key events where upon a case enters a new state. Milestones are the means by which a case can be monitored. Possible WABO milestones are:

• Intake of the permit application;
• Examining the permit application;
• Defining the outcome of the permit application;
• Granting the permit.

A milestone is reached when certain predefined criteria have been met. It’s possible to retract a milestone. A business rule can take care of restarting a previous activity in reaction. A milestone shouldn’t be confused with case lifeclycles. Milestones are defined during design and development of the case and are a means of monitoring the progress of the case. Furthermore milestones have the ability to trigger activities via business rules.

Case Activities

Within the case different case activities, automated as well as manual, can be defined. An activity like eg. a permit being drawn up can be automatically activated within a case. On the other hand activities can also be started manually. Think about an applicant adding extra documents to the case via a website or a service desk. Adding the documents can trigger a new manual activity like a verification task for the new documents.

Data/Documents

Documents and data are also crucial pieces of a case. The documents of a permit application vary from architectural plans to case study reports, etc. Some of the documents, e.g. the ones being supplied by the applicant, are static by nature. Most of the documents though are dynamic and will be adjusted by specialists (stakeholders) during the lifecycle of the case.
Documents are the unstructured data of the case, but a case also consists of structured data. This so called case data is defined in the form of XML documents and can be accessed during the whole lifecycle of the case e.g. in it’s activities and business rules.

Stakeholders and Permissions

A case knows many stakeholders each with seperate rights, tasks and obligations. Stakeholders are defined together with their respective responsibilities in the case definition. This makes it possible to e.g. define which person or group bears responsibility for granting the permit and who is responsible for controlling the information supplied.

User Events

A user event defines an activity triggered by a user. The applicant for one can decide to withdraw his permit application. In doing so the case can be closed with the help of a business rule. Should the applicant change his mind later, the case may be reopened as a result of another user event.

Business Rules

The Business Rules component is the central nerve system of the case and is the glue that makes ACM possible. Business rules act upon and coordinate activities, user events, lifecycle events and milestones for starters. Business rules are defined within the case and are evaluated at runtime by the Business Rules Engine. Business rules were part of the first release of SOA Suite 11g. In BPEL and BPM they weren’t used much, but in ACM they play a vital role. Without the Business Rules component ACM wouldn’t be where it is today.
Every time an event (e.g. a lifecycle event) gets triggered in ACM, all the business rules are validated. A business rule may act upon activities, set a milestone or push the case to a new lifecycle. Business rules determine the main flow of the case. They create a high amount of flexibility for the case, a flexibility which is very hard or nigh impossible to get in a standard BPM process. In the next part of the blog series the power and flexibility of business rules will be explored further upon.

Conclusion

In this first series of ACM blogposts we tried to give you an impression of the current status of ACM in Oracle FMW. The most important aspects of ACM have been highlighted and clarified by relating them to the real-life WABO case. In the next series we’ll look at the technical possibilities and impossibilities of ACM in it’s current standing.

Ook interessant?

Blog

08/11/2013

Adaptive Case Management series – an overview – part 2

Lees blog