This area of the documentation will explain how the various components of the processes engine function on a technical level.
The processes engine module is separated into several systems in order to acomplish what is needed to create a complete process from start to finish.
This system is the bpmn process engine. The process engine is concerned only with how the process transitions through the bpmn diagram.
This system provides "programming in the small" capabilities to the processes engine module. It is a visual scripting language that allows integration between process variables, SGU, webservices and connectors.
This system handles registration and disposition of timer events generated by the SGU process engine. Due to how it is implemented, timer events can only be defined with a granularity up to the minute.
This system provides connectors to be integrated into a given process, allowing that process to execute operations on other SGI modules.
In development: For now only documents module is implemented.
This system was created to help WeFlow handle arithmetic and logic operations. It is similar to StringCalc used by the processes engine, except it can handle variables of arbitrary type.
The interface system handles the disposition of data on a given medium. The medium can be the frontend (webpage), pdf or excel. This system basically is responsible for placing forms and tables (for now, more components may be added in the future) as defined by the process creator.
This system abstracts away actions that can be done during a user activity (for now). For example the submit and save actions or a download report action. More actions may be added in the future.
In development - More objects should be added to WeFlow to allow for more conditional starts to be possible like listener triggers.
This system manages and creates conditional events and evaluates them (all conditional events are a WeFlow™ script that returns true when the process can start).
The current conditional is extremely limited at the moment (not a lot that can be evaluated).
This system validates an entire revision (orquestration, processes, bpmn object options, scripts, etc ...) and itemizes all the errors found, so that the user can fix them.
The tag system allows the user / programmer to find any variable instance / attribute by use of a complex tag ${VAR00001.VAR00002.ATTR00001} (for example).
This is primarily used for creating word templates for the word to PDF system, as well as text (frontend - user activity) and messages (title and body).
This is a pair of systems that work together to formalize the process of creating and retrieving the variable instances of a process (in accordance with their definition as far as the relation between the instances, and the attributes thereof).
Contains webservice callers for REST and SOAP. Allows the WeFlow™ scripting language to call a webservice defined in the management area and handle the outputs of that webservice in an abstract way (the WeFlow™ script does not know if a webservice is SOAP or REST).
This subsystem is used by the SGU Processing engine system to determine the "next tasks" in self itterating activities, as well as the break condition for the self itteration.
This system is a holdover from the first scripting implementation (a Lua interpreter). It is currently not in use but remains in case a more direct (but less intuitive) scripting tool is needed. If the decision is made to use this tool, a php extension will be needed.
Also there was a second version of this system that used blockly (frontend programming tool developed originally by google and later deprecated) but still used lua in the backend.
Both v1 and v2 of this system are no longer used in this module, and any references still remaining related to it may be removed from the code.