Cloud events
Orchestration Engine uses the Cloud Event specification when responding to, or sending out, events. Orchestration Engine uses this to receive information about an event from the related endpoint that is responsible for passing the event information.
Orchestration Engine uses CloudEvents specifically with HTTP Protocol Binding and Binary Content Mode, where currently we support only application/json as a content-type for the data payload.
To learn more about CloudEvents, check out:
To set up Orchestration Engine to work with cloud events:
The first step is to make sure the authentication works properly and the relationship between the endpoint you use for receiving events and Orchestration Engine is correctly established.
To create the relationship, you should provide source and secret values that are configured for your event-receiver endpoint and used as a signature in every request that is sent.
To learn how to configure authentication details for Orchestration Engine, check the Events Authentication and Configuration guide.
To run a digital process you need a start trigger that is specifically configured to set off the process.
The trigger that is configured as the first step of the process should have the following headers' values specified. The headers are cloud event specifications adopted by Orchestration Engine:
ce-source - source of the environment sending the cloud event, you can enter any source here but it should clearly identify the application that is sending the event
ce-type - type of the cloud event
ce-specversion - version of the cloud event spec (for example v1.0)
ce-id - unique ID of the cloud event, it should be unique with the source when combined
x-emporix-hmac - the hmac signature which is the payload of the cloudevent body signed with the Orchestration Engine webhook secret
Note
The event type that is configured as a starting point cannot have the ce-cxpinstanceid (Orchestration Engine Instance ID) defined.
If you have a ce-cxpinstanceid header defined, the start trigger ignores it as the header is used only for restarting an existing digital process instance. Moreover, ce-cxpinstanceid is bound to one digital process, you cannot have the same id defined and used in triggers for another digital process.
If you want to check the request example you can take a look at the postman environment and postman collection examples at Events authentication and configuration - request examples.
Running the Orchestration Engine digital processes allow the orchestration of multiple Make scenarios. Every Make scenario is combined of various modules that gather data one after another. The first module is always an input for the second module that creates output for the next one and further. While a process instance is running, it can be configured to wait for another event before moving to the next step.
In that case, the process goes to a sleeping state and waits for the next event type.
To learn how the digital processes are created, check the Creating digital processes.
To wake up a paused digital process with an event, and make it move to the next step, you need to send an event that wakes up the trigger. You have to have a unique ID (ce-id) for the event and the ce-cxpinstanceid defined. Orchestration Engine instance ID routes the event to the proper sleeping process instance that is waiting.
You can send many events using this field and they are all be routed back to the correct digital process instance.
To learn how to set up the ce-cxpinstanceid, check the Setting a trigger to wake a paused digital process.