Hello developers!


While messing around with Light Processes, I've realized that there is a lack of information on how it works, so I've decided to give some tips.

You can already find some information on how to activate and on which conditions a BPT Process will be triggered as a Light Process:

But there is more relevant information that in my opinion we all should know.

Useful information / tips:

  1. Light Processes will skip the execution of callback actions (like "On Process Start")

  2. Light Processes won't allow you to add an Output parameter to the Process (if you do, you'll have an internal error on the compiling step while deploying)

  3. By default, Light Processes have 20 threads per front-end, this threads are separate from BPT threads (normal BPT have 10 threads by default).

  4. If an unhandled exception occurs during the execution of a Light Process, the Scheduler will pick that Light Process again moments later (the number of times it failed to execute will increase how much in the future that process will be picked again, until it reaches a point that it will be picked once a day)

  5. Light Processes are executed on its own transaction (session variables and GetUser() will be empty unless you define them during its execution)

  6. Light Processes execution is asynchronous (the transaction responsible for triggering the Light Process will not be waiting for the execution of the process, the process will run on the background)

When to use?

  • Light processes are intended to be used for background processing

  • Replace timers that don’t require scheduling by Light Processes

  • Replace normal BPT Processes only used for background processing containing only 1 automatic activity

    • Even if the normal BPT Process has more than 1 automatic activity, it might be the case that the main workflow (for the 80% of the cases) could be made with a Light Process and only on the exception scenarios

    • For the exception scenarios a normal BPT would be launched via “LaunchProcess” action

    • This could alleviate the server load on the normal BPT Process threads and use the more performant 20 threads from the Light BPT

    • Light Processes don’t create entries on BPT tables, which means less entries on tables Activity, Activity_Output, Process, Process_Input and Process_Output

How does Light Process actually works under the hood?

  1. When defining an Entity “Expose Process Events = True”, the deployment will create an SQL event table containing information relevant for the following triggers

    • The trigger (mentioned further) will look at this table to know which ProcessDefinition will be used and if is Light Process or normal BPT process

  2. After publish, the deployment step will create an SQL table to handle the events over the “File_Event” user table

  3. Create a BPT Process and define the “Launch On” to “Create <your entity>”

    • When you do this, during the deployment, a new record will be added to the event table OSEVT_xcd_File_Event mentioned under the point 2

      1. _PROCESS_DEF_ID = 52 corresponds to the process Background_ProcessFile

      2. _IS_LIGHT is set to 1 because this BPT Process matches all the conditions to be a Light Process

  4. A Trigger will also be created for the normal user table (in this case for the File_Event)

  5. When a record is inserted in the user table, the trigger will:

    • Query the event table OSEVT_xcd_File_Event to fetch the _PROCESS_DEF_ID

    • Insert on the system SQL table ossys_BPM_Event (next point will explain this table) the fetched information together with the Entity_Record_Id which identify the Primary Key from the user table File_Event

  6. Scheduler is constantly pinging the system table ossys_BPM_Event for a record with Next_Run <= Current Date, once found, it allocates a thread to handle that event

    • The running thread mentions the Event id 10 which corresponds to the record being picked from the ossys_BPM_Event

  7. In case an Unhandled Exception occurs during the execution, the table column ossys_BPM_Event.Error_Count will increase by 1 and the ossys_BPM_Event.Next_Run will be set to moments later

    • The number of times it failed to execute will increase how much in the future the Next_Run will be set, until it reaches a point that it will be set to be picked once a day

To add to that, I think the normal BPT has a timeout of 5 minutes, where for light BPT it is 3 minutes.

Nice article Cláudio