eiConsole v.23R1
Tutorial & Interface

eiConsole Tutorial Basic

Splitting Attachment Data (Forking)

Overview

This interface demonstrates how to perform content forking; if you have a transaction with multiple “attachments,” a single incoming data stream representing multiple outgoing streams, this is the function you need to perform. In addition, this interface demonstrates how to use the eiConsole to separate a single data stream into multiple data streams – each based on a subset of the original stream’s contents for independent handling and processing.

Transaction Splitting May Be Used When:

• An incoming transaction contains multiple data payloads
• An incoming transaction needs to have different components processed separately

Core Concepts

• Forking
• XPath

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 document Sample2.xml.

How it Works

The forking module is configured in the Source Format.

Viewing the Forking configuration, you will notice an XPath expression and namespaces; the namespaces define prefixes for the XPath configuration. The XPath defines which elements from the original sample file will be output.

For each Node evaluated by the XPath expression, a transaction is generated and passed downstream to the directory Transport.

How to Use This Example

Click the links below for the files you will need for this tutorial, then download them to your local disk.

Sample Data

Configuration File

Interface Download

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. Finally, you may check your work against the provided Route (Sample Data).

This interface has three functioning pieces: the Listener (the Listener stage), the Listener Transformation forking (the Source Transform stage), and the Transport (the Transport stage).

Listener Configuration

The Listener polls a directory set by a configuration value stored in the environment properties file (included with this interface) every five seconds. Using environment properties will be explained in a later tutorial. The sample file intended to be used with this interface is provided alongside this instructional guide; it is Sample2.xml.

Forking Configuration

Viewing the Forking configuration, you will notice an XPath expression and namespaces; the namespaces define prefixes for the XPath configuration. The XPath defines which elements from the original sample file will be output.

In our case, the forking configuration uses a simple XPath-based rule, which searches the document for all available “Attachment” objects, and creates new Transactions out of them.

Below is our sample transaction (this contains in the Sample2.xml file) :

1. <?xml version=“1.0” encoding=“UTF-8”?>
2. <ns2:AttachmentGroup xmlns:ns2=“Sample2.Namespace” Id=“2.000003590486”>
3.         <ns2:Locale/>
4.         <ns2:CreatedDate>2012-07-18</ns2:CreatedDate>
5.         <ns2:LastModifiedDate/>
6.         <ns2:LifeCycleId/>
7.         <ns2:Attachments>
8.                <ns2:Attachment Id=“1”>
9.                       <ns2:CreatedDate>2012-07-18</ns2:CreatedDate>
10.                       <ns2:LastModifiedDate/>
11.                       <ns2:LifeCycleId/>
12.                       <ns2:Mime>Text/XML</ns2:Mime>
13.                       <ns2:AttachmentData>VEhJUyBJUyBBIFRFU1QgVEVYVCBTQU1QTEU=</ns2:AttachmentData>
14.                       <ns2:AttachmentReason>Order</ns2:AttachmentReason>
15.                </ns2:Attachment>
16.                <ns2:Attachment Id=“2”>
17.                       <ns2:CreatedDate>2012-07-18</ns2:CreatedDate>
18.                       <ns2:LastModifiedDate/>
19.                       <ns2:LifeCycleId/>
20.                       <ns2:Mime>Text/XML</ns2:Mime>
21.                       <ns2:AttachmentData>VEhJUyBJUyBBTFNPIEEgU0FNUExFIFRFWFQgQVRUQUNITUVOVA==</ns2:AttachmentData>
22.                       <ns2:AttachmentReason>Order</ns2:AttachmentReason>
23.                </ns2:Attachment>
24.                <ns2:Attachment Id=“3”>
25.                       <ns2:CreatedDate>2012-07-18</ns2:CreatedDate>
26.                       <ns2:LastModifiedDate/>
27.                       <ns2:LifeCycleId/>
28.                       <ns2:Mime>Text/XML</ns2:Mime>
29.                       <ns2:AttachmentData>VEhJUyBJUyBXSUsgV0lLIEEgU0FNUExFIFRFWFQgQVRUQUNITUVOVA==</ns2:AttachmentData>
30.                       <ns2:AttachmentReason>Order</ns2:AttachmentReason>
31.                </ns2:Attachment>
32.         </ns2:Attachments>
33. </ns2:AttachmentGroup>

There are 3 attachments here, so when this is executed in the Testing Mode, we should see three outputs; verifying experimentally, by running this transaction in the Testing Mode:

Transport Configuration

For each node evaluated by the XPath expression, a transaction is generated and passed downstream to the directory Transport.

We use the original file name and extension for the output of this Transport, information produced by the directory Listener as a transaction attribute. Note that because we have 3 incoming transactions that will share this information, the output file name will have a number appended to the end, subsequent to the first file output. This concludes the demonstration of a content-based data forking in PilotFish.