An Electronic Journal enables a financial institution to store and retrieve data from a set of tables, such as flat indexed files or DB2 tables, where each table represents a log of the operations performed during a certain period (usually one day). The institution defines the number of required tables. Normally, an institution keeps a different table for each day of the week, so that all the days are simultaneously accessible. It also defines a backup policy so that each day's data can safely overwrite the data from the same day of the previous week. The institution also defines different tables for different entities, such as the branch, the terminals, and the users, so that information about an operation related to a specific entity can be easily retrieved.
It must be possible to store, retrieve, and update data in the journal. For example, an implementation may specify that a record is written when an operation starts, and then either another record is written when the operation finishes or the existing record is updated with the operation result. Due to the logging nature of the journal system, deletion is not supported.
A journal system implementation must also provide data integrity, allowing commit and rollback operations to be performed automatically by the system or by an application demand.
The UDTT Studio provides the following:
▪ An interface, JournalService, which defines a minimal but sufficient set of public operations that are easy to utilize for most implementations using a journal service.
▪ The Journal class, an abstract base class that represents a generic financial electronic journal. This class extends the JDBCService class (which implements the interface DatabaseConnect, including all methods related to the database connection), and implements the JournalService interface.
▪ The generic methods (some abstract and some with a default implementation) needed by any journal implementation, regardless of the database that is used to store the information.
▪ A Journal subclass, JDBCJournal, which extends the Journal class. JDBCJournal can work with any DBMS (database management system) that provides a JDBC driver. This subclass can be further subclassed if additional functionality is required.
The application working with the journal service (either a JDBCJournal class instance or any other user-written service that subclasses from Journal or that implements the JournalService interface) should always work with the JournalService interface instead of casting the object returned by the toolkit externalizer to the specific Java™ type implementing this interface. This makes particular implementations of the JournalService transparent to the application implementation at any time. Using this approach enables you to use a dummy journal service during development and later change it to the real journal service. To access the appropriate service instance, you only need to modify the external toolkit definition files (services and context definitions), as required by the environment. It is not necessary to modify the written application.
A journal keeps information about the daily operations performed in a branch. The type of information to be included, as well as when that information is to be written, is part of the design of the teller application. A journal record consists of a string of bytes containing the data that the operation wants to store, formatted in a certain way. Each journal record is identified by a unique record number, which is maintained by the journal object. Record numbers are always increasing, although they are not necessarily consecutive.
Different tables within a journal can be organized by user, by workstation, or by any other criterion. Because there can be different tables for a single journal entity, it is possible to define a journal for a certain entity, where the journal comprises the set of journal tables belonging to that entity.
The period over which a journal table exists is normally one day. Therefore, a reference to the journal of a certain entity usually refers to today's journal, a unique table known as the current journal. Older data for the same entity is kept in other journal generations. The system is predefined to keep a fixed number of journal generations for every entity (usually six, which is one working week). At the abstract class level, only the current journal can be accessed. Access to older generations is defined at each platform implementation level.
Two processes are used to define the characteristics of the Electronic Journal:
▪ The first process creates the journal tables in the database, and sets the entities that the journal is going to work with, the number of generations per entity, and the definition of the tables within the database. Typically, the database administrator will perform this process only once, before the application using the journal service is started. (See Using the Electronic Journal Schema Generator.)
▪ The second process creates the journal instance and sets its attributes: the schema name for the set of journal tables, the autoCommit attribute, the JDBCDriver attribute, and all other attributes related to the database connection. These attributes are externalized in the journal service definition in the services definition file. When the journal instance is created, these attributes are automatically set with the values defined in the definition file. In addition to externalizing the service attributes, the journal format definition will be externalized in the formats definition file for the specific journal implementation. This process is part of the application flow, and must be done before the application can begin to use the journal service to access the database.
Journal objects are inactive just after instantiation, and no connection to the database is set at that point. The application must request the database connection and send the open() method to the journal instance to make it active. The open() method selects the table that this journal instance is going to use, and the current journal will work with it for any database operation that is requested while the instance is active. A close() message reverts the state back to inactive, and closes or releases the database connection (if connection pooling is being used).
The current journaling date, a java.lang.String instance with a format of yyyymmdd (yyyy = year, mm = month, dd = day), is obtained by calling the today() method of the journal instance as soon as it is created. The default implementation of this method returns the system date, but this date can be overwritten if a different behavior is required (for instance, the current journaling date can be tomorrow if the current system time is later than 6:00 p.m.). When a journal is opened, the date of the current journal table and the current journaling date are compared. If the latter is greater, then the next generation is selected for the specific entity (and the oldest generation is deleted if the maximum number of generations is reached). If the dates are equal, then the current generation is opened.
Electronic Journal schema
The electronic journal schema is the set of tables needed by a JDBCJournal to work within a particular configuration (entities and number of generations). All the tables for a schema are referenced in the DBMS by prefixing the table names with the name of this particular schema.
The journal schema consists of a control table and a number of journal tables calculated with the following formula:
number of schema tables = (number of entities) x (number of generations)
The tables are intended to be accessed transparently by different journal instances. The application can manipulate data (add, modify, or retrieve journal information) without dealing with daily generation management and the naming convention of the tables within the DBMS, which is internally controlled by the JDBCJournal class.
The organization of the journal schema is detailed below. This information is provided for developers who may wish to develop utilities to exploit journal data through a Java application or data access beans.
The name of the control table is schemaName.DSEJOUCT. It contains an entry for each defined entity (ENTITY_NAME column), with information about the last journal date (LAST_DATE column) and the last wrap number (WRAP_N column). There is also a special entry (with ENTITY_NAME set to the specific value of DSEJOU) with information about the total number of generations to be kept for each entity.
Each entity has a journal table for each generation in the specified schema, with the name entityName_n, where "n" is a number from 1 to the total number of generations defined in the control table.
The structure of the journal tables is defined at schema creation time, and is provided as an argument to the schema generator method (see Electronic Journal Schema Generator). There is always an extra column in the journal tables, called DSERECN, which holds the record numbers and acts as the primary key for accessing the journal tables. The other columns are specified at creation time by passing the column definitions, using the same format required by the standard SQL CREATE TABLE statement. The allowed column types are the ones that are allowed by JDBC support (refer to the JDBC API documentation or JDBC types mapped to Java types).
Electronic Journal Schema Generator
The JDBCJournalSchemaGenerator is an auxiliary class that is used for database administration tasks. It allows an application to do the following:
▪ Generate the set of tables for a journal schema with the given entity names, number of journal generations, and column definitions for the journal tables (in SQL format)
▪ Add or remove an entity from the list of entities
▪ Show the names of the defined entities
▪ Get the number of generations defined for a specific journal schema
▪ Remove the whole schema
The journal schema must be understood as an abstract way of grouping all journal tables. By default, the Schema Generator will try to create a database schema in the DBMS by using the SQL statement CREATE SCHEMA. Because not all DBMSs allow schema generation and management, the application can change the JDBCJournalSchemaGenerator default behavior by setting the createSchema attribute to false, using the setCreateSchema(boolean newCreateSchema) method.