A Tomcat server uses logging services to communicate its status and respond to specific events, including server startup and shutdown information, failures of one or more subsystems, errors, warning messages, access information on HTTP requests, and additional information. For example, you can use the logging services from Tomcat to report error conditions, or to listen for log messages from a specific subsystem.
All administrator and end-user actions and events are logged to the Tomat server console and to the Tomcat server log file which allows easy access to this information for security and operational purposes. Additionally, the audit log system provides the ability to monitor ongoing activities such as authentication activity and up time of the system. File logging is enabled by default.
The workflow functionalities are implemented in a layered architecture. Each feature uses one or more packages. Each package handles a specific area of a feature and has its own independent log level that obtains event messages from different parts of the application. The logs contain information about processing and interactions among components that occur while fulfilling user and administrative requests, and during general system processing. By enabling the correct log levels for various features, an administrator can monitor how the workflow service processes user and administrative requests. Package names are based on Java Development Kit (JDK) conventions. The event messages include these package names indicating the context of the message output. The logs include tags and values that allow the administrator to identify and correlate which package log entries pertain to a given transaction and user. Table 18-1 describes some of the features and the packages they use.
Table 18-1 Workflow Administration Packages and Features
|
Feature |
Description |
Packages |
|---|---|---|
|
Approval |
The approval packages are implemented for approving any permission or other user request. |
|
|
Audit and Logging |
Logging allows you to debug the configurations associated with the various features in the Workflow Administration Console. The logging service allows to write, view, filter, and listen to log messages. You can configure logging to troubleshoot errors, or to receive notification for specific events. These events are logged in CEF format. |
|
|
Authorization |
The Settings page in the Workflow Administration Console is used to assign trustees, configure the display settings, and categories, and process types for the workflow catalog. |
|
|
Common |
The common packages are common to more than one feature in the workflow service. |
|
|
Configuration |
In the Workflow Administration Console, the Configuration tab is used to configure the logging, email based approval, and engine and cluster settings. |
|
|
Dashboard |
The Dashboard is used to monitor the status of workflows and review their performance all in one place. The Dashboard also helps in tracking and prioritizing the workflows based on the need of the organization. |
|
|
Data Layer |
It is the layer that interacts with the persistent store, such as, the database to fetch any information. |
|
|
Email-based Approval |
Email notifications in the Workflow Administration Console informs users of tasks and events in the system. For example, sending an email to approvers when an event or task requires an approval. |
|
|
Engine and Cluster |
Provides information on engine and cluster. |
|
|
External Service |
Implements the client to connect to the external services, such as Identity Governance and Identity Manager. |
|
|
Locale |
Includes information on all default and supported locales. |
com.microfocus.rest |
|
Notification |
The notification function included in the Workflow Administration Console allows you to send email notifications that notify users of changes in the state of a workflow, tasks that they need to perform, or when a user assigns a workflow activity to a new addressee. |
|
|
Workflow Process |
Includes information on workflow processes, such as start, approval, finish. |
|
The generated logs that are primarily intended for debugging the software. System administrators and support personnel can identify and isolate problems caused by configuration errors, invalid user data, or network problems. However, component file logging is typically the first step in identifying software bugs.
Package logging is more verbose than audit logging. It increases the processing load. On a day-to-day basis, you should enable only log levels of error conditions and system warnings. If a specific problem occurs, logging can be set to Info or Debug to gather extra information needed to isolate and resolve the detected problem. When the problem is resolved, logging should be reconfigured to log only error conditions and system warnings.