Welcome to the eiConsole for DTCC product Quick Tour. PilotFish Technology and the DTCC are proud to offer the eiConsole for DTCC. Whether your organization is sending or receiving DTCC supported data formats, and regardless of whether you’re using the widely adopted IPS file layouts or the emerging ACORD TXLife Web Service transactions, the eiConsole for DTCC provides a rich suite of tools to facilitate implementation, reduce project timelines, and control costs.
When first launching the eiConsole for DTCC, the Route File Management window will be displayed. This depicts all of the interfaces and interface templates in the developer’s local working directory. The eiConsole for DTCC includes preconfigured interface templates for each and every one of DTCC’s supported data formats. Creating a new interface that produces or consumes these formats is as easy as selecting the appropriate template, copying, and configuring.
Double-clicking an interface exposes the main route grid. This depicts the paint-by-numbers flow of an interface from one or more Source Systems to one or more defined Target Systems. The developer’s job is to work through each one of these defined stages, in turn, configuring the desired behavior.
A Source System will make data available to a Listener…
…which can then either passively or proactively acquire that data in whatever format the Source System desires. The developer simply chooses the appropriate Listener Type and then configures the displayed configuration options.
After data has been acquired by the Listener you’ll move on to the Processor stage. The Processor stage lets you do general work over the data stream, such as Decompression, Decryption, specialized logging, or DTCC specific validation.
You then move on to the Source Transformation where data is taken from the format of the Source into a canonical model for that transaction type. In this case, the Source System will be producing IPS flat-file APP Sub layouts. This data will be translated through a Transformation Module into an XML representation of the APP file. That XML representation of the DTCC App Sub format will be used as your canonical model. This Transformation Module can be used to translate any non self-describing data into an XML format. XSLT is then used, if required, to logically map that data onto the desired canonical model. In this particular case, the APP XML will be used as the canonical and no XSLT will be configured.
You’ll then move on to the Routing stage. The Routing stage allows you to define Routing Rules, wherein, if you had multiple Targets defined, you could determine which data should be sent to which Target or set of Targets.
The Routing pane also allows you to configure Transaction Monitors. Transaction Monitoring is the eiConsole’s mechanism for proactive error handling and notification. Common examples include email or an SNMP trap.
For each defined Target System, there may be a Target Transform. The Target Transform is used to take the data from the canonical format and to translate it into a format that can be consumed by the Target System. In this case, you’ll be taking the APP XML file and doing a translation into an XML representation of an SQL update.
If further translation to a different data representation is required, a Transformation Module can be used. For instance, the Delimited and Fixed-width file Transformation Module can be used to generate a DTCC IPS file layout.
Finally, the Transport stage is used to handle connectivity to the Target System. Just like in the Listener, there are a variety of Transport Types supported. Select the one appropriate to the Target and configure it.
The Target System then receives the data either in a batch mode or in real-time. Should the Target System provide an immediate response, the Transport will then take that response data and pass it along to a subsequent route, which will handle the processing of that response.
Once a developer has completely configured the Route, they’ll switch to the eiConsole’s testing mode. In Testing Mode, the developer can start the test at any stage (on Source Transform in this case), and end the test at any stage (on Target Transform in our case), with arrows indicating the path that the data might take.
Clicking the Execute Test button will display a dialogue that will allow you to provide sample data for your test. In this case, you’ll provide a flat file APP sample. As each stage completes, the question marks on the screen will turn into either a checkmark for success or a red X for a failure. You can look at the performance of each stage, as well as the data as it appeared at each point in the process.
Here you started with an APP file.
That was translated automatically through the Flat-file Transformation Module into an XML representation of the APP Sub format.
That data was then further translated into a database insert into a table called Entities.
NOTE: the completion of this tutorial requires the creation of the ENTITIES table with the NAME, NATURALIND, APPCONTROL, ADDRESS, CITY, STATE, ZIP, ENTITYDATE fields in the test database.
Finally, that insert was executed against a relational database. Once the developer is comfortable with the outcome of their test, they’ll return back to the File Management window. This will allow the developer to deploy the interface to the separately licensed eiPlatform run-time component.
Now that you have an overview of how the eiConsole works, let’s take a closer look at how the eiConsole helps you specifically for DTCC related transactions.
The eiConsole supports the capability of taking IPS file layouts from XML into a flat-file, or from flat-file into XML. The Delimited and Fixed-width File Transformation Module, supported by the File Specification Editor, is what supports this capability. The tree on the left-hand side of the screen shows the preconfigured layout of an App Sub file – green records representing loops, blue records representing fields.
Any DTCC layout of any version can be read in using the Import from DTCC format capability.
Simply point at the appropriate XLS, the spreadsheet published by IPS, click Open and the data will be loaded into the left-hand side of the screen.
Once loaded, this tool has the capability of taking a flat representation and translating it into the structured XML that you can then map.
The same tool can be used to take the XML representation that you might generate and automatically handle all of the formatting required to place the file in the appropriate fixed-width layout.
You can go from an XML structure…
…into a flat-file. All tedious parsing, or creation of these formats, is eliminated.
Of course, the tool can be used to handle not only DTCC formats but any other fixed-width or delimited format that you might need to parse.
Moving on to the Target Transformation, the eiConsole generates XSLT to represent logical mappings. This XLST is created in a best of breed Data Mapping tool called the Data Mapper. The Data Mapper is a 3-panel mapping tool. You’ll have the Source format on the left, the Target format on the right, and the logical mapping represented in the middle.
When loading in the Source format, the eiConsole for DTCC highlights the DTCC format reader as well as the ACORD Life Schema Release format builder. The DTCC format reader allows you to consume the IPS Layout spreadsheets.
Select the Format Reader, choose your desired format, and click Read Format.
The tree on the left-hand side of the screen will be populated with the appropriate DTCC layout. The DTCC tab will provide searchable documentation for each one of the fields within the DTCC layout that you’re working with.
Additionally, when working with a field that has a codelist associated, a Codes tab will appear.
These codes can be used in conjunction with the eiConsole’s Tabular Mapping tool to very easily generate mappings between two sets of enumerated values.
Mapping in the Data Mapper is as simple as drag and drop. Select the field that you’d like to add from your Target, drop it onto the appropriate parent and then choose the corresponding field in your Source.
Now, let’s take a look at how this applies to DTCC’s ACORD TX Life transactions. For each one of DTCC’s emerging ACORD TX Life transactions, PilotFish provides a transaction template. The transaction template includes DTCC’s desired soap envelope, as well as a version of the TX Life transaction payload. Just as the DTCC documentation for the IPS Fixed-width file layouts were available in-line, the ACORD documentation is also available when mapping to or from an ACORD transaction. The ACORD tab has the ACORD defined or DTCC defined description and definition.
Again, when working with typecodes, a Codes tab appears with the Code, Code Name, and Code Description.
Developing a new ACORD transaction is as simple as reading in your Source format using the Source Format Readers and then mapping onto the map in the middle.
Finally, the eiConsole for DTCC includes a specially developed MTOM Processor. The MTOM input and output Processors allow you to quickly either generate or consume DTCC’s required MTOM attachments. Like with any other Processor in the eiConsole, simply select the appropriate Processor during the Listener or Transport stage and fill out the required configuration information.
You have now seen how pre-developed ACORD and DTCC interface components can dramatically reduce the learning curve required to take advantage of DTCC’s current and emerging offerings. Months of implementation effort are certainly eliminated reducing budget and resource constraints that may have previously prevented valuable projects from moving forward. This concludes the Quick Tour of the eiConsole for DTCC.