Skip to content

Concept

Jump to bottom
tomolimo edited this page May 9, 2017 · 14 revisions

You'll find a good documentation about ProcessMaker Server: http://wiki.processmaker.com/index.php/ProcessMakerDocumentation3_0 And to be read before using PM plugin: http://wiki.processmaker.com/index.php/ProcessMakerDocumentation3_0#qt-test_quicktabs-ui-tabs2

Basics between PM and GLPI

  1. Process: is the definition of a business workflow (=BPMN, see: Business Process Model and Notation.
  2. Case: is an instance of a Process. This instance is mapped to a GLPI ticket. That's the role of the PM plugin.
  3. Tasks: these are the process tasks. these are mapped to ticket tasks (one to one). Consequently, the notifications are the one of the ticket tasks, and as these tasks are scheduled, they will appear on the people planning. One task can be assigned to a person or to a group. When assigned to a group, the task is 'to be claimed'(= someone should claim for it to be assigned to it before executing it). See tasks
  4. Dynaforms: these are the forms used in PM server. See dynaforms
  5. Case variables: these are the variables used in a case. These variables can be read/write by the PM plugin. See case variables
  6. GLPI is the pilot (or the driver, or the master) of the processes. In current plugin state, the ProcessMaker server scheduled tasks can't be used in the processes.
  7. PM server is then a slave: the 'cases' can't evolve by themselves. Only users assigned to a PM task can run a case and make it evolve in a ticket.
  8. Up to now, the plugin can't manage sub-processes. I'm looking at this feature, as it would be a great idea in order to simplify complex processes.
  9. GLPI groups and users are mapped into PM groups and users.
  10. To insure security and confidentiality, passwords of users mapped into PM are not known and are randomly generated by the plugin. This to prevent that one person will approve something that should be approved by someone else.
  11. When a case is started (=created) in a ticket, some ticket information are sent to the case. these are in fact case variables.
  12. When a case is derived (goes from one task to another), some case variables are read by the plugin and are used to perform some actions on the ticket tasks (the one that just finished and the one that just started).
  13. Notificatons are managed by the task notifications in GLPI, then no notifications are managed by the plugin.
  14. Process Design the wiki si very good to: http://wiki.processmaker.com/3.0/Processes

Workflow execution

Case => is an running instance of a process. A case is embedded into a Ticket and viewed in a dedicated Ticket tab (called 'Process - Case'). One and only one case can be linked to a ticket.

  • A new case (for an activated process) can be started at any time for a ticket.
  • At creation, status of the newly created case is 'DRAFT': when in this status, a case can be deleted by anybody.
  • Running status of a case is 'TO_DO': in this status, a case can only be 'CANCELLED' (or 'COMPLETED' when finished), or deleted if the GLPI user is assigned to current task and the profile has been authorized to delete cases.
  • Completed (= finished) case status is 'COMPLETED'

Task => Tasks from a running cases are mapped to Ticket Tasks. They are dynamically added to the Ticket during the running of the case.

  • When a new PM task is activated (or routed), then a new task is created in the ticket. Assigned technician to the Ticket Task is set accordingly to the assignee in PM process definition (or group).
  • When a PM task is finished, then the mapped ticket task is set as done. start and end date are set accordingly.
  • When a PM task is re-assigned, then the Ticket Task is re-assigned to the new technician.
  • When a task is 'to be claimed' (= it has been assigned to a group) then as soon as someone in this group claims the task, it is assigned to this user.
  • If GLPI notifications are enabled for Ticket Tasks, then notifications for Task Events are going to be sent.
Clone this wiki locally