Sentinel event processing


To process Sentinel event messages, the B2Bi trading relies on SentinelProcessors. A SentinelProcessor has three components:


A filter decides on if an input is forwarded to an adapter. A filter is optional for a Sentinel Processor.

Default implementation provided by the trading engine: InterchangeSentinelEventsFilter


An adapter adapts the information is delivered to the Sender. The adapter is required for a Sentinel Processor

Default implementation used by the trading engine: EventToTrkMessageUAAdapter.

This adapts the published trading engine Event to a list of TrkMessageUA.


A sender is responsible for sending the adapted information to Sentinel.

You can configure a backup sender, so that multiple senders can be chained. If the configured sender is unable to send the adapted input/message, then the backup sender is invoked. The backup sender may in turn, have a backup sender.

Default implementation used by the trading engine: XFBTrkMessageUASender. This sends the TrkMessageUA list provided by the adapter to Sentinel.

Processing groups

You can group multiple Sentinel Processors into a SentinelProcessorGroup.

If the last sender of the first configured SentinelProcessor cannot send the message, then the next Sentinel Processor in the group is invoked. This operation is repeated until no other process is left. In that case, the processed input is thrown away. By default, the trading engine provides a sender that is buffered, so that if Sentinel is not available, the event is stored. Once Sentinel connectivity is established, the event is sent. For information on Sentinel buffer settings, see the B2Bi Administrator Guide.

A single configuration file specifies all of the Sentinel processing groups that are delivered by default in B2Bi: <B2Bi_install_directory>/Interchange/conf/sentinel/sentinelProcessorsGroups.xml.

Custom implementation

To customize Sentinel event processing, you specify a Sentinel builder implementation.

The implementation extends: com.cyclonecommerce.monitoring.sentinel.router.processor.builder.SentinelProcessorBuilder

The implementation provides definitions of the adapter, sender, and optionally a filter:

  • To define a custom adapter, you must implement: com.cyclonecommerce.monitoring.sentinel.router.processor.adapter.SentinelAdapter<INPUT, MESSAGE>
  • To define a custom sender you must implement: com.cyclonecommerce.monitoring.sentinel.router.processor.sender.SentinelSender<M>
  • To define a custom filter, you must implement: com.cyclonecommerce.monitoring.sentinel.router.processor.filter.SentinelFilter<INPUT>

To extend the SentinelProcessorBuilder, you define all the components in an override method:


public void configure()


//insert our custom filter which allow us to only publish events on Outbound messages.

Other events are filtered

filterWith(new CustomExtendedFilter());

//insert custom implementation to add additional information to the sentinel events.

adaptWith(new CustomExtendedAdapter(SentinelConnector.getInstance().getBuffered()));

//send using custom sender

sendWith(new CustomSentinelSender(SentinelConnector.getInstance().getBuffered()));


To use the defined connectors to Sentinel from your custom code, ONLY use the SentinelConnector.getInstance() singleton. To use the trading engine Sentinel connectors that have been configured in the UI, use the getBuffered and getDirect methods. For custom connectors, not defined in B2Bi, use:

SentinelConnector.getInstance().getBuffered(mainhost, mainPort, backupHost, backupPort)

Example custom code

An example of a custom builder is provided at the location:


Enable this builder:

Add the builder under: <B2Bi_install_directory>/Interchange/conf/sentinel/sentinelProcessorsGroups.xml, and define a group element.


* <SentinelProcessorGroups>


* ....


* <SentinelProcessorGroup name="MyCustomGroup">

* <SentinelProcessor builderClass="examples.sentinel.SentinelCustomProcessor"/>

* </SentinelProcessorGroup>


* <SentinelProcessorGroups>

Then in the custom code, to use the group, a call can be made to:

* HashMap<String, String> myData = ....

* SentinelConnectorManager.getInstance().process("MyCustomGroup", myData);

This defined group can be used (for example) in an Inline processor.

For an example, see: <B2Bi_install_directory>\Interchange\sdk\java-src\examples\sentinel\

This inline processor adds custom information to a key/value pair map and sends the pair using the defined custom group:

SentinelConnectorManager.getInstance().process("MyCustomGroup", eventDetails);

In this example, a set of attribute values are read from a properties file under:



  • host=sentinelHost
  • port=1305
  • backupHost=sentinelBackupHost
  • backupPort=2345

Test the results

To test the publication of information to Sentinel you can use the the SampleAction tracked object (sampleaction.xml), located in the samples folder <B2Bi_install_directory>\Interchange\samples|sentinel. The readme.txt file in this folder explains how to configure and run tests.

Enable custom event processing

Once you have implemented the custom event processor, to use it, you configure a Message Handler in the B2Bi user interface to selectively apply the processing. The Message Handler provides processing of inbound or outbound messages based on metadata criteria of the input message.

When the example inline processor is triggered it populates the key/value pair map with:

//message core id

eventDetails.put(SystemTrackedObject.CYCLE_ID, message.getMetadata("CoreId"));

//content mime type

eventDetails.put("DocumentType", message.getMetadata("ContentMimeType"));

//some strings

eventDetails.put("MyFixedString10", message.getMetadata("Direction"));

eventDetails.put("MyVariableString250", "MyCustomProcessor");

//direction as Outbound

eventDetails.put("Direction", "Outbound");

The inline processor then sends the key/value pair map through the connector using the MyCustomGroup.

SentinelConnectorManager.getInstance().process("MyCustomGroup", eventDetails);

The custom group MyCustomGroup catches this input and uses its filter to check if the Direction is Outbound. It is since we hardcoded it like that. I then sends the map to the adapter. The adapter defined in the SentinelCustomProcessor class translates this map to a List<TrkMessageUA>. This list is sent to the custom Sentinel sender, which uses the connection details from

Extend Sentinel reporting

After the example Sentinel event processor first filters for events that have the "Outbound" message Direction. Then the processor calls a custom adapter. This adapter adds custom values to the UserData1 and UserData2 fields of messages published in the B2Bi_Message TO.

Then the sending is extended so that, after the data is sent to the Sentinel instance that is specified in the B2Bi UI, another defined sender is invoked. This enables you to publish the event to another Sentinel instance.



* Interchange normal processing calls use:

* - filter: {@link InterchangeSentinelEventsFilter}

* - adapter: {@link EventToTrkMessageUAAdapter}

* - sender: {@link XFBTrkMessageUASender}


* Those are plugged into interchange under a group named:

* <SentinelProcessorGroup name="MESSAGE_ACTIVITY">

* <SentinelProcessor builderClass="com.cyclonecommerce.monitoring.sentinel.router.processor.builder.SendBufferedEventToSentinelProcessorBuilder"/>

* </SentinelProcessorGroup>


* This is defined in a configuration file:

* [Interchange]\conf\sentinel\sentinelProcessorsGroups.xml


* The normal interchange processor can be replaced by a custom implementation just by replacing the interchange builder * mentioned in the xml from above - (SendBufferedEventToSentinelProcessorBuilder).


* <SentinelProcessorGroup name="MESSAGE_ACTIVITY">

* <SentinelProcessor builderClass="examples.sentinel.ExtendedInterchangeCustomProcessor"/>

* </SentinelProcessorGroup>


* So our own implementation is plugged in that will extend the Interchange one, provided by our class:

* ExtendedInterchangeCustomProcessor


* We've defined our own filter, adapter and sender classes in this example:

* - filter: CustomExtendedFilter -> ignores all the events related to messages that are not Outbound

* - adapter: CustomExtendedAdapter -> adds additional attributes named UserData1 and UserData2 to each event

* - sender: CustomSentinelSender -> sends to the sentinel instance configured in interchange and also to another

* different sentinel server.


Related Links