Developer’s guide for EMMA

The generic tool Enhanced Message Management Analysis (EMMA) analyzes any
collection of T100 like messages. A one-stop shop for the analysis of executed business
processes, automatic handling of possible exceptions via built-in case management, and
KPI analyses in BW. The following are the three main features/functionalities:

• Message analysis
Monitor business processes (dialog transactions or background jobs that create
application logs, IDoCs, background job logs, workflow logs, system logs, etc.) at
one central place instead of going to several different transactions. View statistical
information, i.e. number of business objects processed, number of successfully
processed and erroneous objects, and number of messages logged. The messages
are grouped per business object. Directly drill down to the business objects
involved in the messages.

• Case Management
Define exceptions based on combination of messages and the business objects
within to create cases and use role resolution to distribute them. This can be done
just with customizing and no programming is necessary.

EMMA is a generic framework where all the executed business processes (either within a
SAP or non-SAP system) can be monitored and analyzed. The framework is based on the
messages raised or issued by the executed processes and it does not matter where they are
stored originally. In this document we will discuss what needs to be done in order to
analyze a process/job in EMMA.

In order to integrate a process in EMMA the following tasks need to be achieved:

1. Define the Business Process Area (BPA) and Business Process Code (BPC) if
they have not yet been defined in the system. This should be defined by the
Solution Management with the help of the application owner/developer for SAP
delivered processes while customers can define their own processes by using the
SAP standard naming conventions for customers.

2. Do the necessary customizing in IMG to deliver the BPA and BPC.

3. Update the table EMMA_HDR with your executed business processes

information.

4. If the application/process is not writing the logs (application log, workflow log,
IDOC or etc) anywhere in the system, then you have to create one.

5. Create log messages for the start and end of each business object processed.
Let’s look into to the details for each task.

1. Business Process Area (BPA) and Business Process Code (BPC)

Defining the business process is usually the responsibility of the solution
management. For details, please check the section 4.4.1 in the cookbook

2. Customizing in IMG
There are two parts of customizing.
- Codes for business process and area (BPC and BPA) with switch as not active
(customer should decide to activate it or not)
- Class methods to read and analyze the messages for a process. These methods
need to be classified for each delivered business process code (BPC)
For details please check the section 4.4.2 in the cook book.

3. Update table EMMA_HDR

As soon as the business process is executed the application should update the
table EMMA_HDR by providing all the necessary technical information about the
executed process. When updating or inserting the entry the following information
should be provided:
a. RUNID: A unique job number has to be assigned to every executed
business process in the system. The system generated RUNID can be
obtained by calling function module ‘EMMA_NONMASSACT_RUNID’.
For a mass activity/parallel processing framework, specially designed
function module (EMMA_MASS_ACTIVITY_RUNID) has already been
implemented in the frame work and user do not have to do this.
b. BPCODE: This is the main business process code that you have setup
above.
c. EXTRUNID: Assign a preferably unique ID (50 character text to give a
more meaningful text to the executed business process, in order to help the
users to select the job).
d. LOGTCODE: The transaction code via which the business process is
executed.
e. XSIMU: check the flag if the business process is executed in simulation
mode (not every application offers this functionality).
f. XPRUN: define how the business process was executed i.e. either in test
mode = 0 or in production mode = 1.
g. LOGUSER: System user name of person who executed the process
h. LOGDATE: System date of process execution
i. LOGTIME: System time of process execution

You can also use the function module ‘EMMA_NONMASSACT_RUNID’ to update

the EMMA_HDR record.

4. Run time information stored as log

If your business process is not writing any run time information then in order to
utilize EMMA, it should start writing one. The run time information is usually
 stored at different places depending upon the type of application e.g. application
log, IDOC logs, workflow logs etc (for details please see the online
documentation from SAP athttp://help.sap.com).

Every business process that is going to be monitored via EMMA must write
messages in the system i.e. the information about the business object in the
process during its execution. Some applications have their own database to store
these messages for example IDoc, Job logs, System log, Workflow etc, while the
others take the advantage of provided BASIS database tables to store these
messages. These messages raised/issued by the business processes are stored in
application log. We recommend that every application and process should write a
message to identify the processed business object. Remark: twice the some text

5. Message for every processed business object

Every application should write a message to identify the processed business
object. The most recommended way would be to use the message EMMA-011
(for start of processing of business object) and EMMA-012 (for end of processing
of business object). You can also use your own defined message (for this you
have to do the customizing, follow the cook book chapter 4). You can create the
standard messages by using the standard methods ‘CL_EMMA_BPC->START’
and ‘CL_EMMA_BPC->END’ and write these messages into the application log
or any other DB the way you want.

Since ERP 2005 (SP 8) release we have a new class ‘CL_EMMA_BPC’. This
class has several methods. Each method is described in brief with its functionality.
Please use them and replace the old/existing function modules in your application
(highly recommended) with these new methods. These new methods are very
efficiently designed and do not cost high processing time. Below are the new
methods with description and there functionalities.

CALL METHOD ‘CL_EMMA_BPC->START’

EXPORTING
IV_MAIN_BUS_OBJTYPE = Object Type
IV_MAIN_BUS_OBJKEY = Object Key
IV_TCODE = Transaction Code
IV_START_TIME = UTC Time Stamp in Short Form
(YYYYMMDDhhmmss)
IV_NO_TIME_MEAS = ‘ ’ No Time Measurement
(Suppress user time measurement)
IS_BUSOBJECTS = Business Objects in Process
IMPORTING
ES_MSG = Application Log: Message Data
EV_BPGUID_C = GUID of Transaction/Process in
Character Format
EXCEPTION
BPAREA_INACTIVE = Measurement of Processes of this Process
 Area Not Active
MAIN_BUS_OBJTYPE_INCOMPATIBLE = Process code for process
area not found
CALL METHOD ‘CL_EMMA_BPC->END’
EXPORTING
IV_MAIN_BUS_OBJTYPE = Object Type
IV_MAIN_BUS_OBJKEY Object Key
IV_END_TIME = UTC Time Stamp in Short Form
(YYYYMMDDhhmmss)
IMPORTING
ES_MSG = Application Log: Message Data

Note: Above methods do not update the application log but the applications are required
to do it by themselves as we do not offer or support this functionality anymore (mainly
due to performance reasons). Simply said these methods just prepare the EMMA-011/012
messages for your application and return the assembled messages back to it. Then the
application can decide how to store it in the log.

Note: If you are still using the old EMMA function modules and the FI-CA or IS-U
macros to log application log messages, then for technical reasons please make sure that
at least one information message has been logged in the application log before; and if not
then please create a dummy message so that the EMMA message can get logged in the
system. Otherwise the EMMA-011 message might not get logged in the system creating
erroneous results.

Examples
In this section we will take a look at how different applications or components of SAP
and Non-SAP systems are utilizing and working with EMMA.

Examples: Application Log

Let’s take a quick look at three different types’ of application logs getting created by the
different applications.

Example 1: Dialog/on-line transaction (SAP R/3 system)

It has been widely observed that as a best practice (especially when the process is
composed of a single execution of a transaction) a single application log per execution of
the application/business process/transaction has been observed in the system. It is not a
very common practice to have multiple logs per execution of a transaction/process. If the
process/transaction is creating multiple logs per execution in the system then it is not an
easy task to correlate them unless the process/transaction takes the advantage of the field
BALHDR-EXTNUMBER to stamp some kind of a unique identifier by which logs for
that particular process/transaction can be identified.

Example 2: Mass Activities/parallelization frame work

The FI-CA provides the framework (SAP ABA 710) to create a parallelization process
for execution of a process. A large process can be broken down into further smaller
processes to take the advantage of all the available system resources which thus can help
to speed up the processing. Service industry sector is the largest user of this framework.
The framework creates a log per batch job. The framework creates a unique ID to identify
the logs for every batch job which is stored in application log (check field BALHDR-
EXTNUMBER).

Customizing
The correct customizing needs to be maintained and delivered by each application
owner. Please follow the cookbook (chapter 4) with presentation for pictorial
elaboration to maintain the customizing in IMG.

Special conditions
Within a business process there could be one or more collaborations, each
consisting of one or more transaction or events or services. See example below

A business process can be composed of a single transaction or of several

collaborations (see fig 1). Each can have multiple transactions or events. Every
transaction/event is writing the log somewhere in the DB. Now the biggest
challenge is how to analyze the log for these distributed processes. This problem
can be overcome by defining a unique process-ID of each executed business
process. Also you need to make sure that this process-ID is passed to all the
events/transaction/sub-process etc to make sure that they write the log info by
using this unique process-ID. The process should get registered within EMMA
DB at the time of execution.

Business Process
Business ... Business
Process Process Create Long Term Contract

Collaboration
Transaction Forecast Component
Requirements

Transaction
Send Planning Document
...

Supplier
Customer
Collaboration Place Order

Ship Materials

Arrange Payment
Consider the example of the creation of a sales order process. It is usually a pretty
simple process and it can also be a very common process as well. Let’s review the
sales order process for our example (see fig 2).

Fig: 1

In the above example the business process is distributed over different systems
which mean that the information is also distributed over multiple systems as well
(see fig1). So the biggest technical challenge is how to reconcile it in one place
and how to achieve this. The only way to get this run time information is to
capture it via logs. The next big challenge is how to correlate the logs of a process
distributed over different systems. For this a unique GUID needs to be created at
the time of execution of process and when the entry is created in the table
EMMA_HDR. This unique GUID has to be passed to all the steps of the
processes (including the external systems as well). This unique GUID is the only
way to link all the logs of the same process. EMMA keeps that GUID in its job
record.