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 package which in turn is a child of the com.interfaceware.chameleon.Engine class. The following diagram shows the relationship, click on each section for more information:

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. Sometimes 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 Engine();
// 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 Error) 
{
   // Use a try/catch block to produce informative error messages,
   // otherwise you'll get unhandled exception messages.

   println("Error during loading:" + Error.toString());
}

The Chameleon java 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 void onPatientAdmitMessage
(
   PatientAdmitMessage Message,
   Transport ATransport
) throws ChameleonException
{
   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 used to be used to send an ACKnowledgement message back to the original source of the message. Its usage is deprecated since the current networking components do not require it.