CHARM: Custom consistency checks, step-by-step example.

[Former Member]

In this blog i will describe step by step, how to create and use own custom consistency checks in Charm Change Documents f.e. when status is changed.
We already know that there is standard consistency checks delivered by SAP, Posted by mich.vollmer

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/05/15/charm-framework-an-o...

Example Scenario: When  Normal Change switching from "In development" to "To be tested", check that Unit test is attached and have right status.

Steps:

1. Create custom  Z/Y condition
2. Create Z/Y custom message class
3. Register custom message class to use in consistency checks
4. Map messages to conditions ( errors, warnings or cancel )
5. Assign Custom check to User status of Normal Change
6. Implement BADI - write logic here
7. See results

All IMG links are available in SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks. The only object that we have not here is tcode SE91 for creating custom message class to use it here.

1. Let's start first Create custom  Z/Y condition

Go to SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks - Define Conditions

New entries enter give name starting from Z/Y, text - description of condition and assign CL_SOCM_INSTANCE

   * Note for all custom checks always use CL_SOCM_INSTANCE

Example

Save it, done.

2. Create Z/Y custom message class
Tcode SE91, create Z message class next create a message

Unmark SelfExplanatory, create long text for your message example

* Note to insert a link press top menu Include - link - Document class = URL Link

3. Register custom message class to use in consistency checks

Now lets register message for use in Consistency checks Go to SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks - Register Messages

Add created Z/Y message class, after this go to Single messages - check S - column marked

* Note The Save Message flag must be active for the message to be visible in the change transaction.

Save, done.

4. Map messages to conditions ( errors, warnings or cancel )

Go to SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks - Define Basic Settings

5. Assign Custom check to User status of Normal Change

Go to SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks - Assign Conditions to Status Values

Now we need to map Condition check + Message + Status value where check must be triggered

     *A little explanation this entry means: when status is E0004 ( to be tested ) if consistency checks fails show message 000 of class Z class      and       reset status      back to E0002 ( In development )

Now we done here save and leave.

6. Implement BADI - write logic here

Go to SPRO - SAP Solution Manager - Capabilities (Optional) - Change Control Management - Standard Configuration - Change Request Management Framework - Consistency Checks - Implement BAdI Extension

Last we need to write logic, for this we need to Implement and activate BADI for SOCM_CHECK_CONDITION

Give Z/Y name to Implementation

Add filter value = Your created  Z/Y custom condition in 1st step

Now go to Interface and drill down to CHECK_CONDITION method, now here you need to write your logic. I will not describe deeply here.

I will just explain the check behavior, because you may have issues like "some actions are not performed" as error message.

  DATA:

      l_check TYPE boolean.

  conditions_ok = abap_true.

  CASE flt_val.

    WHEN 'ZUNIT_TEST_EXIST'.

      CLEAR l_check.

      l_check = check_real_status( i_guid = hf_instance->change_document_id i_status = hf_instance->estat ).

      CHECK l_check = abap_true.

      CLEAR l_check.

      l_check = check_project_type( i_tasklist = hf_instance->tasklist_id i_project_type  = 'M').

      CHECK l_check = abap_true.

      conditions_ok = check_doc_status( i_guid = hf_instance->change_document_id i_status = 'REVIEW' ).

In my scenario check should trigger only if status are changing from In Development -> To Be tested. ( standard behavior check will be triggered in all situations when changing to and from To be tested ).

To avoid this I've created method that read db table CRM_JEST and checks that actual status are not yet in there - this means check will be triggered only when changing from In Development to To be Tested.

Coding:

METHOD check_real_status.

  DATA

        l_stat TYPE jstat.

  SELECT SINGLE stat INTO l_stat

    FROM crm_jest

    WHERE objnr = i_guid

      AND stat = i_status

      AND inact = ''.

  IF sy-subrc <> 0.

    result = abap_true.

  ELSE.

    result = abap_false.

  ENDIF.

ENDMETHOD.

7. See results

Launch tcode SM_CRM create Normal Change set it to In Development, release tasks and try to set To be tested by choosing related Actions Pass Normal Change to test.

Okay here it is, you will see message with Details even with link in it and status is not changed until check conditions is fulfilled.

Enjoy using it :wink: