Cloud Events in OE

Learn how you can use Cloud Events in OE.

OE uses the Cloud Event specification when responding to, or sending out events. OE uses this to receive information about an event from the related endpoint that is responsible for passing the event information.

OE uses CloudEvents specifically with HTTP Protocol Binding and Binary Content Mode, where currently we support application/json only as a content-type for the data payload.

To learn more about CloudEvents, check the following documentation:

• CloudEvents

• HTTP Protocol Binding for CloudEvents

• CloudEvents spec

To set up OE to work with cloud events:

1. Make sure the authentication works properly and the relationship between the endpoint you use for receiving events and OE 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 OE, check the Events Authentication and Configuration guide.

1. To run a digital process, start a trigger that is specifically configured to set off the process. The trigger for the first step must specify values of the following headers, which are cloud event specifications adopted by OE:

   • 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 cloud event body signed with the OE webhook secret

The event type that is configured as a starting point cannot have the ce-instanceid (OE Instance ID) defined.

If you have a ce-instanceid header defined, the start trigger ignores it as the header is used only for restarting an existing digital process instance. Moreover, ce-instanceid 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.

1. Running the OE digital processes allows 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 process guide.

1. To wake up a paused 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-instanceid (OE instance ID) defined. OE 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 proper digital process instance.

To learn how to set up the ce-instanceid, check the Setting a Trigger to Wake Up a Paused Digital Processes documentation.