This blog post explains the stages in the lifecycle of a processor in the Orchex Enterprise Orchestration Engine.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
Before proceeding, see:
Update 10.Feb.2025: I had forgotten that we intend to invoke rules for a rules engine, likely before prerunscript and then again after postrunscript. We’re a ways away from being able to integrate a rules engine though.
Orchestration processors are fundamental components of orchestration processes. Every orchestration process begins by invoking an orchestration processor. In fact, the Processor type in Rust implements the orchestration process, which determines and invokes any processors on which the current processor depends before calling the processor that depends on them.
An orchestration processor is typically used to consume a JSON payload, potentially to invoke a Webservice API, and then to transform that payload and/or Webservice API response to an output payload.
You can implement logic at several stages in each orchestration processor. For simple things you can generally achieve the same objectives by implementing one or two steps, making the complexity seem unnecessary. All these steps have value for testing, reusability, and otherwise, especially considering processor inheritance, API mocking, differences between environments, and otherwise. Additionally, if you do not instruct a processor to do anything at a given step, it generally skips that step.
Security
We haven’t actually implemented this yet, but we need to ensure that the caller can access Orchex and any processors that they request to invoke.
Dependencies
If the processor depends on other processors, invoke those processors first.
Set Payload
Set the orchex_payload variable in the JavaScript virtual machine to its initial value, which the HTTP request to invoke the API may have passed or may be specified in the scheduled process definition.
Set Context
Set the orchex_contex variable, which passes the Orchex context to the JavaScript virtual machine as JSON.
Load Libraries
Determine any JavaScript libraries required by the processor.
It’s worth mentioning that we’re currently using quick_js, which has some limitations in terms of its ability to download libraries, but also apparently requires that we redefine every function every time we invoke a line of code, which has some performance impact. While we may switch to a different JavaScript virtual machine host, this actually shouldn’t be too significant of an issue. Anything that really depends on libraries probably belongs in an application rather than the orchestration engine, which is not intended to implement applications.
In general, unless functions are reusable or you need to define global logic, I would define functions just above the code that uses them rather than using libraries.
Check for Cached Output
Now we check if output from the processor running under the same conditions already exists in the cache and return that if it does. This is when orchestration determines the cache key for the processor.
We couldn’t check the cache until now because we had to run dependencies and load libraries that could have impacted the caching key, although we may add an option to allow processors to check cache earlier in the lifecycle. Optimally, those dependencies also cached their output.
Reset Payload
Now we run the processorpayload LogicBlock in the processor definition, if any.
The purpose of the processorpayload block is to determine the payload or adapt the default payload as required for the orchestration process.
Prerun Script
Processors typically have one main function, which is either a JavaScript fragment or a webservice API call. The prerunscript LogicBlock runs before that main function.
Webservice API
If the processor defines a webservice API, orchestration invokes it at this stage, setting the orchex_response variable in the JavaScript virtual machine to its result.
Main Function
If the processor defines a mainfunction LogicBlock, orchestration invokes it at this stage. This is where you implement the main logic for a JavaScript processor, which may be to mock a webservice API.
Postrun Script
After the main function of the processor, if the postrunscript LogicBlock has a value, orchestration invokes it at this stage. This is where you typically adapt responses from the webservice API and other processors to normalized JSON for the consumer.
Cache Output
If the processor defines cachingoptions, then orchestration caches the output of the processor.
Update Context
After invoking the processor, orchestration adds its output to the Orchex context so that it is available to other processors in the orchestration process.
deliverystack.net 
5 thoughts on “-Orchex Orchestration Processor Stages”