Introduction

In this section each object's functioning will be detailed by processing phase, including potential thrown errors.

Event start none

Nothing special happens in this event, it serves to mark processes that are started manually by the user.

Event start signal

This object triggers on receiving a signal with the same identifier as it has set. On execution it sets that event as resolved and generates the next token process objects.

Information	Details
Image
Required options	signal_definition - Stores the signal identifier

Event start timer

This object triggers when the timer event manager starts it (the process gets added to the timer event manager based on the timer settings set on the object)

Information	Details
Image
Required options	timer_definition - Stores the timer settings

Activity call process

This object has to be created with a setting indicating which process holder to call. When execution starts the activity will call all processes eligible to start in the active revision of the call process, creating a token process for each of the eligible processes. When all token processes return complete, execution ends and the next bpmn objects are determined.

Information	Details
Image
Required options	process_holder_id - Stores the process holder id to call

Activity manual

This object does nothing, it exists to document parts of a process that are not possible to automate (providing context to the process).

Activity script

This object executes a WeFlow script during it's execution phase. The execution is considered complete when the script completes.

Information	Details
Image
Required options	script - Stores the WeFlow script to execute
Systems used	WeFlow scripting system

Activity send message

This object sends a message (using SGI message system) to the set addressees during execution. Execution is considered complete when the message is sent.

Information	Details
Image
Required options	message - Stores title, body and adressees of message
Systems used	SGI - Messaging system

Activity service

This object is the same as the activity script. The execution is considered complete once the script completes. The only diference between activity service and activity script are the WeFlow components made available to the user. Technically speaking both resolve the same way (through the completion of the script).

Information	Details
Image
Required options	script - Stores the WeFlow script to execute
Systems used	WeFlow scripting system

Activity sub process

This activity runs the enbedded sub process. Due to how SGU processing engine works, the enbedded process is technically a separate process (similar to the call process) that just happens to be inside the main process.

During the execution the main process calls the inside process and halts execution.

The execution is considered complete when the inside process reaches the exit event. All variables are "soft copied" (copied by reference) to the sub token process (so any changes made to variables by the sub process, tranfer immediatelly to the main token process).

Activity user

This activity exposes a form to the user and stores the information into the token process variables.

During the initialization phase, any variables required by the interface are instanced, and the responsible users are determined (since it is possible to set the responsible users dinamically, it is possible to have 0 responsible users, in which case the UnableToAttributeUserActivityToAResponsible exception is thrown).

The activity is considered executed when all forms pass all validations (using the laravel validation system) and the user has signaled the intent to complete the task (by pressing submit).

Information	Details
Image
Required options	owner_assignments - Stores the users, groups and company organizations responsible for this activity. Alternativelly it stores variable / attributes where the responsible may be found, or a directive indicating that the responsible is the user that started the process.
Systems used	Interface System - Used to define the page / forms that will appear on this activity.
Errors thrown	UnableToAttributeUserActivityToAResponsible - Thrown when the activity cannot resolve any responsibles for the task. It is a user mistake in the sence that the process creator has to ensure that there are responsibles for all user tasks

Gateways

Introduction

Gateways are special in that they do not do any work like activities but use logic to select which of the outgoing paths to select. They have two modes of processing paths, how they handle incomming paths and how they handle outgoing paths.

Exclusive Gateway

Entry flows pass through as normal. Exit flows are determined via a script, of which one and only one exit flow will be selected. Failure to select any path (due to bugs in the script) will throw the GatewayLogicSelectsNoTargetFlowsException.

If the script returns multiple outgoing flows, the first one will be selected.

Information	Details
Image
Required options	exit_logic - Stores the WeFlow script (with the special caveat that the exit component is used to select the outgoing path)
Systems used	WeFlow scripting system

Inclusive gateway

Entry flows will halt processing untill all incomming flows return resolved. Exit flows are determined via a script, of which one or more exit flows will be selected. Failure to select any path (due to bugs in the script) will throw the GatewayLogicSelectsNoTargetFlowsException.

Inclusive gateways function in a diferent way then every other object in the SGU process engine. Because the inclusive gateway when joining incomming connections has to behave like a parallel gateway, but there is a chance that a previous inclusive gateway only activated a few of the incomming paths. So every inclusive gateway has to look behind to the previous gateways to see which paths were actually activated and wait only for those.

So the first flow to reach the inclusive gateway attempts to init it, the gateway in turn checks all incomming flows to see if they are resolved, and if not, looks back to check if they should be resolved (if that path is activated) by wallking back through the diagram all the way to the previous gateway, and then stepping forward once to check which paths have a token object directly connected to the token object that reached the gateway to init it.

If there are still unresolved paths, the gateway init will throw false, thus never reaching the execution stage. Only when all paths have a resolved token object or report not having been active will the inclusive gateway proceed to execution and next token generation stages.

This scheme even works inside or outside of looping diagrams and self itterating bpmn activities.

The implementation for this bpmn object required the reading of this PDF: bpmn_inclusive_gateway.pdf

Information	Details
Image
Required options	exit_logic - Stores the WeFlow script (with the special caveat that the exit component is used to select the outgoing path)
Systems used	WeFlow scripting system

Parallel gateway

The parallel gateway on exit will flow down all paths simultaneously. On entry, it will wait for all paths. It does not accept a script, this is the default and only behaviour this gateway has.

Information	Details
Image