Modeling 02 Diagram 01 HeliumModeler EN 20180928 PDF

Modeling
Diagram. Helium Modeler

(September 28, 2018)
This publication belongs to the Documentation Service of AuraPortal (APDS) and all rights
are reserved. The reproduction total or partial of this document is not allowed, nor its trans-
mission to third parties without written permission by the APDS.
www.auraportal.com | info@auraportal.com | Skype: AuraPortal | Tel: +34 962 954 497 |
International: +18 572 390 070
CONTENTS
0. INTRODUCTION ........................................................................................................................................................ 4
0.1. LIFE CYCLE OF THE PROCESSES ................................................................................................................. 4
0.1.1. Modeling ................................................................................................................................................... 4
0.1.2. Simulation ................................................................................................................................................. 5
0.1.3. Execution .................................................................................................................................................. 5
0.1.4. Monitoring ................................................................................................................................................. 5
0.1.5. Optimization .............................................................................................................................................. 5
0.2. TWO FORMATS OF AURAPORTAL HELIUM MODELER .............................................................................. 5
0.3. TWO MODELING TOOLS ................................................................................................................................. 8
0.4. THE BPMN STANDARD ................................................................................................................................... 9
1. STARTING AURAPORTAL HELIUM MODELER ................................................................................................... 12
2. PREPARING THE CANVAS.................................................................................................................................... 13

2.1. BASIC DIAGRAM OPTIONS ........................................................................................................................... 14
2.2. BASIC EDIT OPTIONS .................................................................................................................................... 14
2.3. BASIC CONFIGURATION OF THE VIEW ...................................................................................................... 15
2.4. BASIC CONFIGURATION OF THE PAGES ................................................................................................... 15
2.5. BASIC CONFIGURATION OF THE TEXT STYLE .......................................................................................... 15
2.6. LANGUAGE CONFIGURATION ..................................................................................................................... 16
2.7. THE PAGES .................................................................................................................................................... 16
2.7.1. Using Bands ............................................................................................................................................ 17
2.7.2. Adding Bands .......................................................................................................................................... 18
2.7.3. Naming Bands ........................................................................................................................................ 21
2.7.4. Coloring Bands ....................................................................................................................................... 21
2.7.5. Moving Bands ......................................................................................................................................... 21
2.7.6. Deleting Bands ........................................................................................................................................ 22
3. CREATING THE DIAGRAM .................................................................................................................................... 22

3.1. THE OBJECTS ................................................................................................................................................ 22
3.1.1. Selecting Objects .................................................................................................................................... 22
3.1.2. Naming Objects ...................................................................................................................................... 23
3.1.3. Coloring Objects ..................................................................................................................................... 25
3.1.4. Moving Objects ....................................................................................................................................... 26
3.1.5. Copying Objects ...................................................................................................................................... 27
3.1.6. Compound Objects ................................................................................................................................. 27
3.2. THE CONNECTIONS ...................................................................................................................................... 28
3.2.1. Connecting Objects ................................................................................................................................. 28
3.2.2. Links ........................................................................................................................................................ 30
3.2.3. Working with Connected Objects ............................................................................................................ 34
4. SYNTAX ................................................................................................................................................................... 35
4.1. ABOUT THE TASKS ....................................................................................................................................... 35
4.2. ABOUT THE SUBPROCESSES (COLLAPSED NOTATION) ........................................................................ 36
4.3. ABOUT THE EVENTS ..................................................................................................................................... 36
4.4. ABOUT THE GATEWAYS............................................................................................................................... 37
MODELING. DIAGRAM. HELIUM MODELER Page 2 of 97

5. EXPORTING TO OTHER FORMATS ...................................................................................................................... 37
6. DIAGRAMMING EXAMPLE .................................................................................................................................... 43

6.1. APPROACH TO THE EXAMPLE PROCESS.................................................................................................. 43
6.2. RESOLUTION OF THE EXAMPLE ................................................................................................................. 45
7. CONVERTIBILITY BETWEEN FORMATS.............................................................................................................. 46

7.1. EXPORTING A DIAGRAM FROM AURAPORTAL......................................................................................... 46
7.2. MODIFYING A DIAGRAM WITH HELIUM MODELER STANDALONE ......................................................... 47
7.3. CREATING A DIAGRAM WITH HELIUM MODELER STANDALONE ........................................................... 47
7.4. IMPORTING A DIAGRAM IN AURAPORTAL ................................................................................................ 47
8. OBJECTS GALLERY .............................................................................................................................................. 48

8.1. TASKS ............................................................................................................................................................. 49
8.2. SUBPROCESSES ........................................................................................................................................... 51
8.3. EVENTS ........................................................................................................................................................... 52
8.4. GATEWAYS .................................................................................................................................................... 54
8.5. GATEWAYS (SPECIAL NOTATION) .............................................................................................................. 56
8.6. ARTIFACTS ..................................................................................................................................................... 56
9. SIMULATION OF PROCESS EXECUTION ............................................................................................................ 60

9.1. STATISTICAL SIMULATION........................................................................................................................... 60
9.1.1. Object Configuration ............................................................................................................................... 68
9.1.2. Statistical Distributions ............................................................................................................................ 75
9.1.3. Running the Statistical Simulation .......................................................................................................... 89
9.1.4. Analysis of the Results ............................................................................................................................ 90
9.2. REAL SIMULATION ........................................................................................................................................ 95
9.2.1. Quick Execution ...................................................................................................................................... 96
9.2.2. Execution in Production .......................................................................................................................... 97

0. INTRODUCTION
AuraPortal Helium Modeler is the new process modeler included in AuraPortal Helium, which allows
users to design their own business processes. It is without a doubt, the most complete modeler available in
the market and is based on the BPMN 2.0 standard.
0.1. Life Cycle of the Processes

AuraPortal Helium Modeler is the tool used during the Modeling of the Processes, which is the first stage in
the complete Life Cycle of the AuraPortal Processes.
The diagram below shows the 5 stages that make up the Life Cycle of the AuraPortal Processes, highlight-
ing the important position of the Modeling stage.
Here is a brief description of each of the stages:
0.1.1. Modeling
Modeling is the stage where the Classes of Process are designed. It includes two parts:
- Diagramming. This is the part of the AuraPortal Process Life Cycle where the sequence, path and
connections of all the objects included in a Class of Process are graphically designed.
This is performed with the AuraPortal Helium Modeler that comes included with AuraPortal, which
is explained in detail in this document.
- Attribute Assignment. After designing the Diagram, the second part of the Modeling involves as-
signing Attributes to each of the Objects.

For more details about assigning Attributes, refer to the documentation about Process Modeling.
0.1.2. Simulation
With AuraPortal it is possible to perform “simulations” of the running of the processes. This involves virtual-
ly executing the processes in imaginary situations to identify and quantify any circumstances that could
potentially influence the real running of these processes. These operations should reveal bottlenecks, over-
loads, an unequal distribution of workloads, excessive times, costs, etc.
Further on in this document you will find detailed explanations about this stage of the Process Life Cycle.
0.1.3. Execution
After completing the Modeling and Simulation stages and the design of the Class of Process is valid, the
Process can now pass to the Execution stage of its Life Cycle, which in AuraPortal terms is called the Pro-
duction Environment Mode.
In this stage the users will work normally with the processes, introducing and consulting real data accord-
ing to the established design.
0.1.4. Monitoring
Once the users are working normally, the Process Monitoring makes it possible to control and supervise
that the Processes are being executed as expected or if there are any deviations that need correcting.
0.1.5. Optimization
Whether or not the design of the Classes of Process requires Optimization depends on the data obtained
through the Monitoring stage. If it is necessary, the BPM tool must allow instant modifications to be made
to the design of the processes and these modifications must be applied immediately in both the real and
imaginary environments, with no need for any programming. This characteristic is available in very few
BPM tools, only AuraPortal can truly offer it, because BPM tools in general require a certain level of inter-
vention from programmers or expert technicians to put any modifications made to the design of the pro-
cesses into execution. This makes it impossible to perform an elevated number of function tests on the
processes in a short time period, because the application would need to be reprogrammed in each case.
0.2. Two formats of AuraPortal Helium Modeler

AuraPortal offers two modeler formats:
1. AuraPortal Helium Modeler, which comes integrated in the AuraPortal application.
2. AuraPortal Helium Modeler ‘Standalone’, which can be downloaded for free from the AuraPor-
tal website (www.auraportal.com) to be used independently of the AuraPortal suite.

The differences between the two formats are described below:
1. The AuraPortal Complement
The version integrated in AuraPortal requires the installation of the AuraPortal Complement. This is a set
of necessary applications required by certain AuraPortal features such as the editing of Class of Process
Diagrams, Digital Signature, amongst others.
The following link appears in those AuraPortal options where the complement is necessary:
On clicking this link, it will be installed on your computer and available for all the functionality that require
it. Firstly, a system window will appear asking if you wish to Execute or Save the Complement. Click Exe-
cute. A window will appear to choose the language and then the installation window, which is like the fol-
lowing:
Click Install. When the installation is complete, click Finish.
Note.
The Download Complement link does not disappear even if it is already installed on
the computer, but it is only necessary to install it once. After that, the different applica-
tions that include the complement will be updated automatically and independently

when accessing the corresponding functionality (Diagram, etc.), if a new version is de-
tected.
2. The access to the Modeler
- The version integrated in AuraPortal is accessed from the design options of each Class of Process
within the AuraPortal structure.
- The Standalone version is accessed by clicking on the icon that will have been automatically created
on your desktop during the installation of the Standalone AuraPortal Helium Modeler. The installer
can be obtained for free from the AuraPortal website (www.auraportal.com).
- From the same website (www.auraportal.com) it is also possible to use the AuraPortal Helium Mod-
eler online, using the same Standalone format but without the need to install it on your computer.
3. The language of the Modeler
- The BPM Helium Modeler integrated in AuraPortal will always adopt the language of the user who
has logged on to AuraPortal.
- In the ‘Standalone’ AuraPortal Helium Modeler the language is chosen by clicking the Language
button in the actions bar at the top of the window:
4. Running the Simulation
- In the version integrated in AuraPortal, the statistical simulation can be configured and executed
from either the Simulation option (2) located in the EXECUTION panel (1) of the Class of Process
design accessed from Structure:
or from the Modeler itself:

- In the Standalone version, the statistical simulation is executed from the Statistical Simulation but-
ton located in the Modeler Button Panel at the top left:
The diagrams built with both formats are compatible. Therefore, diagrams built with the ‘Standalone’
version can be imported at any time to an AuraPortal installation to be put into execution, with no need
for any programming.
Note.
The conversion possibilities between both Modelers are explained later on in this document.
0.3. Two Modeling Tools

Besides the AuraPortal Helium Modeler explained in this document, which is designed with Java technolo-
gy, AuraPortal also offers an alternative modeling tool named AuraPortal Visio Modeler which, as its name
suggests, is based on Microsoft Visio. The main differences between the two are:
1. AuraPortal Helium Modeler
It is designed with Java technology and is 100% web-based, compatible with Internet Explorer, Firefox,
Chrome, Safari, etc.
No third-party programs are required. Everything you need is included in AuraPortal without having to
install any additional programs.
In regard to Version Control, every time a Diagram is modified and saved the system automatically creates
a new Version. These versions can be consulted and restored if necessary from the Version Control feature.

2. Technical Aspects of AuraPortal Visio Modeler
It is based on MS Visio, both Standard and Professional, and has been developed to fully adapt to the
business process diagramming practice using the BPMN 2.0 standard, and is very easy to use.
Note.
The versions of MS Visio that are compatible are 2003, 2007 and 2010. The 2013
version has lost compatibility because Microsoft has withdrawn the necessary XML
file format.
AuraPortal Visio Modeler is also available in two formats; integrated in the AuraPortal installation, or
Standalone to be used independently of AuraPortal.
Note.
Although the features offered by the Visio Modeler are similar to the Helium
Modeler, AuraPortal Visio Modeler has its own specific documentation.
0.4. The BPMN Standard

AuraPortal Helium Modeler has adopted the international BPMN (Business Process Modeling Notation)
standard (v2.0) for the Class of Process modeling, with some additional customized developments (for
example, the Collectors and Control Points) which cover certain BPMN shortcomings and significantly in-
crease its power.
Essentially, BPMN is composed of several sets of elements that represent both the flow Objects and their
connections, and the help instruments, namely the Bands (Swimlanes) and the Artifacts.
The Objects are divided into three categories: Activities, Events and Gateways. In turn, the Activities are
divided into Tasks and Subprocesses.
1. Tasks. These objects perform the process activities. They can be Personal (performed by people) or
System (performed automatically by the system without human intervention). Examples of Task nota-
tions:
2. Subprocesses. These are sets of objects with a homogenous purpose (a sub-diagram within the main
diagram). They are represented by their Collapsed notation to simplify the diagrams. They can be in-
cluded in the different points of the diagram where their operative is required. The Developed nota-
tion is accessed from a link and can be consulted from the Collapsed version when more detail is re-
quired. This also helps to keep the integrity of the model from start to end when the details of a Sub-
process are not known. Examples of Subprocess notations:

3. Events. In charge of starting and stopping the Process flows in the threads where they are situated.
Examples of Event notations:
4. Gateways. These objects redirect the flow between the process threads depending on their configura-
tion and conditions. Examples of Gateway notations:

Note.
As can be appreciated in the images, each object is identified by an abbreviation.
TP for Personal Tasks, TS for System Tasks, SP for Subprocesses, DA for Parallel
Divergent Gateways (AND) etc.
5. Canvas and Bands. The canvas where the objects of the Diagram are drawn can be divided into Bands
(Swimlanes), which are vertical or horizontal strips that help when situating the Tasks and Subprocess-
es in relation to the departments or roles of the task performers.
6. Artifacts. Complementary elements that help to improve the comprehension of the Diagram. Their
function is illustrative and nonexecutive, therefore the Motor does not take them into account when
executing the Processes.
It is important that you identify each object and understand its function before beginning to work with the
modeler.
The chapter titled BPMN Objects Gallery contains a list and explanation of all the Flow Objects and the
BPMN Artifacts.

1. STARTING AURAPORTAL HELIUM MODELER
On starting AuraPortal Helium Modeler from AuraPortal, the following window will open:
As can be seen in the image above, the window has several Areas.
The right-hand area (1) contains the Canvas where the objects are placed to create the diagram.
The left-hand area contains the Button Panel of the Modeler (2) and the BPMN Objects Gallery (3) which
is used for the modeling. Each of the graphical shapes of the objects in the gallery are explained in the
corresponding chapter further on in this document.
In the header of the Standalone version there are some additional buttons: Create New, Open Existing and
Save As. These buttons are not necessary in the version integrated in AuraPortal because the diagram is
created and edited from the configuration window of the Class of Process and, once open, the only options
that many be needed are Save Draft or Save Diagram.
The vertical Actions Bar (4) which separates the two areas contains the object alignment tools.
The upper horizontal Actions Bar (5) is made up of a series of buttons with drop-down submenus con-
taining actions that can be performed on the complete diagram or on the individual objects and connec-
tions. Below this bar is another Quick Access Bar (6) which includes the icons for the most frequent ac-
tions.
To create a diagram, you must:
1. Prepare the canvas (text style, language, pages, bands, etc.).
2. Draw the diagram, carrying out the following three actions:
- Place the Objects on the canvas.

- Identify them with a description of the function they are going to have in the process.
- Connect them with the corresponding object(s) to create the current flows.
3. On finishing the diagramming session, you can exit the Modeler using any of the following options:
- Save Diagram. To save the diagram checking that there are no errors according to the BPMN syn-
tax.
- Save Draft. To save the diagram without checking if there are any BPMN syntax errors.
- Save As. Only in the Standalone version. This allows the diagram to be saved with another name
and/or in another path.
To Exit without Saving click the icon in the Quick Access Bar or the File button in the Vertical
Actions Bar, and then click Exit. If no changes have been made, the diagram will close. If any changes
have been made, the window below will appear with the following options:
Notes.
1. Syntax. AuraPortal Helium Modeler includes Syntax checks to ensure that the
objects that make up the diagram are as they should be, indicating exactly where
any errors are and explaining their nature. This way, when a diagram has passed
the syntax check, the execution of the model will be correct.
2. Version Control. If working from AuraPortal, on clicking Save Diagram, the

system automatically creates a new Version. These versions can be consulted and
restored if necessary from the Version Control feature.
If working with Standalone (independent of AuraPortal), on clicking Save As you

can either substitute the current version or create another version by changing
the name.
2. PREPARING THE CANVAS

The Canvas is the space where the diagram is drawn. The canvas can be divided into Pages and these pag-
es can be organized into Bands.
Before beginning the diagram, it is advisable to prepare the canvas by establishing the general values you
want to work with, modifying the AuraPortal Helium Modeler default values.
The default values can be modified and adapted to each situation at any moment from the tabs in the top
left of the window:

All these features are explained below.
2.1. Basic Diagram Options
The submenu of the File button in the Upper Actions Bar includes the following possibilities:
- Save and Exit
- Save Draft
- Page Setup
- Print
- Exit
The Page Setup option allows defining the Size, the Margins and the Orientation of the diagram canvas.
The other options are self-explanatory.
The Standalone version also includes the Open Existing option, to open a diagram saved previously.
2.2. Basic Edit Options
The Edit button in the Upper Actions Bar includes the basic edit possibilities for the Objects and Connec-
tions: Undo and Redo the last action; Cut, Copy, Paste, Delete or Edit (to name the object or connection)
the selection; Select All to select the whole Diagram, and Select None to deselect anything selected with
the previous option.

2.3. Basic Configuration of the View
The submenu of the View button in the Upper Actions Bar includes the following possibilities:
- Grid. To indicate if the pages will be shown with a grid to guide the user when adjusting the posi-
tion of the objects. The characteristics of this grid can be configured from the Page submenu.
- Rulers. To indicate if the horizontal and vertical rulers will be visible, also to guide the user when
adjusting the position of the objects.
- Zoom. To modify the size of the diagram in the page. If the cursor is placed over a particular ob-
ject, on zooming in it will become centered on the specified object.
- Page / Width. To determine the default size of the pages. With Page selected the canvas will fit the
visible height of the window, and with Width selected the canvas will fit the visible width of the
window.
2.4. Basic Configuration of the Pages
The submenu of the Page button in the Upper Actions Bar includes 3 elements:
- Background. To determine the appearance (Color or Image) of the page background as well as the
background of the canvas.
- Grid. To configure the characteristics of the Grid to optimize its use.
- Objects. To determine the appearance of the diagram objects (flat, embossed or with shadow).
2.5. Basic Configuration of the Text Style

AuraPortal Helium Modeler already has a default text style established which applies to the diagram ob-
jects, but this can be customized on two levels:
1. Firstly, if you want to give the Modeler a uniform style, clicking on the Text Style button in the Upper
Actions Bar will open the Text Style window:

Here it is possible to configure the Font, Size, Style, Alignment and Line Spacing independently for
the Tasks, Events, Gateways and Connection Lines.
These values will be applied as default except in the objects that have been specifically customized
using the corresponding icon in the Quick Access Bar.
Clicking on the Default Style button will reset the AuraPortal default values.
2. As the objects are created, they can be customized individually if desired, using the icons available in
the Quick Access Bar, as explained further on.
2.6. Language Configuration
To change the Language, just select the desired one from the drop-down menu. The changes will take
effect the next time the Modeler is opened.
2.7. The Pages

When starting to work the canvas, a page is provided by default, and more can be added as necessary to
complete the diagram. By default, the size of each page is designed so that the diagram can be printed on
A4, although, using the icon the page can be configured as desired.

Note.
In complex or extensive processes, the first page may be used to draw the basic
process diagram divided into ‘Subprocesses’, and in the subsequent pages, display
the developed notation (the content) of these Subprocesses.
Each page will be identified by a small tab with the page number at the bottom left of the canvas. This
number can be changed by double clicking on the label.
To add pages to the Canvas, click on the icon found in the vertical toolbar. Each click will add a page.
Below this icon you will find another icon to Delete the page.
Right click anywhere on the page to open the following submenu, which contains the actions that can be
performed on the page:
2.7.1. Using Bands

The Bands can be used to differentiate process functions, such as the different areas or departments where
tasks are to be performed, but also to identify other functional aspects to improve the understanding of
the diagram.
Working with Bands is not compulsory.
The Bands can be Horizontal or Vertical.
Each page of the Diagram can contain several Bands, either all horizontal or all vertical.
Note.
If you are going to use Bands, we recommend that the Bands are prepared before

beginning the diagram (which can be different in each page), although they can
be added or deleted at any time.
2.7.2. Adding Bands

To add a band to a page, go to the Artifacts tab in the Objects Gallery (at the left) and click, drag and drop
either the Vertical Band or Horizontal Band to the desired position on the page.
As bands are added to a page, the system will place them to the right of the previous, grouping them un-
der the same Title, as can be seen in the image below:
After placing the band on the page, it can be resized, moved, colored, etc. To work with the band, it must
be selected (it will become outlined in red).
- When adding a new band to a page it is automatically selected and therefore can be worked with
immediately.
- To select a band already in the page, just click on it.
In the upper left-hand corner of the Bands there is a small square with a ‘-‘ sign which will minimize the
band.

The minimized band shows the same square with a ‘+’ sign to maximize it.
If there is more than one band, the ‘-‘ icon will minimize all the bands that have been added.
When the first object is added to a band, the band in question will now show its own minimize icon,
making it possible to minimize the bands independently.

Minimizing a band can be very practical to keep the page clear when very complex diagrams are being
designed.
Right click with the mouse anywhere on the band to open the ‘Band Actions Menu’, to select the actions
you wish to perform on the band:
To select a group of bands, just click on the header of the group (the group with become outlined in red).

2.7.3. Naming Bands
To name a group of Bands or the header of each Band, double click on the header to activate the text
box. The same result is achieved by opening the ‘Band Actions Menu’ and selecting Edit. To change to style
of the text, select the band or group of bands and click any of the Edit icons in the Quick Access Bar to
change the font type and size, bold, italic, font color, alignment and line spacing.
Note.
When the style of the text in a text box belonging to an object or artefact is modi-
fied from the Edit Mode using the icons in the Quick Access Bar, you must click
with the mouse anywhere on the page for the changes to be updated.
2.7.4. Coloring Bands

The Body and the Header of each band can be colored. To do this, right click on any area of the Band to
open the ‘Band Actions Menu’ to choose from the different actions available. Select Background to open
the submenu in the following image:
Here it is possible to:
- Color the header of the band, using the options that refer to the Title.
- Color the body, using the functions that make reference to the Body of the Band: Body Fill Color (to
color its background), Body Gradient and Line Color (to color the border of the band).
2.7.5. Moving Bands

To move a group of Bands all at the same time, firstly you must select them by clicking on the header of
the group. You can also click outside the group of bands to be moved and drag the cursor to the opposite
corner to select them.
Once the group is selected, drag it to the desired position. To better adjust the position or for short dis-
tances, use the arrow keys on the keyboard.
To change the width or height of a band, select it and “pull” the icon that appears in the lower right cor-
ner of the band or set:

To make more precise adjustments, you can increase the size of the canvas by using the zoom tools:
Note.
Mastering the use of these icons greatly eases the diagramming. It is advisable to fa-
miliarize yourself with them by placing various objects on the page and using the icons
to test their behavior.
2.7.6. Deleting Bands

To delete bands, click on the band you want to delete to select it (it will become outlined in red) and press
the Delete key.
3. CREATING THE DIAGRAM

In this chapter you will find an explanation of the actions and tools that can be used to create the Diagram.
3.1. The Objects

To add an object to the Canvas, select one in the Objects Gallery (left-hand area), drag it and drop it in the
desired position on the page.
When an object is added to the canvas, the system itself will identify it with a Code made up of the abbre-
viation of the object and an order number, separated by a dot, for example TP.1 (Personal Task 1) or DX.1
(Divergent Gateway 1). This can be seen in the image further down.
Note.
Before beginning to diagram you should know and understand each object and its
function. The chapter titled BPMN Objects Gallery further on in this document
contains a list and explanation of each of the BPMN flow objects and artifacts.
3.1.1. Selecting Objects

Once an object has been placed on the page, to work with it (move it, copy it, align it, etc.) it must first be
selected.
- When adding an object to a page it is automatically selected and therefore can be worked with
immediately.
- To select an object already in the page, just click on it.
When an object is selected it is outlined in red, as can be seen in the image below:

Right-clicking with the mouse on a selected object will open the Object Actions Menu, which offers the
following functions:
These features are detailed in the following sections in the explanations of the actions they are related to.
3.1.2. Naming Objects

Besides the code that identifies each object, which is determined by the system itself when the object is
placed on the canvas, an explanatory text can also be added to the diagram. In Tasks and Subprocesses
the text is introduced inside the object, whereas with Events and Gateways it appears outside the object,
as can be seen in the image below:
To open the text editor, just double click on the object.
A blue frame will appear around the text indicating that it is in Edit mode, enabling text to be added, modi-
fied or deleted. The same result can be obtained by invoking the ‘Object Actions Menu’ and selecting Edit.
Note.
Format can also be applied to the text of the object once out of the edit mode.
Just click on the object once and it will become outlined in red, then change the
format as desired.

With the same criteria, double clicking on a gateway or event, the same blue frame will appear outside the
object and the object itself will become outlined in green.
After writing the text, format can be applied: font color, bold, etc.
The size of the text box can also be adapted by “pulling” the four squares that appear in the corners:
To move the label, hold the mouse over it until the four pointed arrow appears like in the image below:
Then it is possible to click, drag and drop the label to the desired location. It can also be moved with the
arrow keys on the keyboard, or by holding down <Shift> or <Ctrl>+Arrow keys (up, down, left and right)
to move the text shorter distances, usually for finer adjustments.
The text can also be rotated using the rotation icon:
The Upper Bar contains the following text tools: Font Type and Size, Bold, Italic, Font Color and Alignment
(Horizontal and Vertical):

Note.
While the object is outlined in green, the move, delete, etc. actions are applied to
the label, not to the object.
Object Descriptions. Each object in the diagram can be given a general description. This description will
not appear in the diagram.
To introduce this description, first select the object and then right click on it to open the ‘Object Actions
Menu’. Click on Description and a window will open to introduce the desired text.
A D icon will appear next to the object in the diagram to identify that a Description has been included.
Note.
When the diagram is saved in AuraPortal, these descriptions will form part of the
attributes of the object in the modeling window, in the box outlined in red in the
following image:
This description also appears next to the name of the object in the document that
is generated on exporting the diagram and its objects. The Export feature is
explained further on.
3.1.3. Coloring Objects

Right click on the object to open the ‘Object Actions Menu’. Selecting the Background option will open the
image shown below, with the coloring options for changing the Background of the body, the color of the
Gradient, the Opacity and the Line color with which the objects will be added to the diagram:

The Quick Access Bar also contains the icons: Line Color (to color the border of the object) and
Body fill color (to color the background). The window for selecting the color of the different object char-
acteristics (Border, gradient, etc.) has the following appearance:
Clicking the Default Color button will return the color to the Modeler’s default settings.
3.1.4. Moving Objects

To change the position of an object, click on it and drag and drop it in the desired position on the page.
You can also use the arrow keys (up, down, left and right) to move the object, or the arrow keys + <Shift>
or <Ctrl>. The latter option is useful for making finer adjustments or for shorter distances.

Note.
When you wish to make finer adjustments, it is advisable to increase the size of
the pages to get a closer view, using the tools in the upper horizontal toolbar:
Zoom in, Actual Size (puts the page zoom to 100%), Zoom Out, Page (to view
the whole page), Width (to zoom in to the full width of the page) and Personal-
ize:
3.1.5. Copying Objects

To add a new object to the canvas with similar characteristics to a previously created one, select the origi-
nal object and drag it to the desired location holding down the CTRL key. The system will give the new
object a different code.
Cut, Copy and Paste icons are available in the Quick Access Bar,
or you can use CTRL+X, CTRL+C and CTRL+V, or the options in the ‘Object Actions Menu’ to repeat objects
in another page of the Diagram, for example. To Cut and Paste the objects they must first be selected.
3.1.6. Compound Objects

In the BPMN notation, Intermediate Message (EM), Time (ET) and Multiple (EX) Events can be embedded
in Personal Tasks (TP) and Subprocesses (SP).
To add a Compound Object to the page:
1. Firstly, the Activity (task or subprocess) must be added to the page
2. Secondly, the Event (Intermediate Message, Time or Multiple) is added on top of the Activity. The
Event can be placed wherever convenient around the edge of the Activity.
- To change the position of the event on the object, use the arrow keys.
- To un-embed the event from the object, just select it and press Delete.
Note.
As the BPMN syntax requires the Tasks and Subprocesses with Embedded Events
to be represented in the diagram with two outlets: one for the Activity and one for

the Event, the position of the event in the task or Subprocess may be important to
the presentation of the diagram, to make it more simple and understandable.
3.2. The Connections

After placing various objects on the canvas and naming them, these objects must be connected to each
other, thereby forming threads of current where the flows are configured. The objects can be connected to
Connections and Links.
3.2.1. Connecting Objects

To connect two objects:
Place the cursor over the edge of the object that will be the flow origin (a red square will appear to indicate
the origin connection point). STEP 1.
Click and drag until you reach the Destination object (a red square will appear to indicate the destination
connection point). STEP 2.
and release. STEP 3.
Once connected, the need to perform actions on groups of objects all at the same time is very common
(aligning the objects, moving several at a time, etc.). This is explained further on.
3.2.1.1. Moving a Connection Line
As can be seen in the previous image, when a connection line is selected, a rounded rectangular icon ap-
pears on the line. To change to path of the connection line, it must be manipulated from these icons (1),
dragging the cursor over the page with the mouse pressed (2) until it is in the desired location (3).

Manipulating the vertical icon (as in the previous image) will move the line from left to right, and the
horizontal icon will move it up and down.
To change the point where the line connects to the object, place the mouse over the starting point or over
the end (the arrow head). When the hand icon appears (1), click on the mouse and, keeping it held down,
move the end of the line (start or arrow head) to the desired point on the object (2) and release (3).
Note.
With AuraPortal Helium Modeler, the user designs the path of each connection
between objects as they wish, so that nothing will obstruct or hinder the correct
understanding of the diagram.
3.2.1.2. Naming a Connection Line
A text can also be added to the connection lines to clarify the action of the flow.
Note.
Connection lines that are outlets of DX and DO gateways must always be named
to determine the outlet the flow will take, according to the gateway conditions.
To introduce text to a connection line, double click with the mouse anywhere on the line to open the text
editor:
In the same way as with the objects, when in edit mode the connection changes to green. After writing the
text, click once anywhere on the canvas. The label will be come outlined in a red dotted line:
It is now possible to move the label with the icon or with the arrow keys, or resize it with the icon.

The same result is achieved by opening the ‘Object Actions Menu’ (by right clicking on the connection line)
and selecting Edit.
The Quick Access Bar contains the following text tools: Font Type and Size, Bold, Italic, Font Color and
Alignment (Horizontal and Vertical):
To modify the text, follow the same procedure as when creating it. Clicking on the line will open the text
box and double clicking on this box will make it editable. The same result is achieved by opening the ‘Ob-
ject Actions Menu’ and selecting Edit.
To change the location of the text, drag the text box to the desired location, as explained previously for
the objects:
- The text can be adapted by “pulling” the four squares that appear in the corners of the text box
with the icon.
- It is also possible to rotate the text using the rotation icon.
3.2.2. Links
In addition to the connections drawn with the current threads mentioned previously, the objects can also
be linked in the diagram via hyperlinks. There are two possibilities:
3.2.2.1. Linking between Collapsed and Developed Subprocesses
Subprocesses are groups of Tasks and other Objects that can function as an independent operative unit,
while still being integrated in the Process.
- A collapsed notation of a Subprocess is just an object that contains the name and code of the
Subprocess; it does not show the objects and connections.

- The developed notation is the group of objects and connections that, starting with a Subprocess
Start Event (IS) and ending with one or more End Events (FN), make up the diagram that repre-
sents the actions to be executed in the Subprocess.
The developed notation is drawn in another part of the diagram which may be in the same page as the
main Process or, more commonly, in another page.
Every object that represents the Collapsed Notation of a Subprocess must have a link; i.e., it must be linked
to the Start Event of the Developed Notation of the same Subprocess.
To link the two notations, in the example of the previous image the following steps have been taken:
1. From the Objects Gallery, the SP object (Subprocess in Collapsed Notation) has been added to a page,
and has been represented in the canvas as SP.1.
2. Also from the Objects Gallery, the Developed SP (Subprocess in Developed Notation) has been added
to another page, and the actions that must be executed in the Subprocess have been introduced, preceded
(as obliged) by a Subprocess Start Event (IS.1) and ending with an End Event (FN.1) (also obligatory).
3. So that the Process current flows, a Link has been created from the Subprocess SP.1 object to the Sub-
process Start Event IS.1.
4. To create the link between the two notations, right-click on the Subprocess SP.1 to open the ‘Object
Actions Menu’ and click on Select IS:
5. A list of all the IS codes that have been created will appear. Select the corresponding IS code, in this
example IS.1, and the two objects will now be linked:

In the top left corner of the Developed Notation there is a small square with a “minus” sign . Clicking
on this icon will minimize the object. This action is useful to clear the canvas when drawing a complex
diagram.
The Collapsed Notation has a small square with a “plus” sign . Clicking this icon will expand the object
displaying the Developed Notation, making it very easy to review the Diagram.
3.2.2.2. Linking between two Objects
The Link Events allow the flow to be Sent and Received via a hyperlink. They substitute a Connecting Line
between two objects, and are used only when the two objects to be connected are widely separated, or
when there are various Connecting Lines in-between them which they would have to cross, causing possi-
ble confusion in the diagram.
In these cases, to connect two objects via a link, two separate Link Events (EL) are placed on the canvas
(following the common procedure), one connected to the source object as an outlet and the other con-
nected to the target object as an inlet, each one in the corresponding page, as seen in the image below:
There are two types of EL event in the Objects Gallery – Events Tab, with the arrows in opposite direc-
tions. One is the Source Event and the other is the Target Event:
and
On placing them on the Canvas, at first, they will act as such, Source and Target, but changes can be made.
See the image below:

Both the type of Link and the Arrow Direction can be changed to adapt them to the design of the Diagram.
Lastly, to create the connection, right-click on the Source Link Event to invoke the ‘Object Actions Menu’
and click on Select target. A list of all the Target Link Events that have been created will appear. Select the
corresponding one, in this example EL.3.
All the Target Link Events codes that have been created will appear, to select the corresponding one. In
this example, EL.2.

Note.
In general, to undo and redo any actions the icons in the upper toolbar
of the window can be used.
The icon for undo is also available in the ‘Object Actions Menu’, or the CTRL+Z
keys can also be used.
3.2.3. Working with Connected Objects

The need to perform actions on groups of objects all at the same time is very common (aligning the ob-
jects, moving several at a time, etc.). The following sections explain the actions that can be performed.
3.2.3.1. Selecting a Group of Objects
To work with a group of objects, the group must first be selected. There are two ways to select several
objects simultaneously:
1. By clicking outside the group of objects to be moved and dragging the cursor to the opposite
corner to select them.
2. By selecting one of the objects and then, holding down the Ctrl key, clicking on each of the other
objects that you want to include in the group.
If you want to deselect an object that is within the selected group, just click on the unwanted object while
holding down the Ctrl key.
When a group of objects is selected, each one of the objects in the group will be outlined in red.
3.2.3.2. Moving a Group of Objects
To move a group of objects, select the group via one of the methods explained above and drag it in the
same way you would to move an individual object.
3.2.3.3. Copying a Group of Objects
To copy a group of objects, select the group via one of the methods explained above and act in the same
way you would to copy an individual object.

3.2.3.4. Aligning a Group of Objects
To improve the appearance and understanding of the diagram, it is advisable to align the objects.
To align the objects, one of them must be used as a reference. There are two alignment methods for
grouping objects:
1. Select an object that is in the correct position and, holding down the Ctrl key, select the rest of the
objects that you wish to align. The alignment is made by following the first object selected as a
reference.
2. Click the page outside the group and drag the cursor around all the desired objects. The system
will use the object first inserted in the diagram as a reference for the alignment.
The objects can be distributed horizontally or vertically, and the alignment operative is the following: the
objects are selected via one of these two methods and then aligned using the icons in the vertical
toolbar which is located between the two areas. These icons allow the objects to be aligned to the center
horizontally, to the left, right, top or bottom, and also to equal the height, width and size of the objects. It
is also possible to distribute them horizontally or vertically.
For example, to align several objects horizontally, select them all (as explained previously) and click the
Align Horizontally icon (1):
If you wish to unselect an object from inside the selected group, hold down the Ctrl key and click on the
object to be excluded.
Note.
Mastering the use of these icons greatly eases the diagramming. It is advisable to
familiarize yourself with them by placing various objects on the page and using
the icons to test their behavior.
4. SYNTAX
This chapter explains the correct way to place the objects and connections that make up the diagram, ap-
plying the functions explained in the previous chapter.
4.1. About the Tasks

1. The Personal Tasks (code TP) are performed by people who are users of the system.
2. The System Tasks (code TS) are performed directly by the system, without human intervention.
3. The TP and TS Tasks can have several inlets (at least one) but only one flow outlet.
4. The TC Tasks (Compensation Tasks) only have one inlet, always coming from a TPC (Task within
a Transaction). They have no outlets.

5. All Tasks with Embedded Events can have several inlets (at least one), and must have just one
outlet through the Event but they can also have one outlet directly from the task if desired.
4.2. About the Subprocesses (Collapsed Notation)

1. Each Subprocess (SP in the collapsed notation) must have a Link that links it to the IS Start Event
of the developed Subprocess.
2. The SP Subprocesses can have several inlets (at least one) but only one flow outlet.
3. The SC Subprocesses (Compensation Subprocesses) only have one inlet, always coming from a
TPC. They have no outlets.
4. All Subprocesses with Embedded Events (in the collapsed notation) can have several inlets (at
least one), and must have just one outlet through the Event but they can also have one outlet di-
rectly from the Subprocess if desired.
4.3. About the Events

1. Diagrams always begin with a Start Event, which may be a Message, Time or Multiple Event.
2. This Start Event is unique; there cannot be more than one.
3. Each Subprocess in its developed notation must also have just one Subprocess Start Event.
4. A Start Event, regardless of whether it is in a Process or in a Developed Subprocess, cannot have

an inlet and must have only one outlet.
5. Both the Processes and the Developed Subprocesses can have more than one End Event (FN).
Note.
The fact that the Diagram indicates that the Process (or Subprocess) may contain
more than one Process or Subprocess End Event means that the flow can termi-
nate in different moments, depending on direction the flow takes throughout the
evolution of the process.
When a Process End Event is reached, the Process is terminated and all the Ob-
jects in execution or pending are immediately cancelled, including all other Pro-
cess End Events. The same is applicable in the Subprocesses.
6. The End Events (FN) (whether located in a page of the Process or in a Developed Subprocess)
cannot have outlets, but they can have several inlets.
7. The Intermediate Events (EM, ET, EL and EX) can have one or more inlet but only one outlet.
8. The End of Current (FC) Event will definitively stop the current in the thread where it is located,
but it will not stop the current in the other threads of the Process or Subprocess. This Event can
have several inlets but no outlet.
9. Each Link Event (EL) must have a partner.
- If it is a Source Link Event then it must have one inlet and no outlet. It must also have a link
to the Target Link Event.
- If it is a Target Link Event it must have one outlet but no inlet.

4.4. About the Gateways
1. The Divergent Gateways (DX, DO and DA) must have only one inlet and at least two outlets.
When there are expected to be several inlets to the same gateway, they must previously be united
in a Collector (CL).
2. The Convergent Gateways (CX, CO, CA and CL) must have only one outlet and at least two inlets.
3. The DX and DO Gateway outlets must be named.
5. EXPORTING TO OTHER FORMATS

Both the Standalone and the Integrated version of the Modeler include a function to Export information
from the Diagram to other, more common formats, as required. Those available at the moment are: PDF,
DOCX, DOC, BMP, JPG and PNG.
The result of the export is one or several files in the chosen format, which can include the design of the
Diagram, the Name and the Description of the Objects and the data configured in these objects for their
Statistical Simulation.
In the image below is an example of an export file in .DOC format using the default Helium Modeler tem-
plate, which includes a presentation page (1), a Table of Contents (2) based on the styles, the Description
which was included on performing the export and the general parameters of the Simulation (3), followed
by the design of the Diagram (4), the information about the Diagram Objects over different pages (in the
example there are 3, but the number will vary depending on the diagram and the configured data) (5) and
the final page (6).

This function is accessed by clicking the Export button in the Modeler Button Panel in the area to the left of
the diagram:
The following window will open:
Now we will look at an explanation of the different options.
Select Format (1)

The possible formats, as previously mentioned, are those that are shown in the previous image.
If one of the ones that are specific to images are selected, such as BMP, JPG or PNG, a file will be generat-
ed for each page with the corresponding extension, numbered and beginning with ‘_0’.

If one of the formats typical of documents are selected, such as PDF, DOCX or DOC, one single document
is created which includes all the pages.
Note.
The quality of the result will depend on the chosen format and the reader or
viewer used.
Select Template (2)

AuraPortal Helium Modeler includes the MS Word BaseTemplate.dot template for building the document.
However, any other template of this type can be used as long as the name of the Styles defined in the
BaseTemplate.dot are maintained.
To use the default template nothing specific needs to be done.
To use another template, click the Download button (1) and save it in the desired location:
Note.
The BaseTemplate.dot template is protected and cannot be deleted, modified or
overwritten.
Open the downloaded MS Word template. The default styles can be seen there by opening the Styles
dropdown menu, as shown in the following image where they are outlined in red:

Modify the desired styles and save the template as .dot with another name, for example NewBaseTem-
plate.dot.
IMPORTANT NOTE.
The attributes of the styles can be modified but the name cannot be changed, be-
cause AuraPortal Helium Modeler will ALWAYS apply these style names when ex-
porting the information, regardless of how they have been customized.
To change the attributes of a style, click on the style name’s dropdown menu, for example AP_Normal-Bold
(1),
and then click Modify… (2).

The window shows the configuration of the style for its possible modification, as can be seen in the image
above.
To use the new template, click the Import button in AuraPortal Helium Modeler – Export – Select Template,
and select it from its location:

It will become incorporated in the Select Template panel. See the image below:
The new template is now ready for possible new exports. Just select it with the mouse before clicking the
Export button.
To delete a template, right click on its name, as shown in the image below, and then on Remove.
Export Options (3)

It is possible to export the Diagram, page by page and/or the Objects, those of which include a Name and
Description.
If the Objects box is marked, it is also possible to mark the Statistical Simulation box, so that the data con-
figuration for the Statistical Simulation of the diagram objects will be exported.
Note.
Refer to the chapter about Simulation in this document for more information.
Description (4)
A description can be included to present or clarify concepts about the exported diagram. This is not man-
datory.
On clicking the Export button, a search engine will open for saving the export in the desired path.

6. DIAGRAMMING EXAMPLE
Here we will have a look at an Example Process called Construction Site Investment Approval. This example
is just for teaching purposes so therefore it is only a simple Model, but it contains a variety of functionali-
ties. It includes Personal and System Tasks, Subprocesses, Message and Time Events, Gateways, Control
Points, etc.
The development of this example is carried out in two parts:
1. Process approach
2. Resolution of the example
6.1. Approach to the Example Process

In a construction company, when the Site Manager (an employee assigned this Role) requests approval for
a new investment in his construction site, the appropriate Form must be filled in containing the relevant
information about the investment.
On filling in this Form, titled Request for Approval of Construction Site Investment , a Message must be
generated that starts the Construction Site Investment Approval Process.
Once the Process has been started, a Personal Task called Revision for 1st Approval must appear in the
Group Manager of the site’s pending tasks queue.
When the Group Manager opens the task, he will examine the data provided in the Start Message. When
he has made the decision to approve or reject the request, he must fill in a Form stating his decision. Then
the Task terminates and the flow of the Process arrives at a Gateway named 1st Approval?
If the investment has not been approved, the Gateway must direct the flow to a System Task (task per-
formed automatically by the system with no human intervention) called Informs of Rejection and the Pro-
cess terminates.
This System Task sends an internal message to the requester (Site Manager) notifying him that his invest-
ment request has not been approved.
If the Investment has been approved by the Group Manager, the current will continue to the Gateway
named Requires 2nd Approval?. This Divergent Gateway decides whether or not the investment that has
already been approved by the Group Manager requires a second approval by the Division Manager.
To make the decision, the Gateway must take into account two criteria, as stated in the corresponding
Business Rule: firstly, the Amount of the Investment and secondly the Risk Assessment associated with
the country where the investment is to be made.
If a second approval is not necessary the current will continue to a System Task named Creation of Approv-
al Document whose function is to automatically create the Investment Approval Document (signed elec-
tronically by the approver).
Next it must pass through a Control Point P1.K (in charge of taking note of the moment that the current
passes through it, for extracting Monitoring data).
Then the flow continues to the Personal Task Informs of Approval which, with the signed Investment Ap-
proval Document, proceeds to carry out the necessary actions for the investment, using other company
processes.

Finally, the current must go to a Subprocess called Investment Account that is performed in the accounts
department and opens the account where the approved investment funds are handled.
If a second approval is required the current must arrive at a Time Event named Only Mondays and Thurs-
days from 10:00 to 12:00. This Event should hold the Process until Monday or Thursday between 10:00 and
12:00. When these days or times arrive, the Event lets the current continue.
Note.
The reason for inserting a Time Event is that the Division Manager only looks at
approval petitions on Mondays and Thursdays from 10:00 to 12:00.
Therefore, it is not desirable that these Tasks appear in his workflow before these
periods as they will be left unopened until the arrival of the established times,
causing anomalies in the Monitoring of the Process. It could give the idea that the
Division Supervisor is not attending to their workflow, which would be improper.
It would also distort the statistics related to workloads and the optimum alloca-
tion of resources.
When the specified time is met in the Time Event, the flow will pass to a Personal Task, Revision for 2nd
Approval. In this Task the Division Manager will examine the Investment request which has already been
approved by the Group Manager, and he will decide whether or not to give his approval.
From here, the process flow will follow the adequate course depending on the decision made, as described
above.

6.2. Resolution of the Example
There are many ways to resolve this situation. Here we will have a look at one:
Diagram of the Example Process once it has been prepared:
Note.
In this example 3 vertical bands have been used: Construction Site, Management
and Administration, indicating the 3 departments that intervene in the Process.
The use of Bands is mainly effective in diagrams that are relatively simple, but in
practice it may be more convenient to use other types of Artefact to clarify or ex-
plain anything important without having to place the object in a specific band, or
purely to simplify the Diagram.
Developed notation of the Investment Account Subprocess:

As a whole, the Diagram expresses what is required of the Model of this Class of Process, i.e.:
- It allows for approval to be requested for an investment in any construction site belonging to the
company.
- It passes this request to a 1st Approval.
- It checks if a 2nd Approval is required according to what has been established by the Business
Rules.
- It adjusts the partial process execution times using pauses to avoid the generation of misleading
task queues.
- It ensures that the system automatically sends Messages to the recipients indicating if the request
has been approved or not.
- It automatically creates the Investment Approval Document, signed electronically by the approver.
- It executes Subprocesses with the Open Investment Account Tasks.
- It establishes, via Control Points, the Lapses that must be measured to detect bottlenecks and op-
timize the distribution of workloads.
7. CONVERTIBILITY BETWEEN FORMATS

The versions of AuraPortal Helium Modeler, integrated in AuraPortal and Standalone, are convertible to
each other.
It is possible, for example, to create a diagram from within AuraPortal, export it to the local disk, open it
with the AuraPortal Helium Modeler Standalone, modify it or add to it and then import it back again in
AuraPortal. From inside AuraPortal just Save the diagram so that the system automatically creates the ob-
jects, leaving them ready to receive their attributes and this way convert the model into an executable pro-
cess.
It is also possible to create a complete diagram with AuraPortal Helium Modeler Standalone and then im-
port it to AuraPortal. In this case, a new Class of Process will be created in AuraPortal and the file that was
created with AuraPortal Helium Modeler Standalone is imported.
In general, the following possibilities are available:
1. Export a diagram from AuraPortal
2. Modify a diagram with AuraPortal Helium Modeler Standalone
3. Create a diagram with AuraPortal Helium Modeler Standalone
4. Import a diagram in AuraPortal
7.1. Exporting a Diagram from AuraPortal

To export a diagram from AuraPortal, go to the configuration window of the Class of Process that you wish
to export and, in the Modeling Window of the Class of Process, click the Export button. A window will ap-
pear to Open or Save the diagram file, called BPM_XX_X.bpmn. Click Save to save it in the local disk. Now
this file can be opened from AuraPortal Helium Modeler Standalone.

7.2. Modifying a diagram with Helium Modeler Standalone
To modify a diagram with AuraPortal Helium Modeler Standalone, click on Open Diagram in the upper
horizontal toolbar, look for the folder where the exported file is located and select it. This will load the
diagram previously exported from AuraPortal. Now you can modify and/or complete the diagram.
Once the necessary changes have been made, click Save Diagram in the action bar to save them on the
local disk. This file can then be imported to AuraPortal, as will be explained further on.
7.3. Creating a Diagram with Helium Modeler Standalone

To create and save a diagram with AuraPortal Helium Modeler Standalone, access the Modeler following
the instructions in the previous section.
Once the canvas has opened, the model can be created without any need to connect to the AuraPortal
installation.
Later, the file that has been created can then be imported in AuraPortal to configure the objects that make
up the model.
7.4. Importing a Diagram in AuraPortal

To import a diagram of a Class of Process in AuraPortal, go to 'Structure - Processes - Tree and Classes'
and click the Import button situated in the actions bar of the ‘Create/Edit Classes’ tab’.
See the image below:
The following window will open:
Firstly, a Class of Process must be created, simply so that it provides the necessary structure for the import.
Then click on the Import only Diagram icon and choose the newly created Class of Process (this Class of
Process must have been created previously) which will be the one to receive (import) the diagram. The

following warning will appear, informing that this will substitute the existing diagram in the selected Class
of Process:
Check the box (1) to confirm and then click on Import Diagram (2). The diagram will be imported and
associated to the Class of Process created for this purpose.
In order to create the objects of the imported Diagram in the Class of Process, you must:
1. Open the diagram of the Class of Process which has just been imported. The diagram which has
been imported from AuraPortal Helium Modeler Standalone will appear.
2. Once open, without having to make and changes to the Diagram first, you can click on Save Dia-
gram, and all the objects will be created automatically in the structure of the Class of Process,
ready to receive their attributes; or if you wish, you can make modifications to the Diagram before
saving it.
8. OBJECTS GALLERY
Here you will find all the graphical shapes of the objects and artifacts used in the Modeling following the
BPMN standard but in AuraPortal’s enhanced version.
The BPMN (Business Process Modeling Notation) standard, developed initially by the BPMI consortium and
later integrated in the OMG group, is a graphical Process Modeling system that consolidates the best ideas
from previous standards, some of which are still used now but that have been surpassed by BPMN.
Examples of standards that have been analyzed and revised as a basis for the development of BPMN in-
clude: UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flor
(ADF) Diagram, RosettaNet, LOVeM and Event-Process Chains (EPCs).
The success of BPMN right from its release has converted it rapidly into the predominant Business Process
Modeling Standard, to the point where leading vendors of business process management tools have rea-
dapted their products to follow this standard.
In this aspect, AuraPortal has the advantage of being designed from the very beginning based on BPMN,
with the addition of some customized developments (for example the Collectors and Control Points) that
cover certain BPMN shortcomings and significantly increase its power.
On the other hand, as AuraPortal carries out the internal programming of the Processes automatically
as they are being modeled, with no need to add any additional programming code manually, some guide-
lines about the correct way to model must be followed to guarantee that the execution runs perfectly.

To guarantee this, the system carries out syntax checks on the diagrams so that when a diagram has
passed the syntax check (a check that is automatically carried out by the system), the modeled process will
execute without any problems.
Essentially, BPMN is composed of several sets of elements that represent both the flow Objects and their
connections, and the help instruments, namely the Bands (Swimlanes) and the Artifacts.
The Objects are divided into three categories: Activities, Events and Gateways. In turn, the Activities are
divided into Tasks and Subprocesses. Specifically, the following objects are available:
- Tasks. These objects perform the process activities. They can be Personal or System Tasks.
- Subprocesses. These are ‘child’ processes that behave as a whole and help to simplify the dia-
gram.
- Groups of Tasks and other Objects that can function as independent operational units, even
though they are integrated in the Process.
- Events. In charge of starting and stopping the Process flows in the threads where they are situat-
ed.
- Gateways. These objects redirect the flow between the process threads depending on their con-
figuration and conditions.
8.1. Tasks
The Tasks perform the Process activities and are carried out either by people (Personal Tasks) or automati-
cally by the system (System Tasks). A Task can have several inlet connections but only one outlet, except
for Tasks with Embedded Events which may have two outlets: the first, the normal Task outlet (not always
required) and the second from the Embedded Event (mandatory).
SYMBOL FUNCTION
Simple
Personal Task
Task performed by a User of the System. There are three types
of performer: Internal User, External User and Guest User.
TP.33
Code: TP
System Task
Task carried out by the system. There is a System Task for each
function (Send a Notification to one or several destinations, Start
a Process, Execute a Stored Procedure, etc.).
TS
Code: TS

Compensation Task
Personal Task that compensates or cancels the effects of the
Task with Compensation Event (TPC) to which it is associated in
a Transaction. (The Transactions are always Subprocesses with
the code SPC). The Compensation Task is only activated when
TPC.47
the Task with Embedded Compensation Event (TPC) has been
terminated successfully but the Transaction it belongs to cannot
be completed and must be cancelled, so the actions already
TC.37
carried in the Task TPC have to be turned back (compensated).
Code: TC
With Embedded Event

Task with Embedded Message Event
There is an Embedded Message Event. If the Message arrives
before the performer of the Task has terminated it, it will be
aborted and the Process current will continue to the exit of the
TPM
Embedded Message Event.
Code: TPM
Task with Embedded Time Event

There is an Embedded Time Event. If the forecast Time arrives
before the Task Performer terminates, the task is then aborted
and the Process current continues to the exit of the Embedded
TPT
Time Event.
Code: TPT
Task with Embedded Multiple Event

There is an Embedded Multiple Event (combination of Message
and Time Events of). If one of the Events is fulfilled before the
performer of the Task terminates it, it is aborted and the Process
TPX.61
current continues to the exit of the Embedded Multiple Event.
Code: TPX
Task with Embedded Compensation Event

This Task, that needs to figure in a Transaction, in the expanded
notation of a Subprocess SPC, has an Embedded Compensation
Event that is associated to a Compensation Task (TC).
If the Embedded Compensation Task (TPC) has terminated suc-
TPC.47
cessfully, the Transaction cannot be completed, the system acti-
vates the Compensation Task (TC) associated for compensation
(to cancel or turn back) the actions already carried out in the
TC.37
Task with Compensation Event (TPC) to which it is associated.
Code: TPC

8.2. Subprocesses
All the Subprocesses in Collapsed Notation must contain a hyperlink that links them to the Start Event of
their corresponding Developed Notations.
The Developed Notation, which must be drawn in another part of the Diagram, shows the detail of the
objects and connections in the Subprocess.
SYMBOL FUNCTION
Simple
Subprocess
Sets of Objects with a homogenous purpose (a child diagram
within the parent diagram). They are represented by their Col-
lapsed notation to simplify the diagrams. They can be included
in the different points of the diagram where their operative is
required. The Developed notation is accessed from a link and
SP can be consulted from the Collapsed version when more detail is
required. This also helps to keep the integrity of the model from
start to end when the details of a Subprocess are not known.
Code: SP
Subprocess of Compensation
Subprocess that ‘compensates’ the effects of the Task with Em-
bedded Compensation Event (TPC) to which it is associated in a
Transaction.
TPC.47 It is only activated when the Embedded Compensation Event
Task (TPC) has been terminated successfully and however the
Transaction (that is the Subprocess SC) to which it belongs can-
SC
not be completed and must be cancelled, so it must be turned
back (compensated) using this Compensation Subprocess on
the actions carried out using the Task TPC. Code: SC
With Embedded Event

Subprocess with Embedded Message Event
If the Message defined in the Embedded Event arrives before the
Subprocess ends normally, the termination of it is forced imme-
diately and the current continues to the exit of the Embedded
Message Event. The Expanded Notation of the Subprocess must
SPM
be designed to contain the necessary logic to meet this mecha-
nism.
Code: SPM

Subprocess with Embedded Time Event
If the defined time is met in the Embedded Event before the
Subprocess finishes naturally, then the termination is forced
immediately and the current continues to the Embedded Time
SPT Event exit. The Expanded Notation of the Subprocess must be
designed to contain the necessary logic to meet this mechanism.
Code: SPT
Subprocess with Embedded Multiple Event

Has an Embedded Multiple Event that combines Message and
Time Events. It functions the same as the one described above
SPX
for the Embedded Message and Time Events.
Code: SPX
Transaction
This Subprocess, that always has an Embedded Compensation
Event, covers the Objects and Connections that configure a
Transaction. If it cannot be completed successfully, the corre-
sponding compensations must be carried out and activated the
exit by the Embedded Compensation Event.
SPC
Code: SPC
Note.
The expanded notation of this Subprocess must be
built correctly for the compensations to take place.
8.3. Events
The Events are in charge of starting and stopping the Process flows.
- Start Events start the Processes or Subprocesses. They have no inlet connection and only one
outlet.
- Intermediate Events stop the current in their position until the conditions established when de-
fining the attributes are met. They may have various inlet connections but only one outlet.
- End Events terminate the Processes and Subprocesses or stop the Currents of specific threads in
the Processes and Subprocesses. They may have several inlet connections but no outlets.
A Process or Subprocess may have several End and Intermediate Events, but they can only have one Start
Event.
SYMBOL FUNCTION
Start
Start Message Event
Starts the Process on receiving the Message edited with the
Form that specifies the attributes of the Event or by a Process

Start System Task.
Code: IM (Invisible)
Time Start Event

Starts the Process on reaching the time (any form of definition:
Day of the month, of the week, date, time, minute, etc.) indicat-
ed in the specific conditions for this Event.
Code: IT (Invisible).
Multiple Start Event

Contains any combination of Message and Time Events. Starts
the Process when the specified conditions for one of these
Events are met.
Code: IX (Invisible)
Subprocess Start Event

Start Event in the Expanded Notation of a Subprocess. It is acti-
vated as hyperlink of its corresponding Collapsed Notation
when the current of the main Process reaches it.
IS.60
Code: IS
Intermediate
Intermediate Message Event
Stops the current until the Message edited with the Form that is
specified for this Event has been received or using a Message
activation System Task, generally from another Process.
EM
Code: EM
Intermediate Time Event

Stops the current of this thread until the specified time has been
met for this Event.
ET
Code: ET
Multiple Intermediate Event

Contains a combination of Message and Time Events. Stops the
current in the thread until one of the Events is fulfilled.
EX
Code: EX
Link Event
Sends or receives the current to or from another Link with which

it maintains a hyperlink.
EL
Code: EL

End
End of Current Event
Indicates the End of a Process or Subprocess Current. When this
Event is reached, the current of thread is stopped definitively but
the currents of the rest of the threads continue.
FC.32
Code: FC
End of Process or Subprocess Event
If the event is situated in the general Process it forces the com-

plete termination and the definitive cancelation of all the ob-
jects, including the unfinished Tasks and the Subprocesses that
they contain.
If this event is inside of the expanded notation of a Subprocess,
FN.73
this is terminated and its objects canceled. However, the general
Process that contains the Subprocess continues to be active until
reaching its own End of Process.
Code: FN
Other
Control Point
Takes samples (of time and others) at the moment that the flow
passes through it. They are used in the Monitoring.
Code: K
8.4. Gateways
The Gateways re-direct the Process flows, deviating the current from one thread to another. The Divergent
Gateways (which only allow one Entrance), re-direct the current from the inlet thread to one or several of
the outlet threads. The Convergent Gateways (which only allow one outlet) group all or some of the cur-
rents from their inlet threads to one outlet thread.
SYMBOL FUNCTION
Divergent
Divergent Exclusive Gateway (XOR)
It has one Entrance and several Exits. The Exits must be num-
bered to establish the order in which they are to be examined,
as the first that fulfills the established conditions will direct the
Process flow. The rest of the Exits will be disqualified.
Code: DX

Divergent Inclusive Gateway (OR)
It has one Entrance and several Exits, of which one or several will
be valid. The valid Exits generate parallel currents in their re-
spective threads and the rest of the threads will be disqualified
(will not contain current).
Code: DO
Divergent Parallel Gateway (AND)

It has one Entrance and several Exits all of which are valid. Each
Exit generates a parallel current in its respective thread.
Code: DA
Convergent
Convergent Exclusive Gateway (XOR)
It has several Entrances and one Exit. When the first Entrance
occurs, it conducts the current to the Exit and the rest of the
Entrances are disqualified.
Code: CX
Convergent Inclusive Gateway (OR)

It has several Entrances and one Exit. The Gateway, that knows
which of the Entrance threads has current and which do not,
(depends on what has happened in the Process beforehand), it
waits until all those with current before allowing the only Exit.
Code: CO
Convergent Parallel Gateway (AND)

It has several Entrances and one Exit. All the Entrances must be
threads with current as the Gateway will wait until all the En-
trances have occurred before allowing the only Exit.
Code: CA
Collector (OR)
This Gateway is always open. Its mission is to re-direct any En-
trance to its one Exit when the current passes through it. Its use
is necessary to unite threads in the Objects that only accept one
Entrance (as is the case with the Divergent Gateways DX and
DO).
Code: CL

8.5. Gateways (Special Notation)
This notation is applicable to all the Gateways when the number of outlets in the Divergent Gateways, or
the number of inlets in the Convergent Gateways, is greater than three. As seen in the image, up to seven
inlets/outlets can be used and, from each of them, as many current threads can Enter/Exit as desired.
The circles have been included to represent any object: Task, Subprocess, Event or Gateway.
8.6. Artifacts
The Artifacts are complementary elements that help to improve the understanding of the Diagram. Their
function is to illustrate and not execute, therefore the Engine does not take them into account when exe-
cuting the Processes.

Below is an explanation of their functions:
Horizontal and Vertical Bands (1)
Used for grouping actions with the same criteria, for example, actions from the same department or busi-
ness area, etc.
They are most useful in very complex diagrams where the grouping simplifies the understanding of the
diagram.
Business Rules (2)
To insert the representative icons of the different types of Rules (Textual, Assignation, Calculation and In-
ference). It doesn’t influence the Process execution.
Adapter (3)
This connects to external applications, like ERP, CRM, etc., to read, import or export information from the
Process. The connections with this Object are represented by trace lines.

Title (4)
Used to identify the Process. It automatically includes the date on which it has been added to the Canvas
as process creation date. Both the title and the date can be deleted if you don’t wish for them to appear.
Note (5)
Explicative text in a square bracket which can be placed in different positions. On adding the note to the
diagram, the square bracket will be on the left, as can be seen in the following image:
Right clicking on it with the mouse will open a submenu with the Bracket Position option, to change the
position is as desired.
Text in Post-it (6)
Text shown in a post-it type artefact. The square’s dimensions can be adjusted at will. It can connect to
other objects if necessary.
Free Text (7)
To insert a free text in the Model. As in the rest of the Artifacts texts, both the letter type and its size and
attributes can be modified. It cannot connect to other Objects.
Text in Frame (8)
Text appearing in a square with a solid background of the desired color. The square length can be chosen
and then the height automatically adapts to the size of the contained text. It can connect to other objects if
necessary.

Note.
When selecting a text in the diagram, the attribute options will be shown colored
in the upper bar of the canvas. See the image below:
Dialog (9)
An elliptical shaped artefact that can outline text or other types of content. Its attributes can be changed
using the icons in the Quick Access Bar.
AuraPortal Logo (10)
The program’s corporate logo.
Lines and Arrows (11)
To indicate text, images or any other element that may be of interest.
Note.
It is also possible to add external images to integrate them in any part of the dia-
gram.
To do this, go to the Images tab and click on Add Image.

9. SIMULATION OF PROCESS EXECUTION
The Simulation is an important part of the Life Cycle of the AuraPortal Processes.
With AuraPortal it is possible to perform “simulations” of the execution of the processes. This involves vir-
tually executing the processes in imaginary situations to identify and quantify any circumstances that could
potentially influence the real execution of these processes. These operations should reveal bottlenecks,
overloads, an unequal distribution of workloads, excessive times, costs, etc.
AuraPortal offers two complementary simulation methods:
- Statistical Simulation
- Real Simulation
Looking again at the diagram of the AuraPortal Process Life Cycle, we can see how the Statistical Simula-
tion forms part of the Modeling Stage, and the Real Simulation forms part of the Execution Stage.
The following sections explain both types of Simulation.
9.1. STATISTICAL SIMULATION

The statistical simulation involves introducing probability data to the events considered critical in the pro-
cess being studied, for example, the estimated duration of one or several tasks during the process, the
resources associated to determined actions, their costs, etc. With these imaginary data, the aim is to predict
“what if” type results which will make it possible to identify bottlenecks, performance, costs, workloads and
in general, the KPIs that are considered essential.

Statistical Simulation implies the application of probabilities that are not always easily quantifiable, forcing
the introduction of probabilistic calculations which are not always reliable, although they are considered
valid when there is nothing better to go by.
Likewise, the statistical simulation allows information to be obtained from the imagined environments but
this information is not suitable for detecting specific errors or insufficiencies in the design of the processes.
For example, excessive personal task execution times due to non-optimal designs of task forms, etc.
The statistical simulation practices show that the reliability of the conclusions only reach a first level estima-
tion, which in general is insufficient for determining the suitability of the process design. For this reason, in
AuraPortal the “statistical simulation” is amplified by the “Real Simulation”, which is generally much more
reliable because it does not involve resorting to probabilistic estimates. Instead it makes it possible to truly
observe the KPIs through real tests, and as many of these tests can be carried out as deemed necessary.
Note.
In contrast to the statistical simulation, the real simulation offered by AuraPortal is
within immediate reach, not only for the designers of the processes, but also for the
business directors and analysts, so that they can easily perform simulations on running
processes in real working environments, demonstrating the comparative advantage of
AuraPortal.
In effect, once an error or lack of performance is detected through the real simu-
lation, it can be corrected immediately without the need to perform any pro-
gramming.
The AuraPortal statistical simulation is configured and executed from the Simulation option (2) located in
the EXECUTION panel (1) of the Class of Process design, from Structure:
Clicking on Simulation (2) will open the simulator window:

The left-hand panel in the image above shows parameters and results of the running of the simulation, and
the right-hand panel shows the diagram of the Class of Process.
The left-hand panel in turn divides into two sections, the upper includes the general values of the Class of
Process and the lower shows a grid with the values specific to each object.
The details of each element are explained below.
The upper section of the left-hand panel, shown above, shows the action buttons and the panels of general
simulation data:
ACTION BUTTONS
- Exit. This closes the simulation and takes you back to the main Class of Process design window in
the AuraPortal structure. In the Standalone Helium Modeler (which executes independently of
AuraPortal), this button takes you back to the Diagram design window.
- Save and Exit. This saves the configured values and closes the simulation.
- Save. This button saves the configured values without closing the simulation.
- Run. To start the simulation. While running, the Running! Label will be displayed.
- Stop. This is active while the simulation is running and will stop it if clicked. If clicked, the Can-
celled! Label will appear.

- Charts and Graphs. This is active when the simulation has finished or has been stopped. On click-
ing it, a window will open showing charts and graphs of the results.
- Grid Only. This hides the right-hand panel containing the Diagram.
- Diagram Only. This hides the left-hand panel containing the grid. The buttons needed to run the
simulation will appear in the header.
The panels in this section are described below.
PROCESSES
This indicates the values relative to the number of processes executed in the simulation:
- Total. The total number of processes you wish to execute in the simulation.
- Simultaneous. The number of processes that will be executed simultaneously during the simula-
tion.
- Completed. This shows the number of completed processes as they are completed during the
simulation, until the number indicated in Total is reached, unless the maximum time indicated in
Max Duration in the CALENDAR panel is reached first.
- Pending. This will show the difference between Total and Complete. To begin with it will be the
same as Total, and it will gradually reduce until reaching 0, unless the maximum time indicated in
Max Duration in the CALENDAR panel is reached first.
CALENDAR
The values relative to the simulation run times are indicated in the CALENDAR panel:
- Hours per Day. The number of working hours per day, by default 8.
This value acts as a base for the calculation of the simulation results. For example, if a process
takes 16 hours to execute, and the working day is 8 hours long, the total execution time of the
process would be 2 working days.
- Days per Month. This indicates the number of working days per month, by default 22.

This value is applied to the results of the simulation similarly to the previous field. For example, if
a process takes 26 days to execute and there are 22 working days in each month, the total execu-
tion time of the process will be 1 working month and 4 working days.
- Max Duration. This is to define the maximum duration the simulation will run for. If no value is in-
dicated, Undefined will appear in the field, which means that the simulation will run as long as it
needs until the number of processes indicated in the Total option of the PROCESSES section has
been completed.
To indicate a limited duration, click on the EYE and a window like the following will open:
If values higher that the context of the fields are introduced, they will be recalculated automatical-
ly. For example, if 70 minutes is indicated, it will automatically be converted to 1 hour and 10
minutes.
In the Days and Hours fields, the calculation is based on the Hours per Day and Days per Month
values. This way, if 16 hours are indicated and Hours per Day is limited to 8 hours, it will automati-
cally be converted into 2 days.
- Real Duration. This shows the actual duration of the processes throughout the simulation run time.
PERSONAL RESOURCES COST
The PERSONAL RESOURCES COST section includes all the information related to the costs of the people
that perform actions during the simulation.
- Currency. The currency you wish to be displayed in the results. To change it, click on the EYE and a
window like the following will appear:

Look for the desired currency using the search field, or scroll through the list, then click on the de-
sired one and the economic values will be shown with the corresponding symbol.
- Expected Cost. Here the estimated costs of the simulation to be run are indicated.
- Real Cost. This will be filled in with the real costs resulting from the running of the simulation. As
will be seen further on, the costs are obtained from the values indicated in the parameter configu-
ration in the objects of the diagram that involve human intervention, specifically Personal Tasks
(TP), Start Messages (IM) and Intermediate Messages (EM).
- Deviation. This will calculate and show the difference between the two previous fields. If the esti-
mated cost is higher that the real cost it will be shown in green, and when the real cost is higher,
it will change to red.
- Personnel Time. This shows the time invested by the employees for the personal resources
throughout the simulation run time, i.e., in the Personal Tasks (TP), Start Messages (IM) and In-
termediate Messages (EM). This omits however the time spent for the System Tasks and other ob-
jects such as the Gateways that are not performed by people.
- Persons/Day. This shows the daily personal resources needed according to the result of the simu-
lation. As it refers to people, no decimals are used. For example, if a certain task has a duration of
4 hours and it is executed just once a day by just one person in a working day of 8 hours, the re-
sult of this field will be 1 person per day, even though it has only taken half of that time. To cor-
rectly analyze this result, it must be evaluated jointly with the staff performance; a datum which is
provided in the following field.
- Personnel Performance. This shows the performance of the personal resources. For example, if
each person executes just one Personal Task that has a duration of 4 hours in a working day of 8
hours, their performance will be 50%.
Now we will look at the details of the grid in the lower section of the left-hand panel:

This grid lists all the objects in the diagram, and includes the following columns:
- Object. This includes the code of the object, preceded by the page of the diagram where the ob-
ject is located.
- Name. The name of the object. If it doesn’t fit in the column, ellipses will appear and the full name
will be visible in the tooltip which appears on hovering over the cell with the mouse.
- Arrivals. The number of times the current flow has reached the object. It will be filled in while the
simulation is running.
- Completed. The number of objects completed during the simulation run time. This is different
from the Arrivals (previous column) for two values:
o If the process reaches an end before the object is terminated, it will not be completed
and therefore will not be counted.
o It takes into account the parallel execution of the Personal Tasks that are configured in
this way, that is, if an object is configured with two parallel performers, every time it is
completed the counter will increase by two.
- Total Time. Total execution time of each object during the simulation.
- % Time. Percentage of the run time of each object relative to the total of completed processes.
- Alerts. This shows, in orange, the number of objects that have reached the Alert stage for not be-
ing completed within the time indicated in their configuration.
- Alarms. This shows, in red, the number of objects that have reached the Alarm stage for not being
completed within the time indicated in their configuration.
- Persons / Day. This shows the daily personal resources needed for the execution of each object
during the simulation. As it refers to people, no decimals are used. For example, if a certain task
has a duration of 4 hours and it is executed just once a day by just one person in a working day of
8 hours, the result of this field will be 1 person per day, even though it has only taken half of that
time. To correctly analyze this result, it must be evaluated jointly with the performance of the per-
sonnel; a datum which is provided in the following cell.
- Performance. This shows the percentage yield of the objects executed by people. For example, if a
person executes just one Personal Task that has a duration of 4 hours in a working day of 8 hours,
their performance will be 50%.
- Cost ($). This is calculated automatically with the cost of each object during the simulation run
time.
The last column shows an icon with the status of the configuration of each object:

- -
A hyphen ‘ ‘ indicates that the object has no specific configuration for the simulation.
- ! – The red exclamation mark indicates that the object requires configuration. If it is not config-
ured, the simulation will run with default values, for example:
o TP, IM, EM, TS, FN and ET. These objects will have no estimated execution time or costs.
o The DX gateways will equally distribute the number of outlets.
o The DO gateways will allow the flow to pass through just one outlet.
o The CO gateways will allow the flow to pass every time the current arrives.
- ! – The blue exclamation mark indicates that the object is partially configured for running the
simulation.
The red exclamation mark ( ! ) will change to blue ( ! ) if the configuration of an object is entered
for the first time and the Save and Exit button is clicked without making any changes. The default
values explained above will be used and the exclamation mark will change to blue.
- √- This icon indicates that all the parameters for the simulation have been configured.
The right-hand panel shows the Diagram of the Class of Process:

9.1.1. Object Configuration
The configuration of the objects in the Class of Process for the simulation is performed by clicking on each
object, either in the Grid or in the actual Diagram.
In both cases, the configuration window will open, which is detailed for each type of object below:
9.1.1.1. Personal Task (TP)
The configuration window has two panels: STATISTICAL DISTRIBUTION and COST:
STATISTICAL DISTRIBUTION
Given that the time it takes to perform the same task varies depending on the people and/or the circum-
stances, AuraPortal’s statistical simulation allows probabilistic calculations to be applied to the duration of
the BPM objects. This is the case with Start (IM) and Intermediate (EM) Messages and Personal (TP) and
System (TS) Tasks.
For this purpose, AuraPortal offers the most common Statistical Distributions which cover practically all the
necessary simulation possibilities. They are grouped in four sections according to the nature of their distri-
bution (FIXED VALUE, CONTINUOUS, DISCRETE and UNKNOWN).
Select the desired distribution in the configuration window of a Personal Task (TP) (previous image) and fill
in the options.
The details of the FIXED VALUE section are explained below:

FIXED VALUE
This option is used when the duration is known in advance with a fixed value and therefore there are no
deviations. For example, if it has been confirmed that the duration of a System Task (TS) is always 15 sec-
onds, the Fixed Value option will be used and this way all the executions of this task in all the processes
that are executed throughout the simulation, will take the same time of 15 seconds, without statistical vari-
ation.
The configuration panels are titled PARAMETERS and CHRONOMETRICS:
- PARAMETERS. In this panel the only configuration parameter is Media, where the estimated aver-
age times desired for the duration of the object in the simulation is introduced. The data are in-
troduced in the Months, Days, Hours, Minutes and Seconds fields (30 minutes in the image be-
low):
If values higher that the context of the fields are introduced, they will be recalculated automatical-
ly. For example, if 70 minutes is indicated, it will automatically be converted to 1 hour and 10
minutes.
In the Days and Hours fields, the calculation is based on the Hours per Day and Days per Month
values. This way, if 16 hours are indicated and Hours per Day is limited to 8 hours, it will automati-
cally be converted into 2 days.
Note.
By default, all the objects have a minimum duration of 1 second during the run-
ning of the simulation. This time can be modified in the Start (IM) and Intermedi-
ate (EM) Messages, Time Events (ET), Personal (TP) and System (TS) Tasks. This
cannot be modified in the other objects, so they will always count last 1 second.
This is the case in the Gateways (CA, CX, CO, DA, DX, DO), Collectors (CL), Col-
lapsed Subprocesses (SP) and End of Subprocess Events.
- CHRONOMETRICS. In this panel the Alerts and Alarms are determined for controlling that the ob-
jects are terminated before a specific time, from the beginning of the process:
o Alert. Here we indicate the maximum time accepted from the start of the process until
the warning is triggered (1 Hour in the image). In the running of the simulation, an or-
ange counter will be displayed numbering the objects that are terminated after the indi-
cated time.

o Alarm. In the Alarm field, we indicate the maximum time accepted from the start of the
process until the warning is triggered (1 Hour and 15 Minutes in the image). In the run-
ning of the simulation, a red counter will be displayed numbering the objects that are
terminated after the indicated time.
All the configuration details for the other distributions are explained in the STATISTICAL DISTRIBUTIONS
chapter further on in this document.
COST
In the COST panel of the Personal Task configuration window (shown below), values can be indicated for
controlling the cost of the personnel required for the execution, with two parameters: Execution and Cost /
Performer:
- Execution. Here it is possible to define whether or not the object is going to be executed in paral-
lel by several employees at the same time. In the attributes for the real execution of the Task, this
simulation configuration corresponds to the assignment of a Parallel Employees Group as Per-
former. When the current reaches the object, each of the users belonging to the Group will re-
ceived a task.
Note.
If the Employees Group is Exclusive, the Task will only be executed by one of the
members of the Group, not by all of them, as is the case with a Parallel Employees
Group.
Cost / Performer. The cost per performer can be indicated per working day or per month, as desired. With
either option, the system will calculate the costs during the running of the simulation.
9.1.1.2. Start Message (IM)
The configuration window for the simulation parameters in the process Start Messages (IM) is the follow-
ing:

For details on the possible values to configure, refer to the section about the configuration of the Personal
Task (TP) described previously.
Take note that in the Start Message configuration, no Alerts or Alarms are indicated, nor Parallel Execution.
9.1.1.3. Intermediate Message (EM)
The configuration window for the simulation parameters of the Intermediate Messages (EM) in the process
is the following:

The configuration of the Intermediate Messages (EM) is the same as the Personal Tasks (TP). The only dif-
ference is that in the COSTS it is not possible to select Parallel Execution; with these objects it is not appli-
cable.
9.1.1.4. System Tasks (TS)
System Tasks are not performed by people; the BPMS Motor is in charge of executing them. For this rea-
son, for simulation purposes, their configuration only takes into account the temporal values, not costs,
because the costs only apply to people:
9.1.1.5. DX Gateway
The DX Gateways allow just one current arrival and multiple possible outlets, but only one is active. When
the flow arrives, it will continue through the first outlet that meets the conditions.
For simulation purposes, the conditions are based on the percentage distribution of the outlets. Thus, the
configuration is based on determining the percentages of the process current that will exit through each
outlet.
The configuration window is the following (an example of a Gateway with 4 outlets):

A double, horizontal arrow ( ) will appear on pacing the cursor of the mouse over each of the blue
squares that separate the gateways. Click on it and drag the cursor to the left or right to modify the per-
centage of flow that each outlet will use for the simulation.
As this type of Gateway only allows each flow arrival to exit through one outlet, the outlet used in the dif-
ferent simulation executions will depend on the indicated percentages.
9.1.1.6. DO Gateway
The DO Gateways allows just one current arrival and multiple possible simultaneous outlets, depending on
the conditions. When the current arrives, the flow will continue through all the outlets that meet the condi-
tions.
For simulation purposes, the conditions are based on the percentage distribution of sets of outlets.
The configuration window is the following (an example of a gateway with 4 outlets: Notify, Management,
Calculations and Administration):
In the example above, we can see that 3 sets of conditions have been created with the following percent-
ages:
- 50% of the current will continue through all of the outlets at the same time ( Notify, Management,
Calculations and Administration).
- 25% of the current would continue through just the Notify and Administration outlets.

- 25% would continue through just the Notify outlet.
The total of all the sets must add up to 100%.
9.1.1.7. CO Gateway
The CO Gateways allow multiple current arrivals but just one outlet, which will only become active once the
flow has arrived from all of the inlets that meet the established conditions.
For simulation purposes, the only thing to determine is the number of expected inlets.
The configuration window is the following (an example of a gateway with 2 inlets):
It is only necessary to indicate the number of expected arrivals in the Number of Arrivals field.
9.1.1.8. End Events
The End Events (of Processes and Subprocesses) allow the configuration of Alerts and Alarms, which have
already been explained previously:
9.1.1.9. Time Event
Time Events allow the configuration of the time the current will be detained after arriving at the object,
including statistical distributions:

9.1.1.10. Objects that don’t need configuring
The following objects do not require any configuration for the simulation:
- DA Gateways. The current continues through all of the outlets at the same time.
- CA Gateways. The BPMS Motor waits for the current from all the inlets before it continues.
- CX Gateways. The flow will continue each time a current arrives.
- Collector. As with the CX Gateway, the flow continues each time a current arrives.
- IS Event. The start event of a Subprocess does not need configuring because its only function is to
pass the current to the Subprocess.
- EL Events. The Link Events do not need configuring because their only function is to pass the cur-
rent to the destination EL Event.
9.1.2. Statistical Distributions

Given that the time it takes to perform the same task varies depending on the people and/or the circum-
stances, AuraPortal’s statistical simulation allows probabilistic calculations to be applied to the duration of
the BPM objects. This is the case with Start (IM) and Intermediate (EM) Messages and Personal (TP) and
System (TS) Tasks.
For this purpose, AuraPortal offers the most common Statistical Distributions which cover practically all the
necessary simulation possibilities. They are grouped in four sections according to the nature of their distri-
bution:
- FIXED VALUE. This option is used when the duration is known in advance with a fixed value and
therefore it is not susceptible to deviations. For example, if it has been confirmed that the dura-
tion of a System Task (TS) is always 15 seconds, the Fixed Value option will be used and this way
all the executions of this task in all the processes that are executed throughout the simulation, will
take the same time of 15 seconds, without statistical variation.

- CONTINUOUS. This is a continuous distribution function, that is, that the results can vary within
the indicated parameters, such as the duration of a task performed by a person. Whereas the du-
ration of a System Task can be fixed, when there is human intervention (as is the case in the Per-
sonal Tasks (TP) and the Start (IM) and Intermediate (EM) Events) the duration is not always the
same; it depends on the variations that may be reflected with the Continuous Distributions.
This group includes the following Distributions: Erlang, Normal, Negative Exponential, Gamma,
Log-Normal and Weibull:
- DISCRETE. The values of Discrete Distributions have a specific number, it can’t be any number. For
example, if warehouse materials are dispatched in just one lorry per day, the possible results are
whole numbers: 1 day, 2 days, 3 days… And if a delivery is prepared 1 minute after the lorry has
left, another whole day will be counted until the next lorry leaves.
This group includes the Binomial and Poisson Distributions:
- UNKNOWN. This is the case when there is statistical distribution but the curve is unknown. It in-
cludes Uniform and Triangular Distributions:
To configure the Statistical Distribution of an object, click on the object in the diagram, or in the grid in the
left-hand panel of the Simulation window, to open the configuration window.
We will look at more details about each of the Distributions in the following chapters.
9.1.2.1. Fixed Value
This option is used when the duration is known in advance with a fixed value and therefore there are no
deviations. All the details of this option have been described previously in this document in the configura-
tion of the Personal Tasks (TP) section.
9.1.2.2. Erlang Distribution
The Erlang Distribution generally best reflects the work carried out by people, where the times are distrib-
uted asymmetrically with respect to the most probable value, giving preference to the elongated times
over the shortened times, which is the case of the execution of the objects in the process diagrams. In oth-
er words, if it is considered that the most likely average execution time of a task is 1 hour, with a deviation

of ±15 minutes, there are generally more cases lasting over 1 hour than lower, meaning that the results
curve is asymmetrical, as shown in the graph outlined in red below:
- PARAMETERS. The configuration parameters for the Erlang distribution are Average and K:
o Average. Introduce the estimated average duration of the object in the Months, Days,
Hours, Minutes and Seconds boxes.
o K. This parameter determines the amplitude of distributed values. The greater the value,
the more concentrated the results will be. In general, whole values are used between 1
and 5, and the most common is K=3.
Note.
The Erlang distribution encompasses the Negative Exponential distribution making
k=1, and encompasses the Gamma distribution making Shape=K and
Scale=Average/K. The results are practically the same as the Weibull and LogNormal
distributions. When the determination of the Average and K parameters is unreliable,
the Normal distribution can be used with the corresponding limits to simulate the
asymmetrical effect that characterizes the Erlang distribution.
- EQUIVALENCES. The equivalences panel shows the Mean and Standard Deviation values that cor-
respond to the introduced parameters. They are calculated automatically and are used to guide
the selection of the suitable parameters for each scenario.

o Mean. In the Erlang distribution, these values will always coincide with the Average pa-
rameters introduced previously.
o Standard Deviation. This refers to the estimated deviation from the Mean value. In the ex-
ample in the image, 15 minutes have been specified, which means a deviation of ±15
minutes from the hour introduced as the Average.
- LIMITS. Besides the introduced parameters, it is also possible to determine limits, both above and
below the Average.
Typical examples of this limits are the following:
o Lower Limit. Imagine that given the characteristics of a task you know that it is not possi-
ble to perform it in less than a specified amount of time. This will be the Lower Limit. If
nothing is indicated here, the value will be zero (0).
o Upper Limit. An example of an upper limit could be in a sale transaction, where the task
to be performed takes as long as the operator takes to perform it. This could be just sec-
onds, but in no circumstances should it take longer than a specified amount of time. This
specified time will be the Upper Limit. If nothing is indicated here, there will be no limit, it
will be infinite (∞).
9.1.2.3. Normal Distribution
The Normal distribution (Gauss-Laplace distribution) is one of the probability distributions that best adjusts
to the true facts, and is represented by a well-known curve, known as the Gaussian bell curve for its shape.

The blue dot at the higher part of the graph represents the Average, or the estimated average duration of
the object.
The horizontal axis shows the different records of the time duration of the object, and the vertical axis
shows the number of times the object is executed during the simulation.
The further away from the Average, the less the probability.
As the distribution is symmetrical, the values above and below the Average are distributed equally, not like
in the Erlang distribution where the higher values prevail.
As most of the tasks performed by people are more suited to the Erlang distribution, there are also cases
where a symmetrical distribution (like the Normal) is more suitable. For example, the duration of marketing
calls to potential customers does not necessarily have an asymmetric tendency.
- PARAMETERS. The configuration parameters for the Normal distribution are the Average and the
Standard Distribution:
o Average. The estimated average duration of the object is introduced in the Months, Days,
Hours, Minutes and Seconds boxes.
o Standard Deviation. This is the estimated deviation from the average value. In the exam-
ple, 10 minutes have been indicated; that is, a deviation of ±10 minutes from the 30-
minute average.
The deviation is represented in the graph with the Greek letter sigma () and marks the
inflection point where the curve starts to flatten on both sides.
- EQUIVALENCES. In the Normal distribution, the equivalences coincide with the parameters.
- LIMITS. As in all the distributions, besides the parameters introduced it is also possible to deter-
mine limits, both above and below the Average:

When limits are established in the Normal distribution, it is general called Truncated Normal distri-
bution.
The Normal Distribution Law or Gauss-Laplace law is one of the most important of all the probability distri-
butions because it reflects a large amount of real phenomena.
It was first observed by Abraham de Moivre in 1733 and was later developed by Gauss in 1774 and Laplace
in 1812. It is represented with a curve well-known for its bell shape, shown in the image below:
For beginners to statistical analysis, in the curve that represents the normal distribution, the distance from
the central value to the inflection point (curvature change) of the curve is known as Standard Deviation and
is represented by the Greek letter sigma (). The standard deviation is a measure of the dispersion of the
values represented. The greater the , the flatter the curve and the more spread out the values are.
The probability that a random value of the studied population is between two given limits (A and B) is de-
termined by the “probability density” in the area between the curve and the vertical lines that indicate
these limits, as shown in the following graph:
The enclosed area between the A and B values is the measure of the probability density, which is calculated
using the following formula:
The P(x) function has a somewhat complex formulation which does not need to be explained here.

In this type of distribution, the probability of distancing from the Standard Deviation () is the following:
50%
± 0.68 
95%
± 1.96 
99%
± 2.58 
99.8%
± 3.08 
The values of the probability density of the area of the curve between + and - is the same for all the
distributions that follow the Normal law, and the area represents 68.26% of the measured values. This
means that in all statistical distributions that follow the Normal Law, 68.26% of the set of values fall within
the area enclosed by the curve and the vertical lines distanced + and - from the central value. If the en-
closed area is between +2 and -2, the probability density will reach 95.44%, and if it’s between +3 and -
3 it will reach 99.7%.
9.1.2.4. Negative Exponential Distribution
The Negative Exponential Distribution is asymmetric and is based on the Poisson statistical distribution, but
using the time it takes to cause a fact as the random variable.
Its applications are similar to the Erlang distributions explained previously, making K (Shape) = 1.

- PARAMETERS. In the Negative Exponential distribution, Average is the only configuration parame-
ter:
The EQUIVALENCES, LIMITS and CHRONOMETRICS panels are the same as those explained previously for
the Fixed Value, Erlang and Normal distributions. Refer to the corresponding sections further up in this
document for all the details.
9.1.2.5. Gamma Distribution
An asymmetric distribution with applications similar to the Erlang distribution:
- PARAMETERS. In the Gamma distribution, the parameters are Scale and Shape:
Shape allows decimals.
It is equivalent to the Erlang distribution making Shape=k and Scale=Average/k.
If the appropriate values are unknown, see the equivalences in the following panel.

9.1.2.6. LogNormal Distribution
An asymmetric continuous distribution with applications similar to the Erlang distribution is some scenari-
os:
- PARAMETERS. In the Gamma distribution, the configuration parameters are Location and Spread:
9.1.2.7. Weibull Distribution
An asymmetric continuous distribution with applications similar to the Erlang distribution is some scenari-
os.
It is equivalent to the Negative Exponential distribution, making Shape = 1.

- PARAMETERS. In the Weibull distribution the parameters are Scale and Shape:
Shape allows decimals.
If the appropriate values are unknown, see the equivalences in the following panel.

9.1.2.8. Binomial Distribution
This is a discrete distribution applicable to a number of correct values against tests that have been con-
ducted.
- PARAMETERS. In the Binomial distribution, the parameters are Trials and Probability:
Probability allows decimals between 0 and 1.

9.1.2.9. Poisson Distribution
A discrete distribution applicable to a number of correct values against tests that have been conducted.
- PARAMETERS. The only parameter in the Poisson distribution is Average:

9.1.2.10. Uniform Distribution
This is the case when there is statistical distribution but the curve is unknown:
- PARAMETERS. In the Uniform distribution, the parameters are Minimum Value and Maximum Val-
ue:

9.1.2.11. Triangular Distribution
This is an unknown distribution which is only used when the only information available is related to the
measurement limits and the most probable value of the measurement:
- PARAMETERS. In the Triangular distribution there are three parameters: Mode, Minimum Value
and Maximum Value:

9.1.3. Running the Statistical Simulation
After configuring all the desired parameters, start the simulation by clicking the Run button in the ac-
tions bar:
The Grid and the Diagram will be filled in with the results during the running of the simulation:
The diagram Counters can be hidden at any time by clicking the button located in the
action bar above the diagram in the right-hand panel. To make them visible again, just re-click the same
button.

9.1.4. Analysis of the Results
The aim of AuraPortal’s statistical simulation is to detect any “bottlenecks” and to quantify the time, re-
sources and costs involved in the processes.
Depending on the complexity of the process being studied, the analysis of the simulation results may re-
quire multiple executions with different parameters, and although the number or executions may be high,
this is never a problem with the AuraPortal statistical simulation because it is capable of simulating years of
work in just seconds.
The possible “bottlenecks” are analyzed from several different perspectives:
- Number of completed objects compared to the flow arrivals. Depending on the scenario, you
may wish for the objects the flow has arrived at to have sufficient time to be completed before
the process terminates in another part of the diagram. The AuraPortal Statistical Simulation pro-
vides information about the difference between the number of flow arrivals and completed ob-
jects.
- Chronometrics of the completed objects. The completed objects show the results of whether
they have been terminated within the expected time, or if they have entered Alarm or Alert
stage.
- Occupation percentage of the objects. It is also useful to see the percentage of time use of all
the objects within the process, to see where most time and resources are being spent.
The resulting values and calculations are filled in throughout the execution in the Grid and Diagram. From
the example in the previous image, the following things require some attention:
In the upper left-hand panel:
- PERSONAL RESOURCES COST – Deviation. From the $10.000 expected cost, there is a deviation
of $12,383.56.
- PERSONAL RESOURCES COST – Personnel Performance. The performance of the personnel is

19.96%, a long way off the optimum 100%.
In the Grid:
- 1.TP.6. Of the 1000 completed 1.TP.6, 318 have reached the Alert time and 299 the Alarm time.
- 1.TP.8. The 299 completed 1.TP.8 have reached the Alert time.
- Performance. Note that all of the values are in red and most of them are a long way off the opti-
mum 100%.
In the Diagram:
During the execution of the simulation, the objects that receive current will light up with different colors
depending on their chronometrics. See the examples below:
Green when the object terminates within the expected time.
The element counter can be seen inside each object, showing the
completed objects according to their chronometrics, in this case:
None have completed in Alarm time.

None have completed in Alert time.
1000 have completed within the expected time.
Orange when the object has completed in Alert time. In this case:
None have completed in Alarm time.
299 have completed in Alert time. If any object has reached the
Alert, it will be shown in orange even though some objects have
completed within the expected time.
None have completed within the expected time.
Red when the object has completed in Alarm time.
In this image there is a Personal Task followed by an End Event,

both with the same result:
243 have completed in Alarm time. If any object has reached

the Alarm, it will be shown in red even though some objects have
completed within the expected time or in Alert time.
None have completed in Alert time.
477 have completed within the expected time.
In the objects that don’t have chronometrics, the counter shows

the number of times the current has passed through it. This is the
case with Gateways, Link Events, Collapsed Subprocesses and
Subprocess End Events.
As has been mentioned previously, every time the current passes

through an object with no specific Chronometrics, 1 second will be
added to the duration of the simulation execution, with the excep-
tion of the Process End Event which doesn’t add anything.
Once the simulation is complete, the Charts and Graphs button will become active in the actions bar:
Clicking this button will open a window with all the details of the results already seen, as well as displaying
them in graph format.

General
The General tab shows the same data that we have seen in the simulation execution, with the possibility of
exporting them to a file in PDF format:
In the Description field, write the description you would like to appear in the PDF document.
The following tabs display graphical analysis of the obtained results:

Arrivals / Completed
The Arrivals / Completed tab shows bar charts comparing the number of times the flow has arrived at the
objects with the number that have actually been completed. If any processes are completed before some
of the objects where the flow has arrived, the number of Arrivals will be greater than the number of Com-
pleted.

Chronometrics
This tab compares the three chronometrics parameters of the objects; completed in Alarm time, Alert time
or within the Expected time:

Runtime Objects (%):
This tab shows a pie chart which proportionally distributes the runtime of the objects over the total
runtime of the Processes.
9.2. REAL SIMULATION

Besides the Statistical Simulation, AuraPortal also offers Real Simulation.
Unlike the statistical simulation, the real simulation offered by AuraPortal is at the fingertips of not just the
designers of the processes, but also the business managers and analysts, so that they can easily perform
simulations on running processes in real working environments.
The power of the real simulation offered by AuraPortal is based on two important characteristics. Firstly,
the possibility of interchanging the “Development Environment” and the “Testing Environment” modes of
the process design as many times as necessary. And secondly, the enormous flexibility available when
modifying the process designs, both on a Diagram level and the attributes of the objects, which allows
improvements, adjustments and corrections to be made at any time and very quickly.
Combining both possibilities, the real simulation can be focused on in two ways:
- Quick execution

- Execution in production
9.2.1. Quick Execution

This procedure involves using the real processes themselves in the Testing Environment offered by Au-
raPortal and making then function provisionally in “quick format”.
The way of implementing this type of simulation depends on the scenario, but here are a couple of exam-
ples to get an idea of its scope:
- Example 1. Variation of the Performers. A complex workflow which affects a large number of
different users can be analyzed by altering the identity of the performers, so that just one or two
people receive and execute all the tasks that would normally correspond to a large number of
performers. This makes it possible to check the process execution threads, determining the real-
time usage in each task and checking their suitability. The results obtained are a reliable reflection
of what will really happen when the process is executed in the real production and everything can
be tested previously without risk and with high accuracy, with the participation of just one or two
people.
The way to modify the identity of the performers depends on the design of each case, but it can
be as simple as temporarily substituting (for the duration of the simulation) the users belonging
to the Roles (Singular and Generic for employees and Account Profiles for External and Guest
users).
- Example 2. Variation of the Diagram. If you want to verify just one part of the Diagram, which
can be difficult or slow to reach through the normal execution from the start of the process, just
add a DX Gateway close to the IM, followed by an “origin” Link Event. This way, as soon as the
process starts, the current will always flow directly to the desired part of the Diagram, where the
corresponding “destination” Link Event will also have been placed, followed by a Collector or a CX
Gateway.
These temporary changes in the diagram will greatly ease the real simulation tests in complex
scenarios, as several successive processes can be started to quickly reach the part of the Diagram
being analyzed.
Note.
If values are required to perform these tests that are normally introduced from the Di-
agram objects that have been bypassed in the simulation, the UPLOADER System Task
or similar can be introduced provisionally.
These scenarios really highlight the comparative advantages of AuraPortal. In effect, when performing the
simulation, any errors or lack of performance that may be detected in the process can be modified imme-
diately bypassing to “Development Environment” mode, and these modifications can also be tested imme-
diately in execution by returning to “Testing Environment” mode, with no need to perform any program-
ming. And this can be done as many times as necessary very quickly. This is also the case if you just want to
check the behavior of the process, trying out different parameters in the System Tasks, the Personal Tasks
or other objects in the design.
Unlimited “what-if” scenarios can be simulated passing from “Testing Environment” mode to “Development
Environment” mode, as many times as you wish and in just minutes or hours, compared to the weeks or
even months it takes to perform similar simulations with other BPM systems that require programming to
implement the modifications.

The real simulation can provide significant time and cost savings in consultancy jobs, because it makes it
possible to see in advance what will happen in reality, making it possible to detect and solve design prob-
lems in a much shorter time. And not only when performing the initial implementation, but also when any
modifications are made to the Classes of Process.
9.2.2. Execution in Production

Generally, once the design of the Class of Process is complete, it is passed to “Production Environment”
Mode so that users can start and execute the processes with real data. In this mode, it is not possible to
change the design and the only way to make modifications is via a new version of the Class of Process. This
is the normal, planned operation.
However, it may be valid in some scenarios to work temporarily with processes with real data in “Testing
Environment” mode. This way, adjustments can be made to the design at any moment before definitively
completing it. In other words, the design may be left open until its suitability has been demonstrated
through the real execution of the users. In this scenario, the changes to the design of the running process-
es must be made with sufficient knowledge of their consequences so as not to affect the processes that are
running at that moment.
Note.
The configuration parameters for the object simulation can be included in the ex-
port document by marking the corresponding option. Refer to the chapter about
Export in this document for more information.

Modeling 02 Diagram 01 HeliumModeler EN 20180928 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modeling 02 Diagram 01 HeliumModeler EN 20180928 PDF

Uploaded by

Copyright:

Available Formats

Modeling

Diagram. Helium Modeler

1. STARTING AURAPORTAL HELIUM MODELER ................................................................................................... 12

2. PREPARING THE CANVAS.................................................................................................................................... 13

3. CREATING THE DIAGRAM .................................................................................................................................... 22

MODELING. DIAGRAM. HELIUM MODELER Page 2 of 97

6. DIAGRAMMING EXAMPLE .................................................................................................................................... 43

7. CONVERTIBILITY BETWEEN FORMATS.............................................................................................................. 46

8. OBJECTS GALLERY .............................................................................................................................................. 48

9. SIMULATION OF PROCESS EXECUTION ............................................................................................................ 60

MODELING. DIAGRAM. HELIUM MODELER Page 3 of 97

0.1. Life Cycle of the Processes

Here is a brief description of each of the stages:

MODELING. DIAGRAM. HELIUM MODELER Page 4 of 97

0.2. Two formats of AuraPortal Helium Modeler

1. AuraPortal Helium Modeler, which comes integrated in the AuraPortal application.

MODELING. DIAGRAM. HELIUM MODELER Page 5 of 97

1. The AuraPortal Complement

Click Install. When the installation is complete, click Finish.

MODELING. DIAGRAM. HELIUM MODELER Page 6 of 97

2. The access to the Modeler

3. The language of the Modeler

4. Running the Simulation

or from the Modeler itself:

MODELING. DIAGRAM. HELIUM MODELER Page 7 of 97

0.3. Two Modeling Tools

1. AuraPortal Helium Modeler

MODELING. DIAGRAM. HELIUM MODELER Page 8 of 97

0.4. The BPMN Standard

MODELING. DIAGRAM. HELIUM MODELER Page 9 of 97

MODELING. DIAGRAM. HELIUM MODELER Page 10 of 97

MODELING. DIAGRAM. HELIUM MODELER Page 11 of 97

To create a diagram, you must:

1. Prepare the canvas (text style, language, pages, bands, etc.).

2. Draw the diagram, carrying out the following three actions:

- Place the Objects on the canvas.

MODELING. DIAGRAM. HELIUM MODELER Page 12 of 97

2. Version Control. If working from AuraPortal, on clicking Save Diagram, the

If working with Standalone (independent of AuraPortal), on clicking Save As you

2. PREPARING THE CANVAS

MODELING. DIAGRAM. HELIUM MODELER Page 13 of 97

2.1. Basic Diagram Options

- Save and Exit

2.2. Basic Edit Options

MODELING. DIAGRAM. HELIUM MODELER Page 14 of 97

2.4. Basic Configuration of the Pages

- Grid. To configure the characteristics of the Grid to optimize its use.

2.5. Basic Configuration of the Text Style

MODELING. DIAGRAM. HELIUM MODELER Page 15 of 97

2.6. Language Configuration

2.7. The Pages

MODELING. DIAGRAM. HELIUM MODELER Page 16 of 97

2.7.1. Using Bands

Working with Bands is not compulsory.

The Bands can be Horizontal or Vertical.

MODELING. DIAGRAM. HELIUM MODELER Page 17 of 97

2.7.2. Adding Bands

- To select a band already in the page, just click on it.

MODELING. DIAGRAM. HELIUM MODELER Page 18 of 97

making it possible to minimize the bands independently.

MODELING. DIAGRAM. HELIUM MODELER Page 19 of 97

MODELING. DIAGRAM. HELIUM MODELER Page 20 of 97

2.7.4. Coloring Bands