Sunteți pe pagina 1din 13

1 1.1.1.1

1 1.1.1.1 Utilities Process Framework Process Control for Utilities CRM Documents SAP AG Dietmar-Hopp-Allee 16 D-69190

Utilities Process Framework

Process Control for Utilities CRM Documents

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

Utilities Prozess-Framework

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

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

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

Utilities Prozess-Framework
Utilities Prozess-Framework Figure 1: Software Layer with Use of CRM UI Framework Implementing the process triggers

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

Utilities Prozess-Framework
Utilities Prozess-Framework Figure 2: Process Manager and Software Layer The Process Manager instance is explained in

Figure 2: Process Manager and Software Layer

Figure 2: Process Manager and Software Layer The Process Manager instance is explained in chapter 2.2.

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

Utilities Prozess-Framework
Utilities Prozess-Framework Figure 3: Overview and Interaction of Process Framework Entities Process Manager: The process

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,

Utilities Prozess-Framework

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 Industry- Specific 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

Utilities Prozess-Framework

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

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 process-

specific, 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

Utilities Prozess-Framework

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.

first, followed by the methods of the item level class. Figure 4: Enhancement Options Using Process

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 non- implemented 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

Utilities Prozess-Framework

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

Utilities Prozess-Framework

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. One- click 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.