Start integrating with ONEiO for free!



The Message Feed  in the Messages view 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.


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 can 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). 


  Section Usage
1 Message filters

You can filter the message feed according to:

  • ID
  • Use Case
  • Message Status
  • Inbound Message (Endpoint / Entity Type)
  • Matching Routing Rule
  • Outbound Message (Endpoint / Entity Type)
2 Message timestamp

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.


Rule(s) applied

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.


Conversation view

Open the conversation to which this transaction belongs.

Message Overview

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.


Message attributes

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

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. 


Message Details

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

Formatted Message

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.


Synchronous responses

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.



Filter Options

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 Usage

Filter Message by ID

Searches the conversation by the ID element defined as ID Attribute in the Endpoint UI

Use Case

Shows all messages whose Routing Rule has this Use Case defined in the Routing Rule UI 

Message Status

Filters messages by their State, more in the Message State section below.

Inbound Message

Filters messages on Endpoint or Entity Type level for Inbound

Matched Routing Rule

Shows all messages whose Routing Rule matches

Outbound Message

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


Use Case

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 Status

Message statuses define the state of a message such as Success, Delay, or Failure. More on the different massage states HERE.


Inbound Message

Filters messages on Endpoint or Entity Type level for Inbound


Matched Routing Rule

Shows all messages whose Routing Rule matches


Outbound Message

Filters messages on Endpoint or Entity Type level for Outbound


Conversation View

The conversation view displays all transactions related to the ticket in question.


On the left side you can see the message chain in the conversation and the direction in which the messages have flowed. If a conversation involves more than two systems (i.e. a conversation involving three systems) all of these can be found here.


To the right of the conversation chain you can find the same message details as in Message Overview.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.