• Introduction
• chm.parse{}
• chm.transform{}

Introduction

As the saying goes it if ain’t broke don’t fix it. For many customers if you have existing interfaces implemented using Chameleon vmd/python technology there is no point migrating that code to the Translator, especially if it meets your current needs.

However if you do have good reasons for moving forward to using the Translator but need to migrate your existing old mappings then there a couple of APIs we have implemented to make that easy for you.

• chm.parse{}: this invokes an HL7 to table grammar parse as one would typically have done inside a To Database component.
• chm.transform{}: this invokes either a scripted or graphical transformation as one would have done in filter component.

If you are interested in porting your existing interfaces to Translator technology have a look at the DB to HL7 migrating a legacy system tutorial. It shows the use of regression testing to ensure equivalent logic. If you have a need to port your existing code over to the Translator then please drop us a line at support@interfaceware.com. We are in the process of helping to build a set of resources to solve this type of problem.

chm.parse{} [top]

This function will perform a legacy ‘full table parse’ as one would have done with Chameleon prior to the Translator in a To Database channel.

It takes these parameters:

• ‘vmd’ – the VMD to use
• ‘data’ – the message to transform

It returns true values:

1. A ‘table grammar’ node tree the data parsed from the message in it.
2. All Python output – i.e. from log and print statements

Here is an example of using it:

local Msg, PythonOutput = chm.parse{ vmd='legacy.vmd', data=Data}

Some caveats:

• The returned “table grammar tree” (legacy format) is different from the “table tree” returned by db.tables. So if you want to insert a “table grammar tree” into a data base, or compare it to a “table tree” you will need to write helper code to do this.
• The vmd needs to be part of the Translator project and therefore be under version control.
• But the python modules the code might use will just be on the general file system

The API is intended to make it convenient to write code to compare the output of equivalent Lua mapping code rather than be an API you would want to use for the long term.

The ability to capture the output from python can be invaluable.

We had a customer that was doing a lot of direct SQL inserts. To make the output of that code visible we did the following:

• Tweaked the code to override the built in database object to instead print out the SQL statements directly.
• Parsed the output SQL in Lua to actually create an equivalent table structure which we could then
• Diff against the equivalent Lua mapping code

Talk to us if you using this API and are curious about more ideas for easily migrating older code.

chm.transform{} [top]

This function will perform a legacy transformation as one would have done with Chameleon in a filter prior to the Translator. It is available in Iguana 5.0.5 and up.

It takes these parameters:

• ‘vmd’ – the VMD to use
• ‘data’ – the message to transform
• ‘config’ – (scripted transformation only) the configuration to use
• ‘in_config’ – (graphical only) the inbound configuration
• ‘out_config’ – (graphical only) the outbound configuration

It returns three values:

1. The transformed message is returned
2. Its name
3. All Python output – i.e. from log and print statements

Here is an example of using it:

local Msg, MsgType,PythonOutput = chm.transform{ vmd='legacy.vmd', data=Data, config='default' }

Some caveats:

• The vmd needs to be part of the Translator project and therefore be under version control.
• But the python modules the code might use will just be on the general file system

The API is intended to make it convenient to write code to compare the output of equivalent Lua mapping code rather than be an API you would want to use for the long term.

The ability to capture the output from python can be invaluable. Say for instance your python code makes direct SQL inserts, then you could tweak that code to output those writes as print statements to make it visible within the Translator environment. Internally we have done some creative things like this to help customers migrate code. Talk to us if you using these APIs.