If you are using the static interface with Chameleon, your project must define an application Engine class. This class must inherit from the generated <prefix>Engine class in the stubcode private DLL which in turn is a child of the iNTERFACEWARE.Chameleon.Engine class. The following diagram shows the relationship:

Engine Class Inheritance

This class can be called anything that the developer chooses, typically something such as ApplicationEngine would be a good choice. There is no limit to the number of engine objects that can be instantiated in each application. It might be helpful to have one engine instance to handle ACKnowledgements, another to pre-sort incoming messages into different types and so on.

There are several steps that need to be followed to set up the Engine object:

• The engine class must be instantiated.
• The load method must be invoked to load the message definition file.
• A Log object may optionally be assigned to the engine.

The following code fragment shows how you would typically create an Engine object:

ApplicationEngine engine = new ApplicationEngine();
// Assign a object which implements the Log interface.
engine.AddLog(this);

try
{
   // Load is a slow operation and should only be performed once. If you try 
   // to load Engine on every transaction, the performance will be slow.

   engine.Load("myfile.vmd");
}
catch (ChameleonException ex) 
{
   // Use a try/catch block to produce informative error messages,
   // otherwise you'll get unhandled exception messages.

   Println("Error during loading:" + ex.ToString());
}

The Chameleon C# framework supports the idea of a Log interface which consists of a single method Println(string line). This abstraction allows any object to implement the Log interface. The Log interface is explained in detail in this section of the documentation.

	Only one thread at a time should go through the Chameleon engine object. Multi-threaded applications should either use one instance of the engine per thread or protect the engine object using synchronization.

The stubcode Engine class has one virtual method for each message defined in the message definition file. Each function must be overridden by the user to implement the business logic required for the interface:

public override void OnPatientAdmitMessage
(
   PatientAdmitMessage message,
   Transport aTransport
)
{
   Println("Sending application = " + message.Header(0).SendingApplication());
   Println("Receiving application = " + message.Header(0).ReceivingApplication());
   // ...process message here 
}

Each of these message virtual functions has two parameters:

• A custom message object
• A transport object

The message object is a generated class which has methods for retrieving the tables that make up each message. Each table object has methods to get and set the column values in the table. These classes are described in the next section.

Transport is an abstract interface which can be used to send an ACKnowledgement message back to the original source of the message. It is designed to allow the server code to be coded independently of the actual source of the messages..