1..1.1.1.

Utilities Process Framework

Process Control for Utilities CRM Documents

SAP AG
Dietmar-Hopp-Allee 16
D-69190 Walldorf

Utilities Prozess-Framework

Copyright
Copyright 2008 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft
Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z,
System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS,
S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture,
POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,
BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2,
Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are
trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered
trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are
trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web
Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign,
and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the
world. All other product and service names mentioned are the trademarks of their respective
companies. Data contained in this document serves informational purposes only. National product
specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and
its affiliated companies ("SAP Group") for informational purposes only, without representation or
warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the
materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should
be construed as constituting an additional warranty.

Utilities Prozess-Framework

Contents
Copyright .....................................................................................................................................2
1.

Motivation...............................................................................................................................4

2.

Architecture Overview.............................................................................................................4
1.1

Software Layer .......................................................................................................................4

1.2

Overview of the Main Entities..................................................................................................6

3.

Definition of Processes ...........................................................................................................8

1.3

Overview................................................................................................................................8

1.4

Process Categories ................................................................................................................8

1.5

Process Execution Mode ........................................................................................................9

1.6

Subsequent Processes...........................................................................................................9

1.7

Process Configuration ..........................................................................................................10

1.8

Process Context Container...................................................................................................10

1.9

Process Reasons .................................................................................................................10

4.

Enhancement Options / Customer-Specific Process Implementation.....................................10

1.10

Overview..........................................................................................................................11

1.11

Enhancement Interface ....................................................................................................11

1.11.1

Central Methods...........................................................................................................12

1.11.2

Event Handler Methods................................................................................................12

1.11.3

Call Sequence..............................................................................................................13

5.

User Interface.......................................................................................................................13
1.12

Generic Process Interface ................................................................................................13

1.13

Separate Process Interface ..............................................................................................13

Utilities Prozess-Framework

1 Motivation
The Utilities Process Framework provides process control for utilities documents in SAP CRM.
Previously, it was not possible to start a dedicated process to preassign values, check start conditions,
and allow easily adaptable enhancements in documents in accordance with process-specific
Customizing or a process-specific implementation.
The CRM business transaction document forms the basis of the Utilities Process Framework.
This document provides persistence for process logging as well as the data used to define and
execute the processes.
For more information about the business transaction see SAP Help Portal at http://help.sap.com under
SAP Business Suite -> SAP Customer Relationship Management -> Basic Functions -> Business
Transaction.
In contrast to the object-based procedure in classical document processing, the definition of processes
follows a new approach which focuses particularly on the enhancement of customer projects. The
process view allows specific checks to be implemented and modified easily by customers.
The main objective during the development of the process framework was to integrate processes in a
user interface. It is important that the process control can be implemented easily in the SAP CRM
WebUIs and in the call center interface. Suitability for mass processes and batch processing is not in
scope for the Utilities Process Framework.

2 Architecture Overview
2.1

Software Layer

The Utilities Process Framework was designed as a parallel layer to the UI, BOL, and API. The UI
uses dedicated methods provided by the process framework to control the processing of document
items. The processing of UI requests is delegated to the appropriate methods of the process
implementation classes. Here, the standard CRM business transaction API and the corresponding
BOL entities can be used to access data. This allows simple and above all customer-oriented use of
the various APIs. The process framework makes sure that the BOL buffer always reacts to changes at
API level and that it is adjusted or invalidated as required.

Utilities Prozess-Framework

Figure 1: Software Layer with Use of CRM UI Framework

Implementing the process triggers actions relating to the CRM business transaction data, and reacts
to events triggered by background changes at API level. This allows an individual reaction to a change
to product, a date, or a point of delivery allocation. As the implementation is process-specific, there are
different reactions to these events depending on the active process. The previous method of making
customer-specific adjustments using BAdI implementations, which could only be implemented
reactively, is now more flexible as a result of this process orientation.

Utilities Prozess-Framework

Figure 2: Process Manager and Software Layer

The Process Manager instance is explained in chapter 2.2.

In the process implementation classes, the new and old data is provided by special event handler
methods so that the process requests can be dealt with accordingly.
One example of this in a utilities environment is the generation of market communication data in a
deregulation scenario. The newly selected product is checked for market communication relevance in
the corresponding method ON_PRODUCT_CHANGED. This involves an item category check and, if
necessary, generation of the required communication data.

2.2

Overview of the Main Entities

A number of different entities play a central role within the Utilities Process Framework. This is
explained in greater detail in this section.

Utilities Prozess-Framework

Figure 3: Overview and Interaction of Process Framework Entities

Process Manager:
The process manager is the central controlling unit within the Utilities Process Framework. All access
to the UIs takes place via the process manager in a special interface (IF_CRM_IU_PROCESS_MGR).
The process manager instance also defines all document items to be used in processes. This virtual
connection means that items from different documents can be used together in one process.
You can use the process manager in the UI layer by means of the BOL entity IsuProcessMgr. This
BOL entity is a BOL wrapper which provides the functionality of the process manager as
implementation class CL_CRM_IU_PROC_MGR_ENTITY derived from the standard BOL entity class
CL_CRM_BOL_ENTITY. The user interface application uses the factory method GET_INSTANCE to
determine the instance of the BOL entity. With BOL relation IsuProcessMgrProcessRel (also see
corresponding model of genIL component ISUORD), the available processes can then be listed as
dependent BOL entities of category IsuProcess.

Process Header and Process Item

Process header and process item refer to the virtual representations of the process as an object
(object header) and the document item (process item). The process header does not necessarily
correspond to a document header, as a process can include items from different documents. The
process implementation classes correspond exactly to these two entities. This means that the
methods for the process header are called once only for each process, and the methods for the
process item are called for each document item contained in the process.

Process Context:
The process context defines the context data for a process. You can temporarily store parameters in a
container, which you can access from the UI and from the process implementation class (see section
3.6 Process Context Containers).
Process Log and Log Access:
The process log allows you to log process execution. An entry is made in the process log every time a
process starts or ends. This means that you can evaluate the entries during processing. The start time,
7

Utilities Prozess-Framework

the end time, the user name, and the process reason (see section 3.7 Process Reason) selected by
the user are all entered in the log.
If a process is cancelled by the user, it does not appear in the process log.
The process implementation classes also have access to the process log and can add messages or
notifications.
Process Customizing:
Process Customizing is accessed centrally and evaluation is profile-dependent. This ensures that the
correct customer-specific processes are selected. Class CL_CRM_IU_PROCESS_CUST contains all
access data.

3 Definition of Processes
3.1

Overview

You define the processes in Customizing for Customer Relationship Management under IndustrySpecific Solutions
Utility Industry
Settings for User Interface
Transaction Processing
Processes. Here you make the settings for configuring processes, registering required UIs, or creating
process profiles.
The definition of a new process starts with the selection or definition of a process category (see
section 3.2 Process Categories). The process category is the connection to the user interface and is
similar to a BAdI definition. In the same way as a BAdI implementation, the process definition (process
ID) can be replaced by a customer-specific process profile.
Once you have created the process category, you can create the process definition (process ID). The
description of the process also appears later on the generic user interface. The process category must
be allocated to the new process definition, and it determines the process configuration parameters.
Process views can also be allocated to the process definition. They are then included dynamically in
the generic user interface when the process is running.
The allocation of the process implementation classes is of critical importance. The classes control the
process execution and can be replaced with customer-specific implementation classes in particular.
This requires the SAP process definition to be copied. The appropriate customer implementation class
can be entered in the new customer process definition.
The process profile combines the process definitions available within a user role. The function profile
IUPROCESS is used for the allocation of the process profile to the user role. This allows you to use
different process definitions in different scenarios or user groups. It is important that subsequent
processes are also defined in the process profile. As a rule, processes can only be executed at
runtime if they are contained in the process profile being used.

3.2

Process Categories

The profile category is the central access ID during execution of a process. In certain circumstances,
the different UIs use a hard-coded process category call to start processes. You should never use a
process definition ID directly for programming as it can be replaced with the process profile.
An example for a process category is the category IUQA for accepting quotations.
The process category is also used to determine the configuration structure of the processes allocated
to it. The structure determines the field set and allows reuse of the input help values defined in the
DDIC.
The configuration structure for process category IUQA is the structure
CRMT_IU_PROC_CONF_STRUCT_IUQA with the components Transaction Type (PROCESS_TYPE)
and Switch Action Group (SWT_MSG:GROUP).
When defining process chains, you should also enter the process category (and not the process
definition ID) as the subsequent process category. This allows more flexibility as the process definition
8

Utilities Prozess-Framework

can also be replaced within the process chain depending on the profile. For more information about
defining process chains, see section 3.4 Subsequent Processes
You can allocate specific transaction types of the CRM business transaction document to process
categories in Customizing. The user is then offered a restricted list when selecting a change process
for a document. With this mechansim, processes can be tailored more individually to specific
transaction types.

3.3

Process Execution Mode

You can determine how processes run in execution mode. You can use the One-Click Process mode
to execute complete processes simply by calling the START method (see section 4.2.1. Central
Methods). The appropriate FINISH method is executed automatically, which means that the process
ends directly rather than waiting for an instruction from the user interface. The one-click processes are
therefore used for simple processes such as setting a status in a document so whenever the
process does not require user interaction. Another area of use for the one-click process is in process
chains in which multiple processes are executed in a predefined sequence (see section 3.4
Subsequent Processes). Here, you can use a one-click process to include an interim step which can
be reused in multiple process chains. As a result, an adjustment to a one-click process in multiple use
has an effect on all process chains it is used in, thus making maintenance easier.
Execution mode also controls the visibility and selectability of processes on the user interface. On the
generic process interface the system offers those processes that were defined using the Process User
Interface or One-Click Process execution modes. The settings Own User Interface or Background
One-Click Process prevent the option to select a process on the generic process interface. Such
processes must be executed using process-specific user interfaces (see section 5.2 Own Process
Interface) or in the event of the background one-click process by using them in process chains (see
section 3.4 Subsequent Processes).
Examples:
Example for a one-click process: Accept quotation (QUOTATION_ACCEPT)
Example for a background one-click process: Complete contract (CONTRACT_CMPLT1C, as
of SAP CRM 7.0 EhP1
Example for a process with Process User Interface: Change end of contract
(CONTEND_CHANGE)
Example for a process with Own User Interface: Start contract (CONTRACT_START)

3.4

Subsequent Processes

You can link processes to a process chain. To do this, you allocate a subsequent process category or
a subsequent process ID to a process in Customizing (if possible, enter the subsequent process
category and leave the subsequent process ID empty - see section 3.2 Process Categories). Now
when the process starts and ends, the process framework automatically starts the appropriate
subsequent process. The process implementation controls the transfer of data to the subsequent
process by registering the process items using method REGISTER_ITEM_GUID_4_FOLLOWUP of
the process context interface for the subsequent process in question.
Only the complete process chain can be cancelled or ended in process execution. If a subsequent
process contains errors or does not allow the process to be ended by the process implementation in
method IS_COMPLETE, the preceding process cannot be ended either. The cancellation of a
subsequent process also causes the automatic cancellation of the preceding process by calling the
appropriate CANCEL methods.
Process chains are particularly suitable for linking two processes that are used with different process
items but are still dependent. This allows, for example, the copying of items to be divided into two
processes: First, the process is started, which duplicates the original items. The new items in this
process are then registered for the subsequent process, which adds a special status to the new items,
for example. The advantage of this process chain is that the two parts can only be cancelled together,
thus avoiding inconsistencies.

Utilities Prozess-Framework

Another possibility for using process chains is the reuse of one-click processes. This allows you to
create a one-click process that assigns a certain status to a process item. You can use a process
chain to attach this process to different processes but you only have to implement it once.
Example:
An example for a process chain is the process Product Change in New Document
(PROD_CHANGE_NEW), for which PCH2 is defined as the subsequent process category that calls
the subsequent process Subsequent Product Change (PROD_CHANGE_PAR2) as standard in the
interaction center.

3.5

Process Configuration

The process configuration allows you to configure processes individually or dependent on the process
profile. In Customizing, you can assign configuration structures to process categories (see section 3.2
Process Categories). The components of the structure are then available as configuration parameters
in process Customizing. Corresponding input help values are offered from the DDIC definition of the
configuration structure.
In the process implementation class, you can use method GET_CONFIG_VALUE in the process
context interface to get the current value of a configuration parameter at runtime. The UI can also
access the configuration parameters by determining the value of a generic attribute with a parameter
name with the format CONF_<Configuration Parameter Name> (for example
CONF_TRANSACTION_TYPE) for the process entity.

3.6

Process Context Container

The process context container allows the process implementation class to temporarily store data
during processing. You can use the process context interface to access the data. Here, the method
SET_CONTAINER_VALUE or GET_CONTAINER_VALUE can provide a name and a generic data
type. You also have the option of storing data for a certain item by transferring the respective GUID to
the methods. This allows you to store item-specific data and cross-item data, which can be accessed
from the different process implementation classes (at process header level and process item level).
This mechanism also allows data to be transferred between the two implementations. An example of
this is the creation of a document in the process header implementation class. The GUID of the
document is stored in the process context container so that the item implementation class can access
it. Another example of data that can be stored in the process context container is a control indicator,
which the UI requires to influence the process flow. If you want a process context container value to
be transferred to a subsequent process, you can use the optional parameter
TRANSFER_TO_FOLLOWUP of method SET_CONTAINER_VALUE to activate the transfer of the
value. The UI can also access the process context container data by determining the value of a
generic attribute with a parameter name with the format CTXT_<Context Container Name> (for
example CTXT_HEADER_GUID) for the process entity.

3.7

Process Reasons

Process reasons allows users to specify the reason for executing a process. They are allocated to the
process category in Customizing. The process reason with the lowest sequence number is used as
the default value at runtime. Process reasons are written to the process log so that they can be
evaluated at a later point as the process log remains as an enhancement of the standard CRM
business transaction document. For example, during a product change process, a customer can
define a process reason to specify the reason for changing products. This could be to change to a
more ecological product or a better price, for example.
A list of possible process reasons is available on the generic user interface. If the UI is processspecific, you have to chose where to position the list on the UI. The REASON attribute of the process
BOL entity (type IsuProcess) is used to access the current value.

4 Enhancement Options / Customer-Specific

10

Utilities Prozess-Framework

Process Implementation
4.1

Overview

The process implementation class is the core of a process in the Utilities Process Framework. You can
implement checks for the executability of a process, preassignment of data in a document, and
completeness of data by means of a defined interface in the form of IF_CRM_IU_PROCESS or
IF_CRM_IU_PROCESS_HEAD. In Customizing, you can enhance or replace the implementation
classes provided by SAP with customer-specific classes. This allows you to derive the SAP classes to
implement additional checks or exchange entire processes.
Both interfaces allow implementations at process header level (IF_CRM_IU_PROCESS_HEAD as
implementation interface for process header) and/or at process item level (IF_CRM_IU_PROCESS for
each document item). Therefore, depending of the requirements of the process, you can decide the
level at which an implementation is necessary. If, for example, you want the process to react to a
change of the allocated product for each item, the item implementation class is more suitable. For a
simple status change process, the implementation class at header level is sufficient. It is also possible
to combine the two implementation approaches. In this case, the methods of the process header
implementation class are always called first, followed by the methods of the item level class.

Figure 4: Enhancement Options Using Process Implementation Classes

4.2

Enhancement Interface

The process implementation is primarily based on the implementation of a predefined interface

IF_CRM_IU_PROCESS_HEAD for the process header implementation or IF_CRM_IU_PROCESS for
the process item implementation. There is a corresponding abstract basic class
(CL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS) for each of the two interfaces. These
basic classes should be used for every process implementation class to protect them from nonimplemented methods during enhancement of the process interface.
BOL objects can be used within the methods of the implementation classes as long as the BOL layer
is available. You can determine this from the interface method IS_BOL_SUPPORTED of the process
context whose instance is transferred as an import parameter to every implementation class method.
Alternatively, you can use the regular API accesses of the CRM document. The process framework
11

Utilities Prozess-Framework

ensures that any BOL buffer is updated. This update can be explicitly triggered at any time using the
process context method TRIGGER_BOL_UPDATE. This takes place automatically after the START,
CANCEL, and FINISH methods.
It is possible to allocate both process implementation classes.

4.2.1 Central Methods

The process implementation classes implement the interface IF_CRM_IU_PROCESS_HEAD or
IF_CRM_IU_PROCES. The most important methods of process control are described below.
Each of these methods (except for INIT) has the instance of the process context as well as the
instance of the process log access as import parameters. This ensures that the current data such as
the items to be processed (GET_CURRENT_ITEM_GUID), the process context container, or the
process configuration can be accessed from the method implementation via the process context.
INIT: The INIT method is called on the first instantiation of the process implementation class. The
method allows you to prepare data for a process start, evaluate your Customizing data, and so on.
IS_EXECUTABLE: This method allows the process implementation to carry out checks regarding
the executability of a process. The return parameter SUCCESS can be used in the form of a
boolean value to release the process so it can be started. It is not possible to start a process if this
method returns the value ABAP_FALSE. The standard implementation of basic class
CL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS returns the value ABAP_TRUE. The
method is called implicitly when the START method is called.
START: The START method is the defined time at which the process flow begins. The
preassignment of process items can take place here. In the event of an error, the method is exited
by means of the appropriate exception to the interface of the method. If processing is cancelled,
the method REVERT_START is called and any changes made before the cancellation are rolled
back into it by the FINISH method. The implementation of the basic classes
CL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS calls the CANCEL method from the
REVERT_START method.
IS_COMPLETE: This method allows the process implementation to check whether the process
can be ended. This ensures consistency in process execution. The return parameter SUCCESS
can be used in the form of a boolean value to release the process so it can be ended. It is not
possible to end a process if this method returns the value ABAP_FALSE. The standard
implementation of basic class CL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS
returns the value ABAP_TRUE. The method is called implicitly when the FINISH method is called.
FINISH: The FINISH method is the end of a process. Final data such as a status or a specific date
can be set here for the process items. In the event of an error, the method is exited by means of
the appropriate exception to the interface of the method. If processing is cancelled, the method
REVERT_FINISH is called and any changes made before the cancellation are rolled back into it
by the FINISH method.
CANCEL: If the user cancels a process, the CANCEL method of the process implementation class
is called. Changes that have already been made can be reversed here resulting in the original
state before execution of the process.

4.2.2 Event Handler Methods

If changes are made to the CRM document or to the items in the document, different events are
triggered by the CRM document framework (business transaction). These events (such as Date
Changed) are usually handled by event handler function modules. However, as no process
information is available in these function modules (this means the function module must first determine
which process could have been executed), a correct and process-specific reaction to these types of
event is difficult and likely to result in errors.
With the event handler methods of the process implementation classes, the process framework
enables a process-specific reaction to the CRM document events. This allows you to activate a
12

Utilities Prozess-Framework

specific additional check, or to generate required data is certain situations (for example, the generation
of market communication data for the selection of a market-communication-relevant product).
The event handler methods of the process implementation classes also get the process context and
the process log access as import parameters. The old and the new data is transferred to the event.
The handler methods are generally only called for active processes and are automatically delegated to
the process implementation class (process header or process item) of the relevant item GUID.
The following event handler methods are available:
ON_ITEM_ADDED: This method allows you to react to a newly created item in the document
being processed. This means you can make preassignments or initial checks for the new item.
ON_ITEM_REMOVED: On deleting an item from the document being processed, the method
ON_ITEM_REMOVED is called to enable the implementation to react accordingly and release
internal buffers, for example.
ON_DATE_CHANGED: Event handler on changing a date for an item.
ON_PRODUCT_CHANGED: Event handler on selecting a new product for an item.
ON_POD_CHANGED: Event handler on changing a point of delivery allocation for an item.

4.2.3 Call Sequence

As a rule, the methods of the process header implementation classes are called first. If execution is
successful (SUCCESS <> ABAP_FALSE, or no exception triggered), the method of the process item
implementation class is called for each process item in the process context. If an exception is
triggered during item processing, the corresponding REVERT_* method is called for the items that
have already been processed and then the REVERT_* method of the process header implementation
class is called. In this way, the REVERT and CANCEL methods differ from the general rule of process
header before process item to allow the changes to be rolled back correctly.

5 User Interface
5.1

Generic Process Interface

The generic process interface allows you quickly start processes for individual document items. Oneclick processes as well as processes with the execution mode Process User Interface" are made
available to users. With the latter, the process views defined in Customizing and the process views
allocated to the process are determined dynamically and made available to the user.
Process control (pushbuttons to start, cancel, and end the process) is implemented generically. The
selection of a process reason is also made available automatically.
The implementation of a process for the generic process interface takes place exclusively by the
definition of the process in Customizing, implementation of the process implementation classes and, if
necessary, the creation and allocation of the process view.

5.2

Separate Process Interface

A separate process UI can be implemented for complex processes. An example of such a process
interface is Contract Management in the call center. Here, multiple processes and process items are
managed in parallel. Such complexity cannot be mapped in a generic process UI. The implementation
of such a process requires the implementation of the entire user interface, and the process control in
particular. You can also use the BOL entities IsuProcessMgr and IsuProcess of genIL component
ISUORD. The methods and relationships of these entities are used to start, cancel, and end
processes (see execute methods in transaction GENIL_MODEL_BROWSER). The methods of the
entities correspond to the methods of the process manager interface.

13