The API is the interface for data collection and
monitoring. The agent collects information of run-
states, and writes them with additional information
into the database table of active business cases. How
a run-state can be determined will be described in
the next chapter. The monitoring interface is used to
connect third party applications. These applications
can represent the data in form of available business
cases or can monitor the current progress of a
business case.
5 COLLECTING RUN-STATES
Several options are given to collect run-state
information of business processes. The layers of the
application landscape provide different views of
process activities. On the hardware and operating
system layer, information about progress of a
process can typically be found in log files. Usually
applications write processing messages into flat log
files. Messages can reflect the current state or are
usable to determine a run-state. An agent for
example can search for a specific pattern like
start or end in a log files can be mapped to a
corresponding status like active or
terminated. On the operating system level,
applications fork processes which can be monitored
as well. A start or the termination of an operating
system process can point to a run-state. Both options
are quite simple methods usable in any application
landscape environment. The implementation is easy
to realize and comes without the need to adapt
applications. It can be used to get a general overview
of process activities and to collect information about
the progress. The disadvantage is that, no detailed
information about process steps is collectable with
this method. The advantage is that less effort is
required to setup the monitoring. And for smaller
environments those methods are sufficient enough to
monitor process activities.
The next level to collect run-state information is
the application layer. It is much closer to the
business cases as the previous one. Most
applications and databases have their own
monitoring tools to measure and make activities
visible. Monitoring tools are used to check for
intensive data load, monitor processes or to prove
the parallelization of user work and can therefore be
used to collect run-state information. Data produced
by the monitoring tools can often be extracted to
XML or flat files. The extract is useful to identify
runs-states of process activities on process level. Not
each and every detail of process activities can be
collected here but it completes the information
collected on the hardware level and is easy to obtain
as well. Collecting information on this layer can be
done without further financial investments. No
development work is required. Only little work
needs to be done, to evaluate the run-state out of the
extracts.
For sure the best level to determine the run-state
of processes is the business process layer itself.
Whenever a business process starts, stops or waits,
the application should send a message with its state
to RT-BCDB. Due to this detailed information of
process-activities, processes can be made visible. To
insert run-state messages, two options are available.
The best method is to insert RunControl commands
into the application. This requires modification to
the source code.
The run control commands send the business
case ID, run-state and the process step to the agent.
RunControl(process step,run-state)
Another option would be inserting run control
commands, is to start and stop applications out of a
batch processing mechanism or a script file. Within
these scripts run control commands can be set. For
instance the start and the end of an application is
notifyable. But detailed information within the
application run is difficult to derive. The advantage,
no modification to the application is required.
Figure 3: Using RunControl Commands.
As described, several options are available to
collect run-states of process activities. Each source
of process activity must be evaluated first. After that
run-state information and must be sent to the RT-
BCDB.
Therefore agents are an important part of the
concept. They are installed on each system and
belong to the application landscape environment.
The tasks of the agents are dependent on the kind of
source of information. On hardware and software
layer the agents have to evaluate XML, plain log
files or extracts of the application tools. The agent
inspects the sources and tries to identify run-state
using pattern matching. Whenever possible, they
INTRODUCING REAL-TIME BUSINESS CASE DATABASE - An Approach to Improve System Maintenance of
Complex Application Landscapes
205