This component receives the message body from incoming requests and, if a JSONata transformation is configured, applies it to the message. It then sends the transformed message back to the client that requested a webhook for a specific flow.
This component requires no authentication.
Please Note: From the platform version 20.51 we deprecated the component
LOG_LEVEL
environment variable. Now you can control logging level per each step of the flow.
The technical notes page gives some technical details about HTTP Reply component like changelog.
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).
However, in many other cases, a two-way messaging conversation is a requirement. In this scenario, sender-receiver pair transforms into a requester and replier pair. Firstly the requestor sends a request message and waits for a reply message and then the replier receives the request message and responds with a reply message.
These two approaches are called: Asynchronous (one-way) and Synchronous (two-way) messaging transmission types. At AVA all integration flows are asynchronous in nature unless HTTP Reply component is added. It enables the two-way messaging conversation through the HTTP Reply pattern transforming the flow into a synchronous one.
This component has no trigger functions. This means it will not be accessible to select as a first component during the integration flow design.
Content-Language, User-Agent
)application/json
): Header value tells the client what the content type of the returned content actually is.200
): Integer number between 200
and 999
(more info about status codes in rfc7231 standart)If provided Custom HTTP Headers
there will be additional field:
The output metadata remains the same as the input metadata
.
Content-Language, User-Agent
)application/json
): Header value tells the client what the content type of the returned content actually is.200
): Integer number between 200
and 999
(more info about status codes in rfc7231 standart)If provided Custom HTTP Headers
there will be additional field:
The output metadata remains the same as the input metadata
.
The use-cases of HTTP Reply component are numerous. It can be used for simple cases of getting an answer from the flow upon the completion of the process till complex cases like:
Here is a typical scenario: Integration flow is set to expect an incoming message via WebHook which is then processed further. The only acknowledgement that is given in this case is a simple Thank You from the WebHook, nothing more.
{
"requestId": "lv25ymyo15twhgp",
"message": "thank you"
}
The sender has no idea what have to happen with the message. If everything goes according to the plan, the message from outside would trigger the integration flow to execute without giving any verbose answer. This kind of communication is called asynchronous communication. However, what if you require a more meaningful response from the flow in order to process or execute something on your end? A simple thank you would not suffice here.
If you require to receive a meaningful, configurable response and immediately then it is better to use HTTP Reply in your integration flow. Here is a typical response from already configured request-reply 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"
}
In all of the use cases described above, the basic principle is the same: there is an incoming message which is passed through the integration flow for processing and a reply is sent back to the waiting entry point with on output information. Logic is the following:
Incoming message: the WebHook receives a payload in the correct and acceptable form which is then passed further. However, the WebHook is kept active or in keep-alive state and told 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.
There are several specific requirements that need to be fulfilled before the request-response mechanism can be used. There are:
sailor-jvm
version 2.0.0 or above.