Tuesday, December 02, 2008

Lombardi Notes 01dec2008

Notes from dec 1 and 2, 2008

Lombardi Teamworks Suite, Business modeling

Class based off chapter 9 of the doc at www.bpmn.org


BPMN (business process modeling notation) www.bpmn.org

BPD (business process definition)

Day 1

Focus on process modeling.  Teamworks uses eclipse to design process models.

BPMN Flow Objects

- Events (start event, end event, intermediate events)

- Activities (tasks and processes)

- Gateways (decision, conditional, etc)

- flows (transitions from one thing to another)

- Pools and Lanes (allows roles to access activities - a security/access model)

Version Control

no built in version control until lombardi version 7

All "assets" can be exported as XML to be added to external source control


Gateways are questions.

Gateways are made on outgoing sequence flow lines. 

The order of the lines in the decision gateway is the order in which they will be evaluated.  Very important for XOR gateways.

Gateway Split Types:

- Simple Split = parallel processing.  Breaks a single process token into multiple process tokens, which continue down the path to complete their part of the workflow

- conditional (inclusive) = parallel processing. Breaks a single process into one or more other processes depending on conditions. must have a default line. All conditions matched are executed.

- decision (XOR) = only one condition is matched, looking at lines from top to bottom, only the first match runs.  else, it runs default process.

Gateway Joins:

    - simple join = waits for all process tokens to return from all lines connected.

    - Conditional (smart) join = waits for all potential splits to return.  Looks upstream to determine the proper amount of tokens to return.

TeamWorks Scripting

- All scripting via JavaScript

- lombardi uses server side AND client side javascript (server side via rhino)

- all coding done via OOP style javascript (Everything is an object, and must be called by its full namespace name)


- Can only be created in a process or a service

- organize data in groups via structures

- all variables must be referenced by its namespace.  in teamworks, the default namespace is tw.local (for process or service) or tw.system.

- variables must be scoped and typed

- passing variables works like calling functions.  You must declaire input and output variables, and they must have the same type.

- as a convention, name/mark variables as input and output as needed.

- BP Variable types should be upper camel case.  Variables within a type should be lower camel case.


Day 2

Morning challenge:

Create a BPD that determines the correct route to take based on weather/time criteria using only activities and decision gateways.

- as a BP, each activity should have its own service.  they should be named the same, if possible
- services run "coaches" which accept user input
- services go into their own folder.  For now, we are putting the services folder into the process folder.

Here, we've create a service and added a single coach

Here, we've started working on the coach.  Be sure to open the "Outline" view.  From there, you can drag variables you've defined in your service into your coach to create a form.

You can drag variables one by one, or you can drag the entire complex datatype onto the form and it will create fields for all variables in the type for you. (as shown in the buttons section below)

-Buttons only ever execute a form "post" method.
-You can only ever drag a button group from the palette into the form.  From the button group, you define specific buttons in the properties window, the presentation tab.
-Buttons are accessed late in javascript via the name "<button_group_id>_<button_id>"
-To flow from one coach to another item, you must have at least one button group.  Without a button, you cannot assign an output line in diagram view.

Form Field Visibility (and other properties)

- Individual fields can be changed to be hidden, viewable, editable or required.  By default, all items are set to "editable".  In addition, you can set conditions where items can become editable, based on other values of the form changing (it generates JS to implement these features in the html rendered)

Now that we have a form and a button, we can draw a flow to and from the coach in diagram view.

Initializing a javascript object
We create a separate service just to initialize the datatype we want to use in the coach (PositionInformation in this case).  To do that, you need to create an output variable of the type you want to initialize.  The service is all custom server side script.  Within the code, all we do is add code (in the implementation tab of the custom server script object) to initialize the datatype in the format "<variablename> = new <datatype>;"

With that new init service defined, we can add that to the "coach service".  Drop in a "nested service" into the coach service.  Make sure that fires off before the coach.  View the properties of the nested service, implementation tab, then assign the init service you created earlier.  You'll end up with something similar to below.

now draw a flow line from the init service to the coach.  Select the init service again, view properties and then the mapping tab. From there, you want to map the output of the init service to the output of the coach service.  Now the variable is initialized before the coach starts.  you can then customize the init script to pre-set variables (from a database perhaps) before the coach loads.

Implement Coach in Process (BPD)

open the BPD and select the task you want to assign the coach to (In my case, "Submit Request") and view its properties, implementation tab.
Assign a "Teamworks Service" and select the coach service we created previously.  After that, we have to map variables, mapping the positionInformation output variable from the coach service to the private variable in the process.

At this point, we set the next step to use the same service, without doing variable mapping (apprently we need that to do the step through the process).  Then we can run the process and do some debugging:

Here's where it gets tricky.
1) Select the process window (the BPD)
2) Click "Run service" at the top toolbar. This kicks off a new token, that process token now lands at the first task in the top right pane.
3) Selecting the new task in the top right pane, start that task by clicking run when its selected.  That should launch the "coach" in a browser (its an html form).
4) Fill out the the form and click submit, when the browser closes (the coach ends) you need to refresh the process in the IDE by clicking on that refrech button in the top toolbar. It should show the token has moved from your first activity to the next one.  You can then inspect task variables in the execution state pane.  Double clicking on the variable will display its xml value.
Implement Coach in Process (BPD) with gateways

Business rules: Between department and job level there are rules

it employee = 5000
it managers = 6000
all others = 8000
executive = 20000

HowTo Enable Advanced Editor


Unknown said...

can we force invoke a timer to fire?

Bryan said...

Tejo - For processes in play, I dont know of a way to force a Timer Event to fire manually instead of waiting for its predefined schedule.

You can try looking at the teamworks API. They may expose some functionality there that might help you.

Unknown said...

he he he,
This is my case, You might be able to imagine why i need this,

I split a process into two , one goes to a intermediate message event, waiting for external action, the other goes to a timer event, check if the waiting time is expired, i want the timer purged if the external action invoke the intermediate message event

Bryan said...

That makes sense Tejo...but I still dont know how to purge a timer event in a running process instance. Sorry.

I've done something similar in one of my projects, splitting a process in two (only running the 2nd process after x number of days have passes from the 1st process end date) but instead of having a timer event in the the 1st process, I used a UCA (undercover agent) to act as the timer. I have the UCA scheduled to fire off every day and the service its attached to checks my process data (in a custom database) to determine if any #1 processes are completed and ready to spawn a #2 process. I then spawn processes as needed from the UCA service. This gives you a little more control because you could fire off your #2 process using an intermediate message event completely independent of the UCA, then you could manually go into the process data or the UCA service itself and make changes so that that specific process instances will never fire.

Probably not the answer you were looking for, but I hope its helpful anyway :D

Unknown said...

Bryan, i got the point, but i haven't try it yet, i hope that will be the answer, Btw, can i Have your private contact, i think there will be couple thing that i want to share with you, he he ,.

Btw, i heard that we can delete a lombardi project using kind of SQL script from lombardi backend database, since, we know, we can't delete a project from lombardi designer, the only thing we can do is archive it, but sometime i do really need to get rid of unused project form wle. have you heard this issue ?

Bryan said...

Tejo - You can shoot me an email directly using the link in my blogger profile.

That issue with deleting an entire project sounds familiar ... I know I've hit it before in my development environment, but I dont remember exactly what the error message was. I -think- I deleted all the process data, then deleted/removed all the services from the BPD in order to delete the process ... but I'm pretty sure I didnt go directly into the database to fix it.

I dont know if that helps you at all ... but if this is something in production, I avoid deleting a process or its instance data. I prefer to keep as much data available as I can and just do something like move old unused projects into an "Archive" folder in the AE or something.

Anyway, shoot me an email and we can talk about it in more detail offline if you want :)