DBEvents service - Faxchange 6.x

DBEvents service

FaxChange service "FaxChange.DBEvents" monitors the application event log and if any FaxChange event occurs, service stores the copy of the event into the database. Service was implemented as part of customer solution for "Česká Spořitelna, a.s."

Installation

Installation is started by executing batch command X:\FaxChange\i386\server\SETUP\_dbevents.cmd
where "X" should be replaced with the drive letter where the UMS CD is placed. The command must be run only from local drive or mapped network drive! The setup of the service starts with the following dialog:

The account name under which the service should run and the password are needed:

Currently there are three available database engines - Microsoft Access, Microsoft SQL Server and Oracle - that can be used to store the events. The default engine is the one selected for FaxChange. Choose the desired type:

If database type selected was Microsoft Access, specify the database file and credentials needed to access the database. Notice that the defaults are preselected based on the FaxChange configuration:

If database type selected was Microsoft SQL Server, specify the database server name, initial catalog and credentials needed to access the database. Notice that the defaults are preselected based on the FaxChange configuration:

If database type selected was Oracle, specify the database SID and credentials needed to access the database. Notice that the defaults are preselected based on the FaxChange configuration:

Next the configuration is stored into the registry branch HKLM\Software\Datasys\FaxChange\global\dbeventlog, service is installed and registered to FaxChange system attendant. After that the dialog with the summary of installation result is displayed:

Press Finish button and the installation is finished.

Uninstallation

Uninstallation is started by executing the same batch command as installation X:\FaxChange\i386\server\SETUP\_dbevents.cmd
The command must be run only from local drive or mapped network drive! The service configuration is detected and uninstallation of the service starts with the following dialog:

Next the service is removed and the service's configuration is deleted from registry. After that the dialog with the summary of uninstallation result is displayed:

Press Finish button and the uninstallation is finished.

How it works

After starting the service "FaxChange.DBEvents" it registers itself to service control manager (SCM). SCM then calls the starting routine which runs two threads - one for monitoring the event log and the second for storing events into the database.

Starting routine reads the registry configuration items for logging purposes. These are the FaxChange configuration entries dir and level and located under HKLM\Software\Datasys\FaxChange\log\system registry key.
The dir entry says where the root logging directory is and the level entry specifies the logging level - this determines the amount of messages written to log and could hold one of the following values: "NONE" (no log generated), "FATAL", "ERROR", "WARNING", "INFO", "DEBUG" or "TRACE" (very intensive logging). The log is generated into "fxdbevt" subdirectory of the root logging directory.

The monitoring thread looks for the last eventlog message and starts waiting for the new one(s). If this occurs, the new messages are read. If the source of the message starts with "FaxChange" then it is assumed that the event was generated by FaxChange and the message is sent to storing thread to be saved into the database.

The storing thread initializes the database objects first. It checks if database exists and if it is not, either the database is created (in case of Access database type) or the service is stopped (in case of SQL Server or Oracle). If database exists the table "FXEVENTS" is searched and if it does not exist, it is created via SQL command. Then the service tries to open the connection. If opening connection fails, the attempt to connect is made whenever a new request to store the message to database comes until connection is opened successfully. Notice that previous messages are lost. After initialization the thread starts listening for incoming messages from the monitoring thread. If any new message is received, it is stored into the database via the prepared SQL INSERT command.

If the service is stopped, the threads retrieve the signal telling them to finish. The monitoring thread deregisters itself from the eventlog notifier and terminates. The storing thread closes the connection to database, frees all the objects used and terminates also. Then the service's starting routine notifies the SCM that it is finished and exits.

Sample of the stored data

Here is the cutoff from the Access database with some events stored by FaxChange.DBEvents service: