The Automated Interface Assembly Line
The Key to Rapid Interface Configuration and Leveraging Reuse
The eiConsole for Healthcare features a 7-stage graphical assembly line where you can build any interface, no matter how complex your integration requirements. It is natively self-documenting, so you’ll never have to worry again about who built an interface or who can maintain it.
In the eiConsole, each interface is constructed from a sequence of stages that are all graphically configurable without requiring any coding or scripting. Data Mapping is accomplished in a graphical 3-pane mapper using drag & drop, where even the most complicated mappings can be created (gone are the hairballs that line drawing mapping tools create). The eiConsole includes components that allow you to handle virtually every communication protocol, parsing, transformation or manipulation task you’ll ever need. Open source components may be leveraged, too, via our Open API – PilotFish offers the only commercially supported product that offers this tremendous advantage to easily and inexpensively extend functionality.
The eiConsole’s graphical automated interface assembly line also makes it easy to leverage business analysts and non-developers who can do 80-90% of your interface work.
Stepping Through Building an Interface in the eiConsole
Step 1: Create and Name Your Route or Interface
When you open the eiConsole the first screen you see is the File Management screen. This is where the interface/route configuration files can be managed. PilotFish configurations are divided into two levels. A single connection between a source and target system is a route, and a collection of routes working together is an interface. In the File Management screen, existing interfaces are denoted by a green box icon, and routes by a puzzle piece icon. Red indicates a configured interface, blue an unconfigured interface.
Click on the Add Route button to create a new Route, then name it and click OK. Double click your new Route to open the interface.
Step 2: Build the Route
The eiConsole’s opens to the main Route Grid. (Note when creating a new interface or route, the grid will empty except for the Route stage.) When creating integrations with the eiConsole most of the work is done building individual routes. In the eiConsole, a route is a connection between a source and target systems. There is no limit to the number of source and target systems that can be linked in this way. In the eiConsole routes are built configuring the stages of the automated interface assembly line. These seven stages are laid out in the table at the top of the screen. These stages handle processing the flow of data from the source system(s) to the target system(s). Regardless of the type of integration or their complexity, each interface or route is created by stepping through and configuring each stage in the Assembly Line.
Step 3: Define the Source and Target System
The first thing to do when building a PilotFish route is to add however many source and target systems are required. Click the Add Source icon and name your Source System by filling in the bottom panel. For easy reference, your systems should be named for what they are supposed to represent. Click Add Target and name your Target System following the same process.
Step 4: Configure the Listeners and Processors (if needed)
Click the “Listener” icon and select the Listener Tab. PilotFish retrieves data from the source system using a component called a Listener. This component communicates with the source system at highly configurable intervals, retrieves the data, and starts a PilotFish transaction. PilotFish comes pre-bundled with over two dozen listeners, capable of handling an incredibly wide range of system types. Included are TCP/IP, Directory, HTTP Post, SOAP Web Services, etc.
Select a Listener from the drop-down list and fill in the configuration information for the type selected. In the example below, HL7 TCP is selected.
After adding a Listener, Processors can be queued up after it to do some initial data handling. PilotFish Processors run in between several of the larger stages to perform in-between operations. These can range from changing the encoding, handling encryption, compression/decompression, preserving metadata, and so much more.
Over 75 are included out of the box or add your own using our Open API.
Step 5: Transform the Source Data to a Common Standard
PilotFish works primarily with XML as it represents an easy-to-transform, common standard for working with data. Once data is received by the application, it goes through this conversion process in two steps. First, it goes through an automated Transformer to convert the raw content to XML, if necessary. These Transformers are pre-built modules that can be set up through a simple graphical configuration. They take a wide range of standard data types and generate an XML representation of them. Among the included Transformers are:
- HL7 v2
- Fixed Width / Delimited Files (including X12 EDI)
- Database Result Sets
In Healthcare, one of our most popular Transformers is our HL7 Transform. This is a lenient HL7 parser capable of working with imperfect, extended, or non-standard message flavors of HL7. Configuration requires changing a handful of options in the application.
After the Transformer, the data is mapped using XSLT. This is a logical mapping from one data structure to another and is easily accomplished using the eiConsole’s Data Mapper. The eiConsole’s Data Mapper is a tool that generates W3C compliant XSLT using a simple, 3-pane, graphical, drag & drop interface. Using the Data Mapper is simple, involving nothing more than loading up sample files of the Source and Target formats, and then dragging and dropping the content into the center panel to map them together. The pane on the left represents the Source format, the pane on the right represents the Target format and the pane in the middle represents the relationship between the Source and the Target.
For more advanced functionality, a panel of powerful XSLT functions and custom PilotFish add-ons is included above the main mapping panel. And if a developer wants to dive deep into the process of the mapping, a tab for an XSLT IDE is also provided for viewing and editing the code generating by the graphical mapping.
Step 5: Configure the Routing Module
The Routing Module is the control point for the entire route. It is a gateway that determines which of the target systems the data is sent to. The data can be sent to all targets, or it can be restricted to one or several targets using a series of Routing Rules that can be defined.
Also, the Routing Module controls the error handling for PilotFish. Should any errors occur while the route is processing, those errors are sent to a PilotFish Transaction Monitor. These components take the error and provide an alert that something has happened in a variety of different ways. As in all areas of the application, a number of pre-built Transaction Monitors have been provided.
A few examples of the transaction monitors included are:
• Email Alert
• SNMP Trap
• Error Route Trigger
Step 6: Transform the Data for the Target System
Once the data is on the target side of the PilotFish workflow, it’s time to transform it so it’s ready to be received by the target system. This is done the same way as the transformation on the source side, only the order of operations is reversed. First, a logical mapping is done using XSLT in the PilotFish Data Mapper. This process is identical to the mapping on the source side, with the only difference being the formats used.
Then, the mapped data is sent to another Transformer. On the source side, Transformers automate the process of converting non-XML files into XML. On the target side, these same Transformers do the reverse, converting the XML data into a non-XML format.
Step 7: Configure the Transport and Processors (if needed)
PilotFish Transports communicate with the target systems and deliver the data to them. As with the Listeners, PilotFish provides a wide range of Transports capable of handling a diverse array of connections to many different systems. Over 25 Transport types are included, among them, TCP/IP, Command Line, Database Polling SQL Listener, Email (SMTP), FTP(S), Generic Socket Transport and HTTP(S), etc. Configuring a Transport in the eiConsole is as easy as filling out the configuration panel. Once configured the Transport will deliver any transactions sent to that target system.
Before and after the Transport executes, additional Processors can be added if required. These processors can handle the final small tasks around the delivery of the data to the target system. The Processors available are the same as those available after the Listener on the Source side.
Step 9: Test the Route
Once the Route has been built, it’s time to test it. The eiConsole comes bundled with a powerful graphical Testing Mode. This mode not only allows the route to be run from end-to-end, but it provides an in-depth look at the processing that occurs each step of the way, making it easier to debug and solve problems. Any Stages that fail provide detailed error messages so that failures can be quickly corrected and retested. You also have the ability to start and end the tests at any stage in the Route and to manually define the data being sent through. The Testing mode offers these and other functions to ensure that the Route works just as expected prior to deployment.
Step 10: Deploy the Interface
The eiConsole is used to develop the routes and interfaces, but once they are ready, they need to be deployed to the eiPlatform server. This can be easily done in one of two ways.
- Copying the files. In the eiConsole configurations are simply files on the filesystem. Simply navigate to the root directory chosen for these configurations, and copy the files over to the other server.
- Use the built-in drag & drop feature. At the bottom of the File Management screen is the ability to connect to another server. Once that connection is established, routes and interfaces can be deployed by simply dragging the route or interface into the server panel below.
With the eiConsole for Healthcare, your interface can be built and deployed into production 10x to 100x faster! Often you can leverage an existing interface by cloning, tweaking and you’re done.
The eiPlatform is scalable, reliable, manageable and secure. Combined with the eiConsole for Healthcare it offers a truly enterprise-class middleware solution for your integration needs.
Simplify Interface Management and Maintenance with the eiConsole
The eiConsole for Healthcare is also designed to simplify ongoing management and maintenance of interfaces. The Route File Management screen allows you to view all of the interfaces for the entire enterprise on one screen. As the number of interfaces increases, you can filter and sort the interfaces using user-defined fields. Once you have identified a particular interface, it can be “downloaded” from the production eiPlatform, cloned, tweaked, and “uploaded” back to the eiPlatform with just a few mouse-clicks.