Lombardi Traning Notes 04dec2008

Lombardi training day 4


Creating Roles/Groups

Group Types
- Participant groups - participant groups are assigned to lanes and also tasks to determine who has access to what.
- lombardi groups - a group of users that can then be implemented in a participant group.  This seems to be the pure lombardi way of handling groups, if you dont have AD or LDAP
- logical roles - groups AD/LDAP groups and users into one logical role that you can then assign to a participant group for assignment to a lane or activity (routing)

Teamworks admin default url (http://<host>:8081/)

logical role admin:

lombardi group admin:

- You can then assign users to the lombardi group by retrieving user profiles.  You can not assign AD groups to a lombardi group.

Participant Groups (PG)
- Participant groups are set in the library (in the teamworks eclipse client)
- In your project, you can right click on a folder and create a new participant group.  Participant groups are then assigned to lanes to allow access to activities in a process.  You can also change the routing assignments to participant groups as well, which gives you a way to override the default lane role assignment. You can assign only one group to a participant group, or you can assign multiple users instead.  you cant mix and match groups and users within a participant group. (Need more info on assigning my expression)
- Logical groups are setup in the lombardi administrator (?) or in AD.  You can then set that one group of groups/users to a participant group.

Once your PG is created, you can then assign it to one or more lanes/tasks in a process.




System Lane
- A system lane must be assigned to the system group (OOtB lombardi group)
- the "is system lane" checkbox must be checked to indicate this is a system lane
- you cant put a coach in a system lane, because the system lane does not allow user intervention.
- all gateways are "system" items by default, they do not need to be put in this lane.

Routing
- determines who the task is assigned to
- who has access to a task
- routing is assigned by the lane PG, or by the routing assignment on the task (the task overrides the lane)

Timer Events
- only available in a process pallet.
- you can indicate where the timer will run.
- implementation
    - stand alone after start of step - means it will hold the process token the specified amount of time, then  picks up again after the timer is done.
    - attached to an activity (drag and drop onto an activity) after start of step - when an activity starts, monitors the time it takes to complete an event.  If the timer reach
- the after start of step starts as soon as a process token hits the activity or timer, that is the start.  Not when the user starts working on the request (user start time is called run time in lombardi.  The token reaching the step is the start of the step in lombardi).
- tolerance level - if the timer runs out, and a tolerance level is set, the timer will then look back and see if the token has changed within the tolerance level.  If the tolerance is set to 30 minutes, the timer will check to see if the user made a change in the database via a coach (or somehow changed the status of the token), within that 30 minute interval.  If it finds a change, it then extends the timer by the tolerance interval (the user gets 30 more minutes to complete the task).
- Close attached activity - closes the task by killing the old process token, then creates a new process token to continue through the process diagram.  If you dont want to kill the process (just fire off a notification/reminder email, etc) uncheck this box.  If the timer is independent of a task and has its own token, be sure to kill its process be sure to kill its token properly.
- Repeatable - repeatable continues forever.  If attached to a task, it will end when the task is complete.
- you can attach multiple timers to a task
- you can set a timer to use a business calendar assigned to a task.

Business Calendars
- business calendars work well with timers because timers will only use valid business hours specified in the calendar
- the buiness calendar is assigned to a PG, which is then assigned to a lane.  A task in the lane can be set to use the calendar assigned to the lane.  The timer then picks up that business calendar if it was set to use a business calendar.


Use a timer to set a task to urgent after a given amount of time

- drag a new timer activity into the coach service we want to watch.
- create a new activity and process flow from the timer, which is embedded in the coach, to the new task. Name the new task "escalate task to urgent".  Drag in a new end event and process flow the escalate task to the end task.
- create a new private variable in the process diagram called "taskIdToEscalate" and make it a string (process id's are strings in lombardi)
- create a new service to imbed in the escalate task to urgent task, you can give it the same name.  place on "modify task" event into the service and in the implementation tab,  select "Priority" in the list, enable it and set the new priority to urgent.  Next, create an input variable in the service called "taskId", then go back to the implement tag of the modify task element and check "use other task" and specifty tw.local.taskId as the other task id.
- go back to the activity in the process diagram, and under implementation map it to the service you just created.  Map the private taskIdToEscalate to the input variable in the service.

(In the above screenshot, the "closed attached activity" should not be checked, because we dont want to kill the activity in process. the following screens show the process running with that box unchecked)

now that we have the activity and service for setting the priority, we need to pass the id of the process to escalate.  From the timer event, look at the process instance and get the process task id before the timer fires off.  To do that, go to the timer service, go to pre-post events tab, and add a new pre event.

You can see when we run the process that the process token pauses at the coach activity, then the timer attached spawns its own process token which then waits for as long as the timer is set for (in this example, only 1 minute).

After that one minute, the timer token takes off into the escalate task.  We've passed along the task id from the parent task token that started the coach service.  That id gets passed into the escalate service, which then updates that task's priority.  The token passes on to the end task and dies.  The original process token still waiting at the coach continues to sit and wait for user intervention, but now with a priority of Urgent.

Coach Buttons

- you can specify isCancel on a button to specify that its not ending the coach.  You can then flow to other tasks from that button to do other features (such as save for later, etc)
- Scripts should be placed in front of the coach to catch/test variables before they are used in the coach, then also afterward to validate both input and output data.
- The status of the process can be changed via a modify task service item connected to a button.
- a good practice is to copy incoming data into a local variable, then when a cancel button is clicked, you should test to make sure the submitted data matches the data going back out.  you may need to "reset" the variables if changes were made in the coach, since clicking the button always submits the form and saves off the bound form variables to the service (not 100% sure this true, need to test)