Welcome to the XCS eiConsole NIEM demonstration. Government is comprised of thousands of federal, state, and local agencies. Each of these entities is home to a largely unique set of systems and technologies. As the regulatory landscape evolves, there’s an increasing need to integrate these islands of disparate information. The PilotFish XCS eiConsole is the highest quality, fastest, and most cost effective means to integrate these heterogeneous systems and expose data in compliance with the law. The XCS eiConsole provides a paint-by-numbers approach to interface development including, configurable components to handle any data format, security method, validation scheme, or connectivity protocol. The XCS eiConsole has also been specially designed to take advantage of the NIEM standards. The National Information Exchange Model, built on the success of the Global Justice XML data model, facilitating standards based communication across a number of government relevant domains. One of the benefits of NIEM can be found in the consistent packaging of standards documentation into information exchange package documentation. These specifications contain artifacts – NIEM XML schemas, XML samples and documentation that can be directly consumed by the eiConsole. Once consumed, the XCS eiConsole user can clone and configure an interface for the generated template. Today, we’ll be taking a look at a driver’s license request and response interface built from the IEPD for the MVR look-up.

Each row in this Route Overview grid represents an interface. When you double click one, it will bring you to the Main Route grid.

This depicts the flow of data from our Source System to our Target. In this case, a Web Form will be filled out with the information about the individual that we want to do a driver’s license lookup for.

The first stage of the interface is the Listener configuration. Here we have a number of different Listener types that allow us to specify how the inbound data will arrive. Here we’re accepting data from a Web Form, so we’ve selected the HTTP Form/POST Listener.

You can see that we specify the Request Path and the fact that this will be a synchronous communication.

We then move on to the Source Transformation. Source Transformations in the XCS eiConsole have two components – a Transformation Module and XSLT. The Transformation Module is used when the inbound data is not in an XML format already. It allows us to convert things like Delimited and Fixed-Width files into an XML structure. However, because we’re receiving information from a Web Form, the Listener handles the conversion of the inbound Form data into an XML representation of the HTTP request.

The next step is to map the data from our Form elements into the DriverLicenseRequest as specified by the NIEM IEPD.

The XCS Data Mapper is the best of breed drag-and-drop data transformation tool that sits on top of the XSLT used to logically map between our Source Format – in this case our Web Form and our Target Format – the NIEM DLSearchRequest. Values from the left and the right are dragged together into the mapping pane in the middle.

Here we can see, for instance, the RequestSearchDemographic information with the PersonName child element and PersonGivenName child element. The PersonGivenName element in the NIEM standard will be populated with the firstname Form element from our Source. That is, blue nodes relate to Source data, green nodes are names of Target data elements.

You can also see that more complex conditional logic and data manipulation is possible. Here you can see a conditional structure, as well as some date/time formatting.

These are handled through a pallet of functions above the main mapping.

In any case, this mapping represents the transformation of our Web Form data into the NIEM standard. Once data has been transformed to that standard we move along to the Routing stage. Here, we’re able to set up Routing Rules to determine which Target system or systems will be in receipt of the data. In this case we have only one Target System, so we’ve selected the All Targets Routing Module. Our Target System in this case is a backend database with the driver’s license information.

The job of the Target Transformation is to take the data from our canonical format, in this case NIEM, and convert it into the format that the Target system c
an consume or process. So here, again, we use XSLT in the Data Mapper.

However, this time you can see the NIEM standard DLSearchRequest is our Source format. On the right hand side we have a database schema; that is we’re mapping fields from our SearchRequest into a set of database queries.

Here you can see that the SQLXML pallet of functions is used in combination with the database schema to set up a set of queries to be run to perform the SearchRequest.

Here we’ll be generating a sql:SQLXML document that we’ll be selecting from our table called DRIVERS…

And matching on or selecting on the FIRSTNAME column matching the first name in the SearchRequest, the MIDDLENAME column matching the middle name in the SearchRequest, etc.

Once again, everything under the covers is W3C standard XSLT.

Here in Testing Mode we can see a sample DLSearchRequest being translated into a SQLXML document.

The final stage in our Request Route is the Transport. The Transport is used to handle the connectivity to the Target System. In this case it’s the Database SQL Transport connecting to a relational database. But, we just as easily could have been dropping the data off in a Directory, emailing it, or invoking a Web Service.

Here we have our connection information for the database, we’ll execute the set of queries defined by the Target Transformation, and then we’ll be calling our Response Listener that will be handling the formulation of the response from the database back into a response to our browser client.

This CallBack Listener is a link between our Source Route, Request Route, and the DriverLicenseResponse.

Here we see the data flowing back from the database to the webpage and dropping a copy off in a directory.

In this case our Listener is a programmable Listener triggered by the return of results from the database in the preceding step.

We then have a Source Transformation where we’re taking now the database results set and translating into a NIEM response.

This time in the Data Mapper we have our database results set as our Source and our NIEM DriverLicenseSearchResponse as our Target.

We’ve now translated our database response into a NIEM document and have chosen to route it, again, to all defined Targets.

In the first case we’re relaying the data along without any further data transformation and dropping the resulting NIEM file off in a local directory.

In the second case we have yet another transformation.

This time we’re mapping from our DriverLicenseSearchResponse into an HTML document.

This HTML document will be what’s returned to the browser client.

Finally, because this response will be returned synchronously to the original request, you can see that we’ve selected the Synchronous Response Transport Type.

Now that we’ve configured both our Request and our Response, we can put it all together and take a look at how this interface can be tested within the eiConsole. Returning back to our Request, we can view the eiConsole’s Testing Mode. When in Testing Mode the icons between the Source System and the Target system are replaced by question marks, indicating a stage of a test that we may or may not choose to run.

We’ll begin the test with the Listener stage. The eiConsole is now waiting for us to post data from our Web Form.

On the webpage, we can enter in the criteria that we are interested in and click the Search button.

Data has now been posted to the eiConsole. As each stage completes questions marks now appear as check marks.

We can view the data as it appeared at each stage. Here we can see the Form data converted into an XML structure by our Listener.

Then, we can see that same information converted into a DLSearchRequest.

Next, we can see that information converted into a SQLXML document that will invoke a query against our database.

Finally, we connect to the database, run the query, and see these results automatically converted into an XML structure. This XML document then becomes the input to the outbound processing.

Looking at our Response Route in Testing Mode, we can start our test not with the Listener but with the Source Transform.

This time when we execute the test we can pull up a copy of that query response…

And manually run it through each stage.

Here we can again see the query results.

The transformation first to NIEM.

And then to HTML.

You can see that one of our stages shows us a red X indicating an error.

Here instead of seeing the data we’ll see the error information. Because we didn’t run the test end-to-end there was no web browser waiting on the response, so that’s the error that we see here.

So now that we’ve shown you how we can test the interface stage by stage, let’s run the entire thing from end-to-end. We can do that with the eiP Emulator. The XCS eiPlatform is the server environment that houses the interfaces deployed from the XCS eiConsole. However, the XCS eiConsole includes a server emulation mode that lets us do virtually everything possible in the server right here from the Console.

This time we’ll run our request using the eiP Emulator and click the Search button.

This time it will run end-to-end and we’ll see our HTML response.

That’s all there is to it. You’ve seen how we can go through and connect to databases, web pages, etc. using the XCS eiConsole for government. It really is the fastest, best, and most cost effective way to build interfaces using the NIEM standards.

To take the next step, download the XCS eiConsole and try out some of the tutorials.