Ansicht
Dokumentation
CRM_IU_PR_PROF - Define Processes
BAL Application Log Documentation ABAP Short ReferenceThis documentation is copyright by SAP AG.
In this activity, you can define the processes of a process category, determine the parameters for a process, and allocate processes that use the generic user interface to previously defined process views. In this activity, you can also define process profiles and allocate them to the relevant processes.
Process Definitions
To define the process for a process category, choose Process Definitions in the dialog structure. In the corresponding Customizing table, first determine the process ID, allocate the process to a category, and enter a descriptive text for the process.
In this table, you can also enter process implementation classes that allow you to change how processes are controlled. To do this, you must implement interface IF_CRM_IU_PROCESS_HEAD (Control for Entire Process) or IF_CRM_IU_PROCESS (Control for Each Contract Item) in a customer-defined ABAP class. We recommend that you use the standard implementation classes provided by SAP as base classes for implementing customer-defined processes.
You also have the option to allocate a follow-on process or a follow-on category to the process. This allows you to specify that the relevant follow-on process starts immediately after ending the process. This is particularly useful for linking together individual activities for processes not on the user interface or for preceding a process on the user interface with a process that is not on the user interface.
In process execution mode, you can determine whether a process uses the generic user interface, a different user interface, or no user interface.
Process Configuration
Select a process and under Process Definitions select the Process Configuration folder to define the parameters for the process in question. The possible parameters are determined by the configuration structure of the process category. The process implementation class makes the selected parameters available during runtime. They can also be evaluated.
Allocate Views
If a process uses the generic user interface, you can choose Allocate Views to allocate previously defined process views. In the Ranking field, you define the order in which the process views allocated to the process are displayed. The view with the lowest ranking is displayed first.
Process Profiles
The process profile controls the selection and execution of contract and quotation processes. You use the process profile to define which processes a user is permitted to execute. To do this, you have to allocate the process profile as function profile IUPROCESS to the relevant user role. You define user roles in the Define User Roles activity.
Allocate Processes
Under Process Profiles, choose the Allocate Processes folder to allocate the permitted processes to a process profile. You can use the Ranking field to define what priority each process has on the user interface. The lowest value has the highest priority.
The ranking also determines which process is used during programmed access via the process category. This is especially the case for special user interfaces such as Contract and Quotation Management. For example, in the process "New Contract" with category IUMI, the starting process is the one to which you gave the lowest ranking value in the process profile.
The ranking also comes into effect when a follow-on process is started via the process category.
Check Repository in the Utilities Process Framework
The Utilities Process Framework can be used to process CRM documents using a standard interface. You can make Customizing settings here to control the process flow, perform configuration using parameters and use the corresponding implementation classes to create a customer-specific program logic. Previously, you could only assign one implementation class for each process at process header level and one implementation class at document item level. The enhancement option of assigning additional checks to a process was created by enhancing the source code for the corresponding methods in these classes. It was necessary to extend or modify the source code for the respective process implementation class for the respective events (such as IS_EXECUTABLE or ON_PRODUCT_CHANGED).
Introducing the check repository allows process-independent definition of checks. You can configure a check ID with a dedicated implementation class for each check in Customizing. The interface signature of the implementation class corresponds to the existing process implementation class methods IS_EXECUTABLE or IS_COMPLETE, which means that you can convert existing check routines by simply copying the source code.
Implementation and Configuration of Checks
The implementation class for a check ID must implement the interface IF_CRM_IU_PROCESS_CHECK. We recommend using the basic class CL_CRM_IU_PROCESS_CHECK for all check implementation classes. At runtime, the system stores the current check ID in the attribute IF_CRM_IU_PROCESS_CHECK~CHECK_ID.
The interface IF_CRM_IU_PROCESS_CHECK contains a CHECK method that can be used by the respective implementation class to implement the actual check routine. The process context (object for interface IF_CRM_IU_PROCESS_CTXT) and the access interface to the process log (interface IF_CRM_IU_PROCESS_LOG_ACCESS) are transferred as import parameters here. The check result can therefore be transferred to the user by displaying messages in the process log.
Check methods also transfer information about the event or context in which the check is executed. The import parameter EXECUTION_TIME contains the time at which the check is executed here; possible events are IS_EXECUTABLE , IS_COMPLETE, ON_PRODUCT_CHANGED, ON_POD_CHANGED, ON_DATE_CHANGED and ON_GENERIC_DATA_CHANGED. The import parameter VALIDATION describes whether the check ID is called before or after the corresponding methods in the process implementation class; the ASSIGNMENT parameter indicates whether the check ID was scheduled at process header or document item level. The relevant constants for the three import parameters are found in the interface IF_CRM_IU_PROCESS_CHECK.
You can use the return parameter RESULT to control the process flow. This means it is possible to prevent process execution or process completion for the events IS_EXECUTABLE and IS_COMPLETE using the return value ABAP_FALSE.
The check ID SAMPLE supplied by SAP can be used as an example implementation. You can assign any number of processes to the check to track the response and call sequence of the checks. The SAMPLE check displays a message to the user at runtime for each call that contains information about the assignment, such as the execution time.
You maintain checks in addition to the process settings using the existing process framework view cluster CRM_IU_PR_PROF (can also be accessed using transaction CRM_ISU_PROC). The view cluster node Define Checks is used to define specific check IDs, whilst the Assign Check node means that check IDs can be assigned at process level or process profile level. The Where-Used Listbutton above the list of check IDs provides an overview of the assignment of process IDs to processes.
Once you have defined a check ID, you can assign this to specific processes in Customizing. You can do this as a standard setting for the actual process definition or you can make this dependent on the process profile and therefore indirectly make this user role-specific. Process profile-dependent definitions have priority during runtime. This means that the profile-dependent setting for a check ID overrides the profile-independent standard definition. Multiple assignment of a check ID to various processes means that check routines can be re-used. However, it is also possible to assign a check to a specific process several times. This means that the check can be executed for the event ON_PRODUCT_CHANGED and the event IS_COMPLETE. Multiple assignment is possible using the key suffix Assignment. You can choose a sequence number as an ID. This number does not affect the execution sequence, which is controlled by the Priority field in Customizing. When assigning a check ID to a process, you can also configure the three parameters execution time (EXECUTION_TIME), evaluation time (VALIDATION) and assignment(ASSIGNMENT), which the implementation class transfers in the method IF_CRM_IU_PROCESS_CHECK~CHECK.
You can deactivate the check IDs in Customizing using the indicator Inactive(INACTIVE). If you select this indicator at check ID level, this means that the system no longer runs or ignores the checks in all processes to which the corresponding check ID has been assigned. The Inactiveindicator can also be selected at the level at which process IDs are assigned to processes, meaning that you can perform a deactivation for specific processes or process profiles.
You can perform a user-specific deactivation of the entire check repository using the user parameter CRM_ISU_PROC_NOCHECK. If you enter the value "X" for this parameter, the system uses the process standard logic and does not run any checks from the check repository.
All checks in the check repository are always called from the existing methods in the process implementation classes. The existing logic used to call methods, such as IS_EXECUTABLE or ON_PRODUCT_CHANGED is not affected by the introduction of the check repository.
SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up General Data in Customer Master
This documentation is copyright by SAP AG.
Length: 10482 Date: 20240523 Time: 171707 sap01-206 ( 257 ms )
