There are the four ways that your application or system can exchange data via Redox:
RESPOND. Each of these actions relates to the type of request, asynchronous or synchronous, and whether or not your application or system is initiating or receiving an inbound request:
|Request Type||Request Direction|
|Asynchronous, one-way requests||——->|
|Synchronous, two-way requests||——–>|
Asynchronous requests are event streams whereby the originator of the data does not wait for a response or verification of receipt from the destination receiving the data.
All asynchronous requests are guaranteed to be delivered at least once and in “first-in, first-out” (FIFO) order. As such, Redox ensures that, for each data stream, each data payload is sent to the desired destination only after it’s predecessor (if any) succeeds.
If a request is successfully processed by Redox, but fails to be accepted by the receiving system, it is automatically retried. After the first failure, Redox will retry the request immediately, then again after another 10 seconds and again after another 10 seconds. After the third retry, the period between retries will increase in the following order: 20, 30, 50, 80, 120 seconds. From there, retries will continue at 120 second intervals until the receiving system acknowledges successful receipt of the data, or they are manually paused by Redox. Automatic retries are only performed in the “Production” environment.
If a request is unsuccessfully processed by Redox, it will not be sent to the intended receiving system. Instead, the payload of the failed request, along with any incoming data payloads after it will be queued to send later. The Redox support team monitors these queues and works to resolve processing failures. Once resolved, the failed request can be manually retried. A manual retry can be initiated from within a specific log entry in the Dashboard.
Asynchronous requests can be duplicated and sent to any number of destinations, depending on how many subscriptions are in place and how many destinations are designated within the request. A single asynchronous request routed to N destinations will generate N log entries.
Synchronous requests are requests whereby the originator of the request does wait for a response or verification of success. In this case, the initiating system may be querying data from or requesting to write data to another system.
In order to translate between each system, these types of requests are processed by Redox twice, once for the original request and again for the response on the way back.
Data Models and Event Types define the type of information that can be communicated between a source and destination via the Redox platform. Specifically:
- Data Models represent the categories of data that can be transacted
- Event Types define specific interactions or data structures for a given Data Model
Data Models describe the categories of data that can be transacted via Redox. Every workflow implemented via Redox must involve a combination of supported data models.
Data Model Reference
Available Data Models and Event Types can be found on our data model reference documentation here: https://developer.redoxengine.com/data-models/
Event Types describe the interactions or data structures that a source and destination system can exchange for a specific data model. As such, each event type is primarily asynchronous (one-way) or synchronous (two-way) in nature.
Asynchronous event types describe a triggering event or a data action (similar to CRUD actions).
Examples of asynchronous event types are:
These event types are primarily used for one-way, event-based data streams where systems
Check out our video explanation
Synchronous event types describe a request that expects a response, such as a query for data, and thus are primarily used for
Most often these event types contain the words
Response. A full list of these event types for each data model is included below for reference:
|Data Model||Synchronous Event Types|
All types mentioned in parentheses above with a “Response” suffix are used to document the expected return format of data from a destination response (log type
RESPOND). They are not separate event types.
The Redox platform (via API or Dashboard) will only ever accept or display the event types without a “Response” suffix.