Log out?

Multi-Stage XML Workflow

eiConsole v.19R1
Tutorial & Interface

eiConsole Tutorial Basic

Multi-Stage XML Workflow

Welcome to the eiConsole Multi-Stage XML Workflow Tutorial. Often automation of a business process requires more than simple point-to-point integration of Source and Target Systems. The eiConsole supports the implementation of a wide variety of the workflow patterns common to these more complex Business Process Modeling (BPM) scenarios. Supported patterns include sequencing, splitting, merging, branching, conditional logic, and iteration. In this tutorial, we will take you through an example of a multi-route interface that demonstrates a number of the components used in the implementation of a multi-stage XML workflow in the eiConsole.

zip-iconTraining kit


Place the eip-root directory from the Training Kit for this section to the desired folder on your drive. In our case, it’s

c:\Program Files\PilotFish Technology\Samples\.

Open the eip-root directory as a new Working Directory, using the Browse button.

Your Route File Management window should now have 4 routes. The last three of them are marked by blue icons which means these routes are fully configured. We want to configure the first one – to begin, double click on it to open the eiConsole’s main route grid.

Overview of routes in route file management screen.

Let’s begin by talking about the different levels of modularity within an eiConsole interface. It all starts with a Stage. There are 7 stages in the eiConsole’s main route grid. Stages are things like Listeners, Transforms, Routing or Transport. These are essentially a node within a workflow, representing an action on the data. A Route, like we’re looking at here, represents a collection of these stages. These make up an XML pipeline. In the eiConsole within a Route, data travels in one direction between a set of Source Systems and one or more defined Target Systems.

Route Example and 7 Stages of the Data in the Route or Interface.


First, we need to configure the Listener. Select the Listener stage and click the icon to open the Listener Configuration panel. Now the Listener Type (Directory / File) is already selected, so we’ll leave that. But we need to point the Polling directory at the right file on your computer. That is where you placed the downloaded Tutorial Workflow folder. Click the Ellipsis button to the right of Polling Directory, click and navigate to the Workflow folder, select the input folder and click Open.

Configure the Listener in the Route to handle the incoming messages.

Set the Postprocess operation.

Configure the Postprocess operation of the Listener.

Now, a single Route with one Source and one Target is the simplest possible example of an XML workflow in the eiConsole. However, in this example, we need two defined Target Systems – one named PilotFish and one named Sharks.

We will need two. Click the Add Target button to add a second target.

Add an additional Target for the output of the messages.


The second Target System appears in the grid.

View the Route Grid displaying the additional target system.


Now we want to name our two Target Systems, but in order to do so, we first have to name our two Target Transforms. So, click the Add Format button.

Select the Target Transformation Icon from the Route Grid.


Name your first Target Transform by entering the name in the Add New Format box (in our example shown below – we entered Transform1) and clicking OK.

Enter the name of the first Target Transform in the Route.

Repeat the same process for the Second Target Transform. Be sure to enter a different name (in our example shown below – we entered Transform2) and click OK.

Enter the name of the second Target Transform in the Route.

Your main route grid should resemble what is shown below. Note the names Transform 1 and Transform 2 now appear in the Target Transform column.

Review the newly named target transforms in the route grid.

Now you can name your Target Systems. To do so, select the Target System stage and click the icon. The System Info dialogue panel will open. Enter a name in the field (in our example shown below – we entered PilotFish) and choose an icon.

Give a descriptive name to the target system.


Repeat the same process with the second Target System. Name it Sharks.

Give a descriptive name to the second target system.


Next, we need to add the Source System information. As was with naming the Target System, the first step in the process is to configure your Source Transform. Select the Source Transform stage in the grid. Click the Add Format button and enter a name in the Add New Format dialogue window. Click OK. In our example shown below – we named ours Fork.

Enter a descriptive name for the source transform stage in the route.


Your main route grid window should now resemble the main route grid shown below. Note: your Source Transform is now named Fork in the grid.

Review the route stages for the message in the grid.


In the Transport stage, we select the RouteToRoute Transport Module. Both Targets use this same Transport Type, but they’re configured slightly differently. Unlike many of the other available connectivity options, the RouteToRoute Transport is used to sequence multiple routes within the given interface. Here we’ll see that Sharks will be passed to one Route indicated by the Listener name and PilotFish to another. You’ll see Pilotfish is sent to a Listener called Step2A-Listener.

Click the first Transport icon in the main route grid to open the Transport Configuration panel. Name it Send To Step 2A. In the Basic tab, enter Step2A-Listener in the Target Listener field.

Click the first Transport icon in the main route grid to open the Transport Configuration panel


Repeat the process for the second Transport, but enter Step2B-Listener in the Target Listener field and name it Send To Step 2B.

Click the second Transport icon in the main route grid to open the Transport Configuration panel

When a Route has more than one Target, the Routing Module is used to select the appropriate execution path or paths. Here, we expect our input message to represent a Fish. If the Fish is a PilotFish, we will proceed down the top path. If the Fish is a Shark, we’ll use the second path. All other messages will be discarded. Hence, the Routing Stage can implement both conditional logic and filtering.

Select the Route icon in the main route grid. The main Route configuration panel opens to the General Tab.

Select the main route icon in the center of the route grid.


Click the Routing Rules tab to open the configuration panel.

Select the routing rules configuration module for the route transactions.


Сlick the Add Rule button.

Click on the Add Rule button to add a routing rule.


The Add Routing Rule dialog will appear. Select XPath Query for the Expression, and Send To Step 2A for the  Transport (our previously configured Route). Click OK.

Selecting the routing rule expression, choose XPath Query in this tutorial.

Enter a name, in the XPath Expression field. In the example shown below – we entered: contains(//CommonName,'Pilotfish').
Please note that case matters: Pilotfish and PilotFish are two different names.
Click enter to save. Note the XPath expression now appears in your Module Configuration panel tree.

Review the routing rules that have been configured.


Our second rule checks to see if the CommonName is shark – contains(//CommonName,'shark'). If so, it sends it to Step 2B. Follow the same process you did for configuring the first set of rules and configure the second rule – Sharks and Step B. Once you have completed these steps, your panel should resemble the panel below.

Setup the second Routing Rule using another XPath Expression.

You are ready to move on to the Source Transform. Click the Source Transform icon in the main route grid. The main Source Transform panel opens. Select the Forking tab, then select XPath Forking from the Forking Module drop-down menu.

Select the Source Transform icon and the Forking tab.

 

Also demonstrated in this Route is our ability to perform a parallel split or forking operation. We see this configured in the Forking tab of the Source Transform. The input document that we’ll be using for this Route is a “batch file” of Fish – each represented as an XML tag. We have used the XPath Forking Module to pull out each Fish tag and to turn it into its own transaction.

We enter /FishXML/Fish in the XPath Expression Field. Click enter/return to save.

Enter the second XPath expression in the route forking configuration panel.


Also, let’s name the Source System. As we start with the file from our local Workflow directory, let it be Local Drive. And let’s choose an icon for it.

Name the Route Input or Source System in the Route Grid.

In the Testing Mode of the eiConsole, we’ll start with the stage immediately before the Source Transformation and we’ll allow the test to run through to both defined Targets. But first, you’ll need to save your Route. To do so, go to the File menu and select Save Current Route.

Save the current route configuration to a file.

Next, go the Mode menu and select the Testing Mode.

Select Testing Mode from the Route Grid.


The eiConsole’s inline graphical test mode opens.

View of the route stages in inline testing mode.


Select the Source Transform icon in the main route grid. Check the Start Test Here box in the Stage Configuration area, choose the From file in the Alternate Data Source drop-down menu. Click Browse.

Select the source transform stage to begin inline testing.


Navigate to your Workflow folder, choose your sample XML file in the Select File to Start Test With dialogue window. You’ll want to select the FishXML-Small.xml file.

Select the test data file from the directory.


With the Source Transform Stage still selected, let the test run to the two defined targets. Click the Execute Test button at the top to start the test.

Click the Execute Test button to start the route message testing.


Once the test executes, the blue questions marks will have been replaced by green check marks indicating that the test has been successful. A red X would indicate a failure.

Review the success or failure of each step in the route by the icons displayed.


With the “No Transformation” stage still selected in the left panel, click the View Stage Output.

View the output of the stage selected in the route.

Now, let’s take a look. The input is FishXML with a number of different Fish tags.

Select XML as the format for view the test data.


Next, select the Forking Stage then click View Stage Output.

Select the route forking stage and view the data at this point.


As you can see, the Forking stage then performed a parallel split.

Example of a parallel split in the routed messages.


Next, select the Route stage. We can see it split into a number of different transactions, each depicted as a row in this Test Results grid.

Select the Route stage in the inline testing mode.


After this stage, some subset of these transactions will be filtered out; others will be branched to one of the two defined Transports. You can select each row and click View Stage Output to view each transaction. Each transaction contains a different Fish. Some will be Pilotfish, some shark.

View the XML formatted data in the Stage Output Viewer.


Now we select the first Target Transform stage (Transform1) and click View Stage Output to view the first test result.

Select the Target Transform Stage of the Route and view the output.


We can see here that one transaction was sent towards the top Transport, the Pilotfish. And we can see here that yes, it is the Fish tag that has the CommonName of Pilotfish.

View the XML formatted message in each stage of testing.


We move down to the second Target Transform (Transform2), select the first row and then click View Stage Output.

View the XML formatted message in each stage of testing.


We see that there were two transactions sent in the Sharks direction, one being the Blacknose shark.

View test data in the output viewer.


Select the second row, then click View Stage Output to view the second transaction with the CommonName of Silky Shark.

View transaction in the stage output viewer for the second transformation.


Now let’s go and take a look at the next two Routes that these transactions are sent to. Go to the File menu and select File Management to return to the Route File Management window.

Select the File Management Window in the eiConsole.

You’ll see that back in our main Route File Management window Step 1 now has the blue icon as a configured route. We’ll take a look at the Route Step 2A.  Step 2A and Step 2B are similar.

Review all of the Routes and see the blue icon to show they are configured.


Double click Route Step 2A to open the eiConsole main route grid. You can see that this Route is simple with a single Source and a single Target.

Open the eiConsole to the main route grid.


Select the Listener stage and click the icon to open the Listener Configuration panel.

A Programmable Listener is selected (Programmable Trigger). In the Listener Name Configuration area, we see the same text that we used in the RouteToRoute configuration area – Step2A-Listener. The name of this Listener is the link between the Transport in the previous stage and this portion of the process. This allows Step 1’s RouteToRoute Transport to call Step 2A or Step 2B by indicating the corresponding Listener’s name. Not much happens in the body of this Route until we get to the Transport Stage.

Select the Programmable Listener Configuration panel.


Next, select the Transport stage. We see the Transport Type selected is the Process Orchestration Transport. This robust transport component allows for the implementation of any number of synchronization and state-based workflow patterns.

Select the Transport Stage and the Process Orchestration transport type.


Perhaps most interestingly, the Process Orchestration Transport, and its corresponding Process Orchestration Listener, allow us to merge asynchronous transactions. In other words, it can serve as a rendezvous point for data arriving from different sources. Here, we want to rendezvous a PilotFish message with a shark message, so that we can merge the two XML messages into a single XML document for further processing. The Transport indicates a process component, which is essentially the piece of this process that the current message represents. Essentially, what we’re doing is creating an empty puzzle board and specifying when a piece of that puzzle should be placed in that puzzle board. Here we’re saying, put the Process Component called “Fish” into our puzzle board.

Merge asynchronous transactions in this routing example.


Similarly, our Step 2B Route also uses a Process Orchestration Transport, but this one places the “Shark” piece in the puzzle board.

Transport Stage basic configuration panel.


Next, we return the main Route File Management window and select our third Route. We double click Step 3 to open the main route grid. Moving on with our third Route, we can see how we can rendezvous and merge data with the Process Orchestration Listener. We select the Listener stage. The Listener Type selected is Process Orchestration.

Select the 3rd Route in the Route Workflow.


Now, here we see that under the Action tab we’re going to Aggregate Transactions. In the Remove Process Instance field, we want When Transactions Fired to be selected.

Select Aggregate Transactions in the Action tab of the Route Listener.


And under our Firing Conditions tab, we’re going to do that when the Fish and Shark puzzle pieces or Process Components have arrived.

Enter the firing conditions for aggregating the transactions.


Please note that there are a number of other workflow patterns that are enabled by the other configuration options of the Process Orchestration Listener and Transport pair. For instance, we can deal with multiple transactions of the same type based on a count using this Transaction Count Required. Or we can implement conditional firing or statement-based operations with this Conditional Statement option.

Review other options for firing the aggregation of the transactions like transaction count.


But in this case, we just take the data from these two puzzle pieces, combine it and then pass it through the process until we get to a simple Directory Drop Transport. Note: We want the Target file extension to be XML.

Enter the extension of the target file name that will be created.


Now that we’ve walked through the four Routes that make up this three-step process, let’s look at this end-to-end in the Local eiPlatform Emulator. We go to the Tool menu to select and launch the Emulator.

Review entire Route in eiPlatform Emulator by selecting this from the Tools drop-down.


But before we can run through the whole test, we’ll need to drop a file into the appropriate input directory. From our Tutorial Workflow folder, open the data folder and copy the FishXML-small.xml file. Just keep it cached for now.

We are ready to start the test. Click Start Emulator.

Click the Start Emulator Button to begin.


While it starts running drop the FishXML-small.xml file into the input folder. Note: If any error occurs it will be indicated by the red error message, as shown below.

The eiPlatform Emulator will show any error messages in red in the log view.


We’ll paste our batch file of Fish into the input directory and we’ll see it disappear as it begins processing.

Select batch data file for input processing.

Once we drop the file in the Emulator, it gets happy again and processes away with pleasant green transactions zipping along. All is well.

View data log of transactions as the are processed.


Finally, when processing completes, we’ll see our output file consisting of the rendezvoused Fish and Sharks.

 

View the final output file of aggregated transactions in the log file.

This concludes the Tutorial of Multi-Part XML Workflow handling within the eiConsole. To review, we’ve seen how an eiConsole interface can be made up of stages and routes, and how various workflow patterns can be implemented with forking, process orchestration, and routing rules. With the eiConsole, you have powerful tools at your fingertips that can support workflow patterns common to more complex Business Process Modeling (BPM) scenarios.

    to post comments

    This is a unique website which will require a more modern browser to work! Please upgrade today!

    Thanks!

    Our editors are notified.

    Close