4.2.3.15. HTTP Client Gateway Out
The HTTP client gateway OUT allows you to issue a sequence of one or more HTTP calls in order to send our your message.
HTTP Flow
The sequence of calls that you want to run when a message comes through is called the HTTP flow. The flow is editable in the "HTTP flow" tab of your gateway. Each call of the flow is represented by a separate box and they are chained according to the order of the calls as determined in the tab "Next Step":
Each call has a set of individual properties:
Request
The Request of the call is defined by the
- HTTP method one uses to call the URL and
- the URL itself.
Your API documentation should indicate which method to use depending on what you are trying to do with that URL. Fetching data will usually involve a "GET" request. Modifying data will use "POST" or "PATCH". Creating data might require using the "PUT" HTTP method.
The URL of your request can be either a constant (URL is used as written in text in the field), one based on metadata (in that case, it will be treated as a constant where all text between curly brackets will be replaced by its matching metadata value - this is not as meaningful in a HTTP client IN), or a script if you wish to compute the URL using JavaScript.
Authorization
In this tab you will either set up a specific authorization for this call or you will choose to use the one you set up for your whole flow. See the "Authentication" article for more information on setting up your authentication.
Headers
This tab allows you to add specific headers to your request. Any headers you add here will override default settings for those headers if they exist. If you have selected
Body
If your flow involves multiple calls, it's likely only one of those calls is meant to send your actual message out. This is where you would set all the other calls' content.
Post Result
The post result is the set of actions you want to take based on the result of your call. This is where you can configure the creation of a message, the extraction of metadata, or running additional scripts for example. You can add any or all of the below actions:
Create Babelway Message |
This post result action allows you to produce a Babelway message. You will define - the content of the message: the result of the call is contained in responseContent. This variable is accessible through script and can be parsed to extract only a subset of the response data. - creation condition: When left blank, a message will be created for each execution of the call. When completed, the message will only be created when this condition is met. - response filename: This will become the file name of your message in. - set metadatas: this allows you to extract metadata to attach to this new message. - connected gateways: This option allows you to configure in which gateways to send the newly created message. - user metadata transfer strategy: You may have collected a large amount of metadata, not all of which ought to be transferred to the child message. This field allows you to configure which metadata to keep. |
Additional response validation |
This allows to configure additional checks after the call completes. - success condition: If this evaluates to true, the call is deemed successful. - error message: If the success condition is not met, the message will be set in error with this error message. This is very useful when it's very specific so that you are quick to identify what went wrong. |
Extract Variable | This allows one to extract variables that can then be used in scripts. |
Extract Metadata | This allows one to attach metadata that can be used later in metadata expressions. |
Set User comment of the Babelway Message | Babelway messages have a "user comment". This action allows to set its value. |
Set Gateway In/Out Message Key | Babelway messages have a gateway out message key. This action allows to set it for messages created by the gateway. |
Next Step
The "Next Step" tab allows you to configure the next step of the flow after successful execution of all the requirements of your current call. Steps are identified by their name. The name can be hardcoded. In that case, select "constant" and write it in.
If you've stored information that allows you to compute the name through a metadata, select metadata. For example, perhaps you have a sequence of calls like this: "fetchProduct1", "fetchProduct2", "fetchProduct3", "fetchProduct4". You have saved the product number in a metadata.
If you need any more elaborate logic to compute your next step, then use the "script" option. Note that since you are in a script, you need to provide a string value for your next step.
Beware that you must provide a string value for all possible cases and an empty string for no further action. Thus, the else "" is important!
if(responseCode == 404) "myNextStep" else ""
When "Next step" is empty or blank, the execution will end and no other calls will be executed.
⚠️ If the "Next step" produces a name with a typo or that simply is not defined, then the call will fail and the message will be set in error.
Settings
Each call has a settings tab that will allow you to set up general properties of your call:
- Timeout: how long do we wait before we abandon the call?
- Wait: how long do we wait before running the call? This is useful when you expect prior calls to do some asynchronous, behind the scenes, processing. Or if the server you are targeting has some caching that will take a while to update before your requests' values are available.
- Valid HTTP Return Codes: This is a comma separated list of the return codes you wish to handle. Note that this doesn't necessarily mean that all these return codes are a successful run of the current call, simply that you want to handle the step after these codes. For example, this call could be requesting product information. A 404 code would indicate it doesn't exist yet. You could then have a next action that does this:
if(responseCode == 404) "createProduct" else "updateProduct"
In this case, although 404 is an error code it will be listed in your Valid HTTP Return Codes.