Process - Best Practices

Pay attention to the performance of process tools used

Description:

When using process tools in your process design, the default configuration is to "Run tools sequentially in current thread".
This means tools are executed in a sequential manner in tandem with the end user's current thread, and their execution time is added on top of process instances started or activities completed.

In other words, if a particular tool takes a long time to finish execution, this time penalty is incurred by end users.
On their browser, it will be perceived as the form taking a long time to submit, or in severe cases, the page misinterpreted as "stuck" on submitting the form.

Solution: 

• For tools that are "fire-and-forget" by nature, please consider setting them to "Run tools sequentially in a new single thread" or "Run tools concurrently in multiple threads".
• For tools that interact with external resources like custom query or JSON API, ensure that those services are executing within reasonably expected durations.
• New in Joget DX 9, you can toggle on the Apache Ignite feature to enable support for async caching.
  After a set timeout, any long-running task assignment submissions will be delegated as background tasks, thus freeing up the end user's browser to continue using the app without waiting.
  Behind the scenes, once the task has finished execution and is ready to reach the next activity, Joget then only adds the next activity to the task inbox.

Perform impact analysis before changing process design

Description:

Let's say in PROD, your app is already in use for a while; you already have several real-world running process instances in DB.

For example, let's say you want to change the label of an activity. It just so happens that you have also changed the activity ID from "approval" to "financeApproval", to follow closely with its label.
By doing this, all running process instances that are pending on the "approval" activity will technically no longer exist in the process design, and Joget will be forced to abort those running instances.

Solution: 

• In PROD, always prioritize creating a new app version first, before making changes to a process design.
  This way, Joget does not perform any process migrations, and new process design changes are only reflected on new process instances created.
  Avoid directly changing any process design in PROD, unless absolutely necessary.
• Take into consideration existing running process instances on a particular App Version before making changes to the process design.
• Take caution especially for these scenarios:
  • Changing activity ID or deleting activities.
    Careless modifications to activity ID or deleting activities will cause current process instances that are pending on such activity to be orphaned, and Joget will be forced to abort those running instances.
    Avoid changing activity ID unless absolutely necessary.
  • Deleting any app versions.
    Even though there may be several app versions already ahead, there may still be running process instances that were kept alive since initially started on older app versions.
    Carelessly deleting app versions will cause these running process instances to be orphaned, and can produce unpredictable behaviour.
    When deleting app versions, always check the process monitor to confirm there are no more running instances remaining on such app versions.
  • Changing process ID.
    This is the equivalent of creating a new process design & orphaning the older-named process design. In this case, Joget is forced to abort all running instances that belong to the older-named process design.
• Assess any other means of fulfilling requirements without the need to alter process-related identifiers.
  If a change is deemed necessary, then consider remediation efforts to maintain process data integrity.
  • Using the above example, you can simply change the activity label without changing the activity ID. This will not impact the identifier references for your process instances.

Avoid hardcoded users as process participants

Description:

Process participants can be assigned to users, groups, departments, organizations, dynamically, etc.

However, do keep in mind that employees in an organization are always subject to change.

What this also means, if, let's say, an "approver" participant is explicitly assigned to user "Cat", and this user is moved to a different role or has sought greener pastures, all references to this hardcoded user must be tediously searched and modified.
This increases the likelihood of configuration errors and increases workload for the app developer.

Solution: 

• Wherever possible, always assign to a logical grouping, such as Groups, Departments, or equivalent categorizations.
  

Do you really need a Process?

Description:

Although Process Builder is capable of orchestrating complex workflows and automating tools along with decision routing, we should consider the business requirements.

Let's say the use case is a straightforward public feedback form and storing data into a List. If there is no need for decision routing nor any complex logic required for the workflow, then we simply do not need a process designed for it.

Keep the app implementation as short and simple as it reasonably can. This also helps reduce unnecessary processing overheads and ease app maintenance.

Solution: 

• If the use case does not require the functionality from Process Builder, keep the implementation straightforward.
  Using the above example, public feedback form data can simply be a CRUD component.

Break down large process designs into subflows

Description:

Often, enterprise use cases have elaborate workflows to carry out business operations. This is often reflected in the business workflow diagram.

With the Joget platform, you can essentially plot out a similar replica of your workflows to perform task assignments, automations, etc.
However, do take the opportunity to identify "flows-within-flows" that can be broken down to its distinct process flow.

In the odd case that you have created an extremely large process design, the app developer may face readability and maintenance challenges, which increases the likelihood of configuration errors.

Solution:

• Break down huge process flows into smaller subflows.
  This allows reasonable readability and reduces the chances of configuration errors impacting an entire set of process design.

Use workflow variables for process routing or storing process-related metadata

Description:

Workflow variables are primarily used for process decision routing logic or to store process-related metadata.
You can create as many workflow variables as you wish in a process design. Joget also does not limit the type or size of value assignable to workflow variables.

However, it is not recommended to use them beyond the cases above.
A brief example of misuse is using workflow variables to store form data that is not used for any decision routing whatsoever.

Joget stores the historical trail of workflow variable data as process instances progress through subsequent activity(s). This also means that the same set of workflow variable data is being duplicated each time a new activity instance is created.
This causes unnecessary processing overheads and unnecessary duplicate data stored in the database.

In severe cases of misuse, like let's say, having 80 workflow variables storing large amounts of data & where the majority isn't useful within the process context, this may even cause database performance degradation during high server traffic due to the amount of data being replicated over and over for every progressed activity.

Solution: 

• Consider if a value needs to be stored into a workflow variable.
  For example, if you are merely referencing form data one-time for decision routing, you can simply use a Form Data Hash Variable to directly retrieve data from the form table.
• Avoid storing very large values into workflow variables (e.g., CSV data).
  Consider other suitable means, such as storing into a hidden field in a form which effectively "hides" it from plain view in the browser.

Prefer decision rules over transition rules

Description:

Prior to Joget DX 8, business rules implementation must be performed on transition lines in the Process Builder.
This approach is no longer recommended as it is difficult to change business logic without redeploying the whole process design of the entire app.

The current best practice is to implement business rules via decision rules on Routes.
This method also provides a more intuitive if-else condition that app developers will be familiar with, and allows for complex condition groupings and rule negations.

To add on, starting from DX 8, Route decision rules will take higher precedence than transition rules. 

In other words, if Route decision rules exist, all transition rules leading up to the route will be ignored.

Solution:

• Use decision rules on Routes. Do not use transition rules.
• If the app was built prior to DX 8, you can convert all transition rules to decision rules on Routes.

Naming convention for process-related identifiers

Description:

Use lower camel case for all process-related identifiers, such as Process ID, Participant ID, Activity/Tool/Route ID.
And as per expected practice for any identifiers, ensure all identifiers used are unique and do not unintentionally reuse the same exact value.

The reason for this practice is that Joget displays process instance ID & activity instance ID in a concatenated format with snake case. This format will appear often in logging and Monitor info.
Format such as:

{ActivityId}_{ProcessId}_{AppId}_{ProcessDefId}_{activityDefId}

If your activity definition ID uses snake case, it can be confusing to interpret the names and separators.

Solution:

• Use lower camel case for all process-related IDs.
  Meaning, all words do not have spaces in between, and the first letter is not capitalized.
  Example: purchaseRequest, myFancyRoute