Gateway PDF

5/23/2017 3.
2Gateways|Documentation@ProcessMaker
GettingStarted Tutorials UserGuide DeveloperInfo SysAdministration
HelpfulResources Sitemap
Search
3.2Gateways
Version: 2.x 3.0 3.1 3.2
Overview Contents: [hide]

1. Overview
Gateways are elements used to control how the ows among 2. AddingaGatewaytotheProcessMap
elements of the design interact. This means, they act like a A. QuickToolbar
mechanism that controls, denes and regulates ows based on B. DefiningtheGatewayDirection
routing rules set for this purpose. There are three types of gateways
C. DefiningtheGatewayType
available in the process map of ProcessMaker v.3.0.
3. GatewayConsiderations
Exclusive (XOR) Gateways A. LoopDesignonGateways
Parallel (AND) Gateways B. GatewaysandtheProcessMakerEngine
Inclusive (OR) Gateways C. GatewaysandIntermediateEvents
D. GatewayRoutingRulesPriority
Adding a Gateway to the Process Map 4. GatewayRecommendations
The three gateway shapes are in the shapes toolbox at the upper part 5. ExclusiveGateway
of the designer. A. GatewayConfiguration
B. ExclusiveGatewayExample
6. ParallelGateway
A. ConvergingParallelGateway
B. ParallelGatewayExample
C. DeleteaParallelGatewayfromtheProcessMap
7. InclusiveGateway
http://wiki.processmaker.com/3.2/Gateways 1/46
5/23/2017 3.2Gateways|Documentation@ProcessMaker
A. GatewayConfiguration
B. ConvergingInclusiveGateway
C. InclusiveGatewayExample
D. DeleteanInclusiveGatewayfromtheProcessMap
8. GatewaytoGateway
9. DefaultFlow
A. DeleteaDefaultFlowfromtheProcessMap
To add a new gateway, simply drag and drop the element onto the process map.
Edit the description of the gateway by right clicking on it and selecting the Edit Label option or, double clicking on the gateway
label.
Enter the new label of the gateway after the editing has been enabled.
If no description is needed, simply erase the text and the gateway will be left blank. If a label is needed later, right click on the
gateway and select the option Edit Label again.
Quick Toolbar
A QuickToolbar has been implemented on each element of the Process Map, to add the next possible element of the gateway by
just clicking on it.
A gateway can be connected to a task, an end event, another gateway or the ow to an element already added in the process
map. The conguration option will also appear in the options of the gateway as well as the delete option.
For example, to connect the gateway to a task, click on the task symbol, then drag and drop it onto the Process Map.
Dening the Gateway Direction
After a gateway has been added to the Process Map, its direction will automatically be selected depending on how many
connections it has. When a gateway has one input ow and several output ows then it will automatically be a "Converging" type
gateway. But if a gateway has several input ows and only one output ow then it will automatically be a "Diverging" type
gateway.
Note: Take into consideration that a gateway CANNOT be diverging and converging at the same time in the same process
design.
Diverging: A Diverging Gateway should have one incoming connection and two or more outgoing paths.
Converging: A Converging Gateway allows the synchronization of multiple branches. It should have two or more incoming
connections and one outgoing connection path.
Note: To make complex routes or more than one outgoing path, it is better to add activities such as the ScriptTask in the
design rather than diverging gateways.
Dening the Gateway Type
The type of gateway can also be changed by right clicking and selecting the Type option from the gateway context menu. Select
any of the three types and the gateway will be changed to the selected one.
Gateway Considerations
Take into account the following considerations before working with gateways.
Loop Design on Gateways
Currently, ProcessMaker does NOT support loop designs made entirely with gateways. The user must include another element
(such as: a task, an event, etc.) between gateways for the process to work.
Gateways and the ProcessMaker Engine
As it is well known, ProcessMaker 3 oers an easy-to-use friendly interface to design processes with all the needed resources to
automate their execution. This interface is the Process Map where all BPMN2 elements and other elements are available for
designing. Now, it is also possible to make any kind of design valid in BPMN2 but take into account that the ProcessMaker engine
does not support the execution of all those BPMN2 elements or some of their combinations.
For gateways, the following combinations are not supported in the execution of processes for gateways:
StartEvents (any type of start event) -> Gateway

(Exclusive, Inclusive or Parallel) Gateway -> IntermediateEmailEvent
Instead, the following are the combinations that the ProcessMaker engine DOES support:
(Exclusive, Inclusive or Parallel) Gateway -> Task

Task -> (Exclusive, Inclusive or Parallel) Gateway
(Exclusive, Inclusive or Parallel) Gateway -> Subprocess (Synchronous)
Subprocess -> (Exclusive, Inclusive or Parallel) Gateway
(Exclusive, Inclusive or Parallel) Gateway -> EndEvent (Empty, Email or Send Message)
IntermediateEvent (any of them) -> (Exclusive, Inclusive or Parallel) Gateway
Gateways and Intermediate Events
An Exclusive, Inclusive or Parallel Gateway can be executed along an Intermediate Event. An example on how these elements
work together will be explained next. Connect a start event with a task and then add a gateway (exclusive, inclusive or parallel)
and connect it to two intermediate events. Use the image below for guidance.
For this example the form executed in the rst task will have only one eld named "Amount" (create a variable that will go with
this eld). The gateway will evaluate the amount given in the form and determine whether it should go into the intermediate
event "Intermediate 1" or "Intermediate 2". To do so, right click on the gateway and select Properties. A window will be displayed
where the routing rule of the gateway and the conditions can be added. Add the conditions as seen in the image below.
For intermediate email events, read thissection to congure an email account that will be used for this example.
After conguring the events, go to HOME > New Case and double click on the example process.
Add an amount in the range of 0 and 50. For this example, the amount 34 has been added. Click on the "Submit" button.
The evaluation in the gateway will route the case to "Intermediate Event 1" and will send the corresponding email to whom it was
congured.
Test the example one more time by adding an amount greater than fty. The amount chosen in this case is 67, which will be
evaluated by the gateway and send the case to the "Intermediate 2" email event.
As seen in the image below, the test was successful and the email has reached the inbox of the person assigned to the event.
Gateway Routing Rules Priority
It is possible to modify the order of the routing rules in the properties of the gateway. The routing rules are set by the design of
the ow of the process in progress, so by default, they have the same order in which they where connected rst. Now the order
of the routing rules can be changed manually (if necessary) with the help of the drag and drop property, aecting the result of the
conditions when running a case.
Right click on any gateway and select Properties. The routing rule window will open.
To drag and drop a condition, locate the mouse near the Delete button or between the Next Task and Condition elds. Click and
do not release the mouse.
Drag the condition up or down and drop it wherever the conditions needs to be. As said before, the order will change the result
of a running case; the condition dropped at the beginning will be the rst priority.
Gateway Recommendations
Take into account the following recommendations before working with gateways:
Before importing processes from previous versions of ProcessMaker into version 3.1, make sure that all diverging gateways
always close their execution threads with a converging gateway of the same type. This includes all type of gateways (Parallel,
Inclusive or Exclusive).
For example, when a ow is divided with a exclusive gateway, the resulting exclusive ow should be consolidated via another
Exclusive Gateway when required.
A gateway cannot be diverging and converging at the same time. This practice is only supported in notation. Moreover, the
ProcessMaker designer does not support it. The ProcessValidator warns against this design error with a message.
Exclusive Gateway
Exclusive gateways are used to select only one path between two or more tasks within a process workow. The decision of which
path the ow will take is based on the evaluation of conditions that dene a unique outcome ow.
Gateway Conguration
To set the routing rules of the gateway, right click on the gateway and select Properties from the gateway context menu.
A new modal window will open where the denition of the path to the next element(s) in the workow is set as well as their
corresponding conditions:
Where:
Add Routing Rule. Click on this button to add a new routing rule, which is a new path in the workow.
Next Task Condition. Select the element where the ow should go if the condition in (3) evaluates to TRUE. The list of
possible paths only includes the existing elements in the Process Map.
Condition. Required eld. Add the condition that, if evaluated as TRUE, will direct the ow to the element set in (2). For
more information, see usingconditions.
@@ Button. To insert a case or system variable inside the condition, click on the [@@] button and select a variable from
the list, then click on the Insert Variable button.
Delete. Deletes the routing rule.
Cancel. Closes the properties window.
Save. Saves and applies all changes in the gateway conguration and then closes the Properties window.
For each possible route out of the exclusive gateway, the conditions are evaluated in the order they are listed in the Properties
window. The rst route whose condition evaluates to true will be taken, and the remaining conditions in the gateway will not be
evaluated. Make sure that at least one of the conditions will always evaluate to true or set a default path to handle situations
where all conditions evaluate to false.
Note: If several conditions in the gateway use the same variable, make sure that conditions higher in the list do not exclude
conditions lower in the list. For example, an exclusive gateway has the following routing rules and their conditions:
Route to Task 2: @@decision=='yes'

Route to Task 3: @@decision=='no'
Route to Task 4: (@@decision=='yes'&&@@contractType=='renewing')
If @@decision is set to 'yes', then the condition for Task 2 will evaluate to true and that route will be taken. The gateway will
never get to the condition for Task 4 to evaluate it. The solution is to move the routing rule for Task 4 to the beginning of the
list, so it is evaluated rst:
Route to Task 4: (@@decision=='yes'&&@@contractType=='renewing')

Route to Task 2: @@decision=='yes'
Route to Task 3: @@decision=='no'
Exclusive Gateway Example
In the example below, the rst task Check order will be connected to an exclusive gateway that will select between the tasks
"Approve Order" and "Reject Order" depending on the documentation provided by the requester of a credit loan. The DynaForm
assigned to the task has a radio (group) eld where the reviewer will choose "Yes" or "No", and the value will be saved in the
variable @@DocumentationReview, which is related to the eld.
To set the conditions that will be evaluated, right click on the gateway and select Properties. A new window will be opened where
the routing rules for the gateway will already be added. Dene the conditions to be evaluated before dening the next task in the
ow.
When running cases, the task "Check Order" will be executed rst, and after the data is submitted, the ow will go to the gateway
where the conditions previously dened will be evaluated.
If the requester has the correct documentation, the radio eld will be marked as "Yes" and the ow will go to the task "Approve
Order".
On the contrary, if the eld is marked as "No" (when the requester does not have the required documentation) the ow goes to
the task "Reject Order".
Parallel Gateway
A Parallel Gateway is also called a Fork because its divided into many tasks with one objective. Parallel gateways are dierent to
other gateways, simply because they do not evaluate conditions or events. Instead, a parallel gateway is used to represent two
tasks that are going to be executed at the same time. Parallel gateways are used to either split the workow into multiple parallel
paths or merge multiple parallel paths. Unlike the other types of gateways, no conditions are evaluated by parallel gateways. Use
the same gateway element to split (diverging) and join (converging) paths.
In the gure below, the workow arrives at a diverging parallel gateway and splits into 2 parallel tasks ("Verify Employment
References" and "Check Credit") that will be executed at the same time.
When a case is routed through this parallel gateway, the following screen will be displayed to the user.
"Verify Employment References" and "Check Credit" will appear as two separate cases in the assigned users' inboxes. The two
dierent tasks must be completed by their assigned users before the case goes to the next task. There is no special order in
which they need to be completed. In the example, both tasks must be completed in order to continue to the task "Evaluate
Application", otherwise this last task won't appear in the user's inbox.
Take into consideration that when working with parallel gateways, the input and output gateway must be the same. Meaning that
if working with a Parallel gateways then the diverging and converging path must use the same gateway (Parallel - Parallel) and
cannot mix Parallel with Exclusive or Parallel with Inclusive. In case this happens then an error will occur when running the case.
Note 1: The ProcessMaker engine does not support the execution of a sub-process congured as "asynchronous" after a
parallel gateway.
If the design of the process includes a section like the gure above, set the asynchronous process(es) and the rest of the
activities in a sequential order instead of using a parallel gateway.
Converging Parallel Gateway
A parallel converging gateway merges parallel paths in a process. It waits until all the parallel paths have been completed before
routing to the next activity in the process.
The parallel paths created by parallel gateways can have as many or as few activities as needed. In the following example, the rst
parallel path has one task, the second has two and the third has three:
Take into consideration the following points:
If one of the cases in a parallel path is cancelled, deleted or never completed, then the process will never route beyond the
parallel converging gateway.
All parallel converging gateways must have a single out-owing connection to another element.
It is important that parallel paths be merged with converging parallel gateways, otherwise, the activity after the paths merge will
be executed multiple times. The image below is an example of converging parallel gateways. It is recommended to use the
parallel gateway in the way the image shows, because it conforms to the BPMN standard and uses a parallel gateway to explicitly
state where the workow splits into multiple paths.
Parallel Gateway Example
In the following example, the rst parallel path has one task, the second has two and the third has three.
Take into consideration the points mentioned before. So the parallel gateway has a task that needs to go through two, three or
more task at the same time as shown in the image, the gateway is diverging to three dierent tasks. This means that three
dierent employees will be working on three dierent tasks to achieve a goal.
For example, the rst task Review of Supervisor will be assigned to the Supervisor, the second task Review of Accounting
Department will be assigned to the Department of Finance and Treasury and nally the third task Review of Internal Audit
Department will be assigned to the Audit Department.
Delete a Parallel Gateway from the Process Map
To delete a parallel gateway from the Process Map, right click to access the gateway context menu then choose the Delete Parallel
option.
Inclusive Gateway
Inclusive gateways are used to create one or more parallel ows based on one or more conditions that evaluate to "TRUE". Use
the same gateway element to split and join paths.
Notice that when working with inclusive gateways the input and output gateway must be the same. Meaning that if working with
inclusive gateways, then the diverging and converging path must use the same gateway (inclusive - inclusive) and cannot mix
inclusive with exclusive or inclusive with parallel. If this happens, an error will occur when running the case.
Gateway Conguration
To congure the gateway, right click and select Properties in the gateway context menu.
A modal window will open to congure the routing rules for the inclusive gateway.
Add Routing Rule: Click on this button to add a new routing rule. A routing rule controls what the next task, sub-process
or end event will be (2) and the condition (3) that leads to those elements.
Next task: Select the next element where the ow should go if its corresponding condition (3) evaluates to TRUE. The list
of available elements only includes the tasks, sub-processes and end events that have already been created in the
Process Map.
Condition: Add a condition that, if evaluated as true, will direct the ow to the next task or end event set in (2). For more
information, see usingconditions.
@@ Button: To insert a case or system variable inside the condition, click on the [@@] button to select a variable and then
click Insert Variable.
Delete: Deletes the routing rule.
Cancel: Discards all changes and closes the window.
Save: Saves and applies all changes to the gateway conguration and then closes the window.
Converging Inclusive Gateway
A converging inclusive gateway merges all incoming parallel paths into a single outgoing path before routing onto the next
element in the process. Take into consideration the following points:
All converging inclusive gateways must have a single outgoing path.

A converging inclusive gateway will wait until all the incoming paths whose conditions evaluated to TRUE have completed
their activities before routing onto the next element in the process. If one of the parallel cases is cancelled, deleted or never
completed, then the case will never route beyond the converging inclusive gateway.
When an inclusive gateway is used to merge together several paths, its type is automatically sets as converging. For example, in
following design:
When the execution of the process arrives at the rst gateway, it will route the ow to "Maintenance Designation" and/or "New
Device Request", depending on whether their conditions evaluate to TRUE or FALSE. If both are TRUE, then two cases will appear
in the inbox. Only after completing both parallel tasks (it doesn't matter which is completed rst), the two parallel paths will
merge at the converging inclusive gateway, and then the process will move onto the "Operation Send" task.
Inclusive Gateway Example
Inclusive gateways tend to be more complicated than exclusive and parallel gateways, therefore, this example will be very
detailed. The process for this example is the following: A specic item is requested to be bought, the list of items includes
"Computers", "Laptops", "Tablets" and "Smartphones". The following conditions made for the purchase of the item will be added
into the inclusive gateway:
If the amount of the item is less or equal than $200, then the Operator is the one who approves or rejects the purchase.
If the amount of the item is greater than $200 but less than $400, then the Supervisor must review to approve or reject the
purchase.
If the amount of the item is greater than or equal to $400 but less than or equal to $600, then Finance must review to
approve or reject the purchase.
If the amount of the item is greater than $600, then the Manager will directly review the purchase to approve or reject it.
Remember, when working with inclusive gateways more than one condition can be True. So more than one person can review
the purchase at the same time, unless the conditions are set not to do this. When the inclusive gateway fullls its purpose to
select which task will follow next, the nal step would be to order the purchase of the chosen item and nish the process.
Begin by creating a start event, connect it to the rst task ("Purchase item"), then add an inclusive gateway that will select one
path among four tasks (because of the conditions in the gateway): "Approve Purchase - Operator", "Review Purchase -
Supervisor", "Review Purchase - Finance" and "Review Purchase - Manager". Connect the "Review Purchase - Manager" task
directly to the "Order Purchase - Manager" task. Add an inclusive gateway to converge all the threads leading from the "Approve
Purchase - Operator", "Review Purchase - Supervisor", "Review Purchase - Finance" and "Order Purchase - Manager" tasks. Right
click on the rst inclusive gateway and set the default ow of the gateway to the task "Review Purchase - Manager", in case none
of the conditions are True. That is why the "Review Purchase - Manager" task will directly approve the purchase and nish the
process. Finally, connect the second gateway to the task "Order Purchase - Manager". The image below shows what the process
should look like.
Create the variables "Items" (string, with options "Computers", "Laptops", "Tablets" and "Smartphones"), "Amount" (oat),
"Approved" and "reviewApproved" (string with the options "Yes" and "No").
Create a new Dynaform named "Purchase Item Form", save and open it in the DynaForm designer. Add a dropdowncontrollabeled
"Item to purchase:" and relateittothevariable "Items". In the same Dynaform add a Textbox control with the label "Amount:" and
relate it to the variable "Amount" created in the beginning. Finally, add a submit button at the end.
The design of the DynaForm should look like this:
Now, assign this DynaForm to rst task and create three more Dynaforms with the same structure for the other tasks. To avoid
repeating the same steps and creating three new Dynaforms from scratch, the best way is to exportandimport the rst Dynaform
and just edit and add the few controls needed. Export the rst DynaForm "Purchase Item Form", then create a new Dynaform
named "Approve Purchase Form" and import "Purchase Item Form". Add a dropdown control labeled "Approve Purchase" and
relate it to the variable "Approved". The elds "Item to purchase" and "Amount" should be congured as "View" in the property
DisplayMode of both eld controls.
Now for the third Dynaform, repeat the same steps as before. Create a new Dynaform "Review Purchase Form" and import the
"Purchase Item Form". Add a Title control labeled "Review Purchase" and a dropdown control labeled "Reviewed for Purchase?"
related to the variable "reviewApproved". The elds "Item to purchase" and "Amount" should be congured to Mode View in the
properties of both controls. Finally create the Dynaform "Order Purchase Form" and import "Purchase Item Form". Add a title
control labeled "Approval" and a dropdown control labeled "Order Purchase" with options "Yes" and "No". The elds "Item to
purchase" and "Amount" should be congured to Mode View in the properties of both controls.
For a more detailed explanation, refer to these pages: How to Create your First Process, Dynaforms, Dynaform Field Controls,
Variables and ImportingandExportingDynaForms
Congure the Steps and AssignmentRules for all tasks.
For the rst task, right click on "Purchase item" and assign the DynaForm "Purchase Item Form" to the users Administrator,
Jared (Operator).
For the second task, right click on "Approve Purchase - Operator" and assign the DynaForm "Approve Purchase Form" to the
user Dawn (Operator).
For the third task, right click on "Review Purchase - Supervisor" and assign the DynaForm "Review Purchase Form" to the user
Jensen (Supervisor)
For the fourth task, right click on "Review Purchase - Finance" and assign the DynaForm "Review Purchase Form" to the user
Craig (Finance)
For the fth task, right click on "Review Purchase - Manager" and assign the DynaForm "Review Purchase Form" to the user
Gabriela (Manager)
For the nal task, right click on "Order Purchase - Manager" and assign the DynaForm "Order Purchase Form" to the users
Administrator, Gabriela (Manager) for nal approval.
Now the most important step for inclusive gateways is to add the routing rules. For this, right click on the rst inclusive gateway
and select Properties. A new window will open where the tasks will be automatically, but the conditions must be added. These are
the conditions for each task:
Task: Approve Purchase - Operator. Condition: @#amount <= 200

Task: Review Purchase - Supervisor. Condition: @#amount > 200 && @#amount < 400
Task: Review Purchase - Finance. Condition: @#amount >= 400 && @#amount <= 600
Task: Review Purchase - Manager. Condition: @#amount > 600
Right click on the inclusive gateway to open the routing rules window. The image below shows what the conditions should look
like to run this process correctly.
Also, right click on the inclusive gateway and select the task "Review Purchase - Manager" as the default ow. In the case all
conditions inside the gateway are evaluated as False, the manager will review the purchase requests sent in the process.
Congure the other inclusive gateway by right clicking and setting the Gateway Direction to Converging.
All congurations needed for this example to work properly have been made. Next, run a case to test every condition added to
the routing rule of the inclusive gateway. To run a case, go to Home > New Case and double click on the name of the process.
All options must be working according to the conditions in the gateway (choose any item for each option, the list is just for
guidance):
Item to purchase: Computers. Amount: 167.
Item to purchase: Laptops. Amount: 200.
Item to purchase: Tablets. Amount: 400.
Item to purchase: Tablets. Amount: 569.
Item to purchase: Laptops. Amount: 1245.
The images above show that each and every condition made in the inclusive gateway is working correctly.
The routing rule conditions can be congured to be evaluated by two tasks at the same time. For example, if two tasks have
similar conditions as in the image below (amount <=600 and amount >=600), the result should choose the users in both tasks to
work in the case if the amount is set to 600.
When running a case and choosing an amount equal to 600, the condition is evaluated as True for two tasks; therefore, the
process will be routed to both tasks at the same time.
Delete an Inclusive Gateway from the Process Map
To delete an inclusive gateway from the Process Map, right click to access the gateway context menu and select the option
Delete.
Gateway to Gateway
It is now possible to execute Gateway to Gateway connections, and the following example will demonstrate how to make a
connection between an exclusive gateway and an inclusive gateway.
Note: Take into consideration that when including gateways in a process, the order of opening and closing gateways must be
respected. The mathematical rules governing brackets are a good example of the expected behavior of gateways. If a set of
parenthesis was opened, it must be closed in the right order. Parent parenthesis cannot be closed without rst closing all the
child parenthesis.
Process Description: The purchase of two items is required but the cost of each item needs to be checked before buying them.
The purchase will be reviewed by the:
Operator
Supervisor
Finance
Manager
Remember that an exclusive gateway will choose only one alternative path while the inclusive gateway can choose one or more
parallel ows based on the conditions given in the properties of the gateway.
The process will start by asking what item to buy and adding the price of that item. Then, an exclusive gateway will have the
conditions set to see if the item costs less than $1000, then it will be approved or disapproved by the Manager and the item will
be purchased depending on the Manager's decision. If the item costs more than or exactly $1000, then it will have to go into an
inclusive gateway where a set of conditions will be added and the tasks will be divided into three. Then, an Operator, Supervisor
and Finance can review the purchase. If none of the conditions are True, then by default the inclusive gateway will be reviewed by
the Manager. The cost will be referred to as "amount". The process is shown in the image below:
Note: When using Gateway - Gateway designs make sure to understand the design of normal gateways rst before using this
for a delicate process. If not used properly it may cause dierent errors when running a case. Also, when using conditions,
make sure to understand what they do before testing a case.
Create a oat-type variable named "amount".
Create three Dynaforms, the rst will have a dropdown control labeled "Item" and a textbox control labeled "Amount". This is the
step for the "Purchase Item" task.
The second will have a dropdown control labeled "Approve?" with the options "Yes" and "No". This is the step for the "Operator
Review", "Supervisor Review" and "Finance Review" tasks.
Finally, the third one will have a dropdown control labeled "Final Approve?" to end the process. This is the step for the "Manager
Review - Order Item" task.
Proceed to add the StepsandAssignmentRules for all tasks.
Now, the conditions in the exclusive gateway are the following:
If the amount is greater than or equal to $1000, then it will go to an inclusive gateway. The condition in the routing rule will
be: @#amount >= 1000.
If the amount is less than $1000, then it will go directly into the nal task where the Manager can approve/disapprove the
order of the item. The condition in the routing rule will be: @#amount < 1000.
The conditions for the inclusive Gateway are the following:
If the amount is greater than or equal to $1000 and less than or equal to $2000, then any Operator can review the case. The
condition in the routing rule will be: @#amount >= 1000 && @#amount <= 2000.
If the amount is greater than $2000 and less than or equal to $3000, then the Supervisor will review the case. The condition in
the routing rule will be: @#amount > 2000 && @#amount <= 3000.
If the amount is greater than $3000 and less than or equal to $4000, then Finance will review the case. The condition in the
routing rule will be: @#amount > 3000 && @#amount <= 4000.
Run the case by going to Home > New Case, and double click on the case to start it.
Gateway to Gateway connections have many options to be tested according to the number of conditions. To prove the Gateway
to Gateway connection works, several tests need to be made.
The conditions for the exclusive gateway are the following:
If the amount is greater than $1000, then an Operator will be in charge of the next task.
If the amount is equal to $1000, then an Operator will be in charge of the next task.
If the amount is less than $1000, then a Manager will be in charge of approving or rejecting the case.
Now, the inclusive gateway conditions should also be met. The conditions tested are the following:
If the amount is greater than $1000 and less than or equal to $2000, an Operator will be in charge of the next task.
If the amount is greater than $2000 and less than or equal to $3000, a Supervisor will be in charge of the next task.
If the amount is greater than $3000 and less than or equal to $4000, Finance will be in charge of the next task.
Finally, if the amount is greater than $4000, the Manager will be in charge of approving or rejecting the case.
Default Flow
The Default Flow of a gateway denes where the ow should go in case all conditions inside the gateway are evaluated to False.
When the default ow of a task is dened, its routing rules are no longer shown in the Routing Rules window because a condition
isn't needed anymore. Therefore, if there was a condition setup for that ow, the condition will be cleared.
To set the default ow, rst right click on the gateway and select the Default Flow option and choose an element. Then, add the
necessary conditions to the other tasks inside the gateway properties. Take into account that this option is enabled in the
gateway context menu only when the gateway has routing rules established in the design (when the gateway is connected to
other elements in the design).
Select the task where the ow should go by default. The line that connects the gateway with the task set by default will be marked
with a (\) mark.
For example, the task "Review Order" was set as default, therefore, when right clicking on the gateway and selecting Properties,
the routing rule will appear as the default ow and a condition is no longer needed, so the eld will be shown as disabled.
Delete a Default Flow from the Process Map
The default ow added can be easily erased by right clicking on the gateway and selecting Default Flow - None. The default ow
will be erased. See the images below for guidance.
DownloadOurApp

ContactUs
+16173403377
AutomateyourWorkflowwithBusinessProcessManagement
SoftwarelicensedundertheGNUAfferoGeneralPublicLicenseversion3
Contactus:mailto:community@processmaker.com
Copyright20002017ProcessMakerInc.Allrightsreserved.

Gateway PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Gateway PDF

Încărcat de

Drepturi de autor:

Formate disponibile

5/23/2017 3.

GettingStarted Tutorials UserGuide DeveloperInfo SysAdministration

Overview Contents: [hide]

Dening the Gateway Direction

Dening the Gateway Type

Loop Design on Gateways

Gateways and the ProcessMaker Engine

StartEvents (any type of start event) -> Gateway

(Exclusive, Inclusive or Parallel) Gateway -> Task

Gateways and Intermediate Events

Gateway Routing Rules Priority

Route to Task 2: @@decision=='yes'

Route to Task 4: (@@decision=='yes'&&@@contractType=='renewing')

Exclusive Gateway Example

Converging Parallel Gateway

Take into consideration the following points:

Parallel Gateway Example

Delete a Parallel Gateway from the Process Map

Converging Inclusive Gateway

All converging inclusive gateways must have a single outgoing path.

Inclusive Gateway Example

The design of the DynaForm should look like this:

Congure the Steps and AssignmentRules for all tasks.

Task: Approve Purchase - Operator. Condition: @#amount <= 200

Item to purchase: Computers. Amount: 167.

Item to purchase: Laptops. Amount: 200.

Item to purchase: Computers. Amount: 250.

Item to purchase: Computers. Amount: 360.

Item to purchase: Tablets. Amount: 400.

Item to purchase: Computers. Amount: 450.

Item to purchase: Tablets. Amount: 569.

Item to purchase: Computers. Amount: 600.

Item to purchase: Laptops. Amount: 1245.

Delete an Inclusive Gateway from the Process Map

Create a oat-type variable named "amount".

Proceed to add the StepsandAssignmentRules for all tasks.

Now, the conditions in the exclusive gateway are the following:

The conditions for the inclusive Gateway are the following:

The conditions for the exclusive gateway are the following:

Delete a Default Flow from the Process Map

S-ar putea să vă placă și