TABLE OF CONTENTS
- Introduction.
- What is a Process Framework?.
- Define Process.
- Business Roles and Process Profile.
- Architecture Overview.
- Enhancement Options / Customer-Specific Process Implementation.
- Related Content.
Introduction.
This document aims at understanding the Process Framework with respect to Processes used in Contract Management area of SAP CRM for Utilities.
What is a Process Framework ?
The Process Framework developed by SAP, can be used to adjust the appearance and application flow of the processes in SAP. Specific functions in the Process Framework are particularly useful in Contract Management Processes in SAP CRM for Utilities. We can make the relevant configurations in Customizing. Moreover we can create our own processes or copy SAP standard processes and adapt them to our needs. 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.
Customizing Involved in Process Framework
All the SPRO customizing related to Process Framework are defined/maintained at the below path:
SPRO->Customer Relationship Management->Industry-Specific Solutions ->Utility Industries->Settings for User Interfaces->Transaction Processing->Processes
Define Process
Following are the two important parameters required to define a Process in the Process Framework:
- Process Category
- Process Class
Process Category
Each Process defined in the Process Framework has to be associated to a Process Category. 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 below screenshot shows the existing Process Category (for New Contracts) in the SPRO.
Process Classes
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, pre-assignment 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.
Process Reasons
Process reasons allow 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 Cancel Contract process, a user can define a process reason to specify the reason for cancelling the Contract.
Process reasons allow 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 Cancel Contract process, a user can define a process reason to specify the reason for cancelling the Contract.
After the Process Reasons are defined in the customizing, it needs to be associated with the Process Category. Below screenshot shows how this can be done in SPRO:
Subsequent Process:
We can link processes to a process chain. To do this, we allocate a subsequent process category or a subsequent process ID to a process in Customizing. 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.
Business Roles and Process Profile.
Defining the Process Profile
After defining the Process in the Process Framework, the same needs to be associated to a Process Profile. The Process Profile is then associated a Business Role. Mentioned below are the steps on how to associate a Process Profile to a Business Role :
Define the Process (as already described earlier)
Process Profiles can be defined as shown below:
After defining the Process Profile as shown above, processes can then be assigned to the profile. The below screenshot shows the Process assigned to the Process Profile “Default”:
Assigning the Process Profile to Business Role:
The Process Profile with the relevant processes assigned can then be assigned to the Business Role as shown below:
Go to the transaction: CRMC_UI_PROFILE and then select the required Business Role (in this case UTIL_IC_REG )
After selecting the Business Role, double on the “Assign Function Profile” in the left panel. Then navigate to the relevant Function Profile (IUPROCESS: Function Profile for Utilities Process).
The Profile Value already defined above in Point 4, now can be assigned to the Function Profile as shown in the screenshot above.
Architecture Overview
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. 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.
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.
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”, 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.
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, the end time, the user name, and the 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.
Enhancement Options / Customer-Specific Process Implementation.
Overview
The process implementation class is the core of a process in the Utilities Process Framework. We can implement checks for the executability of a process, pre-assignment 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, we can enhance or replace the implementation classes provided by SAP with customer-specific classes. This allows us 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, we 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.
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
pre-assignment 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.
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 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 are 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 pre-assignments 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.
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.
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.
Related Content
SAP Customer Relationship Management
Best Practices for SAP CRM Web UI Customization
For more information, visit Customer Relationship Management homepage
- SAP Managed Tags:
2 Comments
