Using Substatus / Status Reason / Closure Codes for ChaRM

SAP Solution Manager IT Service Management is using Substatus or Status Reason to give end-users the possibility to specify why the current status is choosen. This is a very good feature which can be used for initial status (Why transaction is created?) final status (Why transaction is closed/withdrawn?), approval and confirmation status (Why it is approved/confirmed/rejected?). The status „Sucessfully Tested“ or „Back to Development“ is also a confirmation status in this meaning.

We don’t want to discuss here, why SAP SE introduced a new concept of substatus / status reason which was already existing in SAP CRM long time ago and which is heavily used by leads, opportunities, … This is another topic which is out of scope of this post.

In this post I want to tell you how to enable this feature for Change Request Management, because it is helpful for ChaRM as well.

  1. Configuration of substatus can be done like for ITSM. No additional customizing table is needed.
  2. Substatus is available as field /AICRM/REASON_ID of table CRMD_SERVICE_H. This is true for ITSM and ChaRM. No field enhancement is needed. If we want to activate processing/change logging for this field we just have to configure it using these technical information.
  3. Substatus is available as field //BTADMINH/EXT./AICRM/REASON_ID in UI configuration of details form. This is true for ITSM and ChaRM (CR and CD). We just need to make the field visible. However ChaRM is not supporting any value help or input readiness check. This needs to be implemented (see below).
  4. Substatus is available as Search Criteria and Search Result List Field. This is true for ITSM and ChaRM (CR and CD). We just need to make the field visible. However ITSM and ChaRM are not supporting any value help (search criteria) and key to text conversion (result list field). This needs to be implemented (see below).
  5. We still have the issue, that the status change is performed by ppf actions in ChaRM. Therefore we have no chance to maintain the substatus / status reason /closure code on change to a final status, because the transaction is final after status change. Only a popup solution can help here which will need a medium-size development (see linked document).

Full Documentation: ChaRM Substatus.pdf (2.3 MiB)


To enable value help and input readiness check, we need to implement all relevant getter and setter methods of AIC_CMCR_H/AICCMCRHeaderEF-BTADMINH./AICRM/REASON_ID and AIC_CMCD_H/AICCMCDHeaderEF-BTADMINH./AICRM/REASON_ID. To avoid copy past of source code we can alternatively change the inheritance hierarchy. 1. Enhance context node controller of AIC_CMCR_H/AICCMCRHeaderEF-BTADMINH and AIC_CMCD_H/AICCMCDHeaderEF-BTADMINH. 2. Exchange super class CL_SRQM_H_BTADMINH_CN by CL_AIC_INCI_INCIDENTHEADE_CN03. 3. Modify or replace code of method CL_AIC_INCI_INCIDENTHEADE_CN03->IF_BSP_MODEL~INIT and catch exception if cast of owner fails.

 METHOD if_bsp_model~init.

    CALL METHOD super->if_bsp_model~init
    EXPORTING
      ID    = ID
      owner = owner.

*We are reusing BTBadminH Context Node of Incident for Change Request and Documents.
*In this case the cast will fail because of the wrong view controller class.
*We dont need a working solution in this case. Therefore we just need to catch the exception.
    CATCH SYSTEM-EXCEPTIONS MOVE_CAST_ERROR = 1.
    mo_controller ?= owner.
    ENDCATCH.

    EXIT. "needed if this is an enhancement at the beginning of the method instead of a modification.

  ENDMETHOD.

To implement a value help for the Status Reason search criteria, we have to implement method GET_V_/AICRM_REASON_ID for view controller of AIC_CMCD_S/SearchQueryView and AI_CMCR_S/CMSR with following content:

METHOD get_v_/aicrm/reason_id.

  DATA:
    lt_list_proc_type  TYPE crmt_process_type_tab,
    lt_range_proc_type TYPE RANGE OF crmt_process_type,
    ls_range_proc_type LIKE LINE OF lt_range_proc_type.

  FIELD-SYMBOLS:
    <fv_proc_type> LIKE LINE OF lt_list_proc_type.


* Get all relevant process types (see value help getter for process_type)
  me->get_all_proc_type( IMPORTING et_proc_type = lt_list_proc_type  ).
*  lt_list_proc_type = me->get_all_proc_type( ).

*Build select option.
  LOOP AT lt_list_proc_type ASSIGNING <fv_proc_type>.
    ls_range_proc_type-sign = 'I'.
    ls_range_proc_type-option = 'EQ'.
    ls_range_proc_type-low = <fv_proc_type>.
    APPEND ls_range_proc_type TO lt_range_proc_type.
  ENDLOOP.

*Get all possible entries.
  SELECT DISTINCT reason_id AS key txt30 AS value
    INTO CORRESPONDING FIELDS OF TABLE cs_result-ddlb_options
    FROM aic_stat_reasont
   WHERE spras = sy-langu AND
         reason_id IN ( SELECT reason_id
                          FROM aic_stat_reason
                         WHERE user_stat_proc IN ( SELECT user_stat_proc
                                                     FROM crmc_proc_type
                                                    WHERE process_type IN lt_range_proc_type ) )
   ORDER BY reason_id.

*Add empty line.
  APPEND INITIAL LINE TO cs_result-ddlb_options.

ENDMETHOD.

To implement a key to text conversion for the Status Reason result list field, we have to implement method GET_/AICRM_REASON_ID for context node controller of AIC_CMCD_S/SearchQueryView-BTADMINH and AI_CMCR_S/CMSR-BTADMINH with following content:

METHOD get_/aicrm/reason_id.

  DATA: lr_current TYPE REF TO  if_bol_bo_property_access,
        lv_key     TYPE         aic_reasonid.

*Get entity.
  IF iterator IS BOUND.
    lr_current = iterator->get_current( ).
  ELSE.
    lr_current = collection_wrapper->get_current( ).
  ENDIF.

*Get key.
  lv_key = lr_current->get_property_as_string( iv_attr_name = '/AICRM/REASON_ID' ).

*use key as value if text cannot be found.
  value = lv_key.

*Try to find text.
  SELECT SINGLE txt30
    INTO value
    FROM aic_stat_reasont
    WHERE reason_id = lv_key AND
          spras = sy-langu.

ENDMETHOD.

Full Documentation: ChaRM Substatus.pdf (2.3 MiB)

How to allow or prevent status change based on phase of change cycle?

The phase control of change cycles is allowing or disallowing certain transport related activities dependent on the current phase. Sometimes the corresponding status change will be allowed or disallowed.

Some famous examples are:

  • Development without Release / Test / Go Live Preparation:
    • Normal Changes cannot be switched from „In Development“ to „To Be Tested“
  • GoLive:
    • Normal Changes cannot be switched from „In Development“ to „To Be Tested“
    • Urgent Changes cannot be switched from „In Development“ to „To Be Tested“

You might want to have some more status change control dependent on the phase of the change cycle. In other words: You want to allow or prevent a switch to a certain status in Normal Change or Urgent Change if the change cycle is or isn’t currently in a specific phase.

Good news:

This is just configuration. In other words: We are able to allow or restrict status changes dependent on change cycle phases. With the following steps I will guide you thru the configuration of an example:

  1. Define Task List action Z_IN_GO_LIVE_ONLY and Z_NOT_IN_GO_LIVE in view /TMWFLOW/TPCACTS.
  2. Allow Task List action Z_IN_GO_LIVE_ONLY in phase GO_LIFE only. Allow Task List action Z_NOT_IN_GO_LIVE in all phases except GO_LIFE. View cluster /TMWFLOW/VC_PHMD is to be used here.
  3. Map Task List action to ChaRM action ZIGLO_SMMJ and ZNIGL_SMMJ in view cluster /TMWFLOW/VC_CPVR (for path CRMW -> SMMN or SMDV).
  4. Define ChaRM action ZIGLO and ZNIGL in view TSOCM_ACTIONS and TSOCM_ACT_DEF. Assign class CL_CHM1_INSTANCE here. The message class and number can be empty but the ChaRM integration flag needs to be set to flag it as tasklist resp. transport related action.
  5. Implement a dummy BADI implementation for these actions. These implementations just need to exist and to be active. They don’t need to do anything (method body can/should be empty).
  6. Assign ChaRM action ZIGLO_SMMJ or ZNIGL_SMMJ to the target status of your Change Transaction in view cluster AIC_SETTINGS corresponding to your requirements. It does not matter whether this action is defined as early or late action since it does nothing.
  7. Assign ChaRM check condition CHECK_ACTION_PHASE to the target status of your Change Transaction and configure it as cancel action (the status change will be cancelled, if the check fails). This setup is also part of view cluster AIC_SETTINGS which can be accessed via SM34 of SPRO.
  8. Repeat or adjust these steps for other phases, actions or transaction types.

Result: Whenever the end-user is performing a status change to the target status, the check condition CHECK_ACTION_PHASE will be triggered and therefore check whether there is an ChaRM action assigned to the target status which is not allowed in the current change cycle phase. This check will find action ZIGLO or ZNIGL. This action will be translated to action Z_IN_GO_LIVE_ONLY or Z_NOT_IN_GO_LIVE and checked against the current change cycle phase using the Task List action assignment configured in step 2. The action itself is doing nothing.

In case you configured ChaRM action ZIGLO: The status change is only possible if the change cycle is in phase „Go Live“.

In case you configured ChaRM action ZNIGL: The status change is only possible if the change cycle is NOT in phase „Go Live“.

If you want to check more than one change cycle phases (e.g. Test or Go Live), you can combine several ChaRM actions. However, this make sense for ZNIGL and similar action only. If you combine ZIGLO and similar actions at least one check will always fail and therefore preventing the status change. If you want to configure a generic solution, you have to configure actions for every change cycle phase: NOT_IN_DEV_W/O_REL, NOT_IN_DEV_W_REL, NOT_IN_TEST, …

Phase of change cycle is preventing execution of transport related activity. How to change this behavior?

The phase control of change cycles is allowing or disallowing certain transport related activities dependent on the current phase.

Some famous examples are:

  • Development without Release / Test / Go Live Preparation:
    • Transport Request of Normal Changes cannot be released
    • Transport of Copies of Normal Changes cannot be created and released
  • GoLive:
    • Transport Requests of Normal Changes cannot be released
    • Transport of Copies of Normal Changes cannot be created and released
    • Transport Requests of Urgent Changes cannot be released
    • Import All into Test is not allowed
    • Import of Urgent Changes into Test or Prod is not allowed
    • Only in this phase an Import All in Production is allowed

When implementing Change Requests in an agile manner like SCRUM, this phase based transport control is not wanted. Especially the Go Live phase is a critical thing because we need to switch to this phase to be able to import all transports into production but at the same time developers are blocked in continuing their development.

Good news:

This is just configuration. In other words: We are able to remove these restrictions and allow production import in „Development with Release“ or Transport Request release in phase „Go Live“.

  1. Call SM34
  2. Open view cluster /TMWFLOW/VC_PHMD
  3. Select phase model (e.g. DEVRL or MNTCL)
  4. Select phase (e.g. DEVELOP_AND_RELEASE or GO_LIFE)
  5. Add or remove action (e.g. SM_IMP_PROD or RC_TR_RELEASE)

Caution: This configuration is delivered by SAP. It is officially not allowed to change these settings. It might happen that you will lose SAP support for SAP incidents in this area. If you remove some entries they might be restored after activating object piece list in SOLMAN_SETUP again which is a regular activity after Support Package upgrade.

Note: If you want to allow creation and release of Transport of Copies, you need to allow Transport Request release. If you still want to disallow release of original Transport Request, you need to prevent the corresponding status change dependent on the current change cycle phase. This additional setup is described in another blog.

ChaRM should ignore a Transport Request. What to do?

Issue:

  1. You deleted a transport request manually but ChaRM is still checking it.
  2. You implemented something but you now want to ignore the corresponding transport request. However you don’t want to undo all implementation steps manually and to send the build and undo transport request to production.

Note:

  1. The following solutions are workarounds.
  2. You should never delete transport requests manually. Only ChaRM should delete transport requests.
  3. You should never reject undo activities. All changes need to be send to production even undo activities.

Solution:

  1. Decouple Transport Request even if this feature is not configured for Change Documents or event decoupling is not allowed for the current CD Status.
    http://scn.sap.com/docs/DOC-65069
  2. Delete assignment between TR and CD (from table TMWFLOW/TRORDHC) using report /TMWFLOW/TRANSPORT_DELETE after implementation of SAP note 2009859: ChaRM: deleted transport request still exists in ChaRM table.

Authority Check on Execution of Task List Tasks

All transport activities performed by a Change Request Management action, by the IT Operator or by batch jobs are tunneled thru the task list. For every transport activity there exist a specialized task in the task list on header, footer or system role level.

For some of these tasks an authority check is performed on execution, for some not.

Why???

For some of these tasks an authority check against following authority objects will be performed on task execution:

  • /TMWFLOW/H Change Request Management: Task in Header
  • /TMWFLOW/D Change Request Management: Task in Development Systems
  • /TMWFLOW/O Change Request Management: Task in Follow-On Systems
  • /TMWFLOW/P Change Request Management: Task in Production Systems
  • /TMWFLOW/R Change Request Management: Task in Retrofit Systems
  • /TMWFLOW/S Change Request Management: Task in Single Systems
  • /TMWFLOW/F Change Request Management: Task in Footer

However, only following tasks are checked by SAP standard (SM 7.1 SP 11):

  • 1000 REQUEST_CREATE /TMWFLOW/SCMA_TRORDER_CREATE
  • 1500 REQUEST_DECOUPLE /TMWFLOW/SCMA_TRORDER_DECOUPLE
  • 1600 REQUEST_ASSIGN /TMWFLOW/SCMA_TRORDER_ASSIGN
  • 1700 REASSIGN_CHANGE /TMWFLOW/SCMA_REASSIGN_CHANGE
  • 1900 REQUEST_REASSIGN /TMWFLOW/SCMA_TRORDER_REASSIGN
  • 2000 TASK_CREATE /TMWFLOW/SCMA_TRTASKS_CREATE
  • 3000 REQUEST_RELEASE /TMWFLOW/SCMA_TRORDER_RELEASE
  • 4000 REQUEST_IMPORT /TMWFLOW/SCMA_TRORDER_IMPORT
  • 5000 CRIT_OBJ_APPROVE /TMWFLOW/SCMA_CRIT_OBJ_APPR
  • 6000 UC_IN_OTHER_SYSTEMS /TMWFLOW/SCMA_TRIMP_SYNC_TEST
  • 7000 LOGON /TMWFLOW/SCMA_RSRLOGIN
  • 8000 CTS_PROJECT_RELEASE /TMWFLOW/SCMA_CTS_RELEASE
  • 9000 QUEUE_PREPARATION /TMWFLOW/SCMA_QUEUE_PREPARE
  • 9100 QUEUE_IMPORT /TMWFLOW/SCMA_QUEUE_IMPORT

Because of technical/historical reasons, the checks for 1700, 1900 5000 are done against /TMWFLOW/D instead of /TMWFLOW/H. Maybe this will be changed in SAP Solution Manager 7.2 and that is why there already exist the not used authority objects /TMWFLOW/H and /TMWFLOW/F.

What to do if we want to have authority checks for other SAP standard tasks or for customer specific tasks?

  1. Maintain table /TMWFLOW/TSKPRGC (Mapping of task report name to task id). The id should be the same as the id used in task list definition. This customizing alignment is not obligatory but would be nice.
  2. Maintain table /TMWFLOW/AUTTSKC (Extend value help for field /TMWFLOW/T of the mentioned authority objects). The description of the task should be equal to the task list definition. This customizing alignment is not obligatory but would be nice.
  3. If the task is defined on header or footer level, you might need to do a modification to map it to /TMWFLOW/D. The authority check is always done using function module /TMWFLOW/TASKLIST_AUTH_CHECK. This function module is called at line 559+ of /TMWFLOW/TASK_START1 and line 222+ of IF_EX_SCMA_TREE_STATUS~ACTION_ALLOWED of class /TMWFLOW/CL_IM_SCMA_STATUS. At these code sections, you will find the mentioned system role mapping. Maybe a better place to do the mapping by enhancement instead of modification is at the beginning of function module /TMWFLOW/TASKLIST_AUTH_CHECK.

Additionally to these authority checks, function module /TMWFLOW/TASKLIST_AUTH_CHECK is also checking B_SMAN_WPL and /TMWFLOW/M on opening of task list or on changing phases. Therefore please ensure to add these authorities to your PFCG roles if needed.

In case you want to add authority checks for SAP standard tasks, you should use following task ids since these IDs are already hard coded in class interface /TMWFLOW/CL_CS_TL_TASK:

  • 1800 IGNORE_DGP_CONF /TMWFLOW/SCMA_IGNORE_DGP_CONF
  • 2100 REQUEST_DELETE /TMWFLOW/SCMA_TRORDER_CLEAR
  • 2200 REPAIR_IMPORT_FLAG /TMWFLOW/SCMA_SET_REPAIR_FLAG
  • 3100 CLUSTER_RELEASE
  • 3200 CLUSTER_IMPORT
  • 4100 PRELIMNRY_IMPORT /TMWFLOW/SCMA_PRELIMNRY_IMPORT