The Utilities Check Cockpit (UCC) and the Check Repository in the process framework

[ceedee666]

In my previous blog (Testing some of the new features in SAP CRM EhP1, EhP2 and EhP3) I explored some of the general features delivered with SAP CRM EhP1, EhP2 andEhP3. In contrast to that I'll explore utilities industry specific features in this blog, namely the Utilities Check Cockpit (UCC) and the Check Repository in the process framework.

The Utilities Check Cockpit as well as the Check Repository are part of the business function CRM_UT_ER_2 (Energy Retailer 2 - Business Functions for SAP Customer Relationship Management - SAP Library) delivered with SAP CRM EhP2. In order to use these features the business function CRM_UT_ER_2 needs to be activated using transaction SFW5.

However, the Utilities Check Cockpit has also been down ported to SAP CRM 7.0 EhP0 and EhP1 (cf. SAP Note 1742546 - Utilities Check Cockpit for further details).

Utilities Check Cockpit (UCC)

The Utilities Check Cockpit is a tool to automatically perform comprehensive consistency checks of utilities specific application data. In particular the Utilities Check Cockpit can be used to check the consistency of contract and technical data across SAP CRM and SAP IS-U. Inconsistencies of the utilities specific application are usually sources  process problem. An Example of such an inconsistency is a contract that has been cancelled in SAP IS-U and were the  cancellation has not been replicated to SAP CRM correctly for whatever reason. This will most likely cause a process problem if an agent tries to create a move out for the contract in SAP CRM. The Utilities Check Cockpit aims to identify such inconsistencies before they can lead to process problems.

Setup

The initial setup of the Utilities Check Cockpit is pretty easy. Besides the activation of the business function CRM_UT_ER_2 the only thing I had was to implement SAP Note 1919089 - CRM-IU: Utilities Check Cockpit - Creation of a Check Run causes a dump. This note contains only the instruction to create two number range intervals for the number range objects CRM_UOCM and CRM_UOCM_I.

After this, the Utilities Check Cockpit can either be started using transaction CRM_IUCMON or via the Check Cockpit -> Check Run in the UTIL_SALES business role.

Executing Check Runs

In order to execute an individual check run or schedule a periodic check run click "New" and select the check run category. SAP delivers three check categories in the standard delivery of the Utilities Check Cockpit, namely:

• UORD - Utilities Business Transaction Document
• USLO - Utilities Service Location
• USET - Utilities Object Set.

After the selection of the check run category one needs to set the parameters for the check run as well as the scheduling parameters for the batch process executing the checks. In the example below I've selected two check classes and scheduled the background job for immediate start. Furthermore, it is possible to provide an email address for a notification upon completion of the check run.

Upon completion of a check run the Utilities Check Cockpit provides an overview of the found issues for each of the selected check classes. For each issue it is possible to create a task and assign it to some agent in order to get the issues resolved. In the screen shot below the results of the check class CL_CRM_ISU_CM_CHECK_CANC are shown. This check class searches for contracts which are cancelled in IS-U but not in CRM. In the example check run 10 such cases were identified.

Furthermore, the Utilities Check Cockpit also offers the possibility to implement automatic corrections for each issue. However, none of the check classes delivered in the SAP standard provides functionality for an automatic correction.

Extending the Utilities Check Cockpit

In the standard SAP delivers the following set of check classes:

• Check category UORD
  • CL_CRM_ISU_CM_CHECK_CANC - Search contracts cancelled in IS-U but not in CRM
  • CL_CRM_ISU_CM_CHECK_DATES - Compare appointment 'CONTSTART' with its value in the CRM Utilities-Index
  • CL_CRM_ISU_CM_CHECK_EVERH - Compare IS-U-contract history (EVERH) with the CRM Utilities-Index
  • CL_CRM_ISU_CM_CHECK_I1030 - Check if status I1030 'errors' is correctly set
  • CL_CRM_ISU_CM_CHECK_I2413 - Check if status I2413 is correctly set
  • CL_CRM_ISU_CM_CHECK_LINK - Search for CRMD_ISUEXTA4 without CRMD_ORDERADM_I
  • CL_CRM_ISU_CM_CHECK_POD_OCC - Search for Points of Delivery with multiple assigned Contracts
  • CL_CRM_ISU_CM_CHECK_POD_REPL - Check IS-U Replication Error Monitor for Point of Delivery and Connection Object issues
  • CL_CRM_ISU_CM_CHECK_REPL - Search for Contract related issues in IS-U Replication Error Monitor
  • CL_CRM_ISU_CM_CHECK_STAT - Generate IS-U Order error message statistic
• Check category USLO
  • CL_CRM_ISU_CM_CONS_DL_CONNOBJ - Check Connection Objects for consistent Download
  • CL_CRM_ISU_CM_TO_WITHOUT_IB - Check for Technical Objects without an IBase component.

In addition to those check classes it is quite easy to extend the Utilities Check Cockpit with custom check classes. In order to create a custom check on needs to implement the custom check in a class implementing the interface IF_CRM_ISU_CM_CHECK. The check classes delivered in the SAP standard (e.g. CL_CRM_ISU_CM_CHECK_I2413), which are located in package CRM_IU_CM_API, provide plenty of code examples how to implement a custom.

After a custom check class has been implemented it only needs to added to the customizing at SPRO -> Customer Relationship Management -> Industry-Specific Solutions -> Utilties Industry -> General Settings -> Utilities Check Cockpit -> Define Settings for Utilities Check Cockpit. After this, the custom check class can be selected when a new check run is scheduled.

In order to provide an automated correction, the two methods IF_CRM_ISU_CM_CHECK~CORRECT and IF_CRM_ISU_CM_CHECK~IS_CORRECTION_SUPPORTED need to be implemented in the custom check class.

Check Repository

The second feature I want to focus on in this blog is the check repository in the process framework. If additional checks needed to be performed in the standard process classes (like e.g. CL_CRM_IU_PR_CNTR_END) the only way to do this was via the following approach:

1. Create a subclass of the standard process class
2. Implement the additional check in the appropriate method of the process framework (e.g. IF_CRM_IU_PROCESS~IS_EXECUTABLE)
3. Use the custom process class in the customizing of the process framework instead of the standard class.

There are a large number of scenarios requiring the implementation of custom checks in the process classes. In the systems of our clients custom checks are implemented, for example, to check the market communication deadlined before the creation of a move in or check if contract was billed after the date of a planned move out. The check repository in the process framework focuses exactly on this use case. It enables the addition of custom checks to the standard process classes without the need to create a custom process class implantation. Instead a custom check is implemented using the following approach:

1. Implement a custom check by subclassing CL_CRM_IU_PROCESS_CHECK and implementing the method IF_CRM_IU_PROCESS_CHECK~CHECK
2. Add the custom check to the customizing of one or several processes in the process framework.

In the following sections I'll describe these steps in more detail.

Implementing a custom check

The class CL_CRM_IU_PR_CHK_CNTR_BILL_END in the package CRM_IU_IC_6X_SI_PROC_IMPL provides an example of a custom check implemented using the check repository. In the method IF_CRM_IU_PROCESS_CHECK~CHECK a check for a existing bill after the planned move out date is performed. In order to implement the check the method IF_CRM_IU_PROCESS_CHECK~CHECK has access to the process context. Furthermore, a reference to the log object is available in order to raise error messages to the user if necessary.

Adding a custom check to the process framework

The customizing of the check repository is locates at SPRO -> Customer Relationship Management -> Industry-Specific Solutions -> Utilties Industry -> Settings for User Interfaces -> Transaction Processing -> Processes -> Define Processes.

In order to add a custom check to the check repository first a Check ID needs to be created. In the example below the check ID UCBILLEN is assigned to the implementation class CL_CRM_IU_PR_CHK_CNTR_BILL_END.

Next the check can be added to a process. In order to add a check to a process the execution time and the execution frequency within the process framework needs to be specified. The execution time is specified within the methods of the process framework, i.e.. checks can be executed before or after the following methods of the process framework are called for the process implementation class

• IS_EXECUTABLE
• IS_COMPLETE
• ON_PRODUCT_CHANGED
• ON_POD_CHANGED
• ON_DATE_CHANGED
• ON_GENERIC_DATA_CHANGED
• START
• AFTER_START
• BEFORE_FINISH
• FINISH
• AFTER_FINISH.

In the example below the check UCBILLEN is executed after the method IS_COMPLETE of the process framework is called. Furthermore, the check will only be called once per execution of a process. In contrast to that it is also possible to execute a check for each item of a process.

In summary, the check repository provides a nice, clean way to extend the standard process classes with custom checks.

Christian