Introduction

In this section, a series of systems / system portions will be listed that require a closer look / revision or maybe a consideration for deprecation / removal.

Systems / Areas to review:

BPMN - Conditional starts

This system works correcly but is not currently used by anyone since it is very limited. It allows a process to be set to start as a response to a script running and being evaluated to true. Due to the current architecture of the process engine this is not very usefull and was only done for the sake of complying with BPMN 2.0.

Some clients demonstrated the need for a complex process to replace the workflow in documents module that would "fit" into this category, where the WeFlow could have inputs that listened for broadcast events (the event could contain parameters that would be passed through to the script) and that could start the process.

It might be easier to have an empty (no script) conditional start (so that it could not be executed manually) and then in the family configs, the process could be selected and called directly (but this would generate a hard dependency between processes engine and documents witch might not be desirable).

Process self documentation system

This is a relatively recent system that allows for the process to generate a human readable report of what it does, so that a client without bpmn understanding might be able to parse it.

This was implemented to the extent that it would allow HSJ (speficic client) to use it, but this left out many WeFlow objects and has not been tested for all types of processes (for example sub processes and boundary events).

It is an interesting system tha if reviewed / completed, might reduce friction between client expectations and WeMake / Roboyo process creation.

Execution edition - Fewer restrictions

This isn't a system but a set of restrictions placed upon a process that is in execution. A process in execution currently can't edit any forms and validation scripts. This should be reviewed so as to remove these restrictions now that the new variable definition system has been implemented.

This allows for certain validation and form fixes to be performed by wemake / client a lot easier, avoiding having to edit database records to do so.

Any option that does not compromise data integrity (variable definitions) or process flow (gateway scripts) is safe to be editable in production (for example forms, validation scripts, frontend scripts).

BPMN - Call process

This bpmn object has a great deal of complexity and has never been used! A strong case can be made for removing it / replacing it in the backend for the "empty object" that has no code in init and execute functions.

This component hasn't been tested since the implementation of the new variable system. In order to be fully functional it would need to have a tool that allows for mapping variables from the caller (process) to the callee (sub process) and perhaps some method to obtain a result (callee to caller mapping?).

BPMN - Itteration in place

This bpmn notation allows a given activity to iterate "in place" (without arrows) by a given fixed iterable (usually responsibles for activity). This increases the complexity of the code because the process engine has to take into account that an activity can be iterated by self and by connector (loopback) and has never been used by any client. Also this functionality can be replicated with multiple activities and parallel gateways (although it wont work if you have an undefined number of responsibles, determined by script).

See image bellow for example of itteration in place (marked itteration notation):

BPMN - Boundary events (interrupting and non interrupting)

These bpmn objects do add complexity to the process engine but they are great for creating activities with a time limit (interrupting the activity if the activity is not completed before the boundary event fires).

WeFlow - Flow nodes (collect equivalent)

This set of WeFlow nodes were designed to be used to allow operations to be executed per each variable of a multi variable relation. While visually it appears simple, it is in fact the most complex set of nodes in WeFlow by far.

No client has ever used them, but since they replicate the collect function, they have the potential to be very useful. Also, not many components have been made compatible with these nodes, severely limiting the usability of the flow system to arithmetic.

Bellow is the only usage of the flow, to perform arithmetic calculations in elements of a multiple relation

BPMN - Event based gateway

Apparently i implemented an event based gateway (wow!), no idea if it works! Never ever has it been used outside of tests to be compliant with BPMN 2.0.

BPMN - Signal Events

Redundant with link events and may cause confusion because the current implementation allows signals to propagate outside a process.

WeFlow - Frontend engine

This system is used to allow for dynamic form / data changes in the frontend, while using the WeFlow system (instead of javascript) to do it. This is extremelly limited for now, allowing for basic arithmetic operations (data) or hidding / showing form fields based on data values.

It is in use in HSJ successfully, although the system could be made more efficient (not executing the script on every form / data change but only on the changed that would require the script to evaluate) and better organized (creating scripts on change / on button press / etc).

For now the system does what is supposed to.

WeFlow - "Arithmetic of collection in attribute"

This WeFlow component receives a collection as input and outputs a number while allowing for an attribute to be selected. The correct functioning would be to run either SUM or AVG (also an option) on the selected attribute on the input collection (multiple element relation). However the attributes displayed on the selector are the dynamic attributes in the administration (it should be the attributes present on the input collection (by definition)).

WeFlow - "Flow (collection) elements"

The entire set of flow based components are not working as of now. No idea what might be the problem.

BPMN - Multiple pools!!!

Not even Bizagi has this (probably for a good reason), does not have an impact (inter pool interaction is limited) but still, might cause unforseen problems (no one has ever used this and probably never will, this is even less useful than the call process).

Websocket integration - Basic

Can be used to "inform" the frontend when one event disrupts another event / activity (can only think of when boundary event / terminate event cancels the activity it is attached to, closing the form with a notification stating that the time is up / other reason).

Error disposition system

When a given case has an error (either caused by IMS bug / process design bug or declared throwable (yes, process designer can declare throwables)) then the case is no longer interactible (goes to history) and the activity where the bug happened has a button allowing for the error to be resolved.

This has a few options based on the specific error that occurred, and they have been used successfully at HSJ to resolve errors and return the case back to production.

This system can have several improvements done:

• More dispositions for existing exceptions, allowing for more ways / tools to resolve a bug.
• Reviewing the "Bug signature functionality" so that many cases that suffered the same type of bug, can have the same solution applied to them, en masse.
• New Process engine / WeFlow exceptions with their own dispositions, to improve the ammount of errors that can be solved without the "Manual redirect".
• Locking out the "Manual redirect" behind a special permission (the ultimate tool, gives the power to change the flow of a given case, which if misused, can be placed in a permanent unresolvable state).
• Very nice to have: A list just for errors (with filters by exception) per process definition, to make finding / mass fixing exceptions easy.

Visualization system

This system allows for the process creator to also create pages related to this process. This system uses the interface system (so it is familiar to those who already create forms for the process) but only allows for the creation of static pages (lists and views for information that already exists and not for forms).

This system has permissions per page (each page is like a report in that aspect), and if the user does not have permissions for a given page, he wont see it.

This allows for controlled information (for example 2 users see 2 diferent pages, each with curated information just for that type of user).

This system is an alternative to allowing all users to have access to the history list (which allows users to see ALL information).

This system has never been used but has low added complexity (it uses the interface system, and that system is non optional), and it might be usefull in the future.