This blog post describes LogicBlocks in the Orches Enterprise Orchestration Engine. LogicBlock is a flexible programming construct that allows single reusable codebase and data structure to perform multiple kinds of operations.
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:
Just as orchestration processors can store literal JSON, retrieve JavaScript from URLs, and use JavaScript to determine payload values, features including processor definitions can use logic to determine runtime property values. For example, rather than specifying in the JSON representation of a processor a literal project identifier for a Webservice API call, you can store that value as a setting in the EOE. In the processor definition, instead of specifying the identifier, use the get_setting() function to retrieve a value specific to the current environment.
As of January 2025, there are seven types of LogicBlocks:
- Literal – The content of the field is a string value.
- Processor – The content of the field is the identifier of an orchestration processor.
- JsonUrl – The content of the field is a URL that returns JSON.
- JsInline – The content of the field is inline JavaScript.
- JsonInline – The content of the field is inline JSON.
- JsUrl – The content of the field is a URL that returns JavaScript.
- WebApi – Not used to determine field values, but to invoke a webservice API.
Orchex uses LogicBlocks:
- to determine values dynamically for what would otherwise be static values in orchestration processor definitions.
- to implement individual stages of orchestration processors.
- To define input payloads for scheduled orchestration processes.
Not all types of LogicBlocks are relevant to all cases where the solution uses LogicBlocks. For example, Orchex uses LogicBlocks to define processor names. In this context, Literal and JsInline are relevant, where Literal is most typical. The identifier of a processor is not typically the key of another processor, nor is it a JSON value, and JavaScript libraries and webservice APIs are not typically relevant to determining the name of a processor. WebApi is only relevant during the stage of a processor that defines values for a webservice API call. Here is the Rust definition of a LogicBlock, the enum that defines the types of blocks, and a substructure used for blocks that invoke Webservice APIs:
Update: The struct and JSON fragments are obsolete. Properties relevant to webserive APIs have moved under a webapi key in the JSON, with a corresponding struct used in the struct.
The definition of orchestration processors makes extensive use of LogicBlock:
In the following example, which is a template for processors that retrieve items from kontent.ai by code_name, method, protocol, domain, rootpath, and path are all LogicBlocks, and qs is a list of LogicBlocks.
This literals for most values but uses JavaScript to calculate root_path and path.
This processor hard-codes the depth query string parameter passed to the Kontent.ai webservice API, which determines how many levels of referenced items to include with the requested item (Kontent.ai modular content). We could change block_type for that logic_block to js_inline and then content to JavaScript that reads this query string parameter for the Kontent.ai API from the payload, or a query string passed to the orchestration process in the HTTP request and defaults to 1 if neither is present.
You may notice two definitions for structures that pass query string parameters: Processor and WebApiProperties. Orchestration uses LogicBlocks defined in the processor (which can contain JavaScript, JSON, URLs, and other literals) to convert values specified in the processor definition to concrete WebApiProperties used to invoke APIs.
deliverystack.net 
4 thoughts on “-Orchex LogicBlocks”