This example shows how to use a simple properties file to translate between the cryptic codes displayed by a host application and more meaningful descriptions.
The modelLoadedlife cycle event is used to read the properties
file into an in-memory abbreviation table (java.util.ResourceBundle)
stored in the model hashmap. The modelUnloaded event removes the
shared object from memory when the model is unloaded.
The readField event looks up the code it reads from the recordset
field in the abbreviation table and returns any translation it finds as the
value of the field.
The model used is an adaptation of the CCSDemo model. The Code field within the AcctTransData recordset on the AcctTransactions entity has an event handlers attached to it.
The event handlers can be called in the Design Tool by using the Debug Procedure Test menu command. Execute the Transactions.GetTransactions procedure using the account number 167439459. The Code procedure output will display the results produced by the event handlers.
The Design Tool's Recordset Test can also be used to call the event handlers. Navigate to the AcctTransactions entity and issue the Debug Recordset Test command.
The event handlers can be called in the Server by deploying the model to the Session Server.
The model used in this example, and the ways in which it is tested, are exactly the same as those used in the abbreviations example. But in this case, the in-memory lookup table, initialized by a resource file, is replaced with a SQL database using a JDBC query.
This example also illustrates how to write messages to the Verastream log file. If the database connection can't be initialized, a query fails, or an abbreviation is not found, a warning message is written to the Verastream log as an aid to problem diagnosis.
The AbbreviationDB encapsulates how the database
connection is created, and how queries are performed.
The modelLoaded event handler creates an AbbreviationDB object
and stores a reference to it in the shared model hashmap, so that it can be
used by all sessions using that model. The modelUnloaded event
handler closes the connection and removes it from the hashmap.
The AbbreviationDB constructor loads the JDBC driver, connects to the database, and prepares the query. If any of these steps fails, the constructor throws an exception which the caller is expected to catch so that the problem can be reported.
The AbbreviationDB translate method looks up an abbreviation in
the database and returns its translation. If an abbreviations cannot be
found, or if the query fails, the method throws an exception.
A single PreparedStatement object (dbQuery) is
shared by all sessions using the model. The translate method
is marked synchronized so that only a single thread can enter
the method at a time. This is necessary because the dbQuery
object is not read-only: from the time the abbreviation parameter is stored
in the prepared statement until the result is returned, dbQuery
holds information belonging to a single host session.
The model is identical to that used in the Abbreviations example.
Almost any relational database with a JDBC driver can be used for this example. The database design is trivial:
CHAR(2) NOT NULL.
The second column is named Translation defined as
VARCHAR(32) DEFAULT ''.
The database contents are:
| Code | Translation |
|---|---|
| A6 | Loan payment |
| B2 | Electronic funds transfer |
| B6 | Automatic payroll deposit |
| C6 | Credit purchase |
| D6 | Deposit |
| E6 | Escrow payment |
| LC | Late charge |
| GR | Interest payment |
Two database initialization example files are provided in the AbbreviationsDB model directory. The commands necessary to create and initialize the MySQL open-source database are in the file mysql.txt. The initial contents of the Abbreviations table are stored in the tab-delimited file named abbreviations.txt.
Use the instructions supplied with the Abbreviations example.
This example shows how recordset fields, in this case
those representing dates and currency values, can be reformatted
for client applications. The event handlers use the
defaultReadField method on the FieldEvent
interface to read the recordset fields. The field value from
the host application is reformatted and returned as the field
value for use by the client.
The implementation of the example illustrates several points.
AttributeEvents
examples) to do the bulk of the work. This simplifies the actual
event handler code, and promotes code reuse.
DateFieldHandler class uses a read-only instance
of a DateFormatter class to do the actual date parsing
and conversion. A single date formatter is created as part of the
class loading process, and is shared among all host sessions.
The model used is an adaptation of the CCSDemo model. The date- and currency-valued fields within the AcctTransData recordset on the AcctTransactions entity have had event handlers attached to them.
The event handlers can be called in the Design Tool by using the Debug Procedure Test menu command. Execute the Transactions.GetTransactions procedure using the account number 167439459. The date and currency procedure outputs will display the results produced by the event handlers.
The Design Tool's Recordset Test can also be used to call the event handlers. Navigate to the AcctTransactions entity and issue the Debug Recordset Test command.
The event handlers can be called in the Server by deploying the model to the Session Server.