Introduction
Using multiple VMD files in a single channel is a useful technique for separating different uses of VMD files. For example you may want to use one VMD for messages and another for database table structures, or you can use two VMD files to map to two different databases.
If you have any questions about using Chameleon please contact us at support@interfaceware.com
Using Multiple VMD files [top]
This section includes examples for keeping messages and table mapping separated, and the another for separating the structure of two databases.
Use different VMD files for message and table mapping
We recommend using different VMD files for the message structure and the table mapping. It is best practice to use different VMD files to separate the message structure (VMD Message Grammar) and the database table mappings (VMD Table Grammar).
Many organizations need to map various different HL7 messages to a single database. Generally it is best practice to structure code to reflect business process. By using a separate table schema VMD and multiple HL7 messages VMDs (one for each message type) we create a structure that better reflects what the organization does. Also if some messages use different versions of HL7 you can tailor the VMDs to use that specific version of HL7.
How it Works
This example code uses the same VMD file for hl7.parse() and db.tables():
The resulting code would look something like this:
Using multiple VMD files to map to different databases
Another scenario would be migrating from a legacy system, in this case you have multiple databases and multiple messages. This example shows a single message mapped to two databases using a separate VMD file to map to the legacy system.
An example of the power and flexibility of Iguana is that you can use different VMD files for hl7.parse() and db.tables(). In fact we recommend it as best practice to use different VMD files to separate the message structure (VMD Message Grammar) and the database table mappings (VMD Table Grammar) – particularly for more complex systems.
If you are introducing a new system and phasing out a legacy system with a different database structure you could use a second VMD file to map to the legacy system. This could all be achieved in a single channel with multiple calls to db.tables() and conn:merge().
This is the mapping for the new system:
This is the mapping for the (fictional) legacy system, which has a very dodgy database structure:
There are two conn:merge{} calls one for each database:
When the legacy system is no longer needed you can simply remove (or comment out) the second conn:merge{} call. If you like clean code like me you can remove every legacy reference, and still revert at anytime using the Iguana milestones.
This is not intended as a recipe, it is intended to hint at the potential of what you can do with Iguana when you start to think outside the box. I certainly find it to be a revolutionary product, I have not used anything else that combines such power, flexibility and ease of use.