In this example, we demonstrate the usage of custom headers which can provide an additional level of customisation for your HTTP Reply. Custom header feature is entirely optional and HTTP Reply will work without it. However, if the receiving end of the reply message is expecting some parameters to be included in the reply header as well, then this example will demonstrate how to do that.

For a simplicity let us assume that an arbitrary application is calling to know if a particular user is ONLINE or OFFLINE and also expects to get the answer not only in the responseBody but also in the reply header.

The design of calling application is not relevant to this example but let us assume that the input is sent to a particular WebHook with a simple JSON like this:

{
  "fname" : "Jonnie"
}

We want the system to tell us if this particular user is ONLINE/OFFLINE and since when. Obviously, the core information should be kept in one particular Data Base table which needs to be enquired for giving an answer back. For this example, we have a PostgreSQL Data Base which would have the names, status and the timestamp when it was last updated. How this Data Base gets the updates is not relevant here.

Let us build an integration flow like this:

Since our example Data Base is PostgreSQL we use that particular component with a setup like this:

Notice the structure of the SQL query:

select fname,status,cldate,cltime from acmestatus where fname=$fname:string

The query asks for properties fname which is the first name record, status which is the actual status of this particular user, cldate a particular timestamp containing the date of the last update and cltime, which gives the particular time of the last update. We want this to query be done when the fname equals to fname which came from the WebHook part.

Lastly $fname:string part enquiries that that particular field has a type (string in this case) and can be drawn by the UI like this:

Next, we need to take care of the actual response part. The database gives cldate, cltime, fname and status. These fields can now be mapped into HTTP Reply responseBody part like this:

{ "response" : "User {{fname}} is {{status}} since {{cltime}}"}

After saving this task we could simply get responses something like:

{ "response" : "User Jannie is ONLINE since 15:26:42.607543"}

This is already interesting, but what would be even better if we would define some custom header to report back. Here is how you could define the custom headers:

This particular setup is situated below the actual mapping part of the HTTP Reply section. Normally it is left empty, however, when the custom headers are added those custom header names are being dynamically added into the mapping part as well. And obviously they can be mapped as well:

In this particular case Current-status and Last-update custom headers are mapped with status and cldate cltime properties which are coming from Postgre SQL component. So what would be the result?

No change in the actual responseBody obviously but here is what the header of that response would contain: