Tutorial & Interface
eiConsole Tutorial Basic
Content Based Routing
This interface tutorial demonstrates how to accomplish content-based routing; that is, it is a demonstration of how to conditionally send data to an endpoint based on the data itself.
Content based routing may be used when:
- Data needs to flow conditionally to one or more target systems.
- Data should proceed conditionally.
- Data should process differently according to its contents, for example, when different data versions or data Formats originate from the same source.
How to Run This Example
You may run from the Listener by configuring the attached environmental properties file or from the eiConsole testing mode at any point in the process prior to the routing module itself, using the attached documents Sample2.xml and Sample3.xml.
Sample2.xml will be routed to one Transport, and Sample3.xml will be routed to the other. The system utilizes the id to identify which Transport to route to; Sample3.xml uses the Id=”3″ namespace, for example.
How it Works
- The routing module is configured in the routing stage
- Viewing the routing stage in the eiConsole, you will notice two rules.
- Each performs an XPath operation; if the XPath operation evaluates to a Node (if the given XPath target can be found in the data), that rule evaluates to true.
- If a rule evaluates to true, the configured Transport is added to the list of valid Targets for the current transaction.
Note: If “Accumulate Targets” (found in the root configuration of the routing module), is checked, it will send to all Transports in its list. If it is unchecked, only the first Transport it identifies will be utilized.
How to Use This Example
Download the INTERFACE file and save it to your local disk.
Open the eiConsole, click on the File drop-down menu and select Import Working Directory/Route/Format. Highlight the name of the file to import and press the Import Selected button. The imported Interface will appear in your current Working Directory.
Next, follow the tutorial and walk through it step-by-step. You may check your work against the provided Route (Sample Data).
Open the Main Route Grid for the Sample Interface
This interface has four functioning pieces: the Listener, the router, and the two Transports. It performs no data transformation.
The Listener polls a directory set by a configuration value stored in the environment properties file (included with this interface) every five seconds. The sample files intended to be used with this interface are provided alongside this instructional guide; they are Sample2.xml and Sample3.xml.
The routing configuration is very simple; it uses two XPath-based rules, each performing a different operation. One Routes all Transactions with an Id of 3 to a particular Transport; the other routes all transactions with an Id of 2 to a different Transport. This is the fundamental mechanism by which all routing is performed; a rule is defined, criteria are defined for that rule, and an operation is optionally defined. Rules can be nested. There are two different modes for routing; Accumulate Matched Targets and Single Target. Accumulate Targets will continue evaluating rules and executing operations; Single Target will stop at the first operation successfully performed.
Below is one of our sample transactions (contained in the Sample3.xml):
<?xml version=“1.0” encoding=“UTF-8”?>
<ns2:Attachment xmlns:ns2=“Sample3.Namespace” Id=“3”>
Note: The Id, in this case, is 3, so it would be routed to the ID3 Transport. This can be experimentally verified by running this transaction through in test mode:
Run the Transaction Through the Testing Mode
Copy the Sample3.xml into the Polling directory.
Both of the Transports are configured similarly; only the file name is different.
Here we also use an environment property: $$Pilotfish.Demonstration.Directory.Out=C:\Test\Directory\Out
This concludes this tutorial of a content-based routing.