The EBMSAdapter microservice is used for the EB Message Service protocol. Using EBMSAdapter business information can be exchanged in a secure and reliable way between the host and the partner. Messages can be digitally signed and sent encrypted. Additionally, successful receipt of messages can be confirmed by returning an acknowledgment.

Configuration

The microservice can be configured using the Configuration Property Sheet (CPS) as described in the following sections.

Figure 1: Configuration Property Sheet

This panel allows configuring connection details, security details, agreement details and attachments used by the host and the partner, to be sent using this EB Message Service protocol.

Connection Properties

Configuration Property Sheet consists of following properties:

End Point Address

URL of the partner on which EB Message Service Handler (MSH) is listening. It's the URL to which the request has to be sent.

Server Port

Details of the port on which HOST EB Message Service Handler (MSH) runs, the request processing server listens.

HSQL Server Port

The details of the port on which the HSQL server should run.

Request Timeout (in ms)

TimeOut for HTTPConnection. If no response is received, an exception message is sent on timeout.

Authentication Mode

It supports BASIC authentication for both host and partner. When BASIC authentication is selected, username and password are required.

Expert Properties

Figure 2: Configuration Property Sheet with expert properties

Connection Details From Input

Connection details along with agreement details are taken from input port/message. CPS configuration values are overridden.

Proxy Configuration

Proxy configuration values should be provided.

EBMS Properties

Figure 3: From Party Details

CPA ID

It is an arbitrary and mandatory string that can be used to identify sender and recipient. CPA ID describes the formal relationship between a host and the partner. It identifies the parameters governing the exchange of messages between parties. The recipient of a message must be able to resolve the CPA ID to an individual set of parameters, taking into account the sender of the message.

From and To Party Details

The 'From Party Details' attribute identifies the party that originated the message. The 'To Party Details' attribute identifies the party that is the intended recipient of the message. The "Party Details" attribute has PartyID, Type and Role. The type indicates the domain of names to which the string in the content of the PartyID element belongs. The value of the type MUST be mutually agreed and understood by each of the parties. The Role property identifies the authorized role (from or to) of the Party sending (when present as a child of the From element) and/or receiving (when present as a child of the To element) the message.

Figure 4: With Reliable Communication enabled

Reliable Communication

If reliable communication is enabled, it enables properties described in the section below.

Duplicate Elimination

If Duplicate Elimination is enabled, it will eliminate the duplicate responses. When Message Order is enabled, Duplication Elimination is mandatory.

Send Acknowledgement

If enabled, then Acknowledgement will be sent for synchronous.

Request.Retry Count

The maximum number of times request is retried if ack is not received.

Retry Interval(in ms)

The interval for which request will be retired.

Send Acknowledgement to outport

If enabled, Received acknowledgments from the partner are sent to the output port.

Persist Duration(in ms)

Specifies the minimum length of time to keep the EB message in persistent storage (HSQLDB).

Synchronous communication

The sender of an EB message can use synchronous communications protocol to receive the associated response message over the same connection request. For synchronous reply, use following options:

responseOnly - any mshSignals along with business responses are received on same connection request.
None(asynchronous) - business responses are received asynchronously.

If Message Order will be available only in Asynchronous Communication.

Message Order: If true, the recipient receives EB messages in the order of sending.
Message Buffer: It is used in case of Message Order.If Messages are received out of sequence, messages are buffered (not sent to the output port). If the number of messages are more than the buffer size, BUFFER_OVERFLOW message is sent to partner.

Create Timestamp

Add Timestamp in the request.

Create Time To Live(in ms)

Specify the interval in milliseconds for the request sent.It is used to indicate the time by which a message should be delivered to the To partner. If the time taken for the message to deliver is more than the value of Time To Live, the message expires.

Attachments

Payloads

Configure the attachments by adding payloads.

Security Properties

Security Details

Security Details for both host and counterpart can be configured here.Set 'Sign Message' to indicate whether to require inbound messages to be signed. Set Message Encrypted to indicate whether to require inbound messages to be encrypted. If requiring encryption from the EncryptionMethod, select the required method.Present encryption methods are:

DESede
AES-128
AES-192
AES-256

The acknowledgment is signed at the request of a partner and depends on the configuration of identification credentials set. From the 'Signature Algorithm' list, select the algorithm used to sign the outbound EB message. From the 'Canonicalization Method' list, select the algorithm to canonicalize the SOAP Envelope XML and exclude comments before signing outbound EB messages.

Figure 5: Host Security Details

Icon

Similarly, counterparty's security details can be configured.

Functional Demonstration

Scenario

Send a message from an EDBSAdapter in one event process to the one in another event process. Use a Feeder microservice to send a message and two Display microservices to view the output.

EBMSAdapter1 acts as the sender and EBMSAdapter2 as the receiver.

Figure 6: First Event Process from where the message is sent from EBMSAdapter1 using Feeder

Figure 7: Second Event Process where the message is received by EBMSAdapter2

Icon

Use the port numbers appropriately in the End Point Address and Server Port of both the EBMSAdapter microservices to represent the sender and receiver ports.

Input Message

Use the following message in the Feeder:

Figure 8: Message sent using the Feeder microservice

Output Message

The message which reaches the EBMSAdapter in the other event process appears in the Display connected to it.

Figure 9: Message received by EBMSAdapter2

Figure 10: Confirmation Message sent from EBMSAdapter1