bpem cookbook screenprints
TRANSCRIPT
1
EMMA/BPEMBusiness Process Exception Management
SAP ERP 2005
What, Why, When & How
THE BEST-RUN BUSINESSES RUN SAP
2
Content1.0 Introduction.........................................................................................................61.1 What Is EMMA/BPEM? ...................................................................................................71.1.1 The Three Main Functions of EMMA/BPEM ..............................................71.2 Why Do You Need EMMA/BPEM?.................................................................................8
2.0 Architecture.......................................................................................................102.1 Business Process and Message Monitoring and Analysis.................................102.2 List of Cases ..........................................................................................................102.2.1 Case Creation .............................................................................................102.2.2 Case Worklist ..............................................................................................112.2.3 Case Processing .........................................................................................112.3 Process Model for Processing Worklist ...............................................................122.4 Automatic Solution Processing.............................................................................132.5 Forwarding Methods..............................................................................................132.6 Case Transactions (EMMAC1, EMMAC2 and EMMAC3) .................................142.7 Class method interfaces and BAPIs ....................................................................14
3.0 User Interface....................................................................................................153.1 Log Analysis and Preparation (Transaction EMMA)...........................................153.2 Case Transactions: EMMAC1 (Create), EMMAC2 (Change) and EMMAC3 (Display)
.................................................................................................................................163.3 Transaction EMMACLGEN ...................................................................................163.4 Case Clarification Worklist (EMMACL) .....................................................................163. 5 Case Worklist with Shortcuts (EMMACLS).................................................................173. 6 Automatic Processes for Cases (EMMACAP)............................................................17
4.0 Customizing ......................................................................................................184.1 Specifications for Logging.....................................................................................194.1.1 Maintain Internal Number Range Intervals for Jobs ................................194.1.2 Activate Business Process Areas for Message Management ................194.1.3 Suppression of Messages for Log Preparation........................................204.2 Specification for Generating Clarification Cases.................................................214.2.1 Maintain Internal Number Range Interval for Clarification Cases ..........214.2.2 Define Clarification Case Types ................................................................224.2.3 Maintain Clarification Case Categories.....................................................22
4.2.3.1 Create Clarification Case Category (or transactionEMMACCAT1).................................................................................................234.2.3.2 Other IMG activities within the node: Maintain Clarification CaseCategories: ......................................................................................................32
4.2.4 Define Method for Forwarding Clarification Cases ..................................324.3 Specifications for Processing Clarification Cases...............................................33
3
4.3.1 Generate Selection Screen for Clarification List ......................................334.3.2 Define Reasons for Forwarding Clarification Cases................................33
4.3.3 Define Reasons for Reversing Clarification Cases ......................344.3.4 Maintain Shortcut Keys for Clarification Processing ....................34
4.4 Specifications for Customer-Defined Business Processes and Messages ......364.4.1 Define Customer Business Process Areas for Message Management.364.4.2 Define Customer Business Processes for Message Management........374.4.3 Define Customer Business Processes for Processes in CIC .................424.4.4 Define Customer Transactions for Message Management ....................424.4.5 Define Business Objects for Customer-Defined Messages....................445.1.1 Selection Screen for EMMA .......................................................................465.1.2 Output (for EMMA) ......................................................................................50
5.1.2.1 Summary of Job/Application ...........................................................505.1.2.2 Buttons on the EMMA Output Screen: the Application Toolbar ..535.1.2.3 Interval Level Information for Each Job .........................................555.1.2.4 Objects and Messages....................................................................56
5.2 Case Transactions: EMMAC1 (Create), EMMAC2 (Change) and EMMAC3 (Display).................................................................................................................................59Case Status .................................................................................................59User Authorization for Changing Case Attributes ....................................60Priority ..........................................................................................................61Due Date......................................................................................................61Processors...................................................................................................61Description...................................................................................................62
In this release, the Description pop up window remains an active window (staysopen) to facilitate better use by the clerk of the instructions for completingor resolving the case...................................................................................62
5.2.1.2 Clarification Case Tabs:............................................................................62Objects ....................................................................................................62Processes .............................................................................................64
Notes .....................................................................................................65
Messages .............................................................................................65Additional Data .....................................................................................66
5.2.1.3 Clarification Case Application Toolbar: .....................................................67
o Log .................................................................................................675.2.2 Creating a Manual Case (Transaction Code: EMMAC1) ...................................685.3 EMMA/BPEM Clarification Case List (Transaction EMMACL) ..........................695.3.1 Execute EMMACL.......................................................................................695.3.2 Selection Screen...........................................................................................69
4
5.3.3 Output .............................................................................................................725.4 Clarification List: (Transaction EMMACLS: Case Worklist with Shortcuts) ......76
6.0 Case Generation Process.............................................................................816.1 Manual Cases (Non- Application Log based case)..................................................816.2 Application Log-Based Cases.....................................................................................81
7.0 Interfaces ...........................................................................................................837.1 IF_EMMA_LOGNUMBER_GET...........................................................................837.2 IF_EMMA_INTINFO_GET ....................................................................................847.2.1 GET_MASSACT_INTERVAL ....................................................................847.2.2 MASSACT_INTV_INFO .............................................................................847.2.3 GET_MARUN_STATUS.............................................................................847.2.4 GET_INTERVAL_OBJECT ........................................................................847.3 IF_EMMA_LOGMSG_PROCESS ........................................................................857.3.1 ANALYZE_MSGS .......................................................................................857.3.2 VALIDATE_MSG.........................................................................................857.3.3 ANALYZE_BUSOBJ ...................................................................................857.4 IF_EMMA_CASE_FORWARD .............................................................................857.5 IF_EMMA_CWL_LAYOUT....................................................................................867.5.1 DETERMINE_SELCRITERIA ....................................................................867.5.2 SELECT_CASES_FROM_DB ...................................................................867.6 IF_EMMA_IND_SUBSCREEN_PROCESS ........................................................867.7 IF_EX_EMMA_CASE............................................................................................867.7.1 TRANSFER_DATA_TO_CUSTSUB .........................................................867.7.2 COMPLETE_CASE ....................................................................................877.7.3 DETERMINE_CASE ...................................................................................877.7.4 UPDATE_CASE_ACTION_LOG ...............................................................877.7.5 DETERMINE_CUSTOMER_SUBSCREEN .............................................887.7.6 TRANSFER_DATA_FROM_CUSTSUB ...................................................887.7.7 PROCESS_CUSTSUB_OKCODE ............................................................897.7.8 CHECK_BEFORE_CHANGE ....................................................................897.7.9 CHECK_BEFORE_DISPLAY ....................................................................897.7.10 CHECK_BEFORE_SAVE ..........................................................................898.0 BAPIs for EMMA/BPEM.................................................................................908. 1 BAPI_EMMA_CASE_CREATE ...................................................................................908.2 BAPI_EMMA_CASE_CHANGE ...........................................................................908.3 BAPI_EMMA_CASE_GET_DETAIL ....................................................................908.4 BAPI_EMMA_CASE_ACCEPT ............................................................................908.5 BAPI_EMMA_CASE_BACK_TO_QUEUE ..........................................................908.6 BAPI_EMMA_CASE_CANCEL ............................................................................91
5
8.7 BAPI_EMMA_CASE_CHANGE ...........................................................................918.8 BAPI_EMMA_CASE_CONFIRM..........................................................................918.9 BAPI_EMMA_CASE_FORWARD........................................................................918.10 BAPI_BPEM_CASE_REOPEN ............................................................................918.11 EMMA_BAPIRETURN_GET2 ..............................................................................91
9.0 Appendix............................................................................................................929.1 Authorizations ........................................................................................................929.2 Configuring the CIC for Manual Cases ................................................................929.3 Agent Determination (The Processor Rule) ........................................................949.3.1 Introduction to Agent Determination ..........................................................959.4 BAPI (Business Application Programming Interfaces) .....................................102
6
1.0 IntroductionCustomers need to monitor and manage their complex business processes by analyzingboth successfully completed and failed jobs as well as other transactions in the system.This can be managed via the tool Business Process Exception Management (BPEM).Primarily by analyzing messages, EMMA/BPEM provides you with an overview ofselected business processes or jobs in the SAP or non-SAP system.
The main purpose of this tool is to provide an overview of the system activities in asummarized form and to manage exceptions in an appropriate manner. Currently there isno other tool available in the system that provides this functionality. EMMA/BPEMenables you to view all the activities by analyzing messages issued during the processingof the jobs. EMMA/BPEM saves clerk processing time and increases efficiency inprocessing the error logs by eliminating the need to retrieve the information from thesystem manually. Not only that, but clarification cases can be created for theseapplications to identify and distribute the exceptions that were encountered by thebusiness processes. The clerks then process the exceptions reported in the cases andsubsequently improve the business process quality and performance over the time. Theresults of the EMMA/BPEM exception management are extracted to the SAP BW andcan be analyzed there on a more aggregated level.
Prior to EMMA/BPEM, if an error was logged by a business process, it was not easy totrack the information due to the poor quality and technical nature of the message (forexample, because of missing business object information such as business partner orcontract account). Consider an example from the IS-U (Utilities) solution: 10,000installations are entered in the selection criteria for a mass billing run (via transactionEAMABI). If an error occurs in any of these 10,000 installations the system records theerror but the logs cannot be read easily and are not user-friendly, making it difficult toidentify the specific installation for which the message was issued, no matter what tool isused, e.g. Solution manager, XI, SLG1, BPM, etc. as they provide insufficientinformation. EMMA/BPEM provides a higher level of detail which includes theinformation for the processed object for which the message was raise/issued.
EMMA/BPEM provides a major advantage by reducing the amount of time needed toanalyze these logs. It is a centralized access point for logs, jobs and other messages.Information is readily available for all aspects of the messages.
7
1.1 What Is EMMA/BPEM?BPEM stands for:
B = BusinessP = ProcessE = ExceptionM = Management
Business Process Exception Management is based on the previously released productEnhanced Message Management Analysis (EMMA). Additional enhancements inrecent releases of SAP made it necessary to use a more comprehensive name for the moregeneric and powerful tool. In the current SAP R/3 release you will still find manyreferences to EMMA. EMMA refers to the generic framework of the message monitoringand the case management. BPEM is specifically the ISU specific BI analysis for KPIs.
Currently the enhanced and redesigned EMMA/BPEM is delivered within FI-CA and canbe used by any industry solution based on FI-CA. But EMMA/BPEM is not industry-specific and can therefore be customized to be used for any standard SAP application thatcreates logs.
EMMA/BPEM will be integrated into the NetWeaver platform in coming releasesmaking it available without dependence on FI-CA as noted.
1.1.1 The Three Main Functions of EMMA/BPEM
1.1.1.1 EMMA: A Monitoring Tool
The primary function of EMMA/BPEM is the analysis of logged messages for thebusiness’s executed processes. All messages for the processed objects are groupedtogether making the log analysis more readable than ever before.
EMMA/BPEM displays the total number of business objects involved in the businessprocess broken down by the number of business objects processed successfully, witherrors, or warnings. From here you can drill down to the individual messages issued perbusiness object. In addition you can also analyze the messages for general problems notassigned to any business object.
1.1.1.2 EMMA: A Management Tool
EMMA/BPEM provides the business with the ability to distribute problems or exceptionsto a group of users or an individual by creating clarification cases.
8
Case generation within EMMA/BPEM produces a work list of cases based oncustomizing within the IMG. There are two main steps in the EMMA/BPEM tool todefine and dispatch cases.
First, a process called case determination uses the case category definitions to determinewhich combination of messages should result in the creation of a case.
Second, a process called rule determination finds the users that are responsible to workon the case. The case is forwarded to the persons responsible either by means of a casework list or workflow or any customer defined method. Each case has a processing statusthat enables a supervisor to keep track of all the cases using a reporting tool.
1.1.1.3 BPEM: A Business Process Analysis Tool
Business Process Analysis (BPA) is now available as part of BPEM to measure theperformance and quality of the business processes. It provides the necessary keyperformance indicators to visualize how your business processes improve after theintroduction of BPEM. The reporting will be performed within BI, this new feature iscurrently only implemented in the industry solution for utilities (IS-U/CCS).
The business processes in the system are grouped by Business Process Area and BusinessProcess Code. This allows the monitoring of single business processes as well asprocesses of a specific area for example IS-U Billing or IS-U Customer Service. Themonitored business processes also include processes executed via the CustomerInteraction Center (CIC0).
You can not only monitor business processes but also the performance of user groups orindividual users by activating BPA for selected Business Process Areas. This way thebusiness processes are measured and data can be analyzed within BW. Not only thenumber of processes executed in the system but also the time spent to complete them ismeasured allowing to calculate the total cost of a process, e.g. cost = number x durationx price/unit. The history of a business object can also monitored for all businessprocesses that are activated. Please check out the document ‘BPEM for Utilities’ fordetails.
1.2 Why Do You Need EMMA/BPEM?Every day customers have to evaluate the application logs of the executed processes inthe system especially to check for errors. These errors could be caused by:
Missing CustomizingMissing or incorrect data in master data objectsInformation about exceptionsProgram errors
9
EMMA/BPEM analyzes all the business processes (including batch jobs, system jobs,Workflow, IDE/IDOC processes, etc.) that write messages in the system. Cases can beallocated to individual objects, thus creating a case per business object and relatedmessage. Another option is to create one case for all occurrences of the message in thelog if the correction to resolve the error is missing configuration for example.
To create a case, you have to answer the following questions:What is the problem?How is the problem identified?What steps are required to resolve the case?Who should work on this problem?How important is this case?How fast does it need to be resolved?What further actions are necessary?Who will monitor this case?
EMMA/BPEM can help you to answer all of these questions and therefore enable you toresolve the problem more appropriately and efficiently. It also helps to track the problemstatus in the system.
In addition to errors reported in the system via the messages, errors can also be reportedfrom other sources where there is no message recorded in the system. In these situations,cases can be created manually with a provided transaction or via the provided BAPIs.
10
2.0 ArchitectureThis chapter briefly discusses the technical details of EMMA/BPEM. Each component isdescribed separately.
2.1 Business Process and Message Monitoring and AnalysisYou can analyze and monitor your executed business processes via EMMA/BPEM. Thetool has been designed to analyze messages created by any business process/transactionin the system. It starts with a process overview and the process statistics. (How manybusiness objects were processed successfully, with errors, or warnings and other jobattributes).Any process that is executed within SAP or a non-SAP system can be analyzed andmonitored in the same way by using the provided standard framework and interfaces.These processes include batch jobs, job logs, system logs, IDE processes, IDOC,Workflow, etc.
There are two steps to process the application log of a job:
In the first step, EMMA/BPEM uses the interface methodIF_EMMA_LOGNUMBER_GET~ GET_LOGNUMBER to identify all the applicationlogs of the executed process.
In the second step these application logs are read by the EMMA/BPEM tool and thenpassed to another interface method IF_EMMA_LOGMSG_PROCESS~ANALYZE_MSGS where the messages are analyzed and grouped by business objects.As a result the analyses are presented as output by using the standard ALV functionality.The interfaces are discussed in detail in section 7.
EMMA/BPEM job preparation uses the transaction EMMA to prepare the jobs and tocreate the clarification cases. The transaction EMMA is documented fully in section 3.
2.2 List of CasesAfter the job preparation step, the system generates a worklist of cases. This worklistcontains cases of different categories as defined in customizing. These cases aredistributed among the users using the company’s selected procedure for handling thecases (role resolution, workflow, etc.). Once a clerk starts to process a case, the update ofthe status triggers the removal of the case from the other possible users’ inboxes. Thestatus is primarily used to monitor the case and it is important for reporting purposes.
2.2.1 Case Creation
11
The case creation process has several sub processes:
1. Case DeterminationThis process reads the application log messages and checks for combinations ofmessages that constitute a case of a certain case category.
2. Priority DeterminationOnce a case has been identified, this process assigns a priority.
3. Object DeterminationThis process determines the business objects that are relevant for processing andsolving the problem and attaches them to the case.
Note: This process describes case creation based on application log messages. Manuallycreated cases are not created by this process. The case creation process is described morefully in sections 3 and 5 and the customizing for clarification case categories is describedin section 4.
2.2.2 Case WorklistThe result of the case creation process is a list of cases where each case can be assignedto one or more users. The cases are then forwarded to the users using the company’spreferred method. These forwarding methods may be:
Case worklist (Pull) (transactions EMMACL and EMMACLS)Provides an EMMA/BPEM-specific inbox function by enabling users to selectcases based on various selection criteria such as status, due date, user, andorganizational unit. The worklists are reviewed in more detail in section 3(functionality) and section 5 (customizing).
Customer Specific (Push)Customer can implement the delivered class method interfaceIF_EMMA_CASE_FORWARD~FORWARD to define their own method todeliver the case to the end user. For example, the customer can define the methodby using the defined interface to either forward the case (e.g. workflow, servicenotification, etc) or forward the information about the case to the end user (e.g. anautomatic email, system message, etc).
2.2.3 Case ProcessingThe clerks work on the cases assigned to them. Depending on the users’ authorization,they are allowed to revoke the case assignment and return the case to the case worklist. Inmost cases, only a supervisor has the authorization to revoke a case assignment or assignthe case to another user. Authorization objects for EMMA/BPEM are presented in theappendix. This functionality is similar to the workflow inbox functionality. When a userrevokes the assignment or assigns the case to a different user, he or she will have tospecify a forwarding code (customizing in the IMG).
12
Display
Manual Operation
Pre-defined Process
Preparation
Process
Store data
Store to Disk
Each case has a central status. This way, the supervisor can monitor the status of cases.The status of the case is maintained in a table and is updated based on actions of the userson the case. You can use this table to create a status report for monitoring purposes.
2.3 Process Model for Processing Worklist
Key
Application log
Rule Assignment
Case Type &Category
Determine thecaseforwardingmethod
Manual case
Case
Workflow Custom
BPEMPreparation
Extract to DB
Analyze prepared dataOutput Report
Case Generation
CaseWorklist
Business Objects
Priority
Rule Resolution
Other logs
Messages
13
2.4 Automatic Solution ProcessingSolutions are business processes that help the user to resolve the problem described bythe case. For each type of problem, you can configure a set of business processes. Theuser then executes these business processes manually or they are executed automaticallyby a program. All solutions, whether manual or automatic, are accessible on the tabProcesses in the case maintenance transaction EMMAC2 or EMMAC3 that allow you tochange or display a case (usually accessed by users from the worklist view: EMMACLS).
There are two types of solutions:
Manual: Manual solutions can only be executed manually in dialog by a user.The clerk can execute each process by clicking on the pushbutton showing theprocess icon. Once the process has been executed, the time, date, and user arenoted next to the process.
Automatic: Most automatic solutions can be executed in dialog like themanual solutions. However, they can also be executed automatically viatransaction EMMACAP (program REMMA_CLIST_AUTPROC_EXEC). Abatch job is scheduled for this program that runs immediately after the jobcreating the cases has finished. This job then executes all automatic solutionsfor the cases. The goal of the automatic solutions is to resolve the caseswithout a clerk having to work on the case at all. You mark solutions as‘automatic’ in the configuration of the solution path.
For a more detailed description of the automatic solutions, see thedocumentation for program REMMA_CLIST_AUTPROC_EXEC.
Please note that automatic solutions must not contain any dialog stepsotherwise the batch job executing programREMMA_CLIST_AUTPROC_EXEC will terminate.
2.5 Forwarding MethodsThe forwarding method describes how cases are forwarded to the users that work on thecase. The standard EMMA/BPEM forwarding methods are ‘Case Worklist’ and‘Workflow’. You can also define your own forwarding methods. The case forwardingmethod is evaluated once a case has been created. For example, if the forwarding methodis workflow, then a predefined workflow task is started to put the case in the inboxes ofthe users that are supposed to work on the case. The case forwarding method depends onthe case category and the priority of the case. You can also specify default forwardingmethods if a specific forwarding method is not customized in the IMG for a case basedon its type and priority. The forwarding methods available are customized in tableEMMA_FWM and are then used in EMMA_CCAT_FWM.
14
2.6 Case Transactions (EMMAC1, EMMAC2 and EMMAC3)The case transaction provides the functions for displaying, changing, or creating a manualcase. The case is displayed with its important attributes such as status, priority, currentprocessor, due date, and so on. Furthermore, the case transaction enables you to enternotes to describe the work you have done, make notes for follow-up work, and so on.You can verify what messages led to the case’s creation and what business objects orfield values are important. Then, the case transaction lists the business processes that arerelevant to the solution of the problem the case describes. You can execute the businessprocesses from the case transaction screen. You can also enhance the case transaction byadding customer-specific case attributes and by integrating custom functions.
Essentially, most users will access the individual cases from the EMMA/BPEM Worklist:EMMACLS; these transaction codes will not be used explicitly by users for routine work.All functions described here can be processed when the case is accessed from theworklist.
Use of the Case Transactions is covered in sections 3 and 5.
2.7 Class method interfaces and BAPIsSeveral class method interfaces, BAdIs and BAPIs have been created to enable customersto analyze and process the application log and to create, change, and select the cases, andto perform other functions on the on the case manually. They are discussed in more detailin sections 7 and 8.
15
3.0 User InterfaceBefore we describe the customizing activities for EMMA/BPEM, let’s familiarizeourselves with the user interfaces.
A number of the screens introduced in this section cannot be viewed until there has beenat least minimal configuration in the system. Thus, the transactions are described brieflyin this section and the details are provided in Section 5 after the customizing unit.
3.1 Log Analysis and Preparation (Transaction EMMA)EMMA, the primary tool for the job preparation and case generation has beensupplemented by three parallel processing transactions:
FPEMMA: Similar to EMMA but with fields related to mass job identificationFPEMMAPREP: Parallel processing for job preparationFPEMMACGEN: Parallel processing for case generation
This document reviews EMMA in detail; the other transactions are similar and can beunderstood from this review.EMMA results in the output of the evaluated messages and objects in the form of aninteractive ALV list.Transaction EMMA saves all jobs and batch jobs and assigns a unique run ID to them.For dialog transactions that output application logs, EMMA only determines theinformation required from the database on demand.
The transaction EMMA shows the total number of objects processed for bothsuccessfully processed and terminated jobs, and proportionately thereof, the number ofsuccessfully processed objects, the objects with errors, and the number of objects forwhich the system has issued warnings. This makes it easier for you to determine thecause of errors, such as missing Customizing, missing details in the master data, locks,exceptions, or program errors. The transaction EMMA also provides you with directaccess to the messages output as a result of errors in the programs or during processing.
With EMMA/BPEM, you can automatically convert the error messages output in theapplication logs into clarification cases. The system categorizes the error messages,groups them by business object (for example, contract account) if necessary, and placesthem in the clarification worklist. If the same error occurs in different business objects(for example, Missing Customizing), and this error can be rectified centrally, in thecorresponding clarification case category, the system only creates one clarification casefor all business objects concerned.
16
3.2 Case Transactions: EMMAC1 (Create), EMMAC2 (Change) andEMMAC3 (Display)
The case transactions provide the functions for displaying, changing, or creating a case.The case is displayed with its important attributes such as status, priority, currentprocessor, due date, and so on. Furthermore, the case transactions enable you to maintainnotes to describe the work you have done, make notes for follow-up work, etc. You canverify the messages which led to the case’s creation, and which business objects or fieldvalues are important. Then, the case transactions list the business processes that arerelevant to the solution of the problem the case describes. You can execute the businessprocesses from the case transaction screen when you are in Change mode. You can alsoenhance the case transaction by adding customer-specific case attributes and integratingcustom functions.Using the case transactions (EMMAC1, EMMAC2, and EMMAC3) is discussed in detailin section 5.The Case Transaction screen is divided into three main sections: the header, a set of tabscontaining data and processes and the application toolbar.
3.3 Transaction EMMACLGENBefore you view the generated cases via transaction EMMACL, you have to call uptransaction EMMACLGEN once in the system. This transaction generates the selectionscreen for EMMACL. You can add your own fields to EMMACL; each time fields areadded for EMMACL, this transaction code must be executed again to refresh theEMMACL display.
Even if you have not defined your own fields, you have to generate the selection screenfor EMMACL the first time you use it. When you add a customer-defined field tostructure CI_EMMA_CASE, transaction EMMCLGEN has to be called every time toregenerate the selection screen and to adjust the database selection for EMMACL.
3.4 Case Clarification Worklist (EMMACL)You can view cases created in the system via the case worklist in transaction EMMACL.This case worklist displays the list of cases with the header information, for example,case origination date, priority, status, current processor, case category, and the mainobject type involved in the case together with its value. You can define the selectioncriteria for cases to be viewed.
17
You can accept a case, forward it to another user, or change any attributes of the case(that are allowed), return the case to the list after accepting it, confirm the case anddisplay the details of case.In addition to the technical fields and customer-defined fields, you can also select casesbased on the organizational data, that is, plan version, object types, evaluation path (anevaluation path allows you to focus inquiries/reports on objects that are affected bycertain relationships). The organizational data is set up based on the HR data organizationfor the workflow. For details, check transaction PPOME (Organizational Managementand Workflow) in the R/3 System. EMMACL is probably used primarily as amanagement tool: it is not intended to serve as the primary access point for users toprocess EMMA/BPEM cases.
3. 5 Case Worklist with Shortcuts (EMMACLS)This transaction is another way to view cases. You can define your own layout and theshortcut buttons to appear on screen. This transaction is mainly designed for the clericalstaff who are primarily interested in the cases that are assigned to them or to thedepartment to which they belong. You can create own selection criteria for the databaseselection or use SAP standard criteria in transaction EMMACL by saving it as a variant(for details see section 5)
3. 6 Automatic Processes for Cases (EMMACAP)Clarification Cases can be resolved automatically where the solution is easily andpredictably determined. In that scenario, you use transaction EMMACAP to execute theautomatic solutions without having to use EMMAC2 and execute the solutions manuallycase by case and process by process. This transaction provides a selection screen similarto the case worklist (Transaction EMMACL).
First, you would specify the selection criteria for the cases for which you would like toexecute the automatic solutions. When you run the program, it selects the cases based onthe selection criteria. It selects only those cases that have the status ‘New’ or ‘In Process’and that have a clarification case category where the flag Execute Automatic Solutions ischecked.Second, once you have selected the cases, the program executes each automatic solutionon the selected cases. If you would like to see a list of cases that were selected forautomatic solution execution, check the flag Manual Selection. You can then select thecases for the automated solution execution manually.
The execution of the automatic processes is logged in each case. The log is also displayedafter all cases have been processed.To execute EMMACAP in batch, create a job using programREMMA_CLIST_AUTPROC_EXEC.
18
4.0 Customizing
IMG path:
Financial Accounting Contract Accounts Receivable and Payable BasicFunctions Enhanced Message Management
The customizing of EMMA/BPEM is divided into 4 parts, each corresponding to one ofthe IMG nodes:
1. Specification for Logging: Define and activate the business process areaswhich need to be monitored by Enhanced Message Management and BW ProcessManagement. In earlier releases, EMMA was based upon transaction codes. Theconcepts of Business Process Areas and Business Process Codes were introducedin release 4.72 allowing a greater flexibility of the functionality within the R/3environment.
2. Specification for Generating Clarification Cases: Define the configurationfor creating case types, clarification case categories and for forwarding cases.
3. Specification for Processing Clarification Cases: Define the basics forprocessing a case which include: the forwarding reason, the reversal reasonand the short cut keys for the case worklist.
4. Specification for Customer-Defined Processes and Messages: Activate theEMMA log application functionality for customer processes (dialogtransaction or mass activity, BPA project).
The two following steps are required for activating EMMA using the IMG nodes:a. Define Customer Business Process Areas for Message Managementb. Define Customer Business Processes for Message Management
Other options and settings are available:c. Define Customer Business Processes for Processes in CICd. Define Customer Transactions for Message Managemente. Define Business Objects for Customer-Defined Messages
For additional information, please refer to the documentation assigned to each IMG nodeor the OSS note 728581 ‘FAQ for EMMA’. For developers or customers who arecreating their own mass activity, please refer to OSS note 144461.
19
4.1 Specifications for Logging
IMG path:Financial Accounting Contract Accounts Receivable and Payable BasicFunctions Enhanced Message Management Specifications for Logging < entryfrom below>
4.1.1 Maintain Internal Number Range Intervals for Jobs
The system uses internally assigned unique job numbers. In this activity you define thenumber range intervals that the system accesses when creating new jobs.
Create at least one internal number range interval. If you create parallel jobs in EnhancedMessage Management, you need several internal number range intervals.
External number assignment is not supported.
4.1.2 Activate Business Process Areas for Message Management
In this activity, you define which business process areas are to be monitored by EnhancedMessage Management and BW Process Management.
You can select the business process areas that SAP provides monitoring for via thepossible entries. By setting the indicator Activate, you can exclude individual businessprocess areas from the evaluation.
You enter customer business process areas that you want to monitor in the activity DefineCustomer Business Process Areas for Message Management in the section Specificationsfor Customer-Defined Business Processes and Messages.
Data maintained: (columns from left to right)
20
Business Process Area: Predefined configurations are delivered for ISU. Select aBusiness Process AreaBW relevant: flag for the activation of BPA projects (Business Process Analysis).The BPA activation is only available for IS-U functionalities at this time.Record Process: with the following values:
- ‘Message Management Activated’: Activate EMMA/BPEM for theBusiness Process Area- ‘Deactivated’: Deactivate the business process area (an option todeletion of the Business Process Area)- ‘Message and BW Process Management activated’: ActivateEMMA/BPEM for BW (only valid for IS-U functionalities)
Extract triggering flag for clarification cases: This field should only be filled if theproject was previously flagged as BW relevant with an extract class. Classes aredelivered by SAP for ISU only at this time.
Example from ISU: Activate Business Process Area:Business Process Area: ‘EBI’BW: ‘X’Record Process: ‘Message and BW Process Management
activated’Extract triggering flag for clarificationcases:
‘X’
(Text) ‘IS-U Billing’
4.1.3 Suppression of Messages for Log PreparationWhen the application log is being processed, the messages entered in this list will notappear in the EMMA application log analysis.
This process is reversible: after deleting the messages from this list, simply ‘Prepare’ theexecuted business process again in order to include the messages which were previouslysuppressed.
Data Maintained: (columns from left to right)MessageID: Message classMessage number: Message number that should not appear in the log
21
Business Process Area: F4 help for a drop down list of the available business processareas. If this field is left blank, messages will be suppressed for all business processareas.(Message Text)
Example from ISU: Suppression of Messages during PreparationMessage ID: ‘EB’Message number: ‘7’Business Process Area: ‘IS-U Billing’(Message Text) ‘Invoicing of invoicing unit (account &1)
terminated’
4.2 Specification for Generating Clarification CasesIMG path:Financial Accounting Contract Accounts Receivable and Payable BasicFunctions Enhanced Message Management Specifications for GeneratingClarification Cases < entry from below>
This section describes the steps for generating clarification cases that will appear inEMMA. From a set of predefined rules (customized in a clarification case category), acase can be created, assigned to the responsible processor according to SAP roles and setfor a certain due date and priority.
Requirement: EMMA should be activated.
4.2.1 Maintain Internal Number Range Interval for Clarification Cases
The system uses internally assigned unique clarification case numbers. In this activityyou define the number range intervals that the system accesses when generatingclarification cases. Create the equivalent number of internal number range intervals as
22
you create clarification cases in parallel. If parallel processing is not being used, a singlenumber range will be sufficient.
4.2.2 Define Clarification Case TypesDefine a clarification case type to categorize the clarification cases created by EMMA. Acase type does not have any functionality; it is for information purposes only. In earlierreleases, the Case Type was similar in function to the Business Process Area. This fieldcan now be used as the project requires: possibly as an additional status flag or to groupcase categories logically. For example, all manual cases created from the InteractionCenter could share a common case type for quick identification.
Data Maintained: (columns from left to right):Case Type: Define a case type (4 characters long). The case category should start with
‘E’ for ISU‘V’ for Insurance‘F’ for FI-CA‘Z’ for any customer case type
Case Type Text: Enter a short description for the case type
Example from ISU: Case TypeCase Type: ‘BILL’Case Type Text: ‘Test case for IS-U Billing’
4.2.3 Maintain Clarification Case Categories
This section allows the maintenance of the different settings for processing clarificationcases in EMMA (create, change, display, and delete). For each clarification casecategory, you define the conditions for creating clarification cases, which business
23
objects and solution processes are to be assigned to these clarification cases, and who willbe assigned as the responsible clerk.
Different programs that issue the same error messages, such as a dialog transaction andmass activity for the same business process, are assigned to the same business processcode. This means that you can assign these programs to the same case category andtherefore treat them the same.
You can define clarification case categories dependent on a business object; however,they can also be independent of business objects. If the same error message is to beoutput for different business objects, (for example, "Customizing missing"), only oneclarification case is opened for all messages concerned. An example from ISU is themessage: ‘There is no schedule record for portion &1 after &2’. All affected accounts wouldhave a separate case created if the message is flagged as object specific. This could resultin many cases that will all be resolved when the schedule records are created. Completingthe cases would be time-consuming or require a programmatic solution.
4.2.3.1 Create Clarification Case Category (or transaction EMMACCAT1)
Initial Screen:
Case category templates can be reused for creating new case categories. This is especiallyhelpful to copy the processes entered and the other values common to the new casecategory.
Clarification Case Category: Define a case category with the following namingconvention (4 characters long). The case category should start with:
‘E’ for ISU‘V’ for Insurance‘F’ for FI-CA‘Z’ for any customer business process area
Main Screen:
24
Case Category: Description: Enter text to describe the case category.Deactivated checkbox: after a case category has been created, it can be deactivated at anytime, preventing any cases from being created during the preparation of the EMMA log.This flag can also be used to save a case category before the configuration is complete. Itis always possible to save without performing a check on the case category. A casecategory CANNOT be saved if there are errors present UNLESS the deactivated flag isset.
The Case Category customizing requires the entry of data on a number of tabs as seen onthe main screen. Each tab is described in detail below with the fields listed in order ofdisplay from top to bottom in most cases.
TAB: Basic Data
Category Business Object-Specific: By checking the field, all the messages relevant to aspecific business object will be grouped together. In addition, a case will be created foreach object for which the message is present. If this box is not checked, then a single caseis created for all instances of the exception.
Business Process: F4 help provides the list of the business processes: only ISU businessprocess codes are currently provided by SAP. Select one from the list: usually it isapparent from the functional area for which the exception is raised (For example,automatic billing in ISU is EBI00001.
(Business Process Area): Automatically gets populated, based on the selected businessprocess code
25
(Primary Object Type): Automatically gets populated, based on the selected businessprocess code
Case Type: It is not necessary to define a case type, but always good to have it so thatcases can be organized and managed properly: a mechanism for sorting cases/casecategories.
Case Creation Type: Case types can either be created:Manually: not resulting from application log messagesAutomatically: resulting from application log messages primarily
When case are selected to be created automatically, three options are available todefine/configure them:
Based on a simple rule: the default setting: nothing needs to be doneAccording to complex conditionsVia a Business Add-In
Simple Rule: The basic, simplest way to define/identify acase/alert/problem/exception. Simply configure the messages in messages tab(details later)
Complex Condition: Complex conditions can be formulated and are based on allattributes of the business objects or field values that are issued in the messages ofthe message pool. To define a complex condition: (after remaining required fieldson the Basic Data tab have been completed, but documented here for continuity)
Check the box ‘Complex Condition’Press Enter/Return button on the key boardA dialog box will appear at the bottom of the screen with title ‘Condition’.Click in the box with the message displayed: ‘Click here to create a newcondition’. A pop-up editor (the same as the standard workflow editor)will appear. Maintain the condition here. The object container for theselected primary object (for the case category) will appear. Select theattributes for the object to define the expression/condition.Note: The use of complex conditions can result in system performanceissues. This should be evaluated before complex conditions areimplemented.
Business Add-In. If the complex condition is not sufficient for the evaluations yourequire, you can use the Business Add-In (EMMA_CASE) methodDETERMINE_CASE to implement an installation-specific check routine.
Case Priority: Denotes the priority of the case type: Very High, High, Average, Low, andVery Low. These values are not configurable.
26
Processor Rule: Use the ‘Display Standard Rule’ icon to navigate to the ‘Rule Display’screen for choosing a processor (Standard SAP rule – transaction PFAC_STR) andchoose the Binding Case Container. The appendix includes a brief review of basic agentdetermination.
Forwarding rule: Define the methods for forwarding clarification cases. Nothing is to beentered here if the EMMA/BPEM worklist is being used.
Authorization Group: Helps determining if a user is allowed to perform certain activitiesor has the authorization to change certain fields in the objects.
Due Date:
Period: Enter the time allocated for processing the clarification case (‘0000’ to ‘9999’)and the time unit (minutes, hours, days, months, years)
Time Calculation Basis: Starting date for processing each case:‘Case creation in system’: from the date when the case was generated‘Appearance of case’: from the date when the error first appeared in the systembut was not identified as a caseAn example of the difference: billing is processed at 18:32:56 and an error isidentified at that time. If ‘appearance of case’ is used, this time stamp will be usedto determine the due date for the case. But if the other option is selected, ‘CaseCreation in system’, the due date will use the time stamp from the job processedfor the case generation which would be after the other batch jobs for that day.
TAB: Messages
Store Triggering Messages for Clarification Cases: this check will store all the messageswith the case that you used to trigger the case.
Check for Existence of Identical Cases: This check will prevent the creation of duplicatecases. This check will review the values of the application log message with the existing
27
cases and avoid the creation of duplicate case/s for the same object for the sameexception. For example, in ISU billing, an installation included in a case for a specificbilling error will be processed in the subsequent billing runs until the error is resolved.There is no need to create additional cases for that installation for the same billing period.To define a message for a case category press the button ICON_INSERT_ROWMessage:
Example from ISU: MessagesCheck: Check appearance of messageMessage Class: ‘AJ’Message Number ‘027’(message text) No billing orders exist for installation &1
Repeat for all messages to be entered for the case category.
NOTE: EMMA/BPEM provides a transaction: EMMALOG to compare the messagesfound in the application log to the messages contained in clarification case categories.Use of this transaction ensures that the business has captured the relevant messages intoclarification case categories as needed for effective exception management. Thistransaction is reviewed more fully in section 5.
TAB: Objects
The relevant business objects can be determined from the message variable(s) defined onthe message tab.
This functionality only works when the field ‘Category Business Object-Specific ismarked on the ‘Basic Data’ tab. It will automatically pick up under the ‘Object ’ tab thecorresponding EMMA case object. Choose the icon ‘Create’ to create a new bindingelement to the primary object type of the case category.
Create a Object Container:‘Generate from Message pool’ :
28
Create a new container element which will be linked to the main Business Object. Pressthe icon shown and it will bring all the BOR objects that are contained in the messagesdefined on the message tab.
‘Create from message’: This icon will bring the pop-up modal dialog screen withtitle ‘Message Reference to Business Objects or Table Fields’. Select the desired/requiredcontainer element and it will bring it in the object container.
If you need to get some particular data value then press the button. This will bring a pop-up modal dialog screen where you can change/edit/create the binding rule for the caseobject container
‘Create’ : A modal dialog window will pop-up, enter the name of the new element. Inthe subscreen ‘Data Type’ enter the name of the BOR object or the ABAP dictionaryreference.A new node will be inserted into the list.
To bind the newly created element with the main business object, click on: ‘Data Flow
from Message Pool’ .
This brings up a Binding screen which is divided into 3 parts:The top right part: ‘Case Container’ lists all the business objects that should bebound. Choose the newly created element from the objects to be bound with theexisting elements.
(Use the drag and drop feature to insert a new element in the list at the lower righthand side of the screen). The check functionality is available to check if all theelements can be bound together. The bottom of the screen is where the binding isdefined: ‘Data Flow Message Pool Case Container’ (the screen’s third part)The top left part: ‘Message Pool’ contains the objects defined in the message(s)as variables: Expand the message objects to find the relevant added object for thenew element. In other words, the newly added object must be bound to either theprimary EMMA case object or another object from the message pool.Use drag and drop feature to insert the reference on the lower left side of thescreen: ‘Data Flow Message Pool Case Container’ (the screen’s third part)
Where-Used Button : This button will allow you to check whether the case object isused in: solution processes, roles for case distribution to agents, complex or priorityconditions or in the sort/long texts.
TAB: Description
29
Enter a brief description of the clarification case that you would like to show to the enduser. This description should also include processing steps, especially for new usersunfamiliar with SAP screens. Having this information readily available will provide formore efficient processing of exceptions.
The Description Tab can now have variables from the message or added objects. At thetime of the case creation, the specific values will replace the variables for a more logicaldescriptive text.
Click on the ‘Insert Variable’ icon to the left of the Case Text field:
A pop up window will display with the objects contained in the Case Container. Systemfields can also be inserted as variables. To add a variable to the Description:
Select the object or variable to be entered into the textA message will display that the variable has been storedEnsure your cursor is where you want to insert the variable into the textUse standard ‘Paste’ functionality (or the ‘Insert’ icon on the window’s toolbar) topopulate the variable key into the text
TAB: Process
30
Determine the order of the processes or ‘transactions’ needed for processing aclarification case, either manually or automatically, once it is created by EMMA.
Execute Automatic Processes: Check flag when activating the automatic process forsolving clarification cases in transaction EMMACAP. This flag is used in combinationwith a flag at each process level as well.
Individual Process Definition: (columns from left to right in the Solution Process sectionof the tab)
Name: This field will contain the name of the process after it has been defined: Click thebutton with icon ‘Add row’ at the bottom of the tab. A pop-up screen will appear.
Three options will be available in the call definition, i.e. you can pick from an ABAP OOmethod, workflow or a transaction from an action box profile. Assign an appropriate icon(it defines the process) to appear on the solution process button in the case transaction. Ifan action box transaction is identified, then the icon selected in the action boxconfiguration will override the selection made here. This functionality is new in theERP2005 release of EMMA/BPEM. Prior to this release, the definition of all processeshad to be done via the Action Box profile.
Auto: If the box is checked then it means the solution process can be executedautomatically. This goes together with the check box to execute automatic solutionprocesses at the top of the tab.
Type: this icon indicates the type of solution process that has been defined:A methodA workflowAn action box transaction .
Status: If the solution process is defined as a method or workflow, then data needs to betransferred from the case container. An icon appears in this column. If the casecontainer is filled-in correctly then the icon turns green and if it contains errors, it willturn red. It stays colorless if nothing has been defined for it.
TAB: Priorities
31
On this tab, the priority of a case can be overwritten after defining the conditions.
Select the icon ‘Insert’ for creating a new entry.
Priority: Change the current priority by setting a different priority from the F4 list
Condition: Place the cursor on column ‘Condition’ and double click. A new windowappears at the bottom. Click on the line ‘Click here to create a new condition’. Followthe basic instructions provided in the section on the Basic Data tab (above).
Forwarding Method: A standard method has been delivered by SAP with the interface:IF_EMMA_CASE_FORWARD with an example: ‘FORWARD’.
Period: Enter the numeric reference to the number of time units for the determination ofthe new priority.
Time Type: Enter the type of time i.e. hours, days, weeks, months or years
Note: Use of additional priorities can result in slower system performance. Thisshould be evaluated before use.
TAB: Management
Each time a case is processed, EMMA keeps a record of the time, date and user name.There is no standard configuration activity for this tab. The type of information providedincludes:
32
4.2.3.2 Other IMG activities within the node: Maintain Clarification CaseCategories:
Change Clarification Case Category (Transaction EMMACCAT2)
Change an existing clarification case category. Refer to the Clarification Case CategoryCreation. The functionality described in that section applies for any changes needed to anexisting case category.
Display Clarification Case Category (Transaction EMMACCAT3)
Display an existing clarification case category created above. Refer to the ClarificationCase Category Creation.
Delete Clarification Case Category (Transaction EMMACCAT4)
Delete an existing clarification case category. Alternatively, a case category can bemarked as deactivated and no cases will be created for that case category.
4.2.4 Define Method for Forwarding Clarification CasesIn this activity, define the methods and classes for forwarding clarification cases to theresponsible processor: (This customizing activity will be used where the worklist is notsufficient for forwarding of all cases)
Forwarding method: Define a forwarding method first by creating in the customerrange an ABAP OO class (Transaction SE24). SAP provides the interfaceIF_EMMA_CASE_FORWARD with method FORWARD for forwarding the case to theappropriate clerk.
33
Method for Forwarding Cases:Forwarding Method: Define the forwarding reason (4 character long)Name: Enter a short description of the forwarding methodClass Forwarding Method: Enter the name of the forwarding method created intransaction SE24. As example, refer to method ‘FORWARD’.
Example from ISU: Methods for Forwarding Cases:Forwarding Method: ‘MBIL’Name ‘Manual Case forward’Class Forwarding Method ‘FORWARD’
4.3 Specifications for Processing Clarification CasesIMG path:Financial Accounting Contract Accounts Receivable and Payable BasicFunctions Enhanced Message Management Specifications for ProcessingClarification Cases < entry from below>
4.3.1 Generate Selection Screen for Clarification ListThis activity allows the activation of additional fields in the selection screens for theclarification case list (transaction EMMACL) after the insertion of the new field in thecustomer include CI_EMMA_CASE.
1. To include a new field into the customer screen use transaction SE11 –ABAP Dictionary with table EMMA_CASE. Add the field(s) aftercreating the new structure of the customer include: CI_EMMA_CASE. Inthe ‘Maintain Structure’, enter a ‘Short Description’, choose thecomponent type using the F4 help, enter a name, check, save and activatethe new structure.
2. The new structure will be activated in this IMG activity and the new fieldsavailable in the EMMACL screen.
4.3.2 Define Reasons for Forwarding Clarification CasesDefine a forwarding reason that is used in the Change Clarification Case processing. Thereason code must be entered any time a user removes the value in the Processor field.This value will then be displayed to the right of the Previous Processor field when thecase is accessed again.
34
Reason: A four character key to identify the forwarding reasonDescription: A 50 character field to describe the reason for forwarding. The text displaysto the right of the Forwarding Reason field on the case.
4.3.3 Define Reasons for Reversing Clarification Cases
In this activity you define the reasons that a clerk can specify for reversing a clarificationcase. The field for Reversal Reason is only displayed on a case when it is accessed inDisplay mode or when the status is updated to Reversed. At that time, a field will bedisplayed to the right of the Status field on a case for selection of the Reversal Reason bythe clerk.
Reversal name: A four character key to identify the reversal reasonReversal Reason: A 50 character field to describe the reason for reversal. The textdisplays to the right of the Forwarding Reason field on the case.
4.3.4 Maintain Shortcut Keys for Clarification Processing
In this activity, you define the shortcut keys to be displayed that the users can use on theleft side of the clarification list screen (transaction EMMACLS), to access theclarification cases relevant to their work and task assignment.
35
To create shortcut keys, proceed as follows:
a) Shortcut keys are grouped in layouts. Therefore, first define a layout. The layoutis a four character key to hold the set of short cut keys to be defined in a user’sOwn Data as a parameter ID.
b) Provide a name for the layout that describes the users of the layout: for example,North Region Billing Team.
c) Then define the shortcut keys for this layout: (columns are described from left toright for this IMG activity)
i) Number: This field is used to indicate the sequence of the short cut buttons onthe left side of EMMACLS. It cannot be changed once the entry is saved.
ii) Description: This is the text that will display on the short cut button (This fieldis 20 characters in length)
iii) Variant Name: Variants are created for the EMMACL screen and are enteredhere to correspond to the short cut button. Use F4 to select from the list ofpossible entries.
d) Class: Short Cuts: Class for Selection Criteria: Class for implementing theshortcut keys. An ABAP-OO class that provides the selection criteria for theprogram REMMACASELIST via the method DETERMINE_SELCRITERIA ofthe interface IF_EMMA_CWL_LAYOUT. Then enter the name of the class in thefield Class with Selection Criteria. This enables you to circumvent the restrictionsfor the selection criteria that you define with a variant.
e) Class: Short Cuts: Class for Case Selection: Class for implementing the shortcutkeys. With a customer-specific clarification case selection you can adjust theselection to your requirements in addition to the functions of the programREMMACASELIST. To do this, create an ABAP-OO class that carries out thecase selection at runtime using the method SELECT_CASES_FROM_DB ofinterface IF_EMMA_CWL_LAYOUT. Then enter the name of the class in thefield Class for Case Selection.
36
f) Not specifically customizing, the layout must be specified in the User Profile forparameter ID: EMMA_CWLS in order for the transaction EMMACLS to displaywith the short cut keys.
4.4 Specifications for Customer-Defined Business Processes andMessagesIMG path:Financial Accounting Contract Accounts Receivable and Payable Basic Functions
Enhanced Message Management Specifications for Customer-Defined BusinessProcesses and Messages < entries seen below>
4.4.1 Define Customer Business Process Areas for Message ManagementYou can activate the EMMA functionality for any business process by first defining thebusiness process area.
Business Process Area: create a business process area with the following namingconvention (4 characters long).
For example the business process area should start with:
37
‘E’ for ISU‘V’ for Insurance‘F’ for FI-CA‘Z’ for any customer business process area
Description: give a short description of the business process area being definedBW: flag for the activation of BPA projects (Business Process Analysis). The activationis only available for ISU functionalities.Extract class: For BPA projects enter an extract class CL_..._KPI_BW. Use transactionSE24 (Class Builder) to create methods specific to your business process area. SAPprovides a standard interface from EMMA to BW which specifies the parameters forsetting up the infocubes in BW:
IF_EMMA_KPI_BW~WRITE_MSG_TO_BW_DELTA: transfers themessages and cases to the BPA Extract ClassIF_EMMA_KPI_BW~LAST_CALL_TO_BW_DELTA: warns that thereare no further messages to be transferred to the BPA Extract Class
Example from ISU: Definition of Business Process Area:Business Process Area: ‘EBI’Description ‘IS-U Billing’BW ‘X’Extract Class: ‘CL_BI_KPI_BW’
4.4.2 Define Customer Business Processes for Message Management
In this activity, you enter the installation-specific business process that you have createdthat you want to monitor with transaction EMMA.
38
Business Process Code: Define a business process code using the following namingconvention (8 characters long) with a short description.
For example the business process code should start with:‘E’ for ISU‘V’ for Insurance‘F’ for FI-CA‘Z’ for any customer business process area
Text: Enter a descriptive text to describe the specific business process.
Drilldown to the details for a Business Process Code:
39
The Business Process Code:Denotes an SAP business process code (or BPC) that belongs to the same applicationarea. EMMA delivers predefined BPCs for IS-U /CCS.
Business Proc. Area: F4 drop-down menu is available listing all the BOR objectspreviously defined. Select the appropriate Business Process Area.Primary Object Type: When clarification cases are created, this field denotes the primarybusiness object associated to the clarification case.
Classes for Analysis of Application Logs:
Job Analysis Class: Enter the name of the class to analyze the particular business processcode. SAP delivers a standard interface to implement the class method to analyze thebusiness process code. As an example, some class methods are delivered which can beused to analyze a business process based upon the way they are writing messages in thesystem. You can use the provided interface to develop a class method to read themessages from either SAP or Non-SAP systems (as long as the messages are in T100format). It is a required field.For example, the following classes are delivered as an example and can be used:
Application log: Class CL_EMMA_ANALYZE_JOB_APPLLOG
40
Job Logs: Class CL_EMMA_ANALYZE_JOB_LOGIDoc Logs: Class CL_EMMA_ANALYZE_JOB_IDOC
Log Number Class: It is not necessary to define a log number class. If the businessprocess code you are trying to monitor does not write an application log, then there is noneed to develop this class method. You can define the whole message analysis process inthe class method of Job Analysis Class. Three SAP standard methods are available forreading the application logs. Enter:
Method CL_EMMA_ISU_MALOG for ISU mass activitiesMethod CL_EMMA_MALOG for FI-CA mass activitiesMethod CL_EMMA_GET_LOG for dialog transactions
Interval Info Class: Reads the application logs for each interval of a mass activity run:Enter method CL_EMMA_MA_INTINFO
Analysis Class: CL_EMMA_PROC_APPLLOGMSGS_V2 defines the way thesemessages should be analyzed.
Message for identification of Execution Mode:
Mode Message:Execution Mode:
Messages for Identification of a Business Object:
It is necessary when dealing with mass activities, to determine the opening and closingmessages for the interval. The messages will be encapsulated per interval. Thiscustomizing step is required for mass activities.
First message: Enter the message class.Message number: Enter the number of the first message that usually appears in theapplication log.End Message and Message Number: Enter the message class and message number of thelast message to appear in the application log.Business Object Variable: Variable 1, …variable 4.’ In messages, this field denotes theposition of the parameter passed within the message.
Example:
EMMA delivers a standard SAP method GET_LOGNUMBER for displaying theapplication log. When it is not possible to display the application log using this method,the customer has the possibility to implement his own method.
41
Example for a dialog activity:Example from ISU: Definition of Business Process Codes:Business Process: ‘ECS00001’Description: ‘Create Move-In’Business Process Area: ‘ECS’Primary Object Type: ‘MOVEINDOC’Classes for Analysis of Application LogsJob Analysis Class: ‘CL_EMMA_ANALYZE_JOB_APPLLOG’Log Number Class: ‘CL_EMMA_GET_LOG’Interval Info Class: ‘ ‘Analysis Class: ‘CL_EMMA_PROC_APPLLOGMSGS_V2’
Example for a mass activity:Example from ISU: Definition of Business Process Codes:Business Process: ‘EDER0001’Description: ‘IS-U Agg. Posting to Invoicing Party’Business Process Area: ‘EDER’Primary Object Type: ‘ISUSERPROV’Classes for Analysis of Application LogsJob Analysis Class: ‘CL_EMMA_ANALYZE_JOB_APPLLOG’Log Number Class: ‘CL_EMMA_ISU_MALOG’Interval Info Class: ‘CL_EMMA_MA_INTINFO’Analysis Class: ‘CL_EMMA_PROC_APPLLOGMSGS_V2’Messages for Identification of a Business Object (for mass activities only)Beginning Message: ‘EMMA’ – ‘11’ ‘Start process &4 for &1
&2 in process area &3’End Message: ‘EMMA’ – ‘12’ ‘End process &4 for &1
&2 in process area &3’Bus. Object Variable: ‘Variable 2‘
The customizing is set here to show the first message ‘Start process &4 for &1&2 inprocess area &3’ as the first message of the interval and ‘Start process &4 for &1 &2 inprocess area &3’ as the last message in the interval.
These default EMMA messages can be used for any mass activity, otherwise use the firstand last messages within an interval if known.
42
4.4.3 Define Customer Business Processes for Processes in CIC
Process class: Use the F4 help for choosing a process class (CIC standard)Business Process: assign a BOR object to the process classWhere-Used List: For additional information how to activate the EMMA functionality inthe action box within the Customer Interaction Center (CIC). Please refer to section XX.
Example from ISU: Definition of Business Process for CIC Processes:Process Class: ‘MINSTLN EDIT’Where-Used List: Permits user to review which action box
profiles use this processBusiness Process: ‘EBI00001’Text: ‘Automatic Billing’
4.4.4 Define Customer Transactions for Message ManagementThis customizing step is necessary in case a same business process is assigned to onetransaction. The fields are the same as described above in Define a Business Process forMessage Management.
The Initial Screen:
43
The Detail Screen:
The fields shown are displayed in the sequence in which they are displayed on thecustomizing screen.
Transaction Code: Activate EMMA for a specific transaction code.Text: Description of the transaction codePrimary Object Type: The main business object type used for EMMAJob Analysis Class: See 4.4.2 above.Log Number Class: See 4.4.2 above.Interval Information Class: See 4.4.2 above.Analysis Class: See 4.4.2 above.Business Process Code: Choose a business process code using F4. SAP delivers the BPCfor IS-U/CCS.Business Process Area: Choose a business process area using F4Primary Business Object: The BOR object key for theName: The name of the primary business objectDescription: A description of the primary business objectText: The description of the Business Process CodeText: The description of the Business Process Area
Example from ISU: Definition of Customer Transactions:Transaction Code: ‘EA00’Transaction Codes SupportedText: ‘Test Billing of a Contract’
44
Job Analysis Class: ‘CL_EMMA_ANALYZE_JOB_APPLLOG’Log Number Class: ‘CL_EMMA_GET_LOG’Interval Info Class: ‘ ‘Analysis Class: CL_EMMA_PROC_APPLLOGMSGS_V2Business Process Code: ‘EBI00001’Business Process Area: ‘EBI’Primary Business Object: ‘INSTLN’Name: ‘Utility installation’Description: ‘Utility installation’Text: ‘Automatic Billing’Text: ‘ISU Billing’
4.4.5 Define Business Objects for Customer-Defined MessagesAllows the activation of the link between a log entry in EMMA of the main businessobject to the main transaction for this business object. For example in IS-U, if the mainbusiness object of a transaction is the billing document, the navigation to the transactiondisplaying the object of the billing document will be possible by a simple double-click.
Note: All “Z” customer messages must be entered in this table if the variables in themessage are to be included in the case processing.
Message class: Enter the message class corresponding to the message numberMessage number: Enter the message numberVariable: V1, …V4: Position which correspond to the position of the parameter withinthe message.Object Type: F4 help for all BOR objects.Reference Table: Enter the reference table for the fieldReference Field: Enter the reference field for the parameter(Message Text)
45
Example from ISU: Definition of Business Objects for Customer Defined Messages:MessageClass
Number VN Object Type ReferenceTable
ReferenceField
Message Text
EB 162 1 BILLINGDOC Billing document&1 line item &2already contains taxcode &3
EB 162 2 ERCHZ BELZEILE Billing document&1 line item &2already contains taxcode &3
EB 162 3 ERCHZ MWSKZ Billing document&1 line item &2already contains taxcode &3
5.0 EMMA/BPEM Transaction Details and Processes
Several different tasks can be performed once the basic configuration is complete. Thesetasks are:
EMMA: Analyzing the application log.EMMAC1, EMMAC2 and EMMAC3: Creating and updating the cases foridentified problems based on configuration/customizing.EMMACL and EMMACLS: Assigning the case/s to different users/user groupsbased on role resolution. Clerks can then access the assigned cases via theEMMA/BPEM worklists.EMMACL and EMMACLS: Case resolution either manually or via automaticsolution processes.EMMALOG: Once the automatic cases (application log based) have beenconfigured and processing has been ongoing, this transaction will permit thebusiness to compare the messages linked to case categories to all messages in theapplication log.
Each of the transactions is detailed below: the selection screens and the output asapplicable and processing steps for the transactions.
It is recommended to have an SAP system open for review of the transactions and screensreviewed here.
46
5. 1 EMMA: Analyzing the Application Log There are two components of EMMA described here: the selection screen and the outputlist. Details for both are provided, including toolbars and menus if relevant.
5.1.1 Selection Screen for EMMAThe main selection screen is designed to enable you to analyze the application log of allthe activities that took place in the system via dialog or batch mode including batch inputprocesses. You execute the transaction by providing the main selection criteria.Execution of EMMA is documented in Section 5. Four field groupings or blocks areprovided as main criteria (you can add more fields later during theimplementation/development phase if required).
The EMMA selection screen (seen above) has the following fields as selection criteria:(the fields are documented within the field groupings or blocks seen on the screen and insequence of display)
47
Business Process Information:
This block provides you the capability to search the jobs based on the business processes.
Business Process Area: Select the pre-defined business process area bypressing F4. It is a term for a complete application containing only similartypes of business processes: (examples from SAP IS-U/CSS) Billing,Invoicing, Meter Reading, etc. Business process areas can be activated and de-activated by using the IMG activity documented in section 4 or via view:V_EMMAC_BPA. Only the activated business process areas can be viewed indropdown search help. In this release only IS-U/CCS has delivered pre-configured/defined business process areas.
Business Process Code: A business process within a certain business processarea performing a unique operation. It does not matter how this process wasexecuted; by a simple transaction, the online or background execution of areport, or a mass activity. An example for the same business process is thecreation of invoices either by transactions EA19 for individual bills, EA10 formass processing, or EA26 for parallel processing. In this release only IS-U/CCS has delivered pre-configured/defined business process codes for thedelivered business process areas.
Technical information:
This block provides the option to select and analyze the executed system jobs based ontechnical information.
Internal Job Number: This is the job run number for the EMMA job. It isassigned to an executed job internally and has no external control or influence.The number range EMMA_RUNID has been defined for this and must bemaintained by the user (customer) before the activation of EMMA/BPEM.
Transaction Code: Here you enter the transaction code in order to analyzethe application log of a job. The input help for the transaction code showsonly the transaction codes that are maintained and delivered by SAP(including the customer defined ones as well) in the IMG activity or the view:V_EMMA_TCODE. F4 help displays you the transaction code and itsdescription.
Job Number: This is an internally defined 50 character field value. It is an‘easy to read’ value for mass activities (A concatenated value of mass activityrun parameters separated by a space) while for all others, it is a system createdGUID and is impossible to interpret. Thus, the value of this selection criterionwill vary depending on the specific job.
48
Processing Date: You can limit your search for a particular time period. Thisnarrows the search and improves the performance to search on the database.
Processing Time: You can enter the approximate processing time of the job,that is, it’s starting time (as a range) for a better, quicker, and more specificsearch.
User ID: You can specify the particular user who executed the job that youare looking for. This speeds up the search and makes it more specific.
Only for Case Generation:
This block should only be used when cases have to be created.
Interval Number: If a case/s for a particular interval/s of a job/s needs to becreated, then it must be defined For example, if cases are to be generated fortwo intervals of the ten intervals processed for a batch job, then the twointervals would be specified here..
Prepare Block:This block has two checkboxes. They are:
Prepare Jobs: If this checkbox is selected, then only the log analysis isprepared, that is, the application log is analyzed and you can view thestatistics of the job. If a job is selected that has already been prepared, then theexisting run’s analysis is re-prepared by deleting it first and the ‘deletecheckbox’ does not have to be selected. If the cases have already been createdfor the job and it is selected to re-prepare again then the system will delete thecases and re-prepare them. But if any of the cases have a status other than‘New’ or ‘Cancelled’, then those cases will not be re-prepared again. At theend, the transaction informs the user about the operation performed withstatistical information as a message ‘S024 (EMMA)’; ‘XXX mass runsselected, XXX mass runs prepared’.
Create Clarification Cases: If this box is checked, then the cases aregenerated for the jobs whose application log has already been analyzed. Youcan use this in combination with the checkbox Prepare Jobs if the job has notyet been analyzed and you want to create cases and view the application logfirst. (Note: The job types near the bottom of the screen would be set to: Jobsnot prepared yet in this case). You can either select this checkbox alone or incombination with Prepare Jobs.
49
i. Stand-aloneYou select it as stand-alone only if the jobs selected based on theselection criteria are already prepared. This check box can be usedonly for the jobs that are already prepared (based on the selectioncriteria). At the end of the process, the transaction informs the userabout the operation performed as statistics with message S031(EMMA) ‘Jobs selected XX, Jobs processed XX, Cases created forXX jobs’.
ii. Combination with checkbox Prepare JobsThe combination of checkboxes performs two tasks. First, it analyzesthe application log of the selected jobs based on the selection criteria.Second, it prepares the job runs first to make sure that the preparedanalyses are of complete jobs and are not a snapshot of running jobs.Then the case creation process is executed. If the selected jobs arealready prepared, then the system first deletes the run preparationbefore it executes the case creation process for the selected jobs. At theend of the process the transaction displays the statistical information ofthe operation performed as message S031 (EMMA) ‘Jobs selected XX,Jobs processed XX, Cases created for XX jobs’.
Delete Block:Like the prepare block, this block also has two checkboxes:
Delete Job Preparation: Selecting this checkbox deletes the prepared runanalysis of the job. You can use this only as a stand-alone option and not incombination with any other checkbox. Selecting this checkbox deletes the runanalysis of a job but also deletes the run preparation if the cases for the jobs arealready created with an exception. This means that all the cases must have thestatus ‘NEW’ or ‘REVERSED’. If the cases are already prepared then the systemdeletes both the cases and the log preparation. At the end of the process theprogram informs the user with job statistics with message S027 (EMMA) ‘XXmass runs selected, XX mass runs deleted’.
a. Delete Case: If this checkbox is selected, then the cases created for the selectedjobs are deleted from the system depending on the status of the cases. If any casehas a status ‘In Process’, ‘Completed’, or ‘Reversed’, then the generated cases forthe selected job cannot be deleted.Selecting this checkbox only deletes the cases of the prepared runs with theexception of case status. This means that it will delete the cases if all the casescreated for the jobs have status ‘NEW’ or ‘REVERSED’, otherwise no cases aredeleted. At the end of the process statistical information is displayed as messageS027 (EMMA) ‘XX mass runs selected, XX mass runs deleted’.
50
Job Types to Be Processed:This block identifies the types of jobs that you are interested in viewing or processing:
Prepared Jobs: A default checkmark appears opposite this option; the systemshows only the prepared/analyzed jobs with this option..
Jobs Not Prepared Yet: You can view the non-prepared/analyzed jobs byselecting this option.
5.1.2 Output (for EMMA)Output is in the form of an interactive report (multiple levels of information) that you candownload as a spreadsheet. The output is displayed by using the SAP standard ALVtechnology so you can sort, arrange the column location, total, group, and so on in theformat you desire. This means that you can control the display format. The information ispresented in multiple levels depending on the level of detail you require. By using thestandard ALV functionality, you can define your own output (see the onlinedocumentation for ALV). The run analysis information of a job is displayed in threedifferent levels.
5.1.2.1 Summary of Job/Application
The first level of display shows summarized information about each job selected basedon user selection criteria. The information is displayed in a number of columns. A briefdescription is provided here, but more information can be found in the EMMA/BPEMOnline Help in the application SAP Library SAP Utilities Contract AccountsReceivable and Payable Enhanced Message Management.
51
From left to right these columns are: (Note: the sequence may vary depending on theselection criteria entered on the initial screen. All columns are detailed here.)
Business Process Code: Pre-defined and delivered business process code forevery job executed in the system. Currently, only the IS-U/CCS industry has definedthe process codes for their business processes. For the rest of the standard SAPapplication areas, this column will be blank (with the exception of customer baseddevelopment)
Transaction Code: The transaction code of the job is indicated in thiscolumn.
Preparation Status: Each job has a status. If the job has not yet beenanalyzed, then the status column is blank. If it has been analyzed, a traffic lightappears. A green light means that it has been analyzed with no error messages; a redlight means that errors occurred in the job during its run; a yellow light represents awarning message.
Job: Sequentially generated number defined by the system. Each job has aunique RUNID. You can define the number range BPEM_RUNID via transactionSNUM or the IMG task for that purpose. This number range is for the EMMA jobonly.
External Job Number: This is a concatenated field and is defined by theprogram during the runtime. For mass activities this field is a concatenation of massactivity run parameters separated by a space. However, for non-mass activitytransactions, that is, online transactions, it is composed of an external job number thatis essentially impossible to translate (the GUID).
Execution Mode: Execution mode of the job: You can run the job either insimulation mode or in production mode. A job executed in the system prior to theimplementation of the EMMA/BPEM code will not have an execution mode since theinformation was stored in the EMMA/BPEM database at that point in time.Therefore, a job can have one of three execution modes: Simulation mode, productionmode, and <blank>.
Interval: Where a process included multiple intervals (as with most parallelprocessing) the intervals will be seen here for review by interval as needed(drilldown).
The next set of columns refer to the objects processed:
Incorrect Objects: Total number of objects that were not successfullyprocessed in a job, that is, objects with a problem and that were notprocessed. You can rename the column to the particular business objectprocessed for the transaction.
52
Object Warnings: Total number of objects that had at least one warningmessage during processing. You can rename the column to the particularbusiness object processed for the transaction.
Successful Objects: Total number of objects processed successfully in ajob. You can rename the column to the particular business objectprocessed for the transaction.
Objects: Total number of objects processed in a job.
The next set of columns refer to the messages from the jobs:
Error Messages: Total number of error messages generated by theprogram during a run and that are not allocated to any business object.
Warning Messages: Total number of warning messages generated by theprogram during a run and that are not allocated to any business object.
Information Messages: Total number of information messages generatedby the program during a run and that are not allocated to any businessobject.
Messages: Total number of messages logged in the application log for ajob. These messages do not include the messages with special charactersor spaces. The numbers in this column may be different to the totalnumber of messages that appeared for the job via transaction SLG1.Reason: EMMA/BPEM does not include messages with wildcardcharacters and spaces.
The last set of columns:
USER Name: SAP ID of the user who executed the job.
DATE: SAP ID of the date on which the job was executed.
TIME: System time stamp logged in application log.
Job Status: This shows the current preparation status of the job. Asdisplayed in EMMA/BPEM, this can have any of the following threestatues: not yet prepared, prepared or deleted and re-prepared. The statusicons are:
Icon Description
Job completely processed
Job still active
53
Job terminated
(no icon) Status unknown
Clarification Case Execution Process: Indicates the case generationstatus. It can have any of the following 4 statues: Cases never generated,Cases were re-generated after deletion, generated for the whole job orgenerated for the partial job (e.g. parallel jobs i.e. mass activity where youcan generate cases for at least one interval). The status icons are:
Icon Description
Clarification case generationcompleted
Clarification case generation partiallyprocessed (for individual intervals)
Clarification case generation reset (allclarification cases deleted)
(no icon) Clarification case generation has neverbeen started
Cases: Total number of cases created for a job based on the Customizingin the IMG.
5.1.2.2 Buttons on the EMMA Output Screen: the Application Toolbar
Note: Many of the buttons described here have functions similar to the check boxes onthe EMMA Selection Screen. All regular SAP icons (sort ascending for example) are notdocumented here since they are used independently of EMMA functionality.
Button Description and UseMessages: Using this feature, you can search for a specific main business object
involved in the job along with its value, message class, number or type,or a value in a particular variable of a message in a selected job.
Details: All of the details for a line in the list can be displayed in a vertical popup window
Preparation: You can select a job to prepare its application log for use inEMMA/BPEM. If you select this for a job that has already been
54
prepared, the log is re-prepared by deleting it first and then preparing itagain based on the current setting in the IMG.
a. When no job is selected: System selects the job where thecursor is positioned. If the job is not yet prepared then awarning message and question “The selected job run has notyet been prepared for monitoring. The preparation may takesome time. Do you want to continue?” appears with threeoptions for you to select: ‘YES’, ‘NO’, and ‘CANCEL’.Selecting ‘YES’ results in the preparation of the job log,while ‘NO’ or ‘CANCEL’ have no effect and the user stayson the same screen.
b. When one or more jobs are selected: The system analyzesall the selected jobs. If one or more jobs are alreadyprepared/analyzed then the warning message “Prepared jobrun analysis will be re-prepared. Do you want to re-preparethem for analysis?” appears with three options for user toselect: ‘YES’, ‘NO’, and ‘CANCEL’. This re-prepares thejobs that were already prepared and prepares the ones thatare not yet prepared.
DeletePreparation: You can select a single job or multiple jobs and delete the preparation
online. This may take some time depending on the size of the job, (Thetotal number of business objects and messages processed in the job).The fewer the number of business objects the less preparation timerequired and so on. This feature is provided to re-prepare a job if it hasto be re-prepared with different settings in the IMG or it was initiallyprepared while it was still running.
After you have selected jobs, pressing this button results in a warningmessage: ‘This will delete the run prepared analysis of the selectedjobs. Do you want to continue?’. If you select ‘YES’, then this deletesthe prepared analysis of the job and resets the counter in every columnto zero. If the cases were already prepared for the job, the systemchecks all the cases previously created for the job. If any of the caseshas a status ‘In Process’ or ‘Complete’, then the cases are not deleted.The system responds with an error message ‘Job XXX cannot bedeleted, please check the status of job’. You can view the details bylooking at the long text of the message.
Create Cases: Create the cases for the selected job based on the configuration in theIMG.Select a prepared job and press the button . A messageappears indicating the total number of cases created for the job alongwith the job ID. If the job is not prepared then an error message ‘Jobrun must be prepared first’ appears.
Display The application log of the generated cases for the specific job can be
55
GenerationLog:
viewed by selecting the job and then by pressing the button . Theapplication log will be displayed via transaction SLG1 by using thestandard ALV functionality
Delete Cases: Delete cases of the selected job for which the cases have already beencreated. If any case has a status ‘In Process’, ‘Completed’, or‘Reversed’, then the cases created for the selected job cannot bedeleted.
Additional EMMA Output functionality:
Click on any column: A click on any column that has business objectsdisplays the list of business objects that fall under the selected category.Similarly a click on any messages column shows the list of messagesbelonging to the selected column. Clicking on the Cases column willdisplay the Clarification Case List (EMMACL).
Application log of cases: If you click on the icon , then the applicationlog of the cases created appears.
Menus: All of the toolbar functions are available in the menus on theEMMA screen.
5.1.2.3 Interval Level Information for Each Job
The second level of output gives more detailed information: The interval level summaryof each job (mass activities) can be broken into several parallel jobs as in a mass activity.This detail level is the same as when you click on the job log in any mass activityframework.You can obtain this level of detail by clicking on the column ‘interval’. Again, a statuslight has been added to represent the status of the interval: A green light represents noerror or warning; a yellow light displays warning messages or objects; a red lightindicates an error in the object or an error message in a particular interval. All thecolumns and their names are the same as from the first screen.
56
The new columns on this screen are:
By: This shows the lower limit value of the processing interval of the massactivity interval.
Until: This shows the upper limit value of the processing interval of the massactivity interval.
Start time: This shows the starting time of the interval processing.
End time: This shows the finishing time of the interval processing.
5.1.2.4 Objects and MessagesYou can see the third level of detail by clicking on any object number, that is, either onan error or a warning or by clicking on program messages, including error, warning, andinformation messages. If you click on an object error or object warning, all the messagesfor an object are displayed. If an object has caused errors, then the system not onlydisplays the error messages but also displays all the messages for that particular objectthat were raised during processing. If you click just on messages, than only the messagesissued by the program are displayed that are not related to any object.
The following fields/columns are displayed on the screen.
Message Drilldown:The columns are described in sequence depending on the view displayed in your system.
Message Category: The message category specifies whether the message is aninformative one or one that describes an error. We distinguish between thefollowing different categories.
57
Icon Description
Information or success message
Warning message
Error message
Message ID: Message class, message ID of an R/3 message from table T100. Itgroups messages by component.Message No.: Message number in message class i.e. T100 table message number.Message Text: Complete text of the message in sign-on languageLong Text: Icon to display if long text for the message is available.Business Object: Icon to represent that at lest one business object isembedded in the message and navigation to that business object is available. Ifmore than one business objects are embedded in message, than a pop-up willappear and display all the business objects and user can choose the one that he/sheis interested in viewing. The business objects contained in the message textrecognized via table V_EMMAC_MSG_OBJ. A click on the business objecttakes the user to the object display screen. Customer can add their own definedmessages in it.
Detail data icon: If any of the messages has an extra detail information in loggedin application, than this column will appear with icon in it.
Note: If the Business Process Area is not activated for EMMA/BPEM in tableV_EMMAC_BPA, then EMMA/BPEM cannot distinguish the messages related to thebusiness object to which they are allocated. It is important to ensure the Business ProcessAreas have been activated in order for EMMA analysis to be effective.
Object Drilldown:The columns are described in sequence.
58
Object: The first column will display the name of the relevant business object if asingle object is represented by the displayed job. For example, the UtilityInstallation is the standard object of ISU Billing and the column has thisdesignation.
Message Category: The message category specifies whether the message is aninformative one or one that describes an error. We distinguish between thefollowing different categories.
Icon Description
Information or success message
Warning message
Error messageMessage ID: Message class, message ID of an R/3 message from table T100. Itgroups messages by component.Message No.: Message number in message class i.e. T100 table message number.Message Text: Complete text of the message in sign-on languageLong Text: Icon to display if long text for the message is available.Business Object: Icon to represent that at least one business object isembedded in the message and navigation to that business object is available. Ifmore than one business objects are embedded in the message, than a pop-up willappear and display all the business objects and user can choose the one that he/sheis interested in viewing. The business objects contained in the message text arerecognized via table V_EMMAC_MSG_OBJ. A click on the business objecttakes the user to the object display screen. If you know that a business-specificobject (BOR) is embedded in a message and no icon appears in the columnBusiness Object on the object screen, then the message is missing in the table.SAP delivers the entries in this table and you can also add your own messageswith the specified name range (Y* & Z*). In a situation where a business object
59
(BOR) exists in the SAP defined message and no icon appears on the screen,contact SAP.Detail data icon: If any of the messages has an extra detail information in loggedin application, than this column will appear with icon in it.
5.2 Case Transactions: EMMAC1 (Create), EMMAC2 (Change) andEMMAC3 (Display)Generally, clerks will access cases in Change (EMMAC2) or Display (EMMAC3) via aEMMA/BPEM worklist. Cases will be created automatically from messages in theapplication log, or manually (but in the background) by programs or BAdis or by users inthe Customer Interaction Center. But the case transactions are the foundation for theprocessing regardless of the source. EMMAC3 is not documented here. Please refer toUpdating an Existing Case (EMMAC2).
5.2.1 Updating an Existing Case (Transaction Code: EMMAC2):
Assuming that batch processing has been run and case categories have been configured,cases will have been generated during the EMMA processing described above. A reviewof the case structure and some of the fields that can be altered: (Section 4 describes thetabs of a case in detail in the customizing, while the user view of the tabs and header aredetailed here).
The EMMAC2 screen requires the selection of a specific case. Using the standard searchfunctionality, identify the case to be updated and click enter.
5.2.1.1 Case Header Data:
Case StatusYou can manually change the status of a case. However, there are limitations to thestatuses you can choose. The case transaction only offers the statuses that are allowed tobe set dependent on the current status of the case.
60
A case has one of the following statuses:
Status Description
New No processor has been assigned yet
In Process A processor has been assigned andwork on the case has been started: theprocessor could be identified as the‘previous processor’ if the case hasbeen forwarded
Completed Work on the case is complete but thecase can still be re-opened
Reversed Case will not be processed
Confirmed Once a case is confirmed, it cannot bere-opened by anyone
Automatically Cancelled – case was cancelled by a mass cancellation program; case willnot be processed
The following status updates are allowed (where an X is present):
Initial Status InProcess
Completed Reversed Confirmed
NEW X X X NA
IN PROCESS NA X X NA
COMPLETED X* NA NA X
REVERSED X* NA NA NA
* Completed and Reversed cases can be re-opened to In Process status
New Automatically Cancelled
In Process and Completed New
User Authorization for Changing Case AttributesOnce a case is generated, it is assigned to a specific user or an organizational unit. Whena user of this organizational unit accepts the case, his or her user name is stored as thecase processor. Only authorized users are allowed to change the processor, that is, assignthe case to another user (reassign case) or return the case to the worklist.
61
The case can also be assigned to an authorization group such as ‘Very ImportantCustomers’. In this situation, only clerks with the authorization for this authorizationgroup can work on the case. The authorization group is included in the clarification casecategory customizing in the IMG. Authorization objects are reviewed in the appendix.
PriorityYou can change the priority of a case. There is no separate authorization needed tochange the case priority. The case priority can be Very High, High, Medium, Low, orVery Low.
Due DateThe due date of a case is calculated during case creation. The due date calculation isbased on the settings in the case category. It is either based on the time the case wascreated in the system, or the time the problem occurred. The time of occurrence isindependent of the time when the case was actually created in the system. For example,the problem that a customer did not receive a bill occurred before the customer called into report the problem and the CSR created that case in the system. The due date can alsobe changed manually.
ProcessorsAfter a case is created, it is put in the worklist. Initially, the case has status: NEW andthere is no processor assigned. Clerks check the worklist and select the cases to beprocessed. Once a clerk is assigned to a case, his/her user name is shown in the fieldProcessor in the case transaction. When a processor is specified, then this case is not inthe NEW worklist anymore, it now has status: IN PROCESS and is no longer visible inother clerks’ inboxes for NEW cases. The views of the worklist are controlled viavariants created for EMMACL and stored in layouts for the worklist transaction:EMMACLS.
Cases are usually accessed initially in Display mode; once a case is accessed in Changemode, the user ID of the agent is entered into the Processor field.
In the case transaction, the clerk can assign a different user as the processor or return thecase to the worklist. Note: Two separate authorizations are required.
In order to assign the case to another user, the clerk removes his/her user ID from theprocessor field and enters the new processor’s user name in the field Processor. Once thecase has been saved, the clerk is prompted to enter a forwarding reason (reassignmentcode). The forwarding reason is a four-character code defined in Customizing. The
62
previous processor is noted in the case so that the new processor knows who forwardedthe case. The status of a forwarded case is IN PROCESS with a processor and previousprocessor identified. You cannot forward a case at the same time as you set the status to‘Complete’ or ‘Reversed’.
In order to return a case to the worklist, the clerk clears the field Processor. Once thecase has been saved, the clerk is prompted to enter a forwarding reason. The forwardingreason is a four-character code defined in Customizing. The previous processor is notedin the case so that the new processor knows who returned the case to the worklist. Thestatus of a returned case is IN PROCESS but without a processor identified. You cannotforward a case at the same time as you set the status to ‘Complete’ or ‘reversed’. Thesystem prompts you to enter any missing information.
DescriptionAs part of the customizing of the clarification case category, a description of theexception, the case category, or whatever is needed is entered into the customizing. Thistext can include variables from the BOR objects or system fields (for example, date andtime) and can be uploaded from an external file if needed. The Description appears on thecase transaction as a button. Clicking this button displays the documentation in aPerformance Assistant pop up window for use by the processing clerk.
In this release, the Description pop up window remains an active window (stays open) tofacilitate better use by the clerk of the instructions for completing or resolving the case.
5.2.1.2 Clarification Case Tabs:
ObjectsObjects can be attached to a case. These objects can be BOR business objects such asbusiness partner, contract account, sales order, contract, and so on. If there is no businessobject defined in the BOR for a piece of information that should be kept with the case,then you can also attach a field value to the case. An example would be the companycode or the billing class for billing-related cases. However, you should always expect toattach business objects to a case. When a business object is attached to a case, a singleclick on the business object key enables you to display the business object. (In technicalterms, the default method for the business object is called. Most often, this is the displaymethod.) This functionality is not available for attached field values. You can attach ordelete objects from the case. No additional authorization is required.
63
The Objects Tab has the following columns:o ‘P’: Primary Business Object: The primary business object for the case
will display the ‘header’ (hat) icon:o BObj.: Icons indicate objects in the list of attached values. Field values
stored on this tab do not display an icon in this column.o Short Description: The name of the object or field valueo Key: The number of the object per line. This field is a link to the default
method.o Description: Text fields or short text fields from the objects may display
here (contract = contract text and installation = short text)o Element: the name given to the object or field value in the case category
definition or addition on the case itself.
Processing ‘Objects’ Tab:You can add and delete business objects on the tab Objects. If you do that then the systemasks you to insert a business object or a field value. This is of a technical nature since youhave to know whether the business object you would like to add is defined in the businessobject repository. If the business object is defined in the BOR then select ‘BusinessObject’. For example, if you would like to add a contract account to the object list, select‘Business Object’. In the following dialog box enter Object Type: ACCOUNTElement name: Any element name, for example, ‘ContractAccount’
Select the input help for the field Key to select the BOR object you would like to add tothe case objects. Once you enter a valid key, the corresponding contract account is addedto the object list.
You can also delete objects from the object list. Note however, that any change is logged.However, you cannot delete the main object of the case, which is indicated by the haticon. The main object is the business object that the errors were generated for in themonitored transaction. For example, in a case created for an error in the billing runtransaction, an installation might be the primary business object.
If the business object is not defined in the BOR, then select the field value. For example,if you would like to add the contract account number to the case, then select ‘FieldValue’. Reference table: FKKVKReference field: VKONT
64
Element name: For example, ‘ContractAccountNumber’
Select the input help for the field Key to select the contract account number to attach tothe case. Once you enter a valid key, the corresponding contract account number is addedto the object list.
Usually, objects are attached to the case during case creation and not during manualcase maintenance.
ProcessesThe processes tab lists the business processes that are relevant for the resolution of theproblem the case describes. This gives you an overview of the important businessprocesses in the context of the particular case, and enables you to standardize with a setof proven business processes.
You start business processes from the processes tab by clicking on the button containingthe icon. The business processes available for a particular case are defined in the solutionpath of the case category. The business processes may be maintained in the Action BoxConfiguration transaction EWFC0. The action box is the process execution engine usedin the Customer Interaction Center. In addition, the business processes can now bedefined as methods for the BOR objects of the case or workflows.
Most of the business processes require initial data such as the bill document to be re-billed or the business partner whose data environment should be shown. This data isretrieved from the objects attached to the case. If additional data is required, then thisdata has to be determined from within the business process. Data that is returned from thebusiness process is not logged in the case after the business process has finished.
The case transaction merely provides a platform from which business processes arestarted and does not replace the SAP Business Workplace or the Customer InteractionCenter.
The case transaction does not log any information on the outcome of the executedbusiness processes. For example, the case transaction does not record whether the
65
business process ran successfully nor had errors. For simple processes, this is usually notan issue. More complex business processes should be implemented as a workflow. Theworkflow enables you to track and log business processes.If error EMMA 284 occurs during the process, then there is a problem in the Customizingof the corresponding action box transaction. See the long text of message EMMA 284 forhints on how to resolve these problems.
NotesThe case transaction allows the clerk to enter text on the tab Notes. Each time the case issaved, the text entered by the clerk is saved with header information of when the text wasentered and who entered it. Clerks can use the notes section to communicate informallyand update each other on the progress of the case.
MessagesThe messages tab shows the messages that were the reason for the case being created.This tab is for information purposes only. It does not contain messages sent by businessprocesses that were executed from the Processes tab.
New functionality on this tab permits the clerk to view all messages associated with theprimary business object. By default, only the messages that caused the case to begenerated display on this tab.
Click on the toolbar icon: and the tab will be updated to display all messages for thatobject.
66
Additional DataThe case transaction displays additional data on a separate tab. Additional data can becustomer-specific case attributes as well as industry-specific attributes defined by SAP.The order and content of the tabs are defined in a layout that is specified in the fieldEMMA_BASIC-LAYOUT. You maintain layouts via transaction EMMACC. A layoutdefines how many tabs are shown, defines captions for the tabs, and defines what screensare shown on each tab. At the moment only one customer-specific tab is possible. Usegroup box S008 when configuring the layout.
There are two sub-tabs on the Additional Data Tab:o Management Data: Entry date, time and user ID, the last changed
data and technical information: internal job number, case GUID andorigin of the priority.
o Customer Data: This tab is blank unless the business has definedtheir own fields. The extension of the case transaction enables you tomaintain customer-specific case attributes from within the case worklist
67
(EMMACLS) screen. It also allows you to include customer-specificfunctions in the case transactions, that is, your own buttons. However,you should only add fields that should appear in all cases of any casecategory since this field is stored and shown on every case. If you need toattach a field to only a set of cases, consider attaching it as a case object.
To include customer-specific case attributes, create the include structureCI_EMMA_CASE in your system and add the required fields to thisstructure. You should do this early in the implementation since addingthese fields to the case table requires adjustments to the table. Anadjustment can be a time-consuming process if there are already largenumbers of cases in the system. In general however, you can add newcustomer fields at anytime.
Once you have created the include structure CI_EMMA_CASE, you candesign the customer screen in a customer function group. Since thecustomer screen is shown on a tab of the case transaction, it should notexceed the size limit for the tab otherwise the display appears distorted.Also, you need to re-generate the selection screen and data-selectionprocess for cases by executing the transaction EMMACLGEN (discussedin section 3).
Once you have created the customer subscreen, you have to integrate itinto the case transaction. You can use the Business Add-In EMMA_CASEto implement it (See section 8 for details). Once the methods have beenimplemented, activate the BAdI EMMA_CASE.
5.2.1.3 Clarification Case Application Toolbar:Standard SAP toolbar functions are not reviewed here: only those icons with functionsunique to EMMA/BPEM are documented.
o LogThe case transaction records all the actions that are undertaken by the clerk. By looking atthe action log, you can trace what happened with the case from the creation time to thepresent. Each entry is tagged with the user, date, and time in chronological order.
The business processes that are executed are immediately logged with execution date,time, and user. The other actions are only logged when the case is saved.You can add your own messages. To do this, you have to implement methodUPDATE_CASE_ACTION_LOG of Business Add-In (BAdI) EMMA_CASE (for
68
details see section XXXX). This BAdI method is called every time a process is executedfrom the Processes tab and when you save a case.
o Where-Used ButtonAlthough this is a conventional button seen on many SAP screens, the function within thecase transaction is unique. This button will allow the user to identify any other cases towhich the same object is linked. This display is a variant of the worklist (EMMACL) andoffers all of the drilldown functionality of that transaction.
o Other Buttons
The case transaction provides for some of the status updates to be executed from theapplication toolbar. Cases are re-opened or confirmed from the toolbar. These buttons areonly displayed when the case has a status for which the two conditions described areapplicable. The buttons appear as follows:
Icon Description
Re-open
Confirm case
5.2.2 Creating a Manual Case (Transaction Code: EMMAC1)You can manually create a case without having to generate it from the log analysis screenin transaction EMMA. On the entry screen specify the case category for which you wouldlike to create a case.
Only those case categories are offered that have a case creation type ‘Manually’ set inCustomizing of the case categories. You can find this setting in the IMG under FinancialAccounting Contract Accounts Receivable and Payable Basic FunctionsEnhanced Message Management Specifications for Generating ClarificationCases Maintain Clarification Case Categories.
Alternatively, you can specify a case you would like to use as a template. Then, the casecategory and other fields are copied over from the template to the new case. The case isalways created in status NEW. You can add text as notes, change the priority, status,processor, due date, and authorization group. You can add and delete business objects onthe tab Objects.The case transaction displays additional data on a separate tab; customer-specific caseattributes are displayed on this subscreen.
69
5.2.3 Field Selection for the Case Transactions
The transactions EMMAC2, EMMAC1, and EMMAC3 use the field selectionfunctionality to set display attributes for some fields. Use transaction SFAC to makecustomer-specific display settings such as allowing changes to the due date field inEMMA2. In transaction SFAC, enter module poolSAPLEMMA_CASE_TRANSACTION and screen group EMMA. Select Change tomake your settings.
5.3 EMMA/BPEM Clarification Case List (Transaction EMMACL)
5.3.1 Execute EMMACLYou can execute the transaction EMMACL with any of the fields provided on theselection screen (either single fields or in combination). The restrictions of the fields forthe sub-screen of the selection screen are described in section 5.Entering an invalid value in any of the field will result in an error message ‘No casefound per selection criteria’ (EMMA035).
5.3.2 Selection ScreenThe selection screen is divided into two parts. The first subscreen displays the selectioncriteria from table EMMA_CASE. This includes the fields defined in the customerinclude CI_EMMA_CASE.
70
General Selection Criteria:
Case: Specific cases can be specified by case number.Internal Job Number: The job numbers for which cases have been created inthe system via transaction EMMA. These jobs are the EMMA internal jobs, notthe system jobs which resulted in the exceptions.Case Type: This selection allows you to search for all cases related through thesame case type.Clarification Case Category: The case category describes all cases with thesame error or exception.Case Priority: Cases can be selected based on the priority of the case.Origin of Priority: This field allows cases to be selected based on the source ofthe assigned priority:
o 0: Case Categoryo 1: Priority Determinationo 2: Business Add-In: COMPLETE_CASEo 3: Manually
Processing Status: The five delivered system statuses are available for the caseselection process. Note: Reversed is used in this list but the user sets this statususing the Reversal option when processing a case.
71
Primary Object Type: The case categories specify a primary object for all casesthat will be linked to a specific object. The object can vary depending on thebusiness process code so this field can be used for any BOR object.Key: This field refers to the key of the Primary Object specified in the previousfield.Processor: This field selects for the current processor field only. The previousprocessor cannot be used in the search criteria.Original Date: ?????Original Time: ?????Due Date: The date calculated from the case category customizing for the duedate can be used in the selection process. Alternately, the date may reflect achange made by a processor.Due Time: Due dates can be measured in hours so the time can be importantwhen that time period is used.Created On: The date on which a case was created.Created By: The user ID of the person who created the case.Changed On: The date on which the most recent change was made.Changed By: The user ID of the person who made the last change to the casesfound in the search processCustomer-defined fields: Fields added to the customer includeCI_EMMA_CASE are added to the EMMACL selection screen once the screenhas been regenerated using the transaction: EMMACLGEN
The second subscreen contains the selection criteria for selecting cases based on theorganizational structure. Organizational Management allows you to manage scenarios inparallel in various plan versions.
The fields of the Organizational Structure second subscreen are:
Plan Version: Contains a one or two character alphanumeric key thatdifferentiates between scenarios in your organizational plan.
Object Type: Contains a code that represents different types of objects. Use thisfield to confine an inquiry/report to a particular object type. To do so either:
* Enter the appropriate code* Request a list of object types and make a selection
NOTE: To include ALL types of objects in your inquiry/report, leave this field blank.For example: S represents a position, Q represents a qualification, and E represents abusiness event, and so on.
Due to the limited scope of this transaction these object types have been limited to:O = Organizational unitC = Job
72
S = PositionUS = User
Object: The specific value for the object type selected. For example, if theObject Type was S for position, the specific object would be the code allocatedto the Billing Clerk.
Evaluation Path: Contains a code representing an evaluation path. Anevaluation path allows you to focus inquiries/reports on objects that are affectedby certain relationships.
To do so either:* Enter the appropriate code* Request a list of paths and make a selection
When you select the down arrow, a dialog box appears. In the From, Via, and Tofields, enter the object type codes of the objects that interest you. A second dialog boxappears listing the possible evaluation paths. Select the appropriate option.
NOTE: If you do not wish to use evaluation paths, leave the field blank. In this case,however, you may use only the object types (O, C, S, US) mentioned in object type.Customers/users have to define their own evaluation path with the help of a HRconsultant.Example: You may want to focus on objects involved in the relationship construction:Organizational unit (O) > position (S) > person (P)
Technical Depth of Structure: Contains a number of one to six digits. Thenumber corresponds with the different levels of an organizational structure, with 1being the highest level in a structure, and all subsequent numbers representinglower levels.
The level number determines how much of a structure is PROCESSED in aninquiry/report. For example, if the field contains a 3, the system processes threelevels of the structure, beginning from the organizational unit you select as theroot object, down. To indicate how many levels of an organizationalstructure should be processed in an inquiry/report, enter the appropriate levelnumber.NOTE: If you do not wish to limit processing, leave the field blank.
5.3.3 OutputThe output of EMMACL is displayed with the standard ALV, so you can define yourown layout as well. If you change any of the attributes of a case, the case worklist is notautomatically updated. You have to refresh the screen by clicking on the refresh button toupdate the list. There are two distinct sections of the worklist that are documented: thetoolbar and the ALV list columns and functions.
73
EMMACL Toolbar Functions:
The following functionality is provided in the clarification case worklist’s toolbar and aredescribed in the table in sequence from left to right. Standard SAP icons or buttons maynot be documented here.
Button or Icon onToolbar
Description
Display Case:Select a case and press the button: Display (Shift+F1). Thiswill take you to the transaction Display Case (EMMAC3).You can switch to change mode by selecting the pencil icon
from the case’s toolbar.
Change case:One or more cases can be selected followed by pressing theChange button. You can also do this by pressing thekeys(Shift+F2). The case details are displayed and you canchange the attributes (transaction EMMAC2). You can addtext as notes, change the priority, status, processor, due date,and authorization group. You can add and delete businessobjects on the tab Objects (for details see section XXX).Finally, the solution processes can be executed to resolvethe exception that caused the case.
Accept: You can accept case/s by selecting them and pressingAccept (Shift+F4). If the case has no current processorassigned, then the transaction accepts the case forprocessing by automatically entering your user name in thefield Processor. You can change this later manually if youwish to maintain any missing information. This only appliesto cases that have status: NEW
Forward: Select one or more cases and press Forward button(Shift+F5). In a dialog box, you are asked to provide theforwarding reason and the name of the user to whom thecase will be forwarded. You can forward more than one caseat a time to the same user by selecting multiple cases. Youcannot forward multiple cases to multiple users with thesame or different reasons. For each forwarded case you areonly allowed one forwarding reason and one new processor.You can only forward cases if they have the status NEW orIN PROCESS. Note: when forwarding a case within theCase Transaction (EMMAC2), it is possible to leave theProcessor field blank in order to return the case to theworklist for another responsible agent to accept. This is thefunction described with the next button.
74
Button or Icon onToolbar
Description
Return: Select one or more cases and press the Return button(Shift+F8). This action returns the case to the worklist ofavailable cases. You are asked to enter the forwardingreason in a dialog box. You can return more than one case tothe worklist with this action. You can only return cases tothe worklist if they have a current processor assigned.Returning a case to the worklist means that you havestopped processing the case. For example, you may wish toreturn a case to the worklist because you accepted it bymistake. The status of the case remains as In Process butwith the Processor field blank.
Refresh:The clarification case worklist does not have an automaticrefresh function; instead you have to refresh the screen bypressing the Refresh button (Ctrl+F12). You will find thesame behavior in SAP BASIS transactions and this is due tothe processing time involved (depending on the totalnumber of cases selected via the case list).
Confirm: You can confirm the completed cases by selecting them andpressing the Confirm button (Ctrl+Shift+F12). Casesflagged as Confirmed cannot be re-opened; all processing isfinal for the case. The ability to confirm a case is controlledthrough authorizations.
The EMMACL ALV Output:
The standard ALV list output has a number of columns that are documented below insequence from left to right:
75
Column Heading DescriptionDue/Completion StatusIndicator
The first column displays an indicator of the status of thecase. If the case has been completed, reversed or confirmed,the status will be a green light. If the case is New or InProcess, then the status indicator will reflect the due datecompared to the system date.
Case The case number is presented here as a link to the casedetails (EMMAC3: Display Case)
Clarification Case Text This text will be passed from the Clarification CaseCategory name
Status The text description of the case’s status: Confirmed,Completed, Reversed, In Process and New.
Priority The first sort for the ALV list: all cases of the same prioritywill be listed together. The case priority is determined fromthe IMG customizing for the default priority of a CaseCategory or from the expanded customizing for the casepriority within the Case Category customizing.
Due Date and Time Each case has an automatically assigned due date and time.These are determined from the IMG customizing settingsfor the Due Date/Time in the Case Category (described inSection 4). Due date and time are both included in thedelivered sorting for the ALV list.
Processor If there is a current processor, the user ID will be listed here.The field will be blank for New cases or returned cases.
Object Short Description Cases can be allocated to a primary object (all applicationmessage-based cases are). That object will be identifiedhere.
Key The number assigned to the specific object for the case willbe displayed here (there is no drilldown on the list).
Other Fields Depending on the system in which you are reviewing thisscreen, there may have been other columns added to thedisplay. Customer-defined fields are also seen on the outputas needed.
Some of the standard fields which can be added include:Case TypeCase Category and/or Case Category TextForwarding reasonsOriginal Time and DatePrevious ProcessorCreation information
76
5.4 Clarification List: (Transaction EMMACLS: Case Worklistwith Shortcuts)
The case worklist with shortcuts provides a user-friendly interface for selecting cases.The shortcut buttons appear on the left hand side of the screen. When you select ashortcut button then the cases are selected according to the selection method configuredin the IMG. The shortcut buttons are defined in the IMG under Financial AccountingContract Accounting Basic Functions Enhanced Message ManagementSpecifications for Processing Clarification Cases Maintain Shortcut Keys forClarification Processing.
Once the list of cases is displayed, you can accept, change, display, forward a case, andreturn a case to the worklist. These functions work in the same way as the functions intransaction EMMACL. See the description for transaction EMMACL for details.However, the output list does display some additional fields as standard selections andthese are documented below.
5.4.1 EMMACLS Configuration:
The EMMA/BPEM inbox (as used by clerks) is called using transaction EMMACLS.Before it is used several configuration activities have to be in place though.
Step one is to create variants from transaction EMMACL. The variants are then groupedinto a layout. Each user profile is updated with the parameter ID for the layout.
Step1 – Create Variants.Create the needed variants using standard variant configuration.
Step 2 – Configure Layout
This is performed in the IMG and is documented in section 4.
This is where the variants are attached to the layout. You define all variants that shouldbe displayed for this layout. Remember that a specific user will have access to onespecific layout only, you need to define enough variants to support all responsibilities andtypes of users who will use the EMMA/BPEM inbox. The variants can then be assignedto multiple layouts if needed.
Planning the variants and the layouts needed to direct the work appropriately is animportant design element in your EMMA/BPEM implementation.
Step 3 – Attach the layout to the user
77
Go to transaction SU01 and select the user to whom you will attach the layout. Then goto the tab ‘Parameter’
Add the Parameter ID ‘EMMA_CWLS and then the layout name in ‘Parameter value’.(Remember that Parameter IDs are case sensitive!)
After this is done call transaction EMMACLS for this user, and the screen should displaya two-paned screen with the short-cut keys (the defined and allocated variants forEMMACL) displayed on the left.
This screen cannot be called directly WITHOUT short cut keys defined in the userprofile. An error message will display indicating ‘no short cut keys defined’.
5.4.2 Executing EMMACLS
Processing cases from EMMACLS is similar to the steps described for EMMACLS witha few changes.
EMMACL requires the user to define the output: no selection criteria entered on theinitial selection screen will yield the first 200 cases; clearly, this would not be a veryeffective way to manage an agent’s worklist.
With EMMACLS, the agent’s work has been divided into ‘buckets’ of work based on thevariants for EMMACL called short-cut keys. Selecting a short-cut key will display casesthat meet the selection criteria of the variant. The list of cases display in the right-handpane of the screen.
5.4.3 EMMACLS Output
The columns displayed as standard for EMMACLS are different than the columns of dataseen on EMMACL. While they have the same meaning on both Clarification Case Lists,additional fields are displayed here so the output is documented for EMMACLS as well.
78
Column Heading DescriptionOverdue:Due/Completion StatusIndicator
The first column displays an indicator of the status of thecase. If the case has been completed, reversed or confirmed,the status will be a green light. If the case is New or InProcess, then the status indicator will reflect the due datecompared to the system date. Similar to the indicator inEMMACL but the column header is different.
Case The case number is presented here as a link to the casedetails (EMMAC3: Display Case)
Clarification Case Text This text will be passed from the Clarification CaseCategory name
Status The text description of the case’s status: Confirmed,Completed, Reversed, In Process and New.
Job The internal number assigned to the BPEM job thatgenerated the cases
Business Process Code Each case category is assigned to a business process code: acategorization of the business process for the company.Example: Automatic Billing (batch billing) in ISU.
Case Type A customer-defined way of grouping or segmenting casecategories.
Clarification CaseCategory
The key (up to 4 characters) for the case category: theconfiguration resulting in the rules for the case generationprocess.
Case Priority The first sort for the ALV list: all cases of the same prioritywill be listed together. The case priority is determined fromthe IMG customizing for the default priority of a CaseCategory or from the expanded customizing for the casepriority within the Case Category customizing.
Authorization Group The standard SAP function to limit access to cases via anauthorization group: the field is entered in the case categoryheader when the configuration is performed.
Object Short Description Cases can be allocated to a primary object (all applicationmessage-based cases are). That object will be identifiedhere.
Key The number assigned to the specific object for the case willbe displayed here (there is no drilldown on the list).
Original Date/OriginalTime
I have a comment earlier in the document to ask how this isdifferent than the created on in terms of date anyway
Processor If there is a current processor, the user ID will be listed here.
79
Column Heading DescriptionThe field will be blank for New cases or returned cases.
Reason This field holds the text for the forwarding reason enteredby a clerk when they are forwarding a case or returning thecase to the worklist.
Reversal Reason The reversal reason for a canceling a case is displayed inthis column.
Previous Processor If a case has been forwarded or returned to the worklist, the(last) previous processor user ID will be displayed in thisfield.
Due Date and Due Time Each case has an automatically assigned due date and time.These are determined from the IMG customizing settingsfor the Due Date/Time in the Case Category (described inSection 4). Due date and time are both included in thedelivered sorting for the ALV list.
Created On/CreatedTime/Created By
Three columns contain the date, time stamp and user ID ofthe person who created the case
Changed On/ChangedTime and Changed By
Three columns contain the date, time stamp and user ID ofthe person who last changed the case
5.5 Check and Comparison of Messages of Application Log with SLG1and SLG_ISU: (Transaction: EMMALOG)
This transaction allows the business to evaluate messages in the system that are not beinganalyzed in EMMA/BPEM. It will permit the identification of messages which may bemissing from the inventory of messages included in the Clarification Case Categories. Ifthe error or exception message does not result in a case, then the ability to readily addressthe error is compromised.
5.5.1 EMMALOG Selection Screen
80
5.5.2 EMMALOG Output
81
6.0 Case Generation Process
So far, we have reviewed the creation and update cases as an individual process and haveonly briefly described the case generation process. Cases can be generated manually orautomatically as follows.
Cases are created to resolve problems. There are two types: The ones that are identifiedvia the application log and are always linked to an application/transaction; and onesrelated to a business object that has not been identified in applications For example, if anapplication writes application log in the system, then creating a case is easy. However, ifan application/transaction does not write an application log then you can create casesmanually i.e. to create/define a manual case no application log is required. For example,in IS-U, when a front office user wants to report a problem for a specific business object,he/she has to create a manual case. Prior to EMMA/BPEM, the front office users couldnot directly communicate a problem to the back office (using the standard SAP System).
6.1 Manual Cases (Non- Application Log based case)Manual cases are needed for exception handling where the underlying problem does notrefer to a message issued in an application log.
From the viewpoint of EMMA/BPEM, the case is already determined. For example, theuser passes all the information to the system via the API function CASE_CREATE. TheAPI function then creates the case with the information provided.
Clarification Case Categories are created specifically for use in Manual Cases. Thus, theconfiguration activities are nearly identical: the processor rules, priorities, description textand solution processes are configured for manual cases as well.
Manual cases are included in the Clarification Worklist along with the Automatic Cases.Sorting of the cases follows the SAP sorting which does not include the generationmethod.
6.2 Application Log-Based CasesApplication log cases are those that are predicated on the presence of a message in theapplication log. They can be defined as simple or complex, based on their definition,using Complex Conditions or a BAdi. You can attach your own fields/objects to a casecreated/generated/identified via the application log. These fields/objects are attached tocases during the case generation process. A BAdI, EMMA_CASE, has been defined toenable the user to perform several different actions with the case(s). Customer-definedfields can be attached to the cases directly in the case category customizing in the tabcontainer (please check section 7). This way, they also handle the case status based ontheir own sets of rules and using the set of case statuses provided by SAP.
The Case Generation process for application log-based cases is as follows:
82
Step 1: Case DeterminationDetermine the case categories via the Business Process Area and Business Process Codeof the transaction that created the application to be analyzed.
Check the application log messages for simple case categories. The determination rulesare specified in the Customizing table EMMA_CCAT_MSG. If a case is determined,check table EMMA_CASE_MSG_LINK to see if there is already a case created for thesame problem. If there is a case, check table EMMA_CASE to see whether the status iscompleted or cancelled. If it is, do not create a new case and continue checking for thenext case category.Call method CASE_DETERMINE of BAdI BPEM_CASE to determine complex casestypes.Once a case is determined, assign a priority and calculate the time allowed to resolve thecase based on entries in table EMMA_CCAT_HDR.
Step 2: Object DeterminationIn this step the business objects and field values are attached to the case based on thecontainer definition in the case category.
Step 3: Priority DeterminationIf an entry exists in table EMMA_CCAT_PRI for the case category, then check the valueof the BOR object attribute defined. If the attribute value fulfills the condition given,apply the new priority to the case. The attributes can be taken from the BOR objectsdefined in table EMMA_CCAT_MSG.
Step 4: Case CompletionCall method CASE_COMPLETE of BADI ‘EMMA_CASE’ to enable customers tomodify case attributes and add additional information to the case.
We use two BADI methods during case generation:
CASE_DETERMINEMethod CASE_DETERMINE runs only when the case is based on application logmessages and considered complex in nature. This is defined by the value ‘2’ infield CDTYPE of table EMMA_CCAT_HDR. The rules for a complex casecategory can be defined by a combination of messages and several conditionsusing arbitrary application data stored in custom tables. In this situation, thedetermination rules cannot be specified in the IMG tables anymore. You have todefine the rules in BADI method CASE_DETERMINE.
CASE_COMPLETEMethod CASE_COMPLETE is called for all application log-based cases. This isdefined by the values ‘1’ or ‘2’ in field CDTYPE of table EMMA_CCAT_HDR.
83
7.0 InterfacesSeveral interfaces have been defined to make the application more flexible and notspecific to any industry solution. Each interface is described below (this can be changedduring the implementation time).
7.1 IF_EMMA_LOGNUMBER_GETThis interface has been implemented by class method ‘GET_LOGNUMBER’. You candefine any class by using the defined/standard interface to retrieve the application logfrom the system. In addition to this method, others will be created in future for otherpurposes. The method’s input and output parameters are as follows:
Input parameters:Parameter Type Associated TypeIV_TCODE Importing Type TCODEIV_BPCODE Importing Type EMMA_BPCODEIT_USER Importing Type EMMA_USER_RANGE_TABIT_DATE Importing Type EMMA_DATE_RANGE_TABIT_TIME Importing Type EMMA_TIME_RANGE_ TABIV_AKTYP Importing Type EMMA_AKTYPIT_LAUFD Importing Type EMMA_LAUFD_RANGE_TABIT_LAUFI Importing Type EMMA_LAUFI_RANGE_TABIT_EMMA_HDR Importing Type EMMA_HDR_ALV_TABIS_EMMA_HDR Importing Type EMMA_HDR_ALVET_LOGINFO Exporting Type EMMA_LOGINFO_OUT_TABExceptionsNOT_FOUNDNO_LOGOBJECT
Every industry can define there own application/transaction-specific functionalrequirements for the application log by implementing the class method interface. Forexample, in IS-U, mass activity application data is stored in a separate table ERPL alongwith the application log table BALHDR. Therefore, in the case of an IS-U mass activitiessearch, the implemented class interface method carries out an additional search on ERPLbefore searching BALHDR. ERPL returns the external ID, which is then used to do asearch on BALHDR as in IS-U one object can have several sub-objects for the sameintervals. All different type of messages, for example, information, error, successmessages are stored in a separate interval with different log numbers, which means thatone interval can have multiple log numbers (depending on the type of messages thatinterval has).
If any other industry group has a separate or special table or any other requirement, it canbe implemented in a method. Similarly, customer applications can also be integrated withany special needs. This way EMMA/BPEM will become a generic tool for searching and
84
analyzing the application log. This class method interface returns the application lognumber of the job, which is used for message analysis.
7.2 IF_EMMA_INTINFO_GETA mass activity job can be broken down into several parallel sub-jobs. The informationabout each processing sub-job or parallel job can be obtained from the system with thehelp of this interface. Since mass activity is part of standard FI-CA and it provides themain frame work, so this interface has been implemented in the package ‘FKKB’ in class‘CL_EMMA_MA_INTINFO’. Four different class methods have been defined.
7.2.1 GET_MASSACT_INTERVALInformation for each interval of a mass activity can be obtained with help of this. Thisinformation include lower and upper limit of processing business objects in the interval,starting and finishing time of processing and interval type as well.The following parameters have been defined for this class interface method.Parameter Type Associated TypeCT_EMMA_INT Changing EMMA_INT_ALV_TABCS_EMMA_HDR Changing EMMA_HDR_ALV
7.2.2 MASSACT_INTV_INFOMass activity frame work writes interval specific information for each processing intervalin application log. These intervals can be identified with specific interval number (basedon the processing interval) and information is retrieved from the system via this classinterface method.
7.2.3 GET_MARUN_STATUSThe online run status (e.g. interval is still in-process, or complete or aborted etc) of eachprocessing interval of mass activity can be find out with this class method interface.
The input and output parameters for the interface are as follows:Parameter Type Associated TypeCT_EMMA_INT Changing Type EMMA_INT_ALV_TABExceptionsNOT_FOUND
7.2.4 GET_INTERVAL_OBJECTThe processing business object type information can be obtained with this class method.
85
7.3 IF_EMMA_LOGMSG_PROCESSThis class method interface has been implemented to analyze the application log for a joband to count total number of processing objects (either based on standard EMMAmessages or customizing). Two class methods have been implemented to analyze andvalidate a message in the system.
7.3.1 ANALYZE_MSGSThis class method analyzes the application log messages, separate messages for eachprocessing business object, count total number of processing business object, separatelycount each processing business object depending upon their end result i.e. eithersuccessfully processed or processed as an erroneous object or resulted with warningmessage/s. It also differentiate between messages that are not part of any processingbusiness object and are issued/logged in the system by program/job itself (most of thetime it includes information about the job itself e.g. time of execution, machine name,user name etc). In nutshell it is the core processing block of application log analysis partand builds the statistical information for each processed job.Note: If the method implemented does not serve the needs for your application i.e.business process area and code, please implement you own class method by using theprovided interface and complete the customization in IMG.
7.3.2 VALIDATE_MSGThis class method validates the application messages by making sure that the messagecurrently under process/analysis does contain a meaning full text. Many applicationswrite messages in the system that do not have any meaningful text and are not useful forthe end user but are passed in the system for some technical purposes. During the loganalysis/preparation, every message is checked to make sure that it has a meaningful textand not just contain wild card characters ‘!@#$%^&*()?/\|-_ ‘ only.
7.3.3 ANALYZE_BUSOBJThis class method is obsolete, please do not use. It will be deleted from future release.
7.4 IF_EMMA_CASE_FORWARDThis class method is provided in order to define the customer preferred way offorwarding the cases to end users if they do not want to use the standard clarification caseworklist. For example if a workflow needs to be started or an email notification or serviceorder needs to be generated in the system based, then this class method needs to beimplemented and case category customizing has to be correctly maintained. Thisinterface has only one class method ‘FORWORD’.
86
7.5 IF_EMMA_CWL_LAYOUTIf the provided standard case worklist (EMMACL) and case worklist shortcut list(EMMACLS) does not fulfill the criteria to select the cases, then use this interface toimplement the custom defined selection criteria and selection process to select cases.Two class methods have been provided to select cases from the database.
7.5.1 DETERMINE_SELCRITERIAImplement this method if selection-criteria need to be re-define and standard selectionscreen does not fulfill the requirements.
7.5.2 SELECT_CASES_FROM_DBIf the provided standard database selection does not serve the needs of end-users, customdefine database selection can always be implemented to select the cases from DB. Forthis SAP delivers the class method that can be implemented for each individual layoutand for button of case worklist shortcut list (EMMACLS). The class method has beproperly maintained in IMG for the layout of EMMACLS.
7.6 IF_EMMA_IND_SUBSCREEN_PROCESSThis class method is obsolete, please do not use. It will be deleted from future release.
7.7 IF_EX_EMMA_CASEThis interface has been designed to provide the BAdI EMMA_CASE. All the classmethods are available for the customer specific check and validations. These methodsand what they can do (briefly) described.
7.7.1 TRANSFER_DATA_TO_CUSTSUBThis class interface method transfer the case data to the customer defined sub-screen tab.Once the case transaction is called to display or to make a change in a case, the customdefined information that needs to be displayed are passed to be displayed. The followinginformation is available for the customer to make the decision to what needs to bedisplayed for the case.
The following parameters have been defined for this class interface method.
Parameter Type Associated TypeIS_CASE Importing EMMA_CASE (Case information)IT_OBJECTS Importing EMMA_COBJ_T (Table of case objects)IT_MSG_LINK Importing EMMA_MSG_LINK_TAB (Case Messages)IT_ACTORS Importing TSWHACTOR (Table with Org. Objects)
87
IT_SOLPATH Importing EMMA_CSOP_T (Table for Case Sol. Path)IV_WORK_MODE Importing EMMA_CTXN_WMODE (Work Mode ofCase TXN)
7.7.2 COMPLETE_CASEThis class interface method can be implemented to add any custom defined field to thecase. This method is called once the case has been identified during the creation processand its contents are saved in DB. So, the custom defined fields are then added and casegets written to the DB.
The following parameters have been defined for this class interface method.Parameter Type Associated TypeIS_CASE Importing EMMA_CASE (Case information)IT_OBJECTS Importing EMMA_COBJ_T (Table of Case objects)IT_MSG_LINK Importing EMMA_MSG_LINK_TAB (Case Messages)IT_ACTORS Importing TSWHACTOR (Table with Org. Objects)EV_PRIO Exporting EMMA_CPRIO (Case Priority)EV_CUSTFIELDS Exporting EMMA_CCI (Customer Fields of Case)ET_RETURN Exporting BAPIRET2_T (Error messages)CT_OBJECTS Changing EMMA_COBJ_T (Table of Case Objects)
7.7.3 DETERMINE_CASEImplement this class interface method only if the case creation/identification is notpossible by the standard delivered methods. SAP hands over all the messages for eachprocessed business object and the relevant case categories to the method and expects thatcustomer will return case messages based on the custom coding, which is then saved as acase in the DB for the business object.
The following parameters have been defined for this class interface method.Parameter Type Associated TypeIS_CCAT Importing EMMA_CCAT_COMPLETE
(Case Category (Deep Structure with Messages and Objects)
IT_MSG Importing EMMA_MSG_TAB (Table of Messages for Case Determination)
ET_MSG_LINK Exporting EMMA_MSG_LINK_TAB (Case Messages)
7.7.4 UPDATE_CASE_ACTION_LOGThis method writes application log messages for the any custom defined changes andvalidations/checks built in the system depending upon if the application log message arelogged.
88
The following parameters have been defined for this class interface method.Parameter Type Associated TypeIS_DBCASE Importing EMMA_CASE (Case attributes before the
changes)IS_CASE Importing EMMA_CASE (Case attributes after the
changes)IT_DBOBJECTS Importing EMMA_COBJ_T (Case objects before the
changes)IT_OBJECTS Importing EMMA_COBJ_T (Case objects after the
changes)IT_DBMSG_LINK Importing EMMA_MSG_LINK_TAB (Messages before
changes)IT_MSG_LINK Importing EMMA_MSG_LINK_TAB (Messages after
changes)IT_DBACTORS Importing TSWHACTOR (Organizational objects before
changes)IT_ACTORS Importing TSWHACTOR (Organizational objects after
changes)IT_DBSOLPATH Importing EMMA_CSOP_T (Case Sol. Path before
changes)IT_SOLPATH Importing EMMA_CSOP_T (Case Sol. Path before
changes)ET_MSGS Exporting EMMA_CUST_MSG_T (Messages for Action
Log)
7.7.5 DETERMINE_CUSTOMER_SUBSCREENThis method determines the customer screen i.e. the screen to be called in the additionaldata tab of case sub-screen.
The following parameters have been defined for this class interface method.Parameter Type Associated TypeIS_CASE Importing EMMA_CASE (Case information)IT_OBJECTS Importing EMMA_COBJ_T (Table of Case objects)IT_MSG_LINK Importing EMMA_MSG_LINK_TAB (Case Messages)IT_ACTORS Importing TSWHACTOR (Table with Org. Objects)EV_REPID Exporting SYREPID (Main ABAP program to be called)EV_DYNNR Exporting SYDYNNR (Number of screen to be called incase)
7.7.6 TRANSFER_DATA_FROM_CUSTSUBThis class method transfers the additional data of the case (i.e. the custom field values)from the customer sub-screen to the DB.
The following parameters have been defined for this class interface method.
89
Parameter Type Associated TypeEV_CUSTFIELDS Exporting EMMA_CCI (Customer Fields of Case)
7.7.7 PROCESS_CUSTSUB_OKCODEThis class method processes any OKCODE (e.g. OKCODE for a push button) that hasbeen defined by the customer and perform/execute the required action.
7.7.8 CHECK_BEFORE_CHANGEThis class method is obsolete, please do not use. It will be deleted from future release.
7.7.9 CHECK_BEFORE_DISPLAYThis class method is obsolete, please do not use. It will be deleted from future release.
7.7.10 CHECK_BEFORE_SAVEThis class method offers customers to define custom validations before the case is savedto the DB. For example as per end user the case has been resolved and status needs to bechanged to complete. But, if a detail check required as per business requirement thenfurther validations can be defined in this method. So, before the case is saved it checks allthe validations (custom defined) and based on that sets the case status.
90
8.0 BAPIs for EMMA/BPEMEMMA/BPEM provides BAPIs (Business Application Programming Interfaces) so thatSAP business objects can be accessed. SAP business objects and their BAPIs provide anobject-oriented view of the business functions in an SAP System so that SAP softwarecomponents can interact and integrate with the software components of other vendors.
Please refer to the Appendix for more information regarding BAPIs.
8. 1 BAPI_EMMA_CASE_CREATEMethod: EMMACase.CreateBAPI: Create Clarification CaseFunctionality: You can use this function module to create a manual case. You have toprovide all the information required to generate a case. This includes, for example,the case category, main object type, and its value. You can also attach other objectsthat can provide useful information for the case solution. The details of the interfacewill be finalized during the implementation.
8.2 BAPI_EMMA_CASE_CHANGEMethod: EMMACase.ChangeBAPI: Change Clarification CaseFunctionality: You can change any information related to the case status including itspriority, assignment, due date, and so on. Changes to case fields are permitteddepending on the authorization. The details of the interface will be finalized duringthe implementation.
8.3 BAPI_EMMA_CASE_GET_DETAILMethod: EMMACase.GetDetailBAPI: Read Clarification Case DetailsFunctionality: Using this BAPI function module, you can retrieve the details of thecase. You only have to provide the case number.
8.4 BAPI_EMMA_CASE_ACCEPTMethod: EMMACase.AcceptBAPI: Accept Clarification CaseFunctionality: Using this BAPI function module you can accept the case manually.You have to state whether the function module is being run in test-mode, otherwisethe case will be updated in the database.
8.5 BAPI_EMMA_CASE_BACK_TO_QUEUEMethod: EMMACase.BackToQueueBAPI: Return Clarification Case to Worklist
91
Functionality: You can use this function module to return clarification cases fromprocessing in Enhanced Message Management.
8.6 BAPI_EMMA_CASE_CANCELMethod: EMMACASE.CancelBAPI: Reverse Clarification CaseFunctionality: You can use this function module to reverse clarification cases inEnhanced Message Management.
8.7 BAPI_EMMA_CASE_CHANGEMethod: EMMACase.ChangeBAPI: Change Clarification CaseFunctionality: You can use this function module to modify clarification cases inEnhanced Message Management (such as status information, like priority,assignment, and due date).You can change the fields of clarification cases if you have the appropriateauthorization.
8.8 BAPI_EMMA_CASE_CONFIRMMethod: EMMACASE.ConfirmBAPI: Confirm Clarification CaseFunctionality: You can use this function module to confirm clarification cases inEnhanced Message Management.
8.9 BAPI_EMMA_CASE_FORWARDMethod: EMMACASE.CancelBAPI: Forward Clarification CaseFunctionality: You can use this function module to forward clarification cases inEnhanced Message Management.
8.10 BAPI_BPEM_CASE_REOPENMethod: EMMACASE.ReopenBAPI: Reopen Clarification CaseFunctionality: You can use this function module to return clarification cases that havealready been closed or confirmed to further processing in Enhanced MessageManagement.
8.11 EMMA_BAPIRETURN_GET2
92
9.0 AppendixThis section provides supporting documentation for topics related to EMMA/BPEM.
9.1 Authorizations
Authorizations for the EMMACL and EMMACLS transactions are used as a mechanismfor controlling the case processing.
For example, a clerk may be able to mark a case as Completed but only a supervisor canmark a case as Confirmed.
One authorization object for EMMACL and EMMACLS is:
B_EMMA_CAS which has the following associated activities:01: Create or Generate02: Change03: Display31: Confirm37: Accept78: Assign83: Counterconfirm87: Return
One authorization object for processing the EMMA case creation:
B_EMMA_LOG: has the following associated activities:03: Display06: Delete40: Create in Database41: Delete in Database71: Analyze
9.2 Configuring the CIC for Manual CasesManual cases can be created from the Customer Interaction Center. The documentationprovided here is a high level overview of adding a transaction to an action profile. Thisapplies to the Customer Interaction Center in R3 and the Interaction Center in CRMwhere the locator is used to display the data environment.
93
The following steps allow the creation of cases from the CIC Environment screen.
Transaction ENVD - Define Data Environment for Navigation Area:
Initial Screen:Data Environment: Select the profile from the F4-Help to which you wantto allocate the transaction.Selection Routine: Select IS-U Data Environment for Business Partner (orany relevant option).Choose the ‘Maintain Action Profile’ button
Change Action Box Configuration Screen:Select the transaction group where the cases should be createdusing the method or the front office process. Expand the node andplace your cursor above the existing transaction where you wantthe new transaction to appear. If you want it to appear as the toptransaction in the context menu, select the transaction group itself.Choose the ‘Create Transaction’ button. The groupings belowparallel the screen blocks or field groupings.
Transaction:Transaction: Enter a transaction number
Transaction description: Short description of transaction
Transaction Description Menu: Short description on menu bar
Icon Name: Select an icon: this icon is used on the Processes tab toselect the process
Call Definition:Procedure Category: ‘2’
Method: ‘X’. For this example, you will use the standard method tocreate the case transaction for the CIC.
Object Type: Enter the internal key of a business object from theBusiness Object Repository (BOR): ‘EMMACREATE’Method: Enter the method used for the object: ‘CREATE’
Runtime Settings:Parameter Dialog Indicator: ‘X’
2. Complete the Maintain Data Flow screen as applicable. Exit andreturn to ‘Change Action Box Configuration: ISU’. Save.
94
Here is an example from ISU:Define Data Environment for Navigation Area: Initial ScreenData Environment: ‘ISU’Selection Routine: ‘IS-U Data Environment for Business Partner’
Transaction: (for selected object: this example uses the contract)Transaction: ‘0333’Transaction description: ‘Create Case 0333’Transaction Description Menu: ‘Create Case 0333’Icon Name: ‘ICON_INFORMATION’
Call Definition:Procedure Category: ‘2’Method: ‘X’.Object Type: “EMMACREATE’Method: ‘CREATE’
Runtime Settings:Parameter Dialog Indicator: ‘X’
Maintain Data Flow:In the Target Element:Fields for Creation: Clarification Case Category: ‘ZCMN’
Case Priority: ‘2’ Object Type: ‘INSTLN’
Key: ‘&NODEOBJECT.NUMBER&’ Original Date: ‘%DATUM%’ Original Time: ‘%TIMLO%’
Long Text: TDLINE: ‘None’
Check the new configuration:1. Enter transaction CIC0 after confirming the profile uses the Data
Environment you have maintained.2. Select a business partner3. On the tab ‘Environment’: Place the cursor on ‘Electricity’ and use the
right mouse click.4. The new Action Box ‘Create Case 0333’ is available using the F4 help.
9.3 Agent Determination (The Processor Rule)
95
9.3.1 Introduction to Agent Determination
EMMA/BPEM uses Agent Determination Rule to route cases to the appropriate agentrecipients according to the business rules you defined within the Rule. Rule resolutionenables the EMMA/BPEM engine to calculate who is the responsible agent for aparticular case based on runtime criteria.
When defining an agent determination rule, you must specify the following:
o Which information must be available so that rule resolution can be performed whenthe EMMA/BPEM case is executed.
This information constitutes the rule parameters. They are defined as elements ofthe rule container.
o The regulations in rule resolution that are used to determine the appropriate agents.
The rule resolution procedure is specified by the rule category.
There are different options for creating standard rules. You can use:
o Responsibility Rules
When rule resolution is performed, an assignment table is evaluated in whichOrganizational Management objects (jobs, positions, users, organizational units)are assigned to the various versions of the rule parameters. This assignment tablewas explicitly created during rule definition.
o Evaluation Paths
When rule resolution is performed, the system uses information that is availablein Organizational Management on the basis of relationships between individualobjects that are maintained in an organizational plan.
This information can be used, for example, if you need to determine the head ofan organizational unit, or the remaining members of the organizational unit,starting from the initiator of the workflow.
From a technical perspective, this rule resolution is a special case of the RuleType Agent Determination: Function to be Executed. You use the functionmodule RH_GET_STRUCTURE. In addition, you must enter an evaluation path.
o Function Modules
When rule resolution is performed, a function module is accessed that facilitatesevaluations as required. The function module evaluates a table that is maintained
96
in Customizing. The function module must adhere to a given interface, and isspecified during rule definition.
o SAP Organizational Objects
When rule resolution is performed, the system evaluates SAP organizationalobjects, such as materials controller, planner group, shipping point, or sales office,which are maintained in the master data of an application object.
This type of rule resolution requires the use of a separate maintenance transactionindependent of rule definition to create assignments between the SAPorganizational objects and the organizational objects in OrganizationalManagement (jobs, positions, users, organizational units) with which they arerelated.
Regardless of how the Rules are created, the principles of rule resolution are:
The contents of the rule container are read.The rules resulting from the rule category are applied to this data.The result of the rule resolution is returned in an internal table. In the case ofagent determination rules, this table contains the agents as OrganizationalManagement objects (user, person, position, job, organizational unit) in any order.
For this document we will be using ‘Responsibility Rules’ for Rule Resolution. Thereason for this is that the responsibility rules are easy to use, and often flexible enough tohandle most types of determination.
9.3.2 Agent Determination Example
For the routing to work, it is required that the organizational structure is defined in SAP.It is worth noting that there is no requirement for the company to be using HR for anyother reason. The structure can be built for the sake of the routing only.
The example we will be using here is forwarding an error in billing to the back office,based on a rule where monthly accounts go to one group and quarterly accounts go to asecond group of back-office clerks. This example is from ISU.
The concept for the agent determination definition is quite simple. With transactionPFAC you create the ‘agent determination object’. The key components are thedetermination of what data elements should be used in the agent determination and whichpositions / users should be defined as the possible agents.
97
For our example of dividing the work between monthly and quarterly clerks, we can usethe naming convention of the MRU on the installation. If the MRU has a ‘Q’ in the nameit is a quarterly account and if it has an ‘M’ in the name it is a monthly account. This is anexample only.
9.3.3 Definition of the Responsibility Rule
Go to transaction: PFAC
Initial Screen:
Click the ‘Create’ button. Internal numbering will be used.
Note: SAP provides a set of Rules for use too. This document describes how to createnew rules (agent determination) for the project’s specific needs.
9.3.3.1 Create the Rule
Basic Data Field Grouping:Type in the abbreviation for the rule name (Abbr.) and the long name. Then click on thedrop down for ‘Category’ and select ‘Agent Determination: Responsibilities’.
Then hit ‘Enter’
Four Tabs will now be displayed. Different tabs display depending on the Categoryselected in the previous step.
As you will see, there are now four tabs, the ‘Responsibility’ tab was added because ofthe category. Previously, we had the tabs: Rule Definition, Description and Container.
The next step is to add the data fields we are going to use to perform the determination.These fields are added on the ‘Container’ tab.
Click on the ‘Create’ button. A pop up window will be displayed.
Enter data in the following fields: Element: The ‘Element’ name is free formName and Short Description: In our case we will call them all ‘MRU’.
98
ABAP Dict. Reference (Type Tab): Select the radio button for this Selection ofPredefined Types. For the actual MRU field, we have the MRU in table EANLH, fieldABLEINH.
Then click the ‘OK’ button.MRU is now displayed on the Container Tab.
9.3.3.2 Rule Definition
The next step is definition of the rule, and who gets the work item based on the rule. Thisis defined on the ‘Responsibilities’ tab.
When moving to a new tab, you might be asked if you want to save. Say ‘yes’ and thenyou will be prompted for a package name. If this is just a test configuration then it can becreated as a local object, otherwise you will have to create a package in SE80 before youare able to save.
After this, you should be on the ‘Responsibilities’ tab.
For our example the outcome of the determination could have two possibilities. Either itgoes to the monthly clerk or to the quarterly clerk. In this view we have to create 2 sets ofresponsibilities and link each to a type of clerk.
First we will define the monthly clerk – select the ‘create’ button on the toolbar.
Enter values in the fields as follows:
Object abbreviation is defaulted to the name we gave the agent determination object.Since we need more than one rule, change it to ‘Monthly’.Name: This field can be changed to match the two distinct responsibilities being created.Start Date and End Date: The start date will have the system date and the end dateshould be 12/31/9999.Then click the ‘OK’ button.
A new screen will be displayed: Responsibility Display for Rule MONTHLY.
Click the Change button on the toolbar.
The data field we added for the container (MRU) is automatically listed as an option forthe determination. The field is a ‘from – to’ field, but can also be used as a single value.
99
To add more lines for the MRU field, click the green ‘Plus’ button (new row) on thetoolbar. Enter several MRUs from the system in which you are working.
Click ‘Save’ and the red status button on the top of the screen should turn green.
Return to the initial ‘Responsibility’ screen. The responsibility we entered previously forMONTHLY has a green status indicator with the text: responsibility complete.
We now have one defined responsibility. We repeat this option for the quarterly account.The only difference is that we use other values. for the MRU fields, and we name thisresponsibility: ‘Quarterly’.
After this is done the ‘Responsibility’ tab should display two completed responsibilities.
Now we need to assign the person or persons who should get the work item in the inbox.
First mark the Monthly line and then click on the ‘Insert agent assignment’ icon .
A pop-up window will display with the organization structure elements:Work CenterJobOrganizational unitPersonPositionUser
We now have to select the type of HR object to which we would like to assign the task.For this simple test we will assign it to a user, since this is easy to test. In real life, itwould most likely be assigned to a position.
Click on the icon for ‘User’ – then you get a normal search screen and you can search forthe user ID.
Select the correct user and click the ‘Create’ button.
You will be returned to the responsibility tab, we now have an arrow opposite themonthly rule. If we expand the node, we see the assigned agent.
Now we repeat this with a user for the quarterly rule.
100
At this point the agent determination is finished. If we back out to the initial creationscreen, we can also see that the system has created a number for our agent determination:
9.3.3.3 Agent Determination Testing
It is possible to test the agent determination just created, without having to link it to aprocess. Go into the agent determination screen in display or change mode and then pressSHIFT + F8.
A pop up window will be displayed. There are two sections on the screen.
Rule Container for Runtime:We have an input field for the MRU (the container element)Enter one of the specified MRUs from the rule definition and then click the ‘OK’ button.
Rule Resolution Result:The user flagged as responsible for the MRU will be displayed in the Agent ID field inthis section.
The Processor Rule must now be entered in the Clarification Case Category.
IMG financial Accounting Contract Accounts Receivable and Payable BasicFunctions Enhanced Message Management Specifications for GeneratingClarification Cases Maintain Clarification Case Categories Change ClarificationCase Category (or transaction code: EMMACCAT2)
The final steps are the binding steps (below) which will document the assignment of theagent determination to the case category.
9.3.4 Binding of Agent Determination
The binding is the configuration of linking data from one object to another object.
The data initially available for EMMA/BPEM are the objects and the data available basedon the primary object for the exception and the message pool.
The main object for most billing exceptions is the Installation, called the ’PrimaryBusiness Object’. In the configuration for the EMMA/BPEM case, some messages may
101
have additional variables present in the message text. For example, the contract object isoften a variable in billing exceptions.
The result is that when the case is triggered, the Installation object and the Contractobject are transferred to the message pool. These two objects can then be used as the startto either attach other objects in the data container or create the binding (link) to the agentdetermination rule and the processing rules.
We will continue the example from above. We had defined MRU as the data field for theagent determination. We will assume we have the two objects: Installation and Contractavailable to use for the linking since this is a common set of objects in ISU billingexceptions.
First we assign the agent determination to our case. This is done on the Basic Data tab:
In the field ‘Processor Rule’ we add the agent determination ID that we created earlier.To the right we click on the binding icon . (Note: the agent responsibility rule wedefined can be displayed from this tab as well by clicking on the Display Standard Ruleicon: )
The Binding screen is divided into 3 areas.On the top left section we have the ‘Case Container’. This represents all the objects anddata fields we have available to bind from.
On the top right we have the ‘Processor Rule’ and here we have all the fields that weneed to supply with a data field from the Case Container.
The bottom part of the screen is where we see what bindings have been configured.
MRU is already displayed on the upper right because we allocated this field for the agentdetermination rule. We also know that MRU is a data field on the installation object. Tofind this field we drill-down on the Installation object in the Case Container by clickingon the arrow on the left.
For our needs we will locate the MRU. Once the Installation (EMMA_MainObj) hasbeen expanded, we can see the value: ‘ActReadUnit’ and on the right we see the text‘Current Meter Reading Unit’. Since we know that the MRU is time sliced this dataelement is automatically the current MRU, and the one we need for our binding. The iconon the left ( ) tells us this is the Object for the MRU, and since we need the MRU ID,we need to expand this node by clicking on the arrow:
102
Here we see the ‘MeterReadingUnit’ which is the field we need Fields are indicated bythe icon: .
Performing the bindings is done using ‘drag and drop’. First click on theMeterReadingUnit field value within the ActReadUnit in the Case Container (on the left-hand side).
Then drag it down to the ‘Case Container’ field on the lower left in the Data Flow CaseContainer -> Processor Rule.
Now we have the ‘from’ field defined. Then we perform the same steps for the ‘ProcessorRule’ container. Drag the MRU variable in that section (upper right-hand area) down tothe lower right side.
At this point we have configured the binding for our agent determination. To test if wehave errors – click the ‘Check’ icon.
If no errors display, then click the ‘OK’ button, and we are taken back to the ‘Basic Data’tab for the case.
9.4 BAPI (Business Application Programming Interfaces)
SAP has introduced object-oriented technology by making SAP processes and dataavailable in the form of SAP business objects.
External applications can access SAP business objects through Business ApplicationProgramming Interfaces (BAPIs) which are standardized, platform-independentinterfaces. The SAP Business Objects and their BAPIs provide an open, object-orientedview of the business processes and data in an SAP System.
The SAP business objects stored in the Business Object Repository (BOR) encapsulatetheir data and processes. External access to the data and processes is only possible bymeans of specific methods using BAPIs (Business Application Program Interfaces).
The BAPIs in the SAP Systems are currently implemented as function modules, whichare created and managed in the Function Builder. Each function module underlying aBAPI:
Supports the Remote Function Call (RFC) protocolHas been assigned as a method to a SAP business object type in the BusinessObject Repository
103
Is processed without returning any screen dialogs to the calling application
The graphic below shows the relationship between an SAP business object type, itsassociated BAPIs and its function modules.
Business Object Type with BAPIs and Associated Function Modules
This architecture enables SAP to change the implementation of a BAPI without affectingexternal applications that are using the BAPI.
Using a BAPI
To use a BAPI method to access data in SAP business objects, an application programonly needs to ‘know’ how to call the method. The following information is required:
The name of the BAPIDetails of the BAPI interface:
Import parameters, which contain data to be transferred from the calling programto the BAPIExport parameters, which contain data to be transferred from the BAPI back tothe calling programImport/export (table) parameters for both importing and exporting data.
104
Application programmers can work with SAP business objects and implement theirBAPIs without needing to know or consider the underlying implementation and codingdetails for the object.