Installation
Configuration
Management
Monitoring
Troubleshooting
Advanced Configuration
This sections provides details about how the Data Hub handles certain HTTP responses, and about how it handles HTTP headers.
When a request is made from the Dispatch Service to a destination, the response is interpreted as belonging to one of three categories: success, offline, or error.
A success response indicates that the destination accepted the message. Any 2xx HTTP status code is considered a successful response.
An offline response indicates that the destination is failing to respond to requests of any kind. A response is considered an offline response if:
When the Dispatch Service starts, each destination is considered to be online. For durable destinations, when an offline response is returned, the destination is marked offline, and the message that received the response is queued in the destination's offline queue. All further dispatch attempts to this destination just move the message to the offline queue, to reduce traffic to the destination.
Then, periodically (every 60 seconds by default, see offline retry interval), the first message of every offline queue is retried. If the retry results in another offline response message, the message is moved to the back of the offline queue, in case there are any issues caused by that particular message. If the retry results in a success or error response, the remainder of the queue is retried, continuing until the queue is empty or another offline response is received.
Note that the retry interval timer resets each time the Dispatch Service is restarted.
An error response indicates that the destination rejected this message in particular. A response is considered an error response if:
When an error response is returned for a durable destination, the message that received the response is queued in the destination's error queue and timestamped with the time it first entered the error queue. Subsequent messages are not affected (as with offline messages) as the problem is presumed to be with the message in particular.
Then, periodically (every 6 hours by default, see error retry interval) the entirety of every error queue is retried. If a message's retry results in another error response, the message's timestamp is checked; if the time between this retry and the first time the message entered the error queue is greater than the error give-up time span, the message is dropped. Otherwise, the message is moved to the back of the error queue.
Note that the retry interval timer resets each time the Dispatch Service is restarted.
The Data Hub acts much like a network proxy, in that it receives connections from clients and forwards them to destinations, preserving the message body byte-for-byte. Message headers, on the other hand, must sometimes be modified to ensure correct delivery of messages. This section describes the modifications that are made by the Data Hub after the message is received from the client and before it is delivered to the destination.
The following headers are explicitly set by the Hub for all outgoing requests, ignoring the original value sent by the client:
Accept-Encoding
Connection
Content-Length
Expect
Host
X-Forwarded-Proto
X-RI-Capabilities
The following headers are copied from the original incoming request to the outgoing request, or are omitted if they were not originally present:
Content-Type
Date
DNT
SOAPAction
User-Agent
X-RI-AID (PreEmptive Analytics Application ID)X-RI-CID (PreEmptive Analytics Company ID)X-RI-GID (PreEmptive Analytics Group/Batch/Envelope ID)The following headers are updated appropriately before sending (if the original incoming request did not have them, they are added):
Via
X-Forwarded-For
X-PreEmptive-Hub (Indicates that the message passed through a Data Hub)Data Hub User Guide Version 1.3.0. Copyright © 2014 PreEmptive Solutions, LLC