ActivityDiagrams

An important expect of today's enterprise applications and SOA is the externalization of business processes. This allows businesses and their applications to adapt more rapidly as the business environment changes.

To facilitate this Taylor uses UML Activity Diagrams to model business processes. In the current release Taylor Bpm code is generated. Of course, just like everything else, you could generate other business process languages from activity diagrams as well.

Contents 1 Taylor BPM 2 Modeling 2.1 Invoke Nodes 2.2 Task Nodes 2.3 Other Nodes 2.4 Transition Expressions 3 User Interface 4 Related Topics 5 TODO

Taylor BPM

• Taylor BPM is based on JDJ article AOP-Enabled ESB.
• Taylor Bpm Site
• Example Code Old 1.2.0

Modeling

There will typically be one activity diagram per business use case to define the business process.

1. Start by creating a package called 'net.taylor.tutorial.process'.
2. Then right-click on the package to create an Activity and name it 'TicketReviewProcess'.
3. Then right-click on the activity and select New Activity Diagram and save it to the model directory.
4. Next drag Start and End nodes from the palette to the canvas and name them Start and End.
5. Drag an Invoke node from the palette to the canvas and name it Submit
6. Then click on Transition in the palette and then click on the Start node and hold down the left mouse button and move the cursor over the Submit node and release the mouse button. Do not give it a name.
7. Drag a Task node to the canvas and name it Review
8. Create a transition from Submit to Review
9. Drag another Invoke node to the canvas and call it Approve
10. Create a transition from Review to Approve, but this time give it a name 'approved'
11. Create a transition from Approve to End without a name
12. Right click on the canvas and select Arrange All
13. Add the remaining nodes to the diagram so that it looks like the diagram below

Invoke Nodes

• Invoke nodes make calls to operation on services

1. Click on the Submit action in the navigator and go to the General property tab
2. Click on the Operation ... button
3. Type submit in the dialog and then select the TicketService.submit() operation
4. Do the same for the Approve and Reject actions

Task Nodes

• Task nodes represent human interaction steps. They can be assigned to an individual user or a role. Roles are model using Actors. At runtime roles are mapped to groups using JAAS.

1. Create a package under net.taylor.tutorial.process called actors
2. Right click on the package and add two Actors with names User and Admin. These will probably already be available if you have done use case modeling.
3. Click on the Review task in the navigator and go to the Stereotype Attributes property tab
   1. Go to Role and select the Admin actor from the list. This means the task will be assigned to anyone with the Admin role.
   2. Set Priority to NORMAL
   3. Set DueDateUnit to Days and DueDateAmount to 1. This means the task is due within one day.
   4. Set Description to the expression: Review: #{ticket.title}
4. Click on the Correct task in the navigator and go to the Stereotype Attributes property tab
   1. Set Description to the expression: Rejected: #{ticket.title}
   2. Set UserId to the expression: #{ticket.submitter}
   3. Set ViewId to the expression: /jsf/Ticket/View.xhtml

Other Nodes

• Forks and Joins provide for concurrent processing
  • They must be used in conjunction
  • They are only necessary if you want the paths to join before proceeding
  • If no join is necessary then multiple paths can be taken from any node without a fork

• Timers represent an EJB Timer which will fire an event when the time period has elapsed to transition to the next step

Transition Expressions

Transitions can have guard conditions which control when the path is followed. Guard conditions are defined with Java Expression Language.

1. Select a transition in the navigator
2. Go to the General properties tab
3. Enter a guard expression (ex. #{ticket.type == 'Bug'})

NOTE: The pound and brackets (#{}) are optional and will be generated if excluded.

NOTE: Task transitions are different. Their condition is implicit in the action taken by the user who completes the task. The name of the transition represents the outcome selected by the user.

User Interface

The Work List view is automatically added to your application.

It displays tasks based on user and role.

The TaskManager role can see all Tasks and edit them.

Related Topics

• Taylor Bpm
• WS Addressing
• Asynchronous Client Process
• Reliable Messaging
• Endpoint Address Discovery
• Batch Processing

TODO

• new 1.3.0 example & screen shots