Adaptive Case Management series – in action – part 3
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 |
| Actions | |
| 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.
Conditions
A 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 |
| CaseLifecycleEvent.lifecycleEvent=[STARTED, COMPLETED, RESTATRED, TERMINATED, WITHDRAWN] | |
| Document event | CaseEvent.eventType=DOCUMENT_EVENT |
| CaseDocumentEvent.documentEvent=[ADDED, DELETED, MODIFIED] | |
| Milestone event | CaseEvent.eventType=MILESTONE_EVENT |
| CaseMilestoneEvent.milestoneEvent=[REACHED,REVOKED] | |
| CaseMilestoneEvent.milestone=”MilestoneName” | |
| User event | CaseEvent.eventType=USER_DEFINED_EVENT |
| UserDefinedEvent.event=”UserEventName” |
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.
Actions
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.
WABO
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.
The second rule gets triggered by completing the manual task and triggers a new BPM process.
Ook interessant?
Geen reacties
Geef jouw mening
Reactie plaatsenReactie toevoegen