The Message Feed gives you a detailed view of all message transactions in your subscription, plus further insights on the content of messages for both inbound and outbound.
Currently, the advanced message feed is still in the beta phase of development.
The message handling is accurate but visual bugs can occur.
If you encounter any issues please send a mail to email@example.com.
You can sign up for a free trial of ONEiO from the following link: ONEiO Free Trial
This article highlights all parts of the advanced message feed, their usage, and how to debug any issues in message transfer.
Message Feed Overview
The message feed is a real-time view of the message transactions in your subscription. You are able to monitor the traffic and/or search for messages with various filters. The feed consists of three columns; received messages (Inbound), message processing (ONEiO), and messages sent out (Outbound).
You can filter the message feed according to:
Timestamp when the inbound message has been received by the ONEiO receiver
Inbound message/message received
|Message received by ONEiO. Only minimal processing has been applied in this view, only to match the message to an existing conversation and apply conversation variables if necessary.|
|All Routing Rules that match the inbound message.|
Outbound message(s) / message(s) sent
|Message send from ONEiO. This shows our attempt to send the message to the receiving system. Success or failure states are shown on the right. More on that in the Message States section HERE.|
When clicking the message line from the feed, the message details are shown.
The Inbound message represents the message as received by ONEiO with minimal preprocessing done. Primarily the Received Attributes are shown.
These depend on the attributes mapped in the matched Routing Rule and not on what is present in the incoming payload.
If no attributes are mapped in the Routing Rule no attributes will be shown.
If there are no Routing Rules matched, the first 15 attributes of the inbound payload are shown.
The Outbound message structure depends solely on the matched Routing Rule, as only mapped Attributes will be part of the Outbound payload.
By default, the first 15 attributes of the Inbound payload are visible in this view. When a Routing Rule is matched the Received Attributes show a list of Attributes mapped in that rule.
Selecting "See all" shows all attributes in this message.
It is possible to search for an attribute or value through the search function.
Conversation Variables active before the rule is run are visible in a separate tab under the inbound message. Values after the rule is run are shown under the outbound message.
Received attachments are shown in a separate tab under the inbound message. Sent attachments are shown under the outbound message.
Inbound and outbound messages in this view are logical events. Depending on the endpoint type, a single message can contain multiple actions. There can be attachment downloads and uploads or lookups of different kinds. You can see the details of each event by clicking See Details -button
Both the Formatted Message and Raw Message tab show the actual message content, with the Formatted Message tab showing the content in a structured form for better readability.
This tab shows all Header information received or send with the message.
The response shown in this tab is ether from our own receiver as shown below or from the target system as in the second example.
The ONEiO receiver answers always with HTTP 202 Accepted and an alphanumeric ID after the message has been received successfully.
On outbound, the actual response from the target system is shown. In this example, the target system produces an error due to missing mandatory message content.
It is possible to use the synchronous response the same way as an inbound message. However, responses to the outbound messages are directly visible in the message feed only when there is a rule configured to handle it. The result of the response is seen in the message that has originally sent the message out. This shows if the message has been acknowledged successfully, or has ended up in an error. Note, that the response handling is represented from right to left in the feed.
Inbound message reprocessing
With ONEiO it is possible to reprocess the inbound message in case anything didn't go as planned. In this example, a rule was misconfigured and did not trigger from the received message.
Usually, this would mean that the message would need to be resent from the source system. But with ONEiO you can reprocess that message without the need to resend it.
Clicking the Reprocess Inbound Message button under the message submenu and confirming your choice in the Reprocess Modal forces the original message through our inbound adapter just like it would with a new message.
Confirm or Cancel your selection.
The notification on the top of the UI shows that the reprocessing has been successfully initiated.
The reprocessed message is visible in the message feed as a new message with the initial message just below.
While the Message Feed gives an overview of all messages received and sent by ONEiO, it is sometimes necessary to filter messages to find a particular message or transfer. This is possible with the help of our Filter Options.
There are currently six different Filter Options available in the Message Feed. Here is a quick reference:
Filter Message by ID
|Searches the conversation by the ID element defined as ID Attribute in the Endpoint UI|
|Shows all messages whose Routing Rule has this Use Case defined in the Routing Rule UI|
|Filters messages by their State, more in the Message State section below.|
|Filters messages on Endpoint or Entity Type level for Inbound|
Matched Routing Rule
|Shows all messages whose Routing Rule matches|
|Filters messages on Endpoint or Entity Type level for Outbound|
Let's have a closer look at each of them.
Filter Message by ID
Messages can be filtered by the ID of the Ticket. Which element is set as the ID element is defined in the endpoint UI under the ID attribute. More information on Endpoints can be found HERE
This filter only shows messages that have been routed by a Routing Rule that has the selected Use Case defined. Use Cases are set in the Routing Rule UI. LINK
Message statuses define the state of a message such as Success, Delay, or Failure. More on the different massage states HERE.
Filters messages on Endpoint or Entity Type level for Inbound
Matched Routing Rule
Shows all messages whose Routing Rule matches
Filters messages on Endpoint or Entity Type level for Outbound