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.
- 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.
- The process or single action EJB invokes the journal service requester
to create a record.
- The requester accesses the formatter service to format the data for the
create record request.
- 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.
- The services container invokes the create function in the journal service
object.
- The journal service object creates an SQL statement using the contents
of the WSIF message or the parameters of the EJB method call.
- 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.
- The services container returns the response to the requester.
- 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.