4.8.8

HTTP component

HTTP Component

The HTTP component is able to post messages to HTTP(S) endpoints. It will post the content it receives from a previous component without altering it.

Basic configuration

The HTTP component has the following basic configuration options:

URL

Description

URL to the HTTP(s) endpoint that must be reached.

Remarks

Simple expressions can be used in the URL to create a dynamic URL. For example, ${header.<headername>} or ${bodyAs(String)}.

HTTP Method

Description

Choose between GET, POST, HEAD, PUT, DELETE and PATCH.

Auth Method

Description

Select which authentication method must be used with the HTTP(s) endpoint, either none (default) or Basic Authentication.

Auth Username

Description

The username when using Basic Authentication.

Auth Password

Description

The password when using Basic Authentication.

Exclude Headers

Description

Headers to be excluded from the requests made by this component only. Multiple header names may be specified splitting them with a vertical bar |. This can be used, for instance, to prevent sensitive data present in headers from being sent to a 3rd party host.

Auth Preemptive

Description

Set to true if the server supports preemptive Basic Authentication, meaning that credentials are sent immediately, even if the server doesn't request them.

Use Error Route

Description

Set this to false if the endpoint has a redirect or you don't want HTTP errors to be handled by the error route.

Advanced configuration

The HTTP component has the following advanced configuration options:

Maximum amount of connections

Description

This setting defines the maximum amount of connections that are available in the connection pool of the component.

Remark

  • This setting can be increased when the endpoint can handle more requests or when it can't handle many requests it can be decreased.

Maximum amount of connections per route

Description

This setting defines the amount of connections that can be opened per route concurrently. These connections will be taken from the connection pool (see Maximum amount of connections).

Every URL is seen as a new route. When the URL is static then this setting will limit the amount of connections that can be opened for it even when there are more connections available in the pool. In this case you can set the same amount of connections as the Maximum amount of connections setting.

When the URL is dynamic (simple header) then there are multiple routes that can be called by the component. In this case it is better to set this setting to a lower value then the Maximum amount of connections setting.

Remark

  • This setting can be increased when the endpoint can handle more requests or when it can't handle many requests it can be decreased.

Retry failed requests?

Description

Enable the retry mechanism of the component. Messages that get back status 500 or higher will be stored and retried every amount of milliseconds that is set in Retry requests interval. This is useful for example for API's that are not very reliable.

Remarks

  • At the moment the retry mechanism doesn't support dynamic URL's which are URL's that contain simple expressions like ${header.url}.
  • The retry mechanism will generate extra exchanges that will show up in the exchange counters in the Flow manager. This also happens when the flow is idle, because the mechanism has to check if there are any failed messages that it should retry. This check happens every amount of milliseconds that is set in Retry requests interval.
  • The retry mechanism will also add the following to the flow logging on the INFO level:
    • Amount of messages that are being retried
    • When the external service is down
    • When the external service is up
  • The retry mechanism will keep retrying indefinitely, but each message expires after 24h.

Retry requests interval

Description

The interval in milliseconds that determines the time after which messages from failed requests are retried.

Remark

This option is only visible when Retry failed requests? is also enabled.

Remarks

  • This component can be chained to another endpoint. However unlike other components the output will not contain the message you posted somewhere, but will contain the response of the HTTP Post.
  • The HTTP component also has an Validate Url button, which will test if it can send a message to the endpoint.
  • The HTTP Component is only capable of posting messages to HTTP endpoints, use the Inbound HTTP component for receiving messages

Custom SSL Certificates

It can be the case that the endpoint you are trying to reach uses an SSL Certificate (HTTPS), this is not a problem for Dovetail as long as it is signed by a default trusted certificate authority. When the endpoint uses a self-signed certificate, or a certificate not signed by a default trusted certificate authority, the certificate should be retrieved and imported into Dovetail. Unfortunately to date, this has to be done manually by the support staff of Dovetail, please contact your Dovetail provider when necessary.

When you install a flow that uses such an endpoint dovetail will run a pre-install check, to check wether the certificate is valid or not. When using a dynamic url this check can be bypassed and it will show up in the flow logging instead.

Testing with HTTP component

On RequestBin you can set up a temporary HTTP server which you can use for testing purposes. Dovetail can send messages to this HTTP server so that you can see if a flow is configured correctly.

HTTP Component example

To do this:

  1. Go to http://requestbin.net/ and click 'Create requestbin'.
  2. Copy the URL (e.g. http://requestbin.net/r/172193z1) and paste in the HTTP component in Dovetail (see screenshot above).
  3. Kick off the flow in Dovetail by sending a message to it.
  4. Go to http://requestbin.net/r/172193z1?inspect to see if the message has been received by the HTTP server.
← GetVariable componentInbound E-mail component →