Welcome to the XCS eiConsole for IRI (NAVA) Quick Tour. The XCS eiConsole for IRI (NAVA) is a complete developer and business analyst environment to create, test, manage, and maintain interfaces that take advantage of the IRI (NAVA) and other insurance-specific data standards.
The first screen you see when you open up the XCS eiConsole for IRI (NAVA) is the Route File Management window. This catalog of interfaces containing all of the various items in your project directory includes IRI (NAVA) templates for each and every one of the IRI (NAVA) messages defined by the most current version of the specification. This provides an ideal starting point to create interfaces that either produce or consume the IRI (NAVA) messages. In addition to the message templates we also include a validation capability. The IRI (NAVA) specification provides robust validation rules. While most standards are defined by an XML schema alone, the IRI (NAVA) deliverable also includes detailed business rules on a message by message basis. The XCS eiConsole is the first tool to be able to consume this master message specification, and programmatically execute those validation rules. For instance, if you’re a carrier with a set of PPfA documents that need to be validated each time the definition of the standard changes, the IRI (NAVA) validation route can be used to accomplish this. Simply provide all of your PPfA documents to the tool, all business rules will be run against them, and a report will be generated indicating what has or has not succeeded against the new business rules.
Now let’s take a look at an IRI (NAVA) interface in a little bit more detail. When an interface is open in the XCS eiConsole for IRI (NAVA) the data flow of the interface is depicted in the Main Route Grid. A set of icons depict the flow of data from one or more Source Systems to one or more Target Systems. The developer, or business analyst’s, job is to configure each one of the stages in between.
The Source System produces data.
The Listener is responsible for accepting that data either passively (such as a Web Service) or proactively (such as going out and polling a directory on a scheduled interval). The XCS eiConsole supports a wide variety of Listener types represented in this dropdown.
After data has been accepted through the Listener, we then have Processors that allow us to do general work over the data stream. Attachment handling, Decryption, and Authentication can all be handled through XCS eiConsole Processors.
Once the Source System has produced the data and the Listener has accepted it into the XCS eiConsole, we now have a Source Transformation that allows us to take this inforamtion and translate it from the proprietary format of the Source System into a common XML format for this message. In most cases you’ll be using an IRI (NAVA) message as this common format. In this example a flat file is being translated into an IRI (NAVA) Carrier Profile message.
Data transformations in the XCS eiConsole have two stages. First, information is taken from its native format and translated into XML. The XCS eiConsole supports a variety of such conversions. The most common of these is the conversion of a Delimited or Fixed-Width file into an XML format.
The XCS File Specification Editor is a tool that allows the developer or business analyst to specify the structure of that inbound Delimited of Fixed-Width file such that it can be parsed into the described XML format.
File Specifications can be imported from a variety of different sources. One of these is the DTCC record layout spreadsheets.
Once data has been converted to XML we move on to the XSLT stage. This is where the logical data mapping occurs, and where fields from the Source System are mapped onto fields in the Target, or are mapped onto fields in the IRI (NAVA) message.
The XCS Data Mapper is a best-in-breed data mapping tool that allows you to do just this. In this tool the Source format appears in the left hand side and the Target format appears on the right. Through drag and drop the mapping between Source and Target is created in the middle of the screen.
The XCS eiConsole for IRI (NAVA) includes the specially designed IRI (NAVA) format builder.
The IRI (NAVA) format builder is used to provide access to the specification directly from within the data mapping tool.
This tool directly consumes the IRI (NAVA) Master Message File. From the specification, the tool provides access to each and every one of the IRI (NAVA) messages. A message can then be loaded into either the Source or Target trees.
Once the IRI (NAVA) schema is loaded, all of the IRI (NAVA) specific documentation, conditional rules, and codelists become immediately available.
In addition to support for the IRI (NAVA) formats, the XCS eiConsole for IRI (NAVA) Data Mapper also has built in support for the ACORD and DTCC Schemas. Other nonstandard formats are also supported.
Once the Data Mapping is complete we move on to the Routing stage. The Routing stage allows us to Route the data to one or more defined Target Systems. For instance, if multiple administration systems are responsible for different products, we can route a message based on product type.
Transaction Monitors are the XCS eiConsole’s mechanism for exception handling. So, if something goes wrong in the processing of an interface, an email can be sent, SNMP trap raised, etc.
The next stage is the Target Transformation. This is where we’ll take data from our common format and lay it out in a format that our Target System can accept. So, if we’ve adapted IRI (NAVA) internally, but one of our Target Systems doesn’t accept it, our Target Transform will be used to map back onto that proprietary format. The XCS eiConsole for IRI (NAVA) supports a wide variety of output formats including: XML, flat files, databases, etc.
Finally, the Transport stage is used to handle connectivity to the Target System. The final stage of the process is the Transport stage. The Transport stage is responsible for sending data along to the Target System.
Much like the Listener we can apply Processors before we go ahead and send the data to the Target.
The Target System is configured exactly the same way as the Listener. You choose the Transport Type from the dropdown, fill out the configuration information, and you’re done. It’s important to note that the eiConsole supports both synchronous and asynchronous interfaces, as well as both batch and real-time.
Once interface configuration is complete you can switch into Testing Mode. Testing Mode within the XCS eiConsole allows us to test any stage or set of stages of our interface together. The icons between the Source System and Target system become question marks, indicating a stage of a test that we haven’t yet run.
We can choose to start our test at any point and end it at any point.
Once a test is run, green check marks indicate success and an X represents an error.
We can view the data as it appeared when it first entered the system.
How it looked after transformation to XML.
And ultimately how it looked in an IRI (NAVA) compliant XML format.
For those XCS eiConsole users who have also licensed the XCS eiPlatform from PilotFish Technology, interfaces can then be deployed into an eiPlatform environment. This can be done through an automated Web Services interface available through the Route File Management window.
PilotFish and IRI (NAVA) are proud to offer the XCS eiConsole for IRI (NAVA) to the community. The combination of IRI (NAVA)’s robust standards deliverables with a powerful development tool promise to foster productivity and facilitate implementation. Ultimately, the combination of the PilotFish XCS eiConsole and the IRI (NAVA) standards will increase speed to market, data quality, and finally profitability.