Common Log sub-tab displays messages pertaining to
various aspects of
runtime operations, including the execution of application workflows. However,
common log messages are most useful for diagnosing and debugging orchestration
Tip: For diagnostic and debugging purposes, the Log Viewer in
provides the most useful view of the Common Log. For more information, see the
SBM Composer Guide.
Common Log sub-tab, you can:
- Create, edit, and delete custom filters that limit the number of
messages in the log. You can search messages by the user who logged the entry,
application name or orchestration name, date/time, level, or entry content. For
more information, see
Working with Logs.
Note: Filtering the common log by orchestration name is
an effective way to limit results for process apps that were deployed from
However, if the process app was deployed from
filtering by orchestration name does not provide correct results because some
assets in the orchestration are only created during deploy from
- Open the
Settings dialog box, where you can control
logging levels for messages in the log. This option is enabled only if you have
the necessary administration privileges. For details, see
Clear History to clear all the messages in the
log. You can delete all events, or events prior to a specific date. You can
also schedule recurring clear history operations. Note that this option is
enabled only for global administrators.
Cancel any scheduled activities for all
environments option to cancel scheduled clear history operations
for all of your environments.
- Click the refresh icon to update the list with the latest entries.
There are two logging types for messages that appear in the Common
- User: User messages (also known as "key" messages) provide
diagnostic information that pertains to the high-level, logical execution of a
process app, particularly orchestration workflows. These messages can be used
to debug the logic of orchestration workflows because they are generated at key
points in their execution and capture relevant information. They can be of any
logging level (see below).
- Technical: Technical messages provide both high-level and
internal implementation information.
The following information is available for each entry:
The logging level associated with the entry.
The date the entry was logged.
The entity that provided the log entry.
The details of the common log entry.
Settings button to select a logging level that
determines the verbosity, or volume of messages that will be logged.
Note: A list of all known published process apps appears, along with the
applications and orchestrations contained in each process app. Process apps
that are in development (that is, process apps that have been checked in but
not published) do not appear.
Select an application or orchestration, and then select a logging
level from the
Level drop-down list. You can also select a
logging level, and then click
Apply to all to use the selected logging level
with every application and orchestration.
The following logging levels are available:
- user: Logs user-type messages, regardless of
their technical level. This setting also logs "error" and "fatal" messages,
regardless of whether they are marked as user-type messages.
- trace: Detailed information about the
execution of the program (for example, which function was called).
- debug: Useful information about the
execution of the program (for example, the data contained in the request).
- info: The program reached a certain point in
its execution (for example, the request was received).
- warning: Some unexpected or abnormal
condition occurred that does not affect the logic of the program, but may
indicate a general problem (for example, the request is taking a long time to
- error: Some unexpected or abnormal condition
occurred that affects the logic of the program (for example, an out-of-range
value or an expected resource that was not present). This is the default
- fatal: A serious problem occurred from which
the program may not recover (for example, an out-of-memory condition).
- off: Stops all messages from being logged to
the Common Log.
The technical log entry is an attribute attached to the log message
at its origination. It indicates the purpose of the log message and allows log
messages to be filtered, reducing the volume of log messages that are captured
while still capturing useful information.
The highest volume of messages are logged with the
trace level; the lowest volume of messages are
logged with the
fatal level. If any technical logging level is
selected, the system logs both user-type and technical-type messages to that
level. For example, if you select
warn, then user-type messages containing debug
information will not be logged.
Note: SBM Composer
user level when the Debug Logging feature is
turned on in the Log Viewer. To override this so an
user can see technical-type messages in the Log Viewer, select one of the
technical levels in the dialog box shown above. If the
user turns Debug Logging off, the logging level is set to
error; when the user turns Debug Logging on
again, the logging level is set to
Logging Tips and Best Practices
The following list provides recommendations for using the Common Log.
- It is generally not a good idea to set a technical level higher
warn in a production environment, because
system performance can be adversely affected by a large volume of log messages.
If you need to collect more information, consider the
user setting; this will limit the number of
messages while still tracking the execution of the program. If this is not
sufficient, and you need to set a higher technical level, be sure to restore
the setting to
warn or below after you obtain the information
- If you have multiple environments, each environment must have its
own Common Log database. This ensures that Common Log messages you see are
specific to each environment. See the
SBM Installation and Configuration
for information about configuring databases.
trace level is normally only useful to Support
- Log messages accumulate in the database until they are cleared, so
it is important to keep them at a manageable level, especially if you combine
the logging database with other
databases, such as the
database. It is recommended that you clear the log messages you no longer need
as soon as it is practical. Technical level log messages can accumulate very
quickly if your process apps use orchestration workflows, so they need to be
cleared even more frequently. If you encounter a server time out after applying
a filter to the log, consider clearing unnecessary data from the Common Log
- If necessary, you can use the
-clearCommonLog renew utility commands to purge
the common log and event log in the event they have grown large enough in size
that timeouts occur during the purge operation in
For more information, refer to the renew topics in the
SBM Orchestration Guide.
The host address for the
SBM Orchestration Engine
server that hosts the Common Log is the same as the host address for the BPEL
server. This address is displayed in the
column for the first BPEL server on the
tab for an environment. For more
Setting Up the BPEL Engine
Copyright © 2007–2018 Serena Software, Inc., a Micro Focus company. All rights reserved.