This modules covers two different aspects that we need to understand to customize our business processes to specific business situations. The first concept that we need to understand is the Service Task activity defined in the BPMN v2 specification. Once we understand the nature of external system interactions we need to understand the mechanisms implemented in jBPM5 to provide these extension points.
Find more about it in:
http://salaboy.wordpress.com
http://ilesteban.wordpress.com
Introduction to Multilingual Retrieval Augmented Generation (RAG)
jBPM5 Community Training Module #5: Domain Specific Processes
1.
jBPM5 Community Training
Sponsored by Plugtree
2. Module 5: jBPM5 Domain
Specific Processes
jBPM5 Community Training
version: 1.0-SNAPSHOT
Release Date: 03/01/2011
Under The Creative Common License
3. Module 5: Domain Specific
Processes
jBPM5 Community Training Course by
Mauricio "Salaboy" Salatino and
Esteban Aliverti is licensed under a
Creative Commons Attribution 3.0
Unported License.
Based on a work at salaboy.wordpress.
com.
Permissions beyond the scope of this
license may be available at http:
//salaboy.wordpress.com/.
4. Agenda
Domain Specific Processes
Introduction
BPMN2 Service Tasks
Work Item Concept inside jBPM5
Work Items characteristics
Work Item Handlers
Implementing Custom Handlers
Controlling Flow Execution
Examples
5. Introduction
BPMS are domain agnostic, that's good but...
We need to extend them in order to represent specific
business situations
Our processes needs to represent domain specific
behavior
The activities inside our processes reflect how people
work in a specific domain
Different systems behaves differently and we need to
represent this particular behavior in our processes
6. Introduction
The BPMN2 Standard Specification Service Task
It provides a generic way to interact with external
services
Spec: "A Service Task is a Task that uses some sort of
service, which could be a Web service or an automated
application."
We can use the Service Task concept as extension point to
plug domain specific behavior and to handle external
interactions
7. Introduction
Inside jBPM5 the concept of Work Item is used for
extension points
Any external interaction from the process perspective is
done via a Work Item
The work item is executed outside the process scope
A Work Item Handler needs to be defined to technically
specify the execution behavior
At runtime we can plug different implementations for
different environments
8. Work Items Characteristics
Work Items
Represent a unit of work executed outside the process
engine
Main Characteristics:
Domain-specific
Declarative: what, not how
High-level: no code
Customizable to the context
9. Service Task relationship with WorkItems
Service Task relationship with WorkItems
The Service Task Activity inside BPMN2 exposes an
atribute called:
implementation: this attribute can be used to specify
which implementation will be called when a specific
service task is reached by the process execution.
In jBPM5 this implementation attribute will be bond
to a specific Work Item Handler that will contain the
technical specification about how to interact with an
external entity
10. Service Task relationship with WorkItems
Service Task relationship with WorkItems (cont.)
The Service Task activity define the information that will
be required by the external interaction and how it will be
copied from the process scope to the task scope
The Service Task activity define the information that will
be generated by the external interaction and needs to be
copied back to the process scope
11. Service Task relationship with WorkItems
Service Task relationship with Work Items (cont.)
For each Service Task that we define in our process we
need to have at least one WorkItemHandler
implementation that must be bound before we execute
our process
At runtime we can choose which implementation will be
used for each Service Task
12. WorkItems and WorkItemHandlers
WorkItem and WorkItemHandlers
For each external interaction that our process execute we
need to know that a WorkItem will be executed
The engine provides some built in work item handlers
for common use cases
Human Task WorkItemHandler is in charge of
handling the human task creations in the Human
Task Server
Email WorkItemHandler is in charge of getting the
information and interacts with an email server to
send an email
13. WorkItemHandler Interface
WorkItemHandler Interface
org.drools.runtime.process.WorkItemHandler
It's located inside an org.drools package because
Drools and jBPM5 share the same mechanism for
external interactions
Force us to implement only two methods:
public void executeWorkItem(WorkItem wi,
WorkItemManager wim);
public void abortWorkItem(WorkItem wi,
WorkItemManager wim);
14. WorkItemHandler Interface
WorkItemHandler Interface
We can choose and define the behavior of the interaction
inside the executeWorkItem(...) method
The interaction can be synchronous or asynchrnous
We usually do the following things inside the
executeWorkItem(...) method:
We get the information required by the interaction
using the WorkItemManager
We execute the interaction with an External (to the
process) Service
We complete the workItem syncronously or we
delegate the completion to the external asynchronous
system
15. WorkItemHandler Binding
WorkItemHandler Binding
We need to get the WorkItemManager from our
Knowledge Session and register our WorkItemHandlers
implementations
ksession.getWorkItemManager()
.registerWorkItemHandler(key,impl);
When a running process hits and activity that specify the
implementation registered (key) the work item handler
will be executed (the executeWorkItem(...) method).
17. Asynchronous WorkItemHandler
Asynchronous Work Item Handler
Call external service
Delegate the responsibility to the external service
app/service to complete or abort the Work Item
For this reason the external app/service needs to have
access to the session that has the Work Item Manager to
complete or abort the Work Item
22. Asynchronous WorkItemHandler
Once Asynchronous Work Item Handler
Call external service
Delegate the responsibility to the external service
app/service to complete or abort the Work Item
For this reason the external app/service needs to have
access to the session that has the Work Item Manager to
complete or abort the Work Item
23. Asynchronous WorkItemHandler
Asynchronous Work Item Handler (cont.)
We can implement a simple mechanism to keep track of
the external async jobs
We need to store a business key and the workItemId that
needs to be finished when the application ends the async
job
This mechanism needs to have access to the knowledge session
in order to be able to complete the related work item
25. WorkItemHandler Information Scope
Process execution will handle different pieces of information
WorkItemHandlers are considered to be external to the
process scope and for that reason they have a limited scope
to handle information
We need to manually map the information that it is required
by the external interaction to be copied from the process
scope to the WorkItemHandler scope
When we complete a WorkItem we get the results for the
external interaction
We must map manually the information that needs to be
copied back from the workItemHandler scope to the process
scope
29. Examples
Project: 02 - Emergency Service Process and Work Items
Examples
Key points: Synchronous Work Items Handler
URL: git://github.com/Salaboy/Drools_jBPM5-Training-Examples.
git
Project: 03 - Emergency Service Process and
Asynchronous Work Items Examples
Key points: Asynchronous Work Items Handler
URL: git://github.com/Salaboy/Drools_jBPM5-Training-Examples.git
30. Examples: Emergency Service Process
A new node was added: "Vehicle Tracking (GPS)"
Task Activity represents a Task that needs to be
performed by an external system
You need to register a handler for each Task
Handlers could be Synchronous or Asynchronous
31. Examples
02 - Emergency Service Process and Work Items Examples:
Handlers must implement org.drools.runtime.process.
WorkItemHandler
Handlers are registered in the Work Item Manager:
ksession.getWorkItemManager().
registerWorkItemHandler(
"StartTrackingSystem",
trackingSystemHandler
);
The handler completes the Work Item inside the
executeWorkItem() method -> Synchronous behavior
32. Examples
03 - Emergency Service Process and Asynchronous Work
Items Examples:
Interaction between 3 different "Systems":
EmergencyProcessExternalSystemsWorkItemsTest:
Test application that embeds jBPM5 runtime.
AsyncVehicleTrackingMockSystem:
An external system in charge of tracking vehicles.
ActiveWorkItemService:
Service used to register and complete Work Items. This system
maintains the relation between an External Job and a Work Item.
The handler doesn't completes the Work Item inside
the executeWorkItem() method -> Asynchronous behavior
33. Homework
Homework
Add a new output parameter to VehicleTrackingSystem task
and show its value into the final report.
This parameter should contain a String representation of the
Date when the External Task was completed.
Create an external system mock with an isAdmisible
(trackingTime:long):boolean method. This method will receive
the total tracking time and will return true if the total time is
below a given (harcoded) threshold otherwise it will return
false .
Add a new "Call to Validation Service" task
after VehicleTrackingSystem and create a synchronous handler
that invokes the new system.
The final report must contain the value returned by this
system.
34. Homework
Homework
Hints:
In order to define a new output parameter for a Task
activity and to store its value in a process' variable
you need 4 steps:
Create a new <itemDefinition> element.
Create a new <property> in the process.
Add a new <dataOutput> element in the Task
Add a new <dataOutputAssociation> in the Task
to map the output parameter to a process
variable.
35. Homeworks Solutions
Homework Solutions
Send me your homework solutions to my personal email
Use the subject [JBPM5 Community Training] -
Hands On labs 2
If you have doubts about the exercise, post a
comment in the blog
If I start receiving too much questions we can
probably create a google group for answering
questions or use the JBoss jBPM forum
36. Conclusions
Conclusions
We understand how to plug our custom domain specific
behavior into our business processes
We understand internal concepts that are implemented
in jBPM5 that provides extension points for our external
interactions
We play with a couple of examples that show a very basic
interaction and more realistic scenarios
37. Next Modules
Stay tuned for the next modules that will explain important
topics such as:
The Business Process Modeling and Notation V2
Real Human Interactions inside our processes
Task List Oriented User interfaces using different
technologies
etc.
38. Related Links
You can find more information, examples, tutorials and
more in:
Salaboy Blog
http://salaboy.wordpress.com
Esteban Blog
http://ilesteban.wordpress.com
Plug Tree Blog
http://www.plugtree.com