Utilities Prozess FW En

1..1.1.1.1

Utilities Process FrameworkProcess Control for Utilities CRM Documents

SAP AGDietmar-Hopp-Allee 16

D-69190 Walldorf

Utilities Prozess-Framework

2

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 theexpress 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 softwarecomponents of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of MicrosoftCorporation.

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 aretrademarks 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 registeredtrademarks 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 aretrademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide WebConsortium, 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 technologyinvented 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 aretrademarks or registered trademarks of SAP AG in Germany and in several other countries all over theworld. All other product and service names mentioned are the trademarks of their respectivecompanies. Data contained in this document serves informational purposes only. National productspecifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG andits affiliated companies ("SAP Group") for informational purposes only, without representation orwarranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to thematerials. The only warranties for SAP Group products and services are those that are set forth in theexpress warranty statements accompanying such products and services, if any. Nothing herein shouldbe construed as constituting an additional warranty.


3

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


4

1 MotivationThe 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-specificCustomizing 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 andexecute the processes.For more information about the business transaction see SAP Help Portal at http://help.sap.com underSAP Business Suite -> SAP Customer Relationship Management -> Basic Functions -> BusinessTransaction.

In contrast to the object-based procedure in classical document processing, the definition of processesfollows a new approach which focuses particularly on the enhancement of customer projects. Theprocess 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 auser interface. It is important that the process control can be implemented easily in the SAP CRMWebUIs and in the call center interface. Suitability for mass processes and batch processing is not inscope for the Utilities Process Framework.

2 Architecture Overview

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

http://help.sap.com/


5

Figure 1: Software Layer with Use of CRM UI Framework

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


6

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 handlermethods 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 aderegulation scenario. The newly selected product is checked for market communication relevance inthe corresponding method ON_PRODUCT_CHANGED. This involves an item category check and, ifnecessary, generation of the required communication data.

2.2 Overview of the Main EntitiesA number of different entities play a central role within the Utilities Process Framework. This isexplained in greater detail in this section.


7

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 accessto 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 virtualconnection 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. ThisBOL entity is a BOL wrapper which provides the functionality of the process manager asimplementation class CL_CRM_IU_PROC_MGR_ENTITY derived from the standard BOL entity classCL_CRM_BOL_ENTITY. The user interface application uses the factory method GET_INSTANCE todetermine the instance of the BOL entity. With BOL relation “IsuProcessMgrProcessRel” (also seecorresponding model of genIL component ISUORD), the available processes can then be listed asdependent 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 necessarilycorrespond to a document header, as a process can include items from different documents. Theprocess implementation classes correspond exactly to these two entities. This means that themethods for the process header are called once only for each process, and the methods for theprocess 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 acontainer, which you can access from the UI and from the process implementation class (see section3.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 aprocess starts or ends. This means that you can evaluate the entries during processing. The start time,


8

the end time, the user name, and the process reason (see section 3.7 Process Reason) selected bythe 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 ornotifications.

Process Customizing:

Process Customizing is accessed centrally and evaluation is profile-dependent. This ensures that thecorrect customer-specific processes are selected. Class CL_CRM_IU_PROCESS_CUST contains allaccess data.

3 Definition of Processes

3.1 OverviewYou 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 creatingprocess profiles.

The definition of a new process starts with the selection or definition of a process category (seesection 3.2 Process Categories). The process category is the connection to the user interface and issimilar to a BAdI definition. In the same way as a BAdI implementation, the process definition (processID) can be replaced by a customer-specific process profile.

Once you have created the process category, you can create the process definition (process ID). Thedescription of the process also appears later on the generic user interface. The process category mustbe 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 inthe generic user interface when the process is running.

The allocation of the process implementation classes is of critical importance. The classes control theprocess 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 classcan be entered in the new customer process definition.

The process profile combines the process definitions available within a user role. The function profileIUPROCESS is used for the allocation of the process profile to the user role. This allows you to usedifferent process definitions in different scenarios or user groups. It is important that subsequentprocesses are also defined in the process profile. As a rule, processes can only be executed atruntime if they are contained in the process profile being used.

3.2 Process CategoriesThe 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 aprocess 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 allocatedto it. The structure determines the field set and allows reuse of the input help values defined in theDDIC.

The configuration structure for process category IUQA is the structureCRMT_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 processdefinition ID) as the subsequent process category. This allows more flexibility as the process definition


9

can also be replaced within the process chain depending on the profile. For more information aboutdefining process chains, see section 3.4 Subsequent Processes

You can allocate specific transaction types of the CRM business transaction document to processcategories in Customizing. The user is then offered a restricted list when selecting a change processfor a document. With this mechansim, processes can be tailored more individually to specifictransaction types.

3.3 Process Execution ModeYou can determine how processes run in execution mode. You can use the “One-Click Process” modeto execute complete processes simply by calling the START method (see section 4.2.1. CentralMethods). The appropriate FINISH method is executed automatically, which means that the processends directly rather than waiting for an instruction from the user interface. The one-click processes aretherefore used for simple processes such as setting a status in a document – so whenever theprocess does not require user interaction. Another area of use for the one-click process is in processchains in which multiple processes are executed in a predefined sequence (see section 3.4Subsequent Processes). Here, you can use a one-click process to include an interim step which canbe reused in multiple process chains. As a result, an adjustment to a one-click process in multiple usehas 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 thegeneric process interface the system offers those processes that were defined using the Process UserInterface or One-Click Process execution modes. The settings Own User Interface or BackgroundOne-Click Process prevent the option to select a process on the generic process interface. Suchprocesses must be executed using process-specific user interfaces (see section 5.2 Own ProcessInterface) or in the event of the background one-click process by using them in process chains (seesection 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, asof 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 ProcessesYou can link processes to a process chain. To do this, you allocate a subsequent process category ora subsequent process ID to a process in Customizing (if possible, enter the subsequent processcategory and leave the subsequent process ID empty - see section 3.2 Process Categories). Nowwhen the process starts and ends, the process framework automatically starts the appropriatesubsequent process. The process implementation controls the transfer of data to the subsequentprocess by registering the process items using method REGISTER_ITEM_GUID_4_FOLLOWUP ofthe process context interface for the subsequent process in question.

Only the complete process chain can be cancelled or ended in process execution. If a subsequentprocess contains errors or does not allow the process to be ended by the process implementation inmethod IS_COMPLETE, the preceding process cannot be ended either. The cancellation of asubsequent process also causes the automatic cancellation of the preceding process by calling theappropriate CANCEL methods.

Process chains are particularly suitable for linking two processes that are used with different processitems but are still dependent. This allows, for example, the copying of items to be divided into twoprocesses: First, the process is started, which duplicates the original items. The new items in thisprocess 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.


10

Another possibility for using process chains is the reuse of one-click processes. This allows you tocreate a one-click process that assigns a certain status to a process item. You can use a processchain 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 callsthe subsequent process Subsequent Product Change (PROD_CHANGE_PAR2) as standard in theinteraction center.

3.5 Process ConfigurationThe process configuration allows you to configure processes individually or dependent on the processprofile. In Customizing, you can assign configuration structures to process categories (see section 3.2Process Categories). The components of the structure are then available as configuration parametersin process Customizing. Corresponding input help values are offered from the DDIC definition of theconfiguration structure.

In the process implementation class, you can use method GET_CONFIG_VALUE in the processcontext interface to get the current value of a configuration parameter at runtime. The UI can alsoaccess the configuration parameters by determining the value of a generic attribute with a parametername with the format CONF_<Configuration Parameter Name> (for exampleCONF_TRANSACTION_TYPE) for the process entity.

3.6 Process Context ContainerThe process context container allows the process implementation class to temporarily store dataduring processing. You can use the process context interface to access the data. Here, the methodSET_CONTAINER_VALUE or GET_CONTAINER_VALUE can provide a name and a generic datatype. You also have the option of storing data for a certain item by transferring the respective GUID tothe methods. This allows you to store item-specific data and cross-item data, which can be accessedfrom 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 ofthis is the creation of a document in the process header implementation class. The GUID of thedocument is stored in the process context container so that the item implementation class can accessit. 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 tobe transferred to a subsequent process, you can use the optional parameterTRANSFER_TO_FOLLOWUP of method SET_CONTAINER_VALUE to activate the transfer of thevalue. The UI can also access the process context container data by determining the value of ageneric attribute with a parameter name with the format CTXT_<Context Container Name> (forexample CTXT_HEADER_GUID) for the process entity.

3.7 Process ReasonsProcess reasons allows users to specify the reason for executing a process. They are allocated to theprocess category in Customizing. The process reason with the lowest sequence number is used asthe default value at runtime. Process reasons are written to the process log so that they can beevaluated at a later point as the process log remains as an enhancement of the standard CRMbusiness transaction document. For example, during a product change process, a customer candefine a process reason to specify the reason for changing products. This could be to change to amore 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 processBOL entity (type IsuProcess) is used to access the current value.

4 Enhancement Options / Customer-Specific


11

Process Implementation

4.1 OverviewThe process implementation class is the core of a process in the Utilities Process Framework. You canimplement checks for the executability of a process, preassignment of data in a document, andcompleteness of data by means of a defined interface in the form of IF_CRM_IU_PROCESS orIF_CRM_IU_PROCESS_HEAD. In Customizing, you can enhance or replace the implementationclasses provided by SAP with customer-specific classes. This allows you to derive the SAP classes toimplement additional checks or exchange entire processes.

Both interfaces allow implementations at process header level (IF_CRM_IU_PROCESS_HEAD asimplementation interface for process header) and/or at process item level (IF_CRM_IU_PROCESS foreach document item). Therefore, depending of the requirements of the process, you can decide thelevel at which an implementation is necessary. If, for example, you want the process to react to achange of the allocated product for each item, the item implementation class is more suitable. For asimple status change process, the implementation class at header level is sufficient. It is also possibleto combine the two implementation approaches. In this case, the methods of the process headerimplementation 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 InterfaceThe process implementation is primarily based on the implementation of a predefined interfaceIF_CRM_IU_PROCESS_HEAD for the process header implementation or IF_CRM_IU_PROCESS forthe 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. Thesebasic 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 layeris available. You can determine this from the interface method IS_BOL_SUPPORTED of the processcontext 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


12

ensures that any BOL buffer is updated. This update can be explicitly triggered at any time using theprocess 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 MethodsThe process implementation classes implement the interface IF_CRM_IU_PROCESS_HEAD orIF_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 theinstance of the process log access as import parameters. This ensures that the current data such asthe items to be processed (GET_CURRENT_ITEM_GUID), the process context container, or theprocess 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. Themethod 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 regardingthe executability of a process. The return parameter SUCCESS can be used in the form of aboolean value to release the process so it can be started. It is not possible to start a process if thismethod returns the value ABAP_FALSE. The standard implementation of basic classCL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS returns the value ABAP_TRUE. Themethod is called implicitly when the START method is called.

START: The START method is the defined time at which the process flow begins. Thepreassignment of process items can take place here. In the event of an error, the method is exitedby 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 rolledback into it by the FINISH method. The implementation of the basic classesCL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESS calls the CANCEL method from theREVERT_START method.

IS_COMPLETE: This method allows the process implementation to check whether the processcan be ended. This ensures consistency in process execution. The return parameter SUCCESScan be used in the form of a boolean value to release the process so it can be ended. It is notpossible to end a process if this method returns the value ABAP_FALSE. The standardimplementation of basic class CL_CRM_IU_PROCESS_HEAD or CL_CRM_IU_PROCESSreturns 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 datecan be set here for the process items. In the event of an error, the method is exited by means ofthe appropriate exception to the interface of the method. If processing is cancelled, the methodREVERT_FINISH is called and any changes made before the cancellation are rolled back into itby the FINISH method.

CANCEL: If the user cancels a process, the CANCEL method of the process implementation classis called. Changes that have already been made can be reversed here resulting in the originalstate before execution of the process.

4.2.2 Event Handler MethodsIf changes are made to the CRM document or to the items in the document, different events aretriggered by the CRM document framework (business transaction). These events (such as “DateChanged”) are usually handled by event handler function modules. However, as no processinformation is available in these function modules (this means the function module must first determinewhich process could have been executed), a correct and process-specific reaction to these types ofevent is difficult and likely to result in errors.

With the event handler methods of the process implementation classes, the process frameworkenables a process-specific reaction to the CRM document events. This allows you to activate a


13

specific additional check, or to generate required data is certain situations (for example, the generationof 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 andthe 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 tothe 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 documentbeing 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 methodON_ITEM_REMOVED is called to enable the implementation to react accordingly and releaseinternal 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 SequenceAs a rule, the methods of the process header implementation classes are called first. If execution issuccessful (SUCCESS <> ABAP_FALSE, or no exception triggered), the method of the process itemimplementation class is called for each process item in the process context. If an exception istriggered during item processing, the corresponding REVERT_* method is called for the items thathave already been processed and then the REVERT_* method of the process header implementationclass is called. In this way, the REVERT and CANCEL methods differ from the general rule of “processheader before process item” to allow the changes to be rolled back correctly.

5 User Interface

5.1 Generic Process InterfaceThe 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 madeavailable to users. With the latter, the process views defined in Customizing and the process viewsallocated 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. Theselection of a process reason is also made available automatically.

The implementation of a process for the generic process interface takes place exclusively by thedefinition of the process in Customizing, implementation of the process implementation classes and, ifnecessary, the creation and allocation of the process view.

5.2 Separate Process InterfaceA separate process UI can be implemented for complex processes. An example of such a processinterface is Contract Management in the call center. Here, multiple processes and process items aremanaged in parallel. Such complexity cannot be mapped in a generic process UI. The implementationof such a process requires the implementation of the entire user interface, and the process control inparticular. You can also use the BOL entities IsuProcessMgr and IsuProcess of genIL componentISUORD. The methods and relationships of these entities are used to start, cancel, and endprocesses (see execute methods in transaction GENIL_MODEL_BROWSER). The methods of theentities correspond to the methods of the process manager interface.

Utilities Prozess FW En

Documents

Transcript of Utilities Prozess FW En