How the Electronic Journal works

The following process describes what happens when a process running within the Business Process Component or a single action EJB uses the Electronic Journal service to create a record in a journal. Note that the process omits many of the initialization and messaging steps that normally happens in a service. See How services work for information on these steps.

  1. The business process or single action EJB uses the service requester name to get a journal requester from the requester factory. The factory finds the corresponding resource bundle file name and uses the definition in the resource bundle file to create and configure the requester instance.
  2. The process or single action EJB invokes the journal service requester to create a record.
  3. The requester accesses the formatter service to format the data for the create record request.
  4. The requester sends the create record request and its parameters to the service holder. Each service requester has a flag that determines how it invokes the service object. The requester can use a native Java(TM) call if the journal service object is local. If the journal service object is remote, the requester uses EJB method calls, WSIF SOAP binding messages, or WSIF EJB binding messages.
  5. The services container invokes the create function in the journal service object.
  6. The journal service object creates an SQL statement using the contents of the WSIF message or the parameters of the EJB method call.
  7. The journal service object passes the SQL statement to the database through the data source and connection manager. Note that the definition for the service object identifies the database.
  8. The services container returns the response to the requester.
  9. The requester accesses the formatter service to unformat the response, updates the CHA with the response data, and sends the unformatted response to the activity.

When the Electronic Journal service accesses the journal for the first time, it obtains the current journaling date. The journal returns the system date, but you can override this implementation if you require a different behavior (for instance, the current journaling date can be tomorrow if the current system time is later than 6:00 p.m.). When the service opens a journal, it compares the date of the current journal table and the current journaling date. If the latter is greater, the service creates the next journal generation for the specific entity and deletes the oldest generation if the maximum number of generations is reached. If the dates are equal, service uses the current generation.