At its core, nChannel is an event-driven orchestration engine. To pass data from one endpoint system, through nChannel, to another endpoint system requires a pre-determined series of events called an "automation flow". This flow is the roadmap for how data moves through nChannel.

Each step in an automation flow is called an "event". It represents data being sent to one of the many services that make up the nChannel platform. Each event represents and instance of "do something" to or related to the data being passed through nChannel. Each event includes when it occurred, the message that was passed to the event (which includes the business data that is being moved through nChannel), which service was responsible for the event, and information about the success or failure of the event occurring.

The most common series of events used in nChannel are:

  1. GET Something From Source System
  2. Translate From Source System Schema to Destination System Schema
  3. PUT Something To Destination System

The series of events is triggered by a schedule that determines how often to run the automation flow. That could be every minute, every day, or on demand via the user interface or something like a webhook.

Automation flows are typically a linear, therefore predictable, series of events. However, it is possible to create non-linear automation flows that include splitting or branching logic, where the specific series of events for a specific piece of data is determined in real time.

Events View

The Visibility Application includes a view for inspecting all events that flow through nChannel. It gives you granular visibility into every single "do something" that your nChannel account has done or attempted to do. This is the lowest level detail entity provided by the nChannel Visibility Application, but there is quite a bit of fine-grain metadata provided within each event.

Events Grid

The events grid displays all of the current events that have occurred in your account. It also gives you the ability to filter/search to find specific events, so you can drill into event details.

The following columns are displayed:

  • Actions - What actions you can perform on that row, implemented as links.
  • Date/Time - The date/time the event occurred.
  • Session - The ID for the session in which the event occurred. To see an end-to-end event flow for a given session, search for the session ID.
  • Source - The name of the service that triggered the event.
  • State - The state of the session at the time the event occurred. Note: This column does not represent the state or outcome of the individual event.
  • Action - The function called on the the described service. (A service will have one or more possible actions.)

A free text search is also available, however not all detail is indexed for searchability. Common searches include session ID, a business reference (email, order number, etc.), or a status code.

Event Details

There is a robust set of data within the each event that describes system behavior. Each event's output is a little different, but at the top level, every event is described in the same specific pieces of information.

The following is a description of each of the top-level nodes that represent an event:

  • accountNumber - The account number that created the event. (This is also present in the URL of the page you're on.)
  • automationFlowProfileID - The identifier for the specific data flow that the event took place in. This data flow represents the end to end path a document should take through nChannel.
  • afName - ?
  • afContext - Contains all the parameters passed to the data flow for execution. Different events on the flow will leverage different parameters. Examples include the timestamp range for GETting or the identifier for the translation profile (map) to use at the translate step.
  • primaryFile - The JSON document as it exists after the event is complete. If you were to compare events for an end to end session of INIT, GET, TRANSLATE, PUT, you would see different versions of the document at GET compared to TRANSLATE and PUT. When validating that a document looks correct at a place in time, use this node. (For some events, this document may not be the actual business document. It may be a query document, which contains the detail passed to a GET request for querying an endpoint.)
  • afSequence - The sequence number of the event in the data flow.
  • afSessionID - The ID representing a session of data flow. A session may represent multiple records flowing through the system (e.g. if 5 records are found to be updated in one GET request).
  • afAction - The action on the service that the event had triggered.
  • afStatusCode - The result code of the event. These are based on the standard HTTP codes.
  • afTrace - A trace log representing the documents entire path through the system. It will include the log entries added by the event you're looking at and al before it. As you look at events in a data flow from start to finish, you'll see the trace log appended to at each step.
  • afState - A "plain English" status that represents where the session is at the time of completing the event.
  • parentEventIDs - The event IDs that happened before the current event in the session. This allows the system to chain together events for traceability.
  • eventID - The unique  GUID for the current event.
  • eventDateTimeUTC - The date/time the current event occurred.
  • eventSource - The service that triggered the event. (An event is an instance of an action on a service firing.)
  • eventType - A qualifier that describes the type of event.
  • retry - The details of the configured "retry" algorithm that will be used if the event fails due to a 5xx error and should be retried. This is retry algorithm currently hardcoded by the system administrator.
  • afAction_next - Which action should be next in the data flow?
  • source - Context for what profile/settings are passed into the relevant service/action to execute the event.
  • retryCount - How many times has this event retried?
  • retryLimit - How many times will the event be allowed to retry before failing and notifying support?
  • destination - 
  • _id - The URL slug/GUID for this visibility record. Note: This is the same ID you see in the URL to navigate to this event, specifically.