Process definitions can be seen as types of processes handled by ProcMan. Every process in ProcMan must be started as an instance of a process definition. A process definition contains settings necessary for the life cycle of processes using it, like user parameters which have to be specified when starting a process, definition of activities, dependencies among the activities, etc.
Each process definition must use a global definition. Settings stored in a global definition are shared by all process definitions using it, which means that they take effect in all processes of all process definitions using the global definition. Settings special for a kind of processes are stored in the process definition, which means that they take effect only for processes using the process definition.
By clicking on the Process definitions menu item the process definitions administration dialog is being started.
After the dialog has been started, the list of already defined process definitions is displayed (see picture below). If there are no process definitions defined a message informing about this fact is displayed instead.
This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the process definition forms for new and edited process definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.
A new process definition can be defined by clicking the New button in the process definitions list form. After that a form with the process definition fields appears (see picture below).
After filling the fields in this form and clicking the OK button the new process definition is created and appears in the process definitions list. By clicking the Cancel button the dialog returns to the process definitions list without creating a new process definition.
In the field Client the client in which the process definition will be created has to be selected.
In the field Global definition the global definition used by the process definition has to be selected.
The field Name has to be filled with the name of the new process definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.
The field Description can be filled with a textual description of the new process definition. It is a free text, which can contain any printable characters. It also can be left empty.
In the field Role of process creator the role has to be selected, which a user must have assigned, to be able to create processes of this process definition.
In the field Role with permission to read reports a role can be selected, which allows users having this role, to access the process reports of processes of this process definition, even if they are not permitted to change anything in the processes and/or their activities.
The check-box Allow creation of new processes specifies whether new process instances of this process definition can be created. If it is unchecked, users still can proceed with they work in existing processes of this definition in the work list (submit, interrupt, reject, complete, etc. activities of the processes), but no new processes of this definition can be created.
The check-box Enabled specifies whether the process definition can be used in ProcMan or not. If a process definition is not enabled it behaves like if it would not be defined at all.
Further fields are organized in sections. Each section can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the section title.
Process definition specific process parameters
In this section process parameters can be defined for all processes using this process definition. The values of these parameters can be filled by users in the dialog for process creation, in dialogs of process activities or evaluated and set by the process activities without user interaction. In opposite to parameters defined in the global definitions parameters defined in process definitions are not displayed in the work list.
Moreover based on the parameter definitions in this section the process creation dialog is generated for processes using this process definition. The generated dialog provides users with entry fields for setting values of the process parameters. The look of these entry fields has also to be defined here.
The fields of this section can be edited when the section is open (see picture below).
The structure of this section is similar to the structure of the section Global definition specific process parameters in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Global definition specific process parameters for more information.
If the check-box in the field Include process parameters from the global definition is checked (which is the default), the parameters defined in the global definition used by this process definition are used for the generation of the process creation dialog. In this case the global definition parameters are also displayed in the table of parameters in this section. If the check-box is not checked the global definition parameters are ignored when the process creation dialog is generated and they are not displayed in the table of parameters in this section.
In the rows for the general and global definition parameters in the parameters table there is a Change or a Global button at the end of each row. By clicking the Change button the button description changes to Global and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become active. This allows changing the behavior and the look of the parameter fields in generated dialogs, inherited from the global definition, for processes of this process definition. By clicking a Global button the button description changes to Change and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become read-only. In this case the changes (if any) done in the process definition for the parameter are ignored and the behavior and the look of the parameter fields in generated dialogs inherited from the global definition will be used.
Attachment of files
In this section can be specified whether external files (e.g. pdf, doc, ppt, etc.) can be attached to processes using this process definition.
The fields of this section can be edited when the section is open (see picture below).
If the check-box in the field Get the attachment settings from the global definition is checked it depends on the settings in the global definition whether it will be allowed to attach external files to processes using this process definition or not (for the global definition this property is set in the Attachment of files section in the Global definitions administration dialog). If the check-box is checked the check-box in the field Allow attachment of files is read-only and depending on what is set in the global definition it is checked or not. Otherwise the setting inherited from the global definition can be changed in this process definition.
If the check-box in the field Allow attachment of files is checked it will be allowed to attach external files to processes using this process definition.
Status of activities
In this section can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).
The definitions done in this section are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) mappings of control codes to activity statuses here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.
The fields of this section can be edited when the section is open (see picture below).
The structure of this section is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is that the settings inherited from the global definition are displayd here in read-only modus for information. Please refer to the description of Status of activities of global definitions for more information.
Sending of messages
In this section can be specified in which cases e-mail messages shall be sent to which users. Sending of messages in two situations can be defined here: when the status of a process of this process definition has been changed and when the status of an activity of a process of this process definition has been changed.
The definitions done in this section for sending messages when the status of activities has been changed are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) message sending rules here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.
Beware that e-mails can be sent only if an SMTP server has been configured after the ProcMan installation (please refer to the ProcMan installation and customize guide for more information). Moreover e-mails can only be sent to users which have an e-mail address specified in their accounts.
The fields of this section can be edited when the section is open (see picture below).
The structure of this section is similar to the structure of the section Sending of messages in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Sending of messages of global definitions for more information.
The tables with message sending definitions for both parts: when processes change their status and when activities change their status contain message sending definitions inherited from the global definition displayed as readonly rows.
If the check-box in the field Include message sending from the global definition is checked, the message sending definitions for messages sent when processes change their status are inherited from the global definition and displayed in the table as readonly rows. If the check-box is not checked the message definitions from the global definition are neither inherited nor displayed. Beware that the checking or not of this check-box has no effect on the definitions of messages sent when activities change their status which are always inherited from the global definition.
Process Activities
In this section the activities of the process definition, the dependencies among them and other settings relevant to process activities has to be defined. An activity is associated with exactly one action which is executed when the activity is started from the work list. The ProcMan controls whether an activity can be started depending on fulfillment of its preconditions. Moreover ProcMan manages who is authorized to start an activity dependent on the role associated with it.
The fields of this section can be edited when the section is open (see picture below).
The activitiy definitions are displayed as a table where each row represents one activity. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity. The name can be eight characters long and can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase. The activity id must be unique in the scope of one process definition but the same ids can be used in different process definitions.
If the check-box in the field OR Precondition is checked this activity becomes active (status Ready) if at least in one of the dependencies between the predecessor activities and this activity the dependency condition is fulfilled. If the check-box is not checked in all the dependencies between the predecessor activities and this activity the dependency conditions must be fulfilled before this activity becomes active.
If the check-box in the field Start Activity is checked the activity of a process becomes the status Ready and can be started immediately after the process has been created.
If the check-box in the field End Activity is checked the activity will be an end activity. A process becomes the status Complete only if all the end activities of the process have the status Complete.
In the field Role the role which is authorized to start this activity can be selected. If a role is selected here then this role is authorized to start the activity. If it is empty the role specified in the action definition of the action selected in the Action Id field is authorized to start the activity.
In the field Action Id the action has to be selected which shall be executed by the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.
In the field Report Action Id the action has to be selected which shall be executed when the report function of the work list is called for the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.
If the check-box in the field Include status setting from the global definition is checked the settings done in the Status of activities section of the global definition are used for this activity. Otherwise they are not used.
If the check-box in the field Include status setting from the process definition is checked the settings done in the Status of activities section of the process definition are used for this activity. Otherwise they are not used.
If the check-box in the field Include message sending from the global definition is checked the settings done in the Sending of messages section of the global definition are used for this activity. Otherwise they are not used.
If the check-box in the field Include message sending from the process definition is checked the settings done in the Sending of messages section of the process definition are used for this activity. Otherwise they are not used.
Further fields are organized in subsections. Each subsection can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the subsection title.
Autocomplete of activities
In this subsection can be specified, that some activities can be completed automatically, without calling the associated action.
The fields of this subsection can be edited when the subsection is open (see picture below).
The autocomplete entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity which shall be autocompleted.
The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autocompleted, otherwise it is handled as a manual activity and must be started from the work list by a user with the appropriate role. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).
The field Control Code has to be filled with the control code which shall be set when the condition is fulfilled and the activity is being autocompleted. In this case the status of the activity is set depending on the Status of activities settings set in the global definition, process definition and/or activities of the process definition.
In the case on the screenshot above the activity TEST is being autocompleted, if the value of the process parameter TICKET.AC is '1', otherwise it is a manual activity. The value of the process parameter can be set in the process creation dialog and/or in the activity DEV.
There can be specified more entries for one activity in this section. In this case the first entry for which the condition is fulfilled is used for setting the control code and status of the activity when the autocomplete expressions are evaluated.
Autoexecute of activities
In this subsection can be specified, that the actions of some activities can be executed automatically, without a need to manually submitting them from the work list.
The fields of this subsection can be edited when the subsection is open (see picture below).
The autoexecute entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity which shall be autoexecuted.
The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready or Interrupted or Recalled. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autoexecuted, otherwise it is waiting for the fulfillment of the condition, without changing its status. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).
Activities defined in this way can however be submitted also manually from the work list. A special dialog appears in this case. It allows a manual emergency execution or rejection of the automatic action.
Beware, that the actions of such activities can only be autoexecuted, when the Automaton background process (service) is running and properly configured for the autoexecution.
Beware, that not any defined action can be specified in process activities for autoexecutions. The command called by the action must be implemented and configured in a way, so that it supports the autoexecution.
Status of activities
In this subsection can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).
If there has been specified for an activity that the status settings from the global and/or process definition are to be included, the settings done in the Status of activities section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the action called by the activity can return also control codes not specified in the global and/or process definition or if a different activity status shall be set for a control code than specified in the global and/or process definition a new specification must be done here. If no status settings are included from the global and/or process definition for an activity, mapping of all possible control codes returned by the action called by the activity to the activity statuses has to be done here.
The fields of this subsection can be edited when the subsection is open (see picture below).
The structure of this subsection is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Status of activities of global definitions for more information.
Dependencies
In this subsection dependencies for defined activities can be created. A dependency is a relation between two activities where one of them is a predecessor and the other is a successor. There is a condition assigned to each dependency. After the action started by the predecessor activity ends, the control code returned by the action is checked against the condition of the dependency. If the control code matches the condition, the dependency is fulfilled. If all dependencies (for OR preconditions at least one of the dependencies) between predecessor activities and a successor activity are fulfilled, the precondition of the successor activity is fulfilled and the successor activity becomes active (status Ready).
There can also be defined special GOTO dependencies among activities in ProcMan. Such dependencies are ignored in the precondition check of successor activities. If a GOTO dependency is defined between a predecessor and a successor activity and the action started by the predecessor activity returned a control code matching the condition of the dependency, no precondition check takes place for the successor activity and the successor activity becomes active (status Ready).
The fields of this subsection can be edited when the subsection is open (see picture below).
The dependencies are displayed as a table where each row represents one dependency. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity which shall be the predecessor of the dependency.
The field Successor Activity Id has to be filled with the name of the activity which shall be the successor of the dependency.
If the check-box in the field GOTO (no precondition check) is checked the dependency is set to be a GOTO dependency (described above).
In the field Condition the operator has to be selected which shall be applied to compare the control code returned by an action started by the predecessor activity with the parameters of the condition.
In the fields Condition Parameter 1 and Condition Parameter 2 the parameters of the condition operator has to be specified. Two parameters are used only for operators testing whether the control code returned by an action is within or without a range. By other operators the second parameter is ignored. By the operators Anyway and Otherwise also the first parameter is ignored. If the operator Anyway is set, any control code matches the dependency condition and the dependency becomes always fulfilled. If the operator Otherwise is set, no control code matches the dependency condition and the dependency never becomes fulfilled, which makes sense in some cases when for the successor activity the OR precondition is set. Beware that the parameters are handled as integers only if the value of the control code as well as the values of the parameters contain only digits. Otherwise they are handled as strings.
Sending of messages
In this section can be specified to which users e-mail messages shall be sent when the status of the activities has been changed.
If there has been specified for an activity that the message sending from the global and/or process definition are to be included, the settings done in the Sending of messages section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the messages in situations not specified in the global and/or process definition or if massages shall be send to different users than specified in the global and/or process definition, a new specification must be done here. If no message sending specifications are included from the global and/or process definition all the message sending definitions for the activity have to be done here.
The fields of this subsection can be edited when the subsection is open (see picture below).
In the part Messages sent to users when processes change their status activities can be specified, to the last update users of which shall a message be sent, when the process changes its status. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.
The structure of the first table of the part Messages sent to users when process activitys change their status is similar to the structure of the section Sending of messages in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Sending of messages of global definitions for more information.
In the second table of the part Messages sent to users when process activities change their status activities cab be specified, to the last update users of which shall a message be sent, when process activities change their status. Activity Id has to be set to the activity name of activity, of which status change shall cause the sending of a message. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.
Activity Recall Conditions
In this subsection can be specified from which status an activity can be recalled, eventually dependent on the status of successor activities and who can recall the activity.
The fields of this subsection can be edited when the subsection is open (see picture below).
The recall conditions are displayed as a table where each row represents one recall condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity for which the recall condition in the row is specified.
In the field When Status the satus has to be selected from which the activity can be recalled.
The field Successor Activitiy Id can be filled with the name of the successor activity. If no successor is specified the recall of the activity from the specified status can be done independent on the status of successors.
The field When Successor Status the status of the successor specified in Successor Activity Id can be selected. If the successor activity and its status are specified, the activity can be recalled from the specified status only if the successor has the specified successor status. There can be more rows in the table which differ only in the status of the successor status. In this case the recall of the activity is possible if the recall condition in one of the rows is fulfilled. If the activty has more successors, conditions for all the acceptable statuses of all successors for the recall of the activity has to be defined here. In this case for each successor is checked whether there is a corresponding condition specified here to allow the recall of the activity.
If the check-box in the field Admin is authorized is checked the administrator is allowed to recall the activity if the condition specified in this row is fulfilled.
If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to recall the activity if the condition specified in this row is fulfilled.
If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to recall the activity if the condition specified in this row is fulfilled.
If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to recall the activity if the condition specified in this row is fulfilled.
Process delete conditions
In this subsection can be specified for all activities which status they can have to be allowed to delete the process. When a process is deleted, there is checked whether for all activities of the process a delete condition is fulfilled. It is enough that for one activity no delete condition is fulfilled to refuse the deletion of the process.
The fields of this subsection can be edited when the subsection is open (see picture below).
The process delete conditions are displayed as a table where each row represents one delete condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.
The field Activity Id has to be filled with the name of the activity for which the process delete condition in the row is specified.
In the field When Status the satus has to be selected in which the activity can be to allow the deletion of the process.
If the check-box in the field Admin is authorized is checked the administrator is allowed to delete the process if the condition specified in this row is fulfilled.
If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to delete the process if the condition specified in this row is fulfilled.
If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to delete the process if the condition specified in this row is fulfilled.
If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to delete the process if the condition specified in this row is fulfilled.
The field How many Days after the last update date can be specified how many days after the last change in this activity has been done and the condition specified in this row is fulfilled the process can be deleted. Here a positive integer value must be filled in.
Process cleanup action
In this section a cleanup action can be selected, which is called when a process of this process definition is being deleted. The cleanup action can for example remove all entries in the database associated with the deleted process, delete all temporary files used by the process, etc. If there is no cleanup action selected, no action is being called when a process of this process definition is being deleted.
The fields of this subsection can be edited when the subsection is open (see picture below).
In the field Cleanup Action the action which shall be called when a process of this process definition is being deleted can be selected. The selection can be done from a list of defined actions which is displayed by clicking the question mark (?) button right to the field for displaying the name of the selected action. By clicking the Clear button the selection is cleard.
Documentation
When a user is creating a process of this process definition, editing it, working in an activity of it or viewing the report for it he can open the process documentation by clicking the documentation icon in the top of the ProcMan window (see picture below). In this case the process documentation is generated from the entries done in the documentation section of the global definition and from the entries done in this section.
The process documentation is organized in chapters which can contain a multiline plain text, but no objects like pictures, tables, etc.
The fields of this section can be edited when the section is open (see picture below).
The structure of this section is similar to the structure of the section Documentation in the Global definitions administration dialog. The only difference is that the documentation inherited from the global definition is displayed here in read-only modus for information. Please refer to the description of Documentation of global definitions for more information.
A process definition can be edited by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the process definitions list form. Alternatively a process definition can be edited also by clicking on the name in the table of the process definitions list form. After that a form with the process definition fields appears. This form is the same like the form for a new process definition except, that the fields Client and Global Definition are read-only and cannot be changed.
If there are already processes using the edited process definition in ProcMan, the activities and/or activity dependencies has been changed and the changes has been submitted, the original process definition is renamed (the new name is set to be the original name with the current timestamp suffix) and disabled and the changed definition is saved as a new process definition. This is because the existing processes are using the activity specification of the original process definition and would not work with the activity specification changed by editing the process definition.
An existing process definition can be used as a base for a new one by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the process definitions list form. After that the form for a new process definition prefilled with the settings from the selected process definition appears. Beware that at least the process definition name must be changed before the new process definition can be created.
One or more process definitions can be deleted by selecting them in the process definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the process definitions list form. Beware that only process definitions which are not in use by existing processes can be deleted. An alternative to the deleting of a process definition is to disable it.
Select one or more process definitions from the process definitions list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the process definitions list form. After the selected process definitions have been added into the Transfer Case you can add another process definitions or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.
