jBPM5 Community Training
    Sponsored by Plugtree
Module 5: jBPM5 Domain
  Specific Processes
    jBPM5 Community Training
      version: 1.0-SNAPSHOT
     Release Date: 03/01/2011
Under The Creative Common License
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/.
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
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
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
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
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
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
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
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
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
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);
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
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).
Synchronous WorkItemHandler


Synchronous Work Item Handler
   Executes the task
   When it's finished, it can complete or abort the Work
   Item using the Work Item Manager methods
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
Asynchronous & Synchronous Interactions
Synchronous External Interactions
Asynchronous External Interactions
Async & Sync External Interactions
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
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
Vehicle Tracking External Interaction
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
WorkItemHandler Information Mappings
Information Mappings in BPMN 2.0

<ioSpecification>
   <dataInput id="_5_vehicle.typeInput" name="vehicle.type" />
   <dataInput id="_5_vehicle.idInput" name="vehicle.id" />
   <dataOutput id="_5_trackingIdOutput" name="trackingId" />
   <dataOutput id="_5_trackingExecutionTimeOutput"
                                   name="trackingExecutionTime"
/>
   <inputSet>
      <dataInputRefs>_5_vehicle.typeInput</dataInputRefs>
      <dataInputRefs>_5_vehicle.idInput</dataInputRefs>
   </inputSet>
   <outputSet>
      <dataOutputRefs>_5_trackingIdOutput</dataOutputRefs>
      <dataOutputRefs>
              _5_trackingExecutionTimeOutput
      </dataOutputRefs>
   </outputSet>
</ioSpecification>
Information Mappings in BPMN 2.0
<dataInputAssociation>
   <targetRef>_5_vehicle.typeInput</targetRef>
   <assignment>
     <from xs:type="tFormalExpression">#{vehicle.type}</from>
     <to xs:type="tFormalExpression">_5_vehicle.typeInput</to>
   </assignment>
</dataInputAssociation>
<dataInputAssociation>
   <targetRef>_5_vehicle.idInput</targetRef>
   <assignment>
     <from xs:type="tFormalExpression">#{vehicle.id}</from>
     <to xs:type="tFormalExpression">_5_vehicle.idInput</to>
   </assignment>
</dataInputAssociation>
<dataOutputAssociation>
  <sourceRef>_5_trackingIdOutput</sourceRef>
  <targetRef>trackingId</targetRef>
</dataOutputAssociation>
<dataOutputAssociation>
  <sourceRef>_5_trackingExecutionTimeOutput</sourceRef>
  <targetRef>trackingExecutionTime</targetRef>
</dataOutputAssociation>
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
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
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
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
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.
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.
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
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
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.
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
 
              
Questions?
Enjoy! Questions and Feedback are
always appreciated!
 
                     
    Contact us at
www.plugtree.com

jBPM5 Community Training Module #5: Domain Specific Processes

  • 1.
        jBPM5 Community Training Sponsored by Plugtree
  • 2.
    Module 5: jBPM5Domain Specific Processes jBPM5 Community Training version: 1.0-SNAPSHOT Release Date: 03/01/2011 Under The Creative Common License
  • 3.
    Module 5: DomainSpecific 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 domainagnostic, 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 StandardSpecification 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 theconcept 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 WorkItems 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 relationshipwith 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 relationshipwith 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 relationshipwith 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 WorkItemand 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).
  • 16.
    Synchronous WorkItemHandler Synchronous WorkItem Handler Executes the task When it's finished, it can complete or abort the Work Item using the Work Item Manager methods
  • 17.
    Asynchronous WorkItemHandler Asynchronous WorkItem 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
  • 18.
  • 19.
  • 20.
  • 21.
    Async & SyncExternal Interactions
  • 22.
    Asynchronous WorkItemHandler Once AsynchronousWork 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
  • 24.
  • 25.
    WorkItemHandler Information Scope Processexecution 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
  • 26.
  • 27.
    Information Mappings inBPMN 2.0 <ioSpecification> <dataInput id="_5_vehicle.typeInput" name="vehicle.type" /> <dataInput id="_5_vehicle.idInput" name="vehicle.id" /> <dataOutput id="_5_trackingIdOutput" name="trackingId" /> <dataOutput id="_5_trackingExecutionTimeOutput" name="trackingExecutionTime" /> <inputSet> <dataInputRefs>_5_vehicle.typeInput</dataInputRefs> <dataInputRefs>_5_vehicle.idInput</dataInputRefs> </inputSet> <outputSet> <dataOutputRefs>_5_trackingIdOutput</dataOutputRefs> <dataOutputRefs> _5_trackingExecutionTimeOutput </dataOutputRefs> </outputSet> </ioSpecification>
  • 28.
    Information Mappings inBPMN 2.0 <dataInputAssociation> <targetRef>_5_vehicle.typeInput</targetRef> <assignment> <from xs:type="tFormalExpression">#{vehicle.type}</from> <to xs:type="tFormalExpression">_5_vehicle.typeInput</to> </assignment> </dataInputAssociation> <dataInputAssociation> <targetRef>_5_vehicle.idInput</targetRef> <assignment> <from xs:type="tFormalExpression">#{vehicle.id}</from> <to xs:type="tFormalExpression">_5_vehicle.idInput</to> </assignment> </dataInputAssociation> <dataOutputAssociation> <sourceRef>_5_trackingIdOutput</sourceRef> <targetRef>trackingId</targetRef> </dataOutputAssociation> <dataOutputAssociation> <sourceRef>_5_trackingExecutionTimeOutput</sourceRef> <targetRef>trackingExecutionTime</targetRef> </dataOutputAssociation>
  • 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 ServiceProcess 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 - EmergencyService 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 - EmergencyService 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 Adda 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 Weunderstand 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 tunedfor 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 canfind 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
  • 39.
        Questions?
  • 40.
    Enjoy! Questions andFeedback are always appreciated!
  • 41.
        Contact us at www.plugtree.com