icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij Whitehorses
Blog 09/01/2014

Adaptive Case Management series – in action – part 3

In action

Business Rules

One of the most important components of an ACM case is the business rules component. It’s been part of FMW since the beginning although up until now it’s not been widely used. Due to it’s central role in ACM, it’s likely this will change as business rules are the primary means of conducting the process flow in ACM.

To create business rules in the business rules component you add a rule or a decision table inside the ruleset that comes with it. In this blog post we’ll focus on the decision table to keep the examples uniformly.
A decision table is composed of one or more rules. A rule in turn is composed of a condition (the occurrence of an event) and one or more action(s). One could for example add a condition on the starting event of a case and use an action to start a s

Conditions R1
C1 CaseEvent.eventType LIFECYCLE_EVENT
C2 CaseLifecycleEvent.lifecycleEvent STARTED
A1 call activateActivity(activityName:String) ActivityName

The flow in ACM is thus dictated by using actions as a result of occurring case events.

pecific activity. The table below shows this business rule.


condition in ACM is coupled to a case event. Case events are comparable to custom events in e.g. BPEL and are managed by the Event Delivery Network (EDN) underneath the covers. The table below gives an overview of the most important case events that can be acted upon via a business rule and shows the corresponding conditions.

Case event Conditions
Activity event CaseEvent.eventType=ACTIVITY_EVENT
  CaseActivityEvent.activityEvent=[ACTIVATED, COMPLETED, FAULTED]
  CaseActivityEvent.activityName= “ActivityName
Lifecycle event CaseEvent.eventType=LIFECYCLE_EVENT
Document event CaseEvent.eventType=DOCUMENT_EVENT
  CaseDocumentEvent.documentEvent=[ADDED, DELETED, MODIFIED]
Milestone event CaseEvent.eventType=MILESTONE_EVENT
User event CaseEvent.eventType=USER_DEFINED_EVENT

The business rules shown above are only the beginning. They can be refined by making use of the (structured) data of the case. This allows the case to selectively react on the outcome of an activity, thus enabling very fine grained routing. In case of a very complex WABO application, e.g. an application containing a construction and environmental component, one has the means to start activities selectively by defining conditions based on structured data.


A condition can fire one of more actions. The table below gives an overview of possible actions.

Action Parameters Comment
call activateActivity(activityName: String) activityName: activity to be started Starts a conditional case activity (automatic and manual)
call withdrawActivity(activityName: String) activityName: activity to be cancelled Cancels an activity
call reachMilestone(milestoneName: String, comments: String) milestoneName: milestone reached
comments: reason for reaching the milestone
Marks a milestone as reached
call revokeMilestone(milestoneName: String, comments: String) milestoneName: milestone to be revoked
comments: reason for revoking the milestone
Withdraws a milestone

Actions in turn can trigger new events in ACM, which can activate other conditions and thus fire new actions. Hence actions can lead to other actions. For example when a milestone is achieved (e.g. permit rejected) as a result of an activity a new BPM process can be started to inform the applicant.
Business rules, as demonstrated, lead to a high level of flexibility in a case. What makes ACM all the more adaptive is the ability to alter business rules at runtime (by means of the SOA composer). The price to pay for all this flexibility is a heightened level of complexity.


In our WABO demo we added two decision tables containing one rule each. The first rule gets triggered after the creation of the case and starts 2 activities, one manual task and one BPM process.

Business Rules
The second rule gets triggered by completing the manual task and triggers a new BPM process.

Business Rules

Overzicht blogs

Ook interessant?

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.


  • Geen HTML toegestaan.
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.

Wil je deel uitmaken van een groep gedreven en ambitieuze integratiespecialisten? Stuur ons jouw cv!