10 Easy Steps to Building an ACORD PCS Interface 

Step 1 – Create a New Route or Interface

When you open the eiConsole, the first screen you see is the route file management screen. This is where the interface configuration files are managed. PilotFish configurations are divided into two levels. A single connection between some number of source and target systems is a route and a collection of routes working together is an interface. To create a new route, simply click add route and then type in a name and hit OK. 

Step 2 – Build the Route

Double-click your route to open the eiConsole as a main route grid window. PilotFish routes are built using an assembly-line fashion. The graphical automated interface assembly line consists of 7 stages, which are laid out in a grid across the top of the screen. These stages handle processing the flow of data from the source to the target systems. Regardless of the type of integration being done, the process is always the same. There’s also no limit to the number of source and target systems that can be linked in this way. 

Step 3 – Identify Your Source and Target System

Select the Source System stage to name your source system. For reference, name your Source and Target systems based on what they’re supposed to represent. Next to the system name field, type in policy download service and we’ll select a service icon. When the chosen source icon pop-up opens, select a representative icon from a library of 100’s of icons or add your own – then we can click select to make our choice. We can type in any metadata we’d like to include, and we can follow the same process for the Target System over here. If you’d like to add more Source or Target Systems, click the “add source” or “add target” button. 

Step 4 – Choose the Listener and any Processors Required

Next, we need to establish connectivity with the source system. PilotFish retrieves data from the Source System using a component called a Listener. This Listener communicates with the source system at highly configurable intervals, retrieves data, and starts a PilotFish transaction. Select the Listener stage to open the Listener configuration panel. PilotFish comes pre-bundled with several dozen Listeners capable of handling virtually any connection you might need and is easily extended using our open API. For this interface, select the FTP Listener. After the panel opens, we can change the default Listener name. Here, we’re going to change it to an FTP Listener. 

For the FTP type, we can specify encrypted FTP (including a library). We’ll also need to provide connectivity information, such as the host polling interval and credentials. After specifying our Listener, processors can be queued up to perform data manipulation. They’re accessed by clicking this processor configuration tab. Processors perform general work over the data stream – either directly after it is received or immediately before it is sent. You can use a processor to add decryption, perform authentication, validation, etc. Choose from nearly 100 processors or write your own using our open API. For this process, we really don’t need any of these processor steps. 

Step 5 – Transform the Source Data to a Common Standard

For data transformation, 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 to this conversion process in two steps. First, it goes to an automated transformer to convert raw content to XML (which is required). Because it can be set up to do a graphical configuration, they take a wide range of common data types and generate an XML representation of them. 

First, we’ll need to transform our AL3 message to XML. We’ll click our source transform stage here and click the add format button. In the pop-up panel, we will name our format. We usually name them according to what they’re going “from” to what they’re going “to”. The transformation module and XSLT configuration panel will now open.

Transformation modules are used to parse data from non-XML formats into an XML representation – while XSLT, over here on the right, in eiConsole’s data mapper, is used for the logical mapping of our format onto another. We’ll use our ACORD AL3 transformer to transform AL3 to XML. But also built-in, we have support for CSV, delimited and fixed-width files, EDI, no value pairs, XML – you name it. In the ACORD AL3 transform, we will need to specify the AL3 data dictionary. 

Step 6 – Configure the Routing Module

Select the route stage – this is where you can maintain general metadata describing the route, specify routing rules and configure transaction monitoring. When the panel appears, select the routing rules tab. This enables you to route messages to the appropriate target or targets based on the content of the message. From the drop-down, we’ll select all targets here.  The transaction monitoring tab allows us to customize the error notification system used by the interface in production. This practice of alerting supplements the traditional passive logging and audit trail supported and configured in the eiPlatform runtime.

Step 7 – Transform the Data for the Target

Next, we’ll select the target transform stage. This is where we’ll convert our new XML representation of XML into an ACORD PCS XML. You’ll use the same two-step process views of the source transform stage, only in reverse. First, we’ll click the add format button, enter our format name and click OK. In the transformation module configuration panel (on the left-hand side and XSLT configuration panel), we’ll uncheck the “Use Direct Relay” checkbox. This will enable the XSLT transformation, which we can configure by clicking the edit button and open up the data mapper.

The data mapper is a graphical editor within the eiConsole used to generate the XSLT transformations that transform any data formats to any other. The pane on the left shows a Source format; the pane on the right shows the target format, and the pane in the middle represents the relationship between the Source and Target. You can choose a format reader to read in our Source and Target formats – over two dozen are built-in. Relating Source and Target data are done by simply dragging & dropping from the Source Target or tool panel up at the top. Up at the top, this tool palette is a computationally complete list of structures, functions and custom macros that can be used to speed the development of high-quality transformations.

Selecting the XSLT View tab that lets users work in XSLT. While it’s possible to build an entire mapping from scratch, it’s often faster and easier to just simply drag & drop the Source values onto the Target values and build in your transformation that way. Users can also automatically create a skeleton for transformation with sample Source and Target files and import vendor-specific transaction samples to allow more straightforward data mapping with non-standard formats. 

Step 8 – Configure the Transport

You click the Transport stage, and in the Transport configuration panel, we’ll select the HTTP Post Transport from the drop-down list. When the configuration panel opens, we can change the default Transport name. In the basic tab, we can paste in a link or type a new URL for our target service. Here we’ll just put in a dummy value, and then we can fill any additional settings such as connection timeouts, authentication settings and so on. There are also several dozen types of Transport built into the eiConsole, which again can be extended with the open API. 

Step 9 – Test Your Interface from End-to-End

To test your interface, we simply go to mode and click testing mode. The eiConsole will ask us if we want to save our changes and then in testing mode, we can decide where we want to start our tests from. Here we’ll start from our Source Transform. So we’re going to start to test right here and provide a Source sample file. When we’re ready to actually run our test, we can simply click the execute test button up at the top.

As each stage of the testing successfully completes, we get green checkmarks. If a stage failed, we’d get a red X. We can click on any of the stages and view their contents with the stage output viewer. We can see the output from each of those stages and see how our data was changed as it progressed through each step of the transformation. For example, we can see the data in our original ACORD AL3 format transform to the generic XML and then finally into our ACORD XML. 

Step 10 – Deploy Your Interface

Once an interface has been tested from end-to-end, the final step is deployment to an eiPlatform runtime environment. The completed interface is saved as a set of discrete, easily shared and easily managed configuration files. We’ll return to our first file management screen. From here, we can promote our interface by simply copying the directory and files managed here from our local system to our eiPlatform systems or we can use a number of methods – such as directly dragging and dropping onto our target server or using the eiDashboard to deploy remotely to an eiPlatform instance. 

That’s it! In 10 easy steps, we’ve Illustrated how by using the PilotFish graphical automated interface assembly line – you can quickly configure, test and deploy an ACORD AL3 Interface.

We offer a Free 90-Day Trial of the eiConsole. Take it for a test drive. If you have any questions or would like more information please let us know. For more PilotFish videos demonstrating other software features view our PilotFish Product Video page.