iGrafx
iGrafx Onboarding Example
This chapter will give an introduction to modeling with iGrafx by using an onboarding example. Detailed documentation for iGrafx can be found here.
Login into iGrafx
Login to the iGrafx Platform in order to create the first process model that can be published to the system.
2. After login into iGrafx Platform, the following screen will appear:
Create a new business process diagram
In the next step, a new model must be created. This model will define the individual steps in our process. Afterward, the model can be exported as a process definition to the system. After clicking the 'ADD OBJECT' button on the upper left side corner a pop-up will appear:
2. Select 'Blank BPMN Diagram' , give the model a name and click the 'FINISH' button.
Create and edit a process models
The following example is meant to show the different possibilities to model and design processes in iGrafx in combination with the system. The scenario is a so-called “onboarding procedure” for a new employee, which is a process known to any company.
This paragraph explains the basic functions for working with process models.
Model pool and swimlanes
When starting a process model, all involved departments and/or company parts should be defined. This will be managed by so-called pools and swimlanes, also simply called lanes. A pool is a superior unit and the single lanes represent subzones, e.g. departments in the company.
Within our newly created model, we first need to check out the current version in order to start modeling. After that we chose a pool element and drag it into the empty model. In the pool we add two swimlanes.
Reference | Description |
---|---|
1 | Shows the 'Shape Libraries' with all available BPMN shapes |
2 | Pool shape |
3 | Swimlane shape |
4 | The Pool displayed in the model |
5 | 'Plus' icon adds space for additional swimlanes to be placed into the pool |
6 | Customizing the swimlane name by selecting and then clicking on its label. |
In order to rename the swimlanes, the desired element has to be selected and then clicked. Now it is possible to individualize the label. In this case the pool stands for a superior company and the lanes stand for departments in this company. On the one hand there is the Human Resources Department (“HR”) and on the other hand, there is the IT department (“IT”).
Model a start event
The start event is not placed in the diagram, so it has to be added separately. The start event can be added by clicking the corresponding symbol in the left band. The starting event (symbol) can now be placed in the diagram by clicking the desired destination.
Model an activity
For the first step in this workflow, the activity “create a personal file” should be processed. A task node has to be placed behind the start event in order to reach this goal. By selecting the task node symbol in the left band, followed by a click in the diagram, the task is added to the process model. The labeling works similar to the labeling of the swimlanes, by double-clicking. For the next step, the start event has to be connected with the task node. This connection is called a “transition”. This can be managed by clicking and holding on the starting event and then moving the mouse onto the task node.
Model an AND Gateway
With an “AND” gateway it is possible to execute multiple steps of a process instance at the same time. The and/parallel gateway waits for all tasks inside the gateway to be finished before going on. In this example there are two tasks to be done at the same time; one for the HR and one for the IT department.
Select the diamond symbol with a plus inside from the shape libraries tab and place it in the diagram. After placing it, it's type can be altered in the 'Diagramming Properties' tab. This is done by right-clicking it and choosing Diagramming Properties' tab on the left navigation bar. Now the gateway type can be changed to any option via drop down. In our example we stay with the parallel gateway. Now, two new activities can be placed into the HR and the IT lane and connected with the AND. More than two tasks may also be added at the same time.
The HR department now gets the task to “organize the desk”, meanwhile the IT department should take care of “creating a network account”.
A forking AND gateway has to be closed at the end so that the process is able to go on with the next tasks. Therefore a new AND gateway have to be added to the diagram and placed at the point where the parallel part should end.
The process flow is finished so far, but an end event has to be added in order to show where the process terminates.
Reference | Description |
---|---|
1 | Transition button |
2 | Task shape |
3 | Transition in the model connection start event and first task |
4 | Task shape in the model added to the swimlane 'HR' |
5 | AND Gateway |
6 | AND Gateway requires two or more parallel transitions to an equal number of tasks |
7 | AND/Parallel Gateway properties can be altered under 'Diagramming Properties' tab |
8 | AND/Parallel Gateway is closed with two Gateways and all transitions connected |
9 | Closing/Terminate event |
Model a XOR/Exclusive Gateway
When running through an XOR/exclusive Gateway, not all outgoing transitions are followed, in contrast to the AND gateway. A decision must be made which defines which path is followed. Only the tasks on this path are to be completed. That decision is made by the user who finishes the last task before the process enters the XOR Gateway. This can be done by a pop-up, which shows all possible decisions.
In order to extend the process, the ending event must be deleted. This happens by selecting it and pressing the delete key. The resizing of the pool happens automatically when adding an element to the right border of it.
Behind the joining AND gateway, an XOR element has to be added. To clarify what kind of decision has to be made, this XOR can be labeled like all the other elements (e.g. “Hardware necessary?”).
It is possible to label the transitions in order to clarify which way belongs to which decision. By default, one way gets labeled with “yes” and one with “no”; however, this can be customized. In this case, the way denoted 'yes' leads to the activity “Order Hardware” and the other one leads to “archive personal file”. The transition can be adapted in the properties of the XOR gateway.
Model script or mail node
The last activity of the process model can be done automatically by the system without the need for user interaction. Therefore the type of the activity has to be changed. For changing the type, right click on the activity symbol, click on the "Change shape" button.
Choose the activity type 'Script Task'. The procedure for modeling mail nodes is identical, only here is the activity type 'Send Task'.
Model an end event
Finally, we end the process by adding the end element from the shape library and connect all open transitions to the end event.
Save a process model
In order to save the business model left click on file and a drop down menu will open.
After pressing the 'Check In' button a pop-up will appear. Clicking the 'FINISH' button will commit and safe the model.
Defining and editing automation attributes
A process needs different attributes in order to be able to run. These attributes can be created or edited by clicking on an element and choosing the 'Automation Properties' tab. Different menu options are shown for the current element. The attributes that are most relevant to the system are highlighted red by the iGrafx Platform.
Attributes at start event
In the image, we see the general attributes for a process, which can be found in the properties of the start event.
Attributes | Attribute Description |
---|---|
Starter Mandatory | Here a group or a user, who is allowed to start instances of a process definition, e.g. user(john.doe), group(pm) is entered. |
Owner Mandatory | Here a group or a user who “owns” the process in the system is entered. “Owner” means that this person is responsible for the process |
Deployer Mandatory | Here a group or a user who as workflow-designer is allowed to deploy the process in the system is entered. |
Description | Description of the process, which will later be shown in the system (tooltip and process report). |
Form | Here the definition of the smart form is entered. |
Attributes at swimlanes
In addition each swimlane needs to be assigned to a user or group. The 'Automation Properties' can be altered by clicking on the swimlane header and opening the 'Automation Properties' in the 'Object Navigation'.
Attributes at activities
General configuration options
On an activity three automation properties can be added.
Reference | Attribute Name | Attribute Description |
---|---|---|
1 | Duration | Here the duration in which the tasks of this activity must be completed can be entered. |
2 | Tasks | Basically every activity must have its own unique name. If no task is explicitly defined for the activity, the system generates a task with the name of the activity. With the aid of the automation properties menu one or more tasks may be added for an activity. |
3 | Script task | Here events can be entered. Events or ActionHandler are special functions that are executed as soon as a specific process step is reached or left. |
Add processing times to an activity
The processing time can be entered in each process activity. It specifies how long the employee may need for the tasks within an activity until they have to be finished. Open the 'Automation Properties' of an activity. Enter a processing time for this activity into the field 'Target Duration'.
The format in which the duration has to be entered: HMM - like 830 = > 8 hours 30 Minutes.
Adding tasks to an activity
After this short overview of the attributes that are necessary, the example process may be continued. Basically every activity must have its own unique name. If no task is explicitly defined for the activity, the system generates a task with the name of the activity. With the aid of the automation properties menu one or more tasks may be added for an activity. Optionally, the duration of an activity may be entered. More about CPM can be found on this page: Critical Path Method (CPM). In this case, a task is added to the “Create personal file”.
First, the properties menu for this activity has to be opened. By clicking 'Add Task' new tasks can be added to the list. These are the tasks that can be delegated to specific employees, who will be responsible for completing them.
An additional window opens in which the task can be configured. At first, a name must be entered. In addition, there can be an assignment to a special group or user, which overwrites the assignment of the swimlanes. The description field is for further and more detailed information on this task, which will be shown during process execution. It is also possible to add links.
Reference | Attribute Name | Attribute Description |
---|---|---|
1 | TaskName | Name of the task. |
2 | Role Assignment | The role assignment of the activity can be overridden for this task. |
3 | Description | Further instructions for processing the task can be given here. This description will be displayed as soon as the task is generated by the system. |
4 | Links | Links can be added here, which are displayed to the user when editing the task. |
Add events to an activity
Events are special functions that can be executed as soon as a certain process step is reached or left. These events are called ActionHandler and the system supports a whole range of pre-made ones. Events can also be added to script nodes. A detailed description is given in paragraph 'Attributes at script nodes'.
Attributes at mail nodes
The mail node is a simple function to send standard emails in the system. These can be emails to external individuals and groups, as well es notifications to process participants and decision-makers. These emails can contain process information or prompt specific user to complete a task in the system. In Order to add attributes to the mail node left click on the mail node to open the automation properties.
Reference | Attribute Name | Attribute Description |
---|---|---|
1 | To | The recipients can be defined here. On the one hand, groups and user definitions (group (NAME_DER_GRUPPE) / user (NAME_DES_USERS)) can be used again. The email can also be sent to the current processor of the Swimlane "HR". In addition, fixed e-mail addresses or distribution lists can also be used here (e.g. it-asset@yourcompany.com). |
2 | Subject | The subject of the email can be freely assigned. In this example, a variable is also referenced (the name of the process run). These variables can be used in the subject or in the text and are always masked with a $ {…}. As soon as the email is sent, the variable placeholders are replaced by their actual value. Further information on the variables can be found on this page: System Variables |
3 | Body | The email text can be designed in any way. Variables can also be used. The sending of HTML email and other settings are explained on this page: Mail Nodes |
Attributes at script nodes
ActionHandlers or events are special functions that are executed as soon as a certain process step is reached or exited. There are a number of pre-made ActionHandlers. New ActionHandlers are often created for special functionalities in projects. The maintenance of ActionHandlers in the process is always the same. In this section, two events are maintained as examples.
As an example, a process run should be renamed automatically. A unique consecutive number should be generated and used. Two ActionHandlers are required:
YearIdGenerator: Generates the consecutive numbers and saves them in a process variable
RenameInstanceHandler: Uses the sequential number/process variable and builds this into the new name of the instance
The following figure illustrates this process:
This logic is now built into the process. First, you have to decide on which process step such an event should be carried out. For this example, of course, it only makes sense to rename it at the very beginning. For this, we use the first activity "Fill Information" and set up the ActionHandlers on "Node Enter". This means that the name of the instance is displayed correctly from the very first task.
First, the activity must be selected and the automation properties opened. The first thing to add in the popup is a new event (see figure).
The ActionHandler must now be parameterized in the next view. The basic settings for an event can always be found on the associated documentation page (YearIDGenerator). The picture shows the parameterization for this example. The event generates a consecutive number and saves it in a variable called "newNumber". The number can then be addressed in the second ActionHandler using this name.
Reference | Attribute Name | Attribute Description |
---|---|---|
1 | Name | Can be chosen freely. Serves for a better overview of the list of events. |
2 | Event Type | Specifies whether the ActionHandler should be executed when the activity is reached (input node) or when it exits (output node). |
3 | Event Class | Defines which ActionHandler is to be executed. It can be copied from the wiki page. |
4 | Mandatory Fields | Depending on the ActionHandler, either "Mandatory fields" or "Parameters" must be passed. The description can be found on the respective page of the ActionHandler. You only have to enter something in "mandatory fields". |
5 | Parameter | The generated ID can be called on using the variable |
6 | Save Event | Saves the attributes to the script node of the process model. |
After saving, the initial view opens again and a new event can be created. Now a new event must be created (RenameInstanceHandler). However, parameters are required for these. To do this, click the "Add Parameter" button in the automation properties.
According to the documentation, only one parameter has to be added to this handler (instanceName). The value of the parameter can be used to specify how the name of the new instance should be composed. Static values can be entered or values from variables. To access such variables, the mask "$ {... ..}" must be used. In this case, we want to access the previously created process variable "newNumber".
After saving the parameters and the event, the following list should appear with the two ActionHandlers. The order of the ActionHandlers plays an important role. They are executed from top to bottom.
This order is important when ActionHandlers, as in our example, build on each other.
Deployment Check
Before publishing a process it is possible to do a deployment check. This check shows if all settings are inserted and if the process was able to run as currently configured. The deployment check can be accessed under 'Automation' in the file menu.
There are two possible ways this check can end:
There is an error. This will be displayed in the output area of iGrafx.
There are no errors. Consequently, a positive message will show up, which implies that the process is ready to be deployed.
Deployment to the system
The publishing (deployment) of the process to the system can be realized by choosing the option 'Deploy Model' from 'Automation' under the menu 'File'. For this, the user needs the role of workflow-designer in the the system to be able to publish the model.
After entering the URL, username and the password the process can be published by clicking 'DEPLOY MODEL'. In the output window, a message about the success of the deployment will be shown.
© TIM Solutions GmbH | AGB | Datenschutz | Impressum