All messages handled by Blue Integrator arrive and are passed to applications through ports.  The Receive Port is a port that receives messages, and a Send Port is a port that sends messages from Blue Integrator. Ports must have a unique name, which can contain / characters to break the path up into folders.

A Port runs on one or more Servers, and is configured via the Port Configuration Form.  A Port can also contain child Ports, configured on the Child Ports tab in the Blue Integrator Explorer.  When a Port sends or receives a message, it is automatically passed to any children for processing, enabling more specific maps to be specified at a lower level in the hierarchy without duplication of other logic.

A Port can specify a Schema. It is recommended that ports specify a schema, but this isn’t required.  If a schema is not specified, no schema validation occurs.

A Port can either be Enabled or Disabled. If the Port is disabled, messages are queued for later sending. Any queued or Suspended messages for a Port can be viewed in the Blue Integrator Explorer. A Port usually has a Transport associated with it, though this isn’t always necessary if child Ports or Routing entries are involved.  Each Transport has a number of configuration properties that must be set in order to configure the receipt of messages from the underlying transport. For example in the case of File Transport it is necessary to configure to where files are to be sent and the outgoing filename format.

Send Ports

A Send Port is where data leaves the system in the form of Messages via a Transport.

A Send Port has a defined Active Period (effectively a time-range during which messages may be sent).  Outside of this time range messages are queued for later sending.  By default the Active Period is 24 hours a day, 7 days a week.

Send Ports can require a receipt from the recipient, and this is configured by denoting a Receive Port on which receipts are received.  A number of correlation properties can be defined, between Message Context Properties on the Sent Message and Message Context Properties on the received Receipt, so that the correct receipt can be correlated to the appropriate outgoing Message.  Where a receipt is not received within the specified time-frame, the outgoing message becomes suspended.

A Send port can perform encryption and signing if required, and can also contain a Filter to determine if the Message should be submitted for onward processing by the Port, or disposed of or ignored.  If no filter is specified, all Messages are submitted for onward processing.

There are a number of tracking and diagnostic settings relating to a Send Port.  A Maximum Error Countproperty can be set, and if the number of consecutive errors experienced by the Port exceeds this count it will be disabled (to prevent excessive errors clogging up the system).  Additionally you can specify whether to track outgoing messages in the Tracking Database (and if so whether to keep a copy of the message contents), whether any problem messages should be Suspended (rather than retried), and whether to send messages synchronously where possible (that is, a workflow will wait on physical sending of a message rather than successfully queueing it for asynchronous sending).

Some Send Transports can return a response, and in this case the response is available to be retrieved in a Workflow via the Receive Send Port Response Activity subject to a timeout which can be configured.

Send ports are configured through the Send Port Configuration Form.

Receive Ports

A Receive Port is where data enters the system in the form of messages.

You can specify Message Context Properties on a Receive Port, which will be evaluated to a constant or XPath expression on receipt of a Message, and placed in the Message Context for easy future access.  One or more Maps can also be specified, and you can determine whether these maps are applied in order or as required (depending on the type of the incoming document).  A Filter may be specified to determine if the Message should be submitted for onward processing by the port, or disposed of or ignored.  If no filter is specified, all Messages are submitted for onward processing.  A Receive port can perform decryption and signature verification, and can also be used to de-envelope a message (See De-enveloping Messages for more information.)

A set of routing Receive and Send Ports may be given, and in this case the received and processed message will be submitted to all of these ports (assuming it passes any filter) in addition to the parent Port.  Additionally if the Receive Port is bound to any Workflows, the message will be submitted to a new or existing Workflow instance (depending on any correlation filtering).

There are a number of tracking and diagnostic settings.  A Maximum Error Count property can be set, and if the number of consecutive errors experienced by the Port exceeds this count it will be disabled (to prevent excessive errors clogging up the system).  Additionally you can specify whether to track incoming messages in the Tracking Database (and if so whether to keep a copy of the message contents), whether any problem messages should be Suspended (rather than retried), and whether to archive any incoming messages before processing (to a specified Send Port).

Receive ports are configured through the Receive Port Configuration Form.