Request-reply component

Overview

The HTTP request-reply connector makes webhooks reply with the data generated inside integration workflows, with the result of massively speeding up the data processing.

Authentication

This component requires no authentication.

Environment variables

For debugging purposes there is:
LOG_LEVEL - trace

debug

info

warning

error that controls logger level.

Asynchronous vs. synchronous messaging

For some integration flow cases, a simple acknowledgement of the messaging receipt is sufficient, since this kind of transmission makes the message delivery more reliable and decouples the sender from the receiver (e.g., G. Hohpe & B. Woolf, 2009). These types of messages are referred to as sender-receiver messaging pairs.

However, in many other cases, a two-way messaging conversation (referred to as a requester and replier messaging pair) is a requirement. First, the requester sends a request message and waits for a reply message. Once the replier receives the request message, the replier responds with a reply message.

These two approaches are called: Asynchronous (sender-receiver / one-way) and Synchronous (requester and replier / two-way) messaging transmission types. All Connect integration flows are asynchronous in nature unless the HTTP Reply or Request-reply component is added. These components enable two-way messaging conversation through the request-reply pattern, transforming the flow into a synchronous one.

Triggers

This component has no trigger functions. Therefore, this component cannot be used as the first one when designing an integration flow.

Actions

Reply

List of Expected Config fields:

  • Custom HTTP Headers - the non-required header names separated by comma (e.g Content-Type, Content-Language)

  • Content Type (default application/json) - the non-required header value tells the client what the content type of the returned content actually is. The component supports only types with text/... or application/... in the beginning of the header name.

  • Response Body - the required field supports JSONata expressions. Max length of a JSONata expression is 1000 symbols.

image

Use cases for HTTP Reply

There are a number of use cases for the HTTP Reply component. Use this component for simple cases (e.g. obtaining an answer from the flow upon completion of the process), through to more complex cases like:

  • Checking the status of information from a database on the availability of a record.

  • Chatbots as a separate application.

  • Communication between Connect as the back end and a third party mobile application as the front end.

Example: Advantage of Synchronous messaging

As a typical scenario, an integration flow is set to expect an incoming message via a WebHook, which is then processed further. The only acknowledgement that is given in this case is a simple 'thank you' message from the WebHook.

{
  "requestId": "lv25ymyo15twhgp",
  "message": "thank you"
}

The sender has no knowledge of what happened to the message. Assuming normal functionality, a message from outside would trigger the integration flow to execute without providing a verbose response. This type of communication is asynchronous communication.

If an immediate, meaningful, and configurable response is required, then it is better using the HTTP Reply in your integration flow. Here is a typical response from an already-configured requester and replier / two-way pattern:

{
"notification" :"A message was submitted by John Newman",
"subject" : "Sender used a subject Hello",
"email" : "Email was sent by john.newman@example.com"
}

Request-reply mechanism

In all the use cases described above, the basic principle is the same: an incoming message is passed through the integration flow for processing and a reply is sent back to the waiting entry point with output information. Logic is the following:

Request reply schema
  • Incoming message: the WebHook receives a payload in a validated form which is then passed further. However, the WebHook is kept active or in a 'keep-alive' state to expect an HTTP reply before reporting back to the original sender of the payload.

  • The message is processed: the incoming message is mapped into the fields expected by the component and further processed by it. For a simplicity of the presentation, we have one component here but many more components can be here which would consequently process the incoming message through the different actions.

  • The message is delivered to request-reply: an outcoming data from the component (the last one in the chain) can be returned directly without mapping or, the mapping can be performed to have only the specific fields returned using the Response Body. At this stage, incoming fields from the component can also be mapped into the custom headers of choice.

  • Custom Headers can be added (optional): Custom headers can be added to further customise the returned message if it is required by the system which sent the original incoming message.

  • HTTP Reply is sent back: At this stage, the message is sent back directly to the first entry point, the WebHook in our case. The message contains the Response Body + headers.

Pre-requirements to use HTTP-reply

There are several specific requirements that need to be fulfilled before the request-response mechanism can be used. There are:

  • If a custom Node.js component is to be used in the flow with request-reply, then the sailor-node.js version should be 1.3.0 or later to support the messaging in the flow. However, it is recommended that you use the most recent sailor version.

  • If a custom Java component is to be used, use sailor-jvm version 2.0.0 or later.

  • Ensure that all steps have been tested in advance, to verify that the fields are properly mapped.

© 2015- Squiz Pty Ltd