Feature Attributes (DNO_CUST04 2.0)

Introduction

Sometimes we need the capability to activate or deactivate a certain feature or to select a feature variant in context of a specific process type or project id. The already existing solution DNO_CUST04 / DNOC_USERCFG or AGS_WORK_CUSTOM are no proper solutions because here we cannot define attribute names & values and we cannot assign attributes to a project id.

Because SAP SE is not able to design and implement a proper solution, we have to do it.

Tables and Maintenance Views

Attribute Name

Table ZAT_N_C | Attribute Name

  • CLIENT | Client
  • NAME | Attribute Name

Table ZAT_N_T | Attribute Name (Text)

  • CLIENT | Client
  • LANGU | Language
  • NAME | Attribute Name
  • TEXT | Attribute Name Description

Attribute Value

Table ZAT_V_C | Attribute Value

  • CLIENT | Client
  • NAME | Attribute Name
  • VALUE | Attribute Value

Table ZAT_V_T | Attribute Value (Text)

  • CLIENT | Client
  • LANGU | Language
  • NAME | Attribute Name
  • VALUE | Attribute Value
  • TEXT | Attribute Value Description

Search Help ZAT_SH | Attribute Values (used for dynamic value list determination in customizing tables)

  •  ZAT_V_C-NAME | I+E | | Attribute Name
  • ZAT_V_C-VALUE | E | 1 | Attribute Value
  • ZAT_V_T-TEXT | | 2 | Attribute Value Description

Attribute Assignment

Table ZAT_A_C | Attribute Assignment

  • CLIENT | Client
  • PROCESS_TYPE | Process Type
  • PROJECT_ID | Project ID
  • NAME | Attribute Name
  • VALUE | Attribute Value

View ZAT_PT_V | Attribute Assignment on Process Type level (transportable)

  • CLIENT | H | Client
  • PROCESS_TYPE | | Process Type
  • PROJECT_ID | H | = “ | Project ID
  • NAME | | Attribute Name
  • VALUE | | Attribute Value
  • PROCESS_TYPE_TEXT | R | Process Type Description
  • NAME_TEXT | R | Attribute Name Description
  • VALUE_TEXT | R | Attribute Value Description

View ZAT_PT_V | Attribute Assignment on Project level (not transportable)

  • CLIENT | H | Client
  • PROCESS_TYPE | | Process Type
  • PROJECT_ID | <> “ | Project ID
  • NAME | | Attribute Name
  • VALUE | | Attribute Value
  • PROCESS_TYPE_TEXT | R | Process Type Description
  • NAME_TEXT | R | Attribute Name Description
  • VALUE_TEXT | R | Attribute Value Description

View Cluster ZAT_VC | Attributes

  • ZAT_N_C | Attribute Name
    • ZAT_V_C | Attribute Value

API (Class ZAT_CL)

CHECK_ATTRIBUTE

Purpose:

  • Check for Name and Value of an attribute

In:

  • Process Type
  • Project ID
  • Name
  • Value

Out:

  • Boolean

Content:

  • Check for attribute and context in table ZAT_A_C

GET_VALUE

Purpose:

  • Get Value of an attribute

In:

  • Process Type
  • Project ID
  • Name

Out:

  • Value

Content:

  • Read first value for given context and attribute name from table ZAT_A_C. Sort by process type (descending) and project id (descending) to enable overlapping capability.

Overlapping Capability:

  • PROCESS_TYPE | PROJECT_ID
  • X X
  • X O
  • O X
  • O O

GET_ATTRIBUTES

Purpose:

  • Get complete list of active attributes

In:

  • Process Type
  • Project ID

Out:

  • Table of Name Value pairs
  • Table of Strings

Content:

  • Read all attribute names and values for given context from table ZAT_A_C.
  • Concatenate name and value separated by slash (if string table result is requested).

GET_ATTRIBUTES_FOR_TRANSACTION

Purpose:

  • Get complete list of active attributes for a transaction

In:

  • Transaction GUID

Out:

  • Table of Name Value pairs
  • Table of Strings

Content:

  • Get process type using method cl_hf_helper=>get_proc_type_of_chng_doc.
  • Get project id using method cl_al_crm_cm_utility=>read_project_id.
  • Get result data calling method GET_ATTRIBUTES

Business Object Attribute (used by PPF actions)

SWO1 -> Enhancement of BUS2000116 (Service Process) -> Attribute „Features“

Data Reference: BDI_LOG-COMM (String table)

In:

  • Transaction Guid

Out:

  • Feature List

Content:

  • Call method GET_ATTRIBUTES_FOR_TRANSACTION

Note:

  • This attribute can be used in ppf schedule and start conditions
  • Usually we are using operator „CE“ to check for a certain name value pair („NAME/VALUE“). However pattern search (with asterisk and plus is also working).

SPRO / IMG

  • Attribute Definition (Name & Values): Define feature attributes with name and possible values.
  • Attribute Assignment on Process Type level (transportable): Assign feature attributes to process type in order to activate feature or choose feature variant for a specific process type. Note. This configuration is transportable.
  • Assign Attribute on Project level (not transportable): Assign feature attribute to project in order to activate feature or to choose feature variant. Note: This configuration is not transportable. Note: This configuration will overwrite configuration of process type level in case application wants to read the value for a specific attribute name. This configuration will be merged with configuration of process type level in case application wants to check a specific attribute (name & value) or wants to read complete list of active attributes.
  • Optionally we can add DNO_CUST04 and AGS_WORK_CUSTOM here (several existing IMG activities).

Transport-Related Checks (available with SAP Solution Manager 7.2 SPS 3+)

With SAP Solution Manager 7.2 SPS 3 there is a new assignment block available. This new assignment block is called „Transport-Related Checks“ (german: „Transportbezogene Prüfungen“). It merges the results of the Cross-System Object Lock (CSOL), Downgrade Protection (DGP), Critical Object Check (COC), ABAP Test Cockpit (ATC) and Code Inspector (CI) to one place. Additionally it provides a feature to implement Customer-Specific checks (CUC) as BADI implementation.

This is an improvement which will simplify the Change Request Management solution significantly. But …

  • The previously existing assignment blocks for DGP, COC or ATC/CI are no longer valid because they are part of the new assignment block.
  • The checks are not harmonized in one framework. That mean that DGP and COC and ATC still have their own approval feature. DGP can be approved on conflict, event and system level. COC can be approved on conflict level. ATC can be approved on issue level. CUC cannot be approved yet.
  • The checks are not harmonized in one framework. That mean that CSOL/DGP, COC, ATC/CI and CUC are triggered at different events. COC and ATC/CI are still not supported on transport import. On the other side COC and CUC are now supported on object save (analogously to CSOL).
  • The checks are not harmonized in one framework. That mean, that there is no unified customizing setting to activate these checks for specific events, landscapes, systems or clients. Only DGP has the capability to activate or deactivate checks on event, landscape, system or client level. COC and ATC/CI can be activated on system level only. CUC needs to implement an own customizing table to enable flexible configuration of the custom-specific checks.
  • When upgrading to SAP Solution Manager SPS 3, you have to run WCF_RT_COMP and WCF_CC. You also have to adjust your UI configurations for Change Documents and Change Cycles and to synchronize UI personalization. Otherwise the new assignment block will not be available or not be visible.

Official documentation:

SAP Help: Transport-Related Checks

Using IBase Components in Change Requests

Requirement

We want to display and select IBase Components in Change Requests.

Challenge

In SAP Standard IBase Components are not supported on CR level, only on CD Header level and CR Item Level (Scope Assignment Block). Therefore there is not only a UI configuration to do.

Solution

We can reuse the solution already implemented for Change Documents.

However, this is a dirty solution, because it contains one modification, one modified enhancement and two copy-past source code clones.

This is acceptable as temporary solution only till SAP will implement it in Standard. Let’s hope it will happen soon.

Steps

  1. Exchange Context Node Controller of AIC_CMCR_H/AICCMCRHeaderEF-BTREFOBJMAIN from CL_SRQM_H_BTREFOBJ_CN to CL_AIC_CMCD_IBASE_CN. Use the enhancement technique on context node controller level to do that. (We have to do it manually because of technical reasons).
  2. Generalize context node controller CL_AIC_CMCD_IBASE_CN to work with CDs and CRs. Therefore correct definition of attribute MR_VIEW_CONTROLLER from CL_AIC_CMCD_AICCMCDHEADER_IMPL to CL_SRQM_RFC_REQUESTFORCH0_IMPL (or OBJECT) by modification.
  3. Add component usage CUSolmanIbaseValueHelp to AIC_CMCR_H and implement view controller methods OP_FINDIBASECOMPONENT and EH_ONSELIBASECOMPONENT analogous to AIC_CMCD_H by copy & past.
  4. Configure Status Dependent Input Readiness (SPRO -> … -> Adjust UI objects by User Status) for UI element „IBASE_COMPONENT“ to make fields editable at the right time (usually analogous to Project ID).
  5. Configure UI and make fields //BTREFOBJMAIN/IBINSTANCE + //BTREFOBJMAIN/IBINSTANCEDESC visible and editable.
  6. Copy Control is usually working fine because the hidden fields are already used in Standard CR to store IBase Component copied from preceeding Incident.
  7. Steps 1 – 5 are needed for editability and selectability. For display only step 5 is sufficient.

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:
     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 .
    ls_range_proc_type-sign = 'I'.
    ls_range_proc_type-option = 'EQ'.
    ls_range_proc_type-low = .
    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

Change Request Management RollOut Guide

Leitfaden für das Anbinden, Verändern oder Bauen von ChaRM-Satelliten-Landschaften

Die in diesem Leitfaden beschriebenen Aktivitäten sind zu tun wenn

  • Eine bestehende SAP-Lösungs-Landschaft an das SAP Solution Manager Change Request Management angebunden werden soll.
  • Eine bestehende an das SAP Solution Manager Change Request Management angebundene SAP-Lösungs-Landschaft verändert werden soll (z.B. Aufbau von dauerhaftem Projekt- und Konsolidierungssystem).
  • Eine bestehende an das SAP Solution Manager Change Request Management angebundene SAP-Lösungs-Landschaft verändert werden soll (z.B. Aufbau von temporärem Wartungs- und Qualitätssicherungssystem. Bisherige Wartung wird für Projekt genutzt.).
  • Eine bestehende an das SAP Solution Manager Change Request Management angebundene SAP-Lösungs-Landschaft verändert werden soll (z.B. Verlängerung des Wartungsstrangen um ein zusätzliches Qualitätssicherungs- oder Vorproduktionssystem).
  • Eine Demolandschaft im SAP Solution Manager Entwicklungssystem angelegt werden soll.
  • Ein Releasezyklus abgeschlossen und ein neuer Releasezyklus angelegt werden soll.
Change Request Management RollOut Guide.pdf (571.8 KiB)

Change Request Management Downgrade Protection Handbuch

Handbuch zur Steuerung, Überwachung und Vermeidung von Parallelentwicklungen

Systemübergreifende Objektsperre / Cross System Object Lock / CSOL

Die „Systemübergreifende Objektsperre / Cross System Object Lock / CSOL“ ist eine Funktion des SAP Solution Manager Change Request Management. Sie gewährleistet, dass ein Objekt bei Änderung in einem verwalteten System im zentralen SAP-Solution-Manager-System gesperrt wird. Spätestens beim Speichern dieser Änderung wird der Entwickler/Customizer über aktuell laufende parallele Anpassungen am selben Objekt informiert und kann seine Änderung ggf. gar nicht oder nur im fremden Änderungsvorgang speichern. Hierdurch werden Importprobleme von vornherein ausgeschlossen bzw. der Implementierer wird im Vorfeld über die Gefahr informiert.

Downgrade-Schutz / Downgrade Protection / DGP

Der „Downgrade-Schutz / Downgrade Protection / DGP“ ist eine Funktion des SAP Solution Manager Change Request Management. Die Funktion dient der Nachverfolgung von Objektänderungen und deren Transport durch die gesamte Lösungslandschaft. Konflikte und daraus resultierende potentielle und tatsächliche Downgrade-Risiken (z.B. Überholen eines Vorgängers oder Überschreiben eines Nachfolgers) werden identifiziert, bewertet, gemeldet und müssen explizit vom Change- / Release-Manager genehmigt werden. Hierdurch werden Importprobleme proaktiv verhindert bzw. der Change- / Release-Manager wird im Vorfeld über die Gefahr informiert.

Projektschnittmengenprüfung / Project Intersection Check / PIC

Wenn Sie in einer Systemlandschaft mit mehreren parallelen Projekten arbeiten, die Projekte aber nicht vollständig disjunkt halten können, dann müssen Sie Abhängigkeitsbeziehungen zwischen den Transportaufträgen definieren. Beim Import von Transportaufträgen werden die Abhängigkeitsbeziehungen ausgewertet und das System weist die Transport­administration automatisch darauf hin, dass sie die Menge der zu importierenden Aufträge vergrößern muss, um die korrekte Importreihenfolge zu erhalten. Die Funktion „Projekt­schnitt­mengenprüfung / Project Intersection Check / PIC“ dient der automatischen Identifikation technisch bedingten Transportabhängigkeiten, der manuellen Vormerkung von logischen Transportabhängigkeiten und der Überwachung der Abhängigkeiten beim Import.

Änderungs-und-Transport-System-Analyse / Change- and Transport System Analysis / CTSA

Die „Änderungs-und-Transport-System-Analyse / Change- and Transport System Analysis / CTSA“ dient der Ad-Hoc-Analyse einer Menge von Transportaufträgen, der darin enthaltenen Objekte und deren Umfeld. Mit Hilfe dieser Analyse können vor dem Projektimport Abhängigkeiten zu anderen Änderungen / Transportaufträge, deren Produktivsetzungen aktuell noch nicht anstehen, identifiziert werden. Der Umfang der zu importierenden Transportaufträge ist anschließend um diese Transportaufträge zu erweitern, da es ansonsten zu kritischen Objektversionsunterschieden zwischen Quell- und Zielsystem und damit einhergehend zu abweichendem Funktionsverhalten, Inkonsistenzen oder Systemabbrüchen kommen kann.

Transportnachverfolgungsmonitor / Transport Tracking Monitor / TRMO

Nach einem GoLive eines größeren Releases bzw. Projektes besteht häufig der Wunsch eines Nachweises der Transport- und Objektkonsistenz. Für eine Schnellanalyse kann die Funktion „Transportnachverfolgungsmonitor / Transport Tracking Monitor / TRMO“ genutzt werden. Sie können hiermit Transportaufträge von dem System, in dem sie angelegt und freigegeben wurden, bis zu dem System, in das sie importiert wurden, nachverfolgen. Dabei lassen sich sowohl Transportdeltas als auch Reihenfolgeverletzungen identifizieren.

Transportausführungsanalyse / Transport Execution Analysis / TEA

Eine ausführliche Analyse der Lösungslandschaft oder des Releases / Projektes ist mit dem Self-Service „Transportausführungsanalyse (für Projekte) / Transport Execution Analysis (for Project) / TEA(P)“ möglich. Diese Analyse kann vor und/oder nach einem GoLive ausgeführt werden. Sie kann auch unabhängig von einem GoLive ausgeführt werden. In jedem Fall erhalten Sie als Ergebnis einen ausführlichen Analysebericht (Word / HTML / PDF) mit konkreten Handlungsanweisungen zur nachhaltigen Sicherung bzw. Verbesserung der Transport- und Objektkonsistenz.

Importqueue-Web-UI – Importprüfungen / Import Queue Web UI – Import Checks / IQIC

Sämtliche zuvor beschriebenen Funktionalitäten sind ausschließlich für ABAP-Änderungen nutzbar. Für Non-ABAP-Änderungen sind sie nicht anwendbar. Ergänzend zur Funktion „Downgrade-Schutz“ und „Projektschnittmengenprüfung“ ist die Funktion „Importqueue-Web-UI – Importprüfungen / Import Queue Web UI – Import Checks / IQIC“ anzuwenden. Diese Funktion unterstützt die Prüfarten „Prüfung auf Vorgänger“ und „Prüfung auf Downgrades“ für alle ABAP- und fast alle Non-ABAP-Transporte. Es erfolgt ausschließlich eine Analyse der aktuell in der Importqueue zum Import anstehenden oder bereits importierten Transportaufträge, weshalb Überholer nur ein einziges Mal erkannt werden – z.B. nur beim Import in das Qualitätssicherungssystem aber nicht beim Import in das Produktionssystem.

Importhistorie-Web-UI – Analysemodus / Import History Web UI – Analysis Mode / IHAM

Ergänzend zur Funktion „Transportnachverfolgungsmonitor“ ist die Funktion „Importhistorie-Web-UI – Analysemodus / Import History Web UI – Analysis Mode / IHAM“ anzuwenden. Diese Funktion identifiziert Reihenfolgeverletzungen, Downgrades und reparierte Downgrades für alle ABAP- und fast alle NonABAP-Transporte. Es erfolgt ausschließlich eine Analyse der Importhistorie, weshalb unter anderem Transportdeltas nicht erkannt werden können.

Download

Change Request Management Downgrade Protection Handbuch.pdf (2.0 MiB)

Checking landscape information in SAP CRM PPF action conditions using BADI CONTAINER_PPF

In SAP Solution Manager Change Request Management we want to work with different status flows dependent on the landscape (in one process type). Therefore we need to use landscape information in Action schedule (and start) conditions.

With BADI implementation ZLIAC_SYSTROLE_EXIST (BADI Definition CONTAINER_PPF) we have the possibility to check the use of specific system roles. To do this, we simply have to define a condition parameter “ZLIAC_SYSTEM_ROLE_EXISTS_<SYSTEM_ROLE>“. Please have a look at transaction MAINT_ROLES for valid system roles.

In our first use case, we want do differentiate between 3-trier and 5-trier landscapes. To do that, we check for existence of system role “3”. This role will only be used in 5-trier landscapes like “D -> T -> 2 -> 3 -> P”. In 3-trier landscapes like “D -> T -> P”, this role will never be used.


*"----------------------------------------------------------------------
*"Methoden Signatur:
*"  Importing
*"    FLT_VAL TYPE OJ_NAME
*"  Changing
*"    CI_CONTAINER TYPE REF IF_SWJ_PPF_CONTAINER
*"    CI_PARAMETER TYPE REF IF_SWJ_PPF_CONTAINER
*"----------------------------------------------------------------------
method IF_EX_CONTAINER_PPF~MODIFY_CONTAINER.

  TYPE-POOLS: socmt.

  data:
    lv_result          type abap_bool,
    lt_parameter       TYPE SWCONTTAB,
    lv_system_role     type /TMWFLOW/PROJECT_SYSTEM_S-SYSTEM_ROLE,
    ls_object          TYPE sibflporb,
    lv_guid            TYPE crmt_object_guid,
    lv_doc_flow_id     TYPE crmt_doc_flow_id_wrk,
    lv_tasklist        TYPE /tmwflow/tasklist,
    lt_system          TYPE TABLE OF /tmwflow/project_system_s,
    lt_transport       TYPE SOCMT_TRORDHC_TYPE.

  field-symbols:
    <fs_parameter> like line of lt_parameter,
    <fs_transport> like line of lt_transport.

*-------------------------------------------------------------------------

*check if classes are bound
  CHECK: ci_container IS BOUND,
         ci_parameter IS BOUND.

*get all parameters
  CALL METHOD ci_parameter->get_values
    RECEIVING
      values = lt_parameter.

*process every matching parameter "ZLIAC_SYSTEM_ROLE_EXISTS_<SYSTEM_ROLE>". Please have a look at transaction MAINT_ROLES for valid system roles.
  loop at lt_parameter[] assigning <fs_parameter> where element(25) = 'ZLIAC_SYSTEM_ROLE_EXISTS_'.

*Crear result because this is a new run.
    clear lv_result.

*This is the first run. Therefore we have to get some information once.
    if lv_system_role is initial.

*Get Change Document
      CALL METHOD ci_container->get_value
        EXPORTING
          element_name = 'BUSINESSOBJECT'
        IMPORTING
          data         = ls_object.

* Extract GUID
      lv_guid = ls_object-instid.

*Exit if it is no valid context.
      if lv_guid is initial.
        return.
      endif.

*Get assigned tasklist
      CALL METHOD cl_hf_helper=>get_bo_tasklist_of_chng_doc
        EXPORTING
          im_change_document_id = lv_guid
        RECEIVING
          return                = lv_doc_flow_id.

      lv_tasklist = lv_doc_flow_id.

*Exit if it is no valid context.
      if lv_tasklist is initial.
        return.
      endif.

*get systems from tasklist
*If we need more information, we have to use /TMWFLOW/PROJECT_GET or /TMWFLOW/PROJECT_READ to get project id and /TMWFLOW/TRANSPORT_TRACK_GET to get extended system information.
      CALL FUNCTION '/TMWFLOW/TASKLIST_SYSTEMS_GET'
        EXPORTING
          id_tasklist       = lv_tasklist
          id_current_track  = 'X'
        TABLES
          et_project_system = lt_system[]
        EXCEPTIONS
          project_not_found = 1
          OTHERS            = 2.

*Exit if it is no valid context.
      if sy-subrc <> 0.
        return.
      endif.

*get transport requests of change document
      CALL METHOD /tmwflow/cl_transport=>get_chng_doc_transp_req
        EXPORTING
          iv_header_guid = lv_guid
        IMPORTING
          et_transp_req  = lt_transport[].

*We are only interested in transport tracks.
*It is OK if we have no transports yet.
      SORT lt_transport[] by transport_track.
      DELETE ADJACENT DUPLICATES FROM lt_transport[] COMPARING transport_track.

    endif.

*Extract system role to be checked now.
    lv_system_role = <fs_parameter>-element+25(1).

*Check every used transport track.
    LOOP AT lt_transport[] assigning <fs_transport>.

*Is system role used?
      READ TABLE lt_system[]
           WITH KEY transport_track = <fs_transport>-transport_track
                    system_role     = lv_system_role
           TRANSPORTING NO FIELDS.

      check sy-subrc = 0.

*Yes system role is in use!!!
      lv_result = abap_true.
      exit.

    ENDLOOP.

*if there are no transport requests, check all project tracks.
    IF sy-subrc NE 0.

      do 1 times.

*Is system role used?
        READ TABLE lt_system[]
             WITH KEY "transport_track = <fs_transport>-transport_track
                      system_role     = lv_system_role
             TRANSPORTING NO FIELDS.

        check sy-subrc = 0.

*Yes system role could be used!!!
        lv_result = abap_true.
        exit.

      enddo.

    endif.

*set output parameter
    CALL METHOD ci_parameter->set_value
      EXPORTING
        element_name = <fs_parameter>-element
        data         = lv_result.
*            RECEIVING
*              retcode      = lv_subrc.

  endloop.

endmethod.

Change Request Management Critical Objects Check and Approval

How to activate and configure the “Critical Objects Check and Approval” feature?

COA is a powerful ChaRM feature to prevent the release of transport requests containing critical objects. It can easily be activated. We need only a little bit UI Configuration (field Critical Objects), Customizing (Actions “Process Critical Object” and Partner Function “Change Manager”), Authority Assignment (Approval Authority) and Master Data Maintenance (Activation + Definition of Critical Objects).
This short guide explains all steps which need to be done. Additional it explains how to mark all changes as critical or how to mark all configuration changes of a certain customizing table as critical independent from the way of maintenance (table, view, view cluster, IMG, SE16, …).

Change Request Management Critical Objects Check and Approval.pdf (808.2 KiB)

Change Request Management Dual Landscape Synchronization with Retrofit

Handbuch zum automatischen Abgleich von systemübergreifenden Parallelentwicklungen mittels Retrofit

In Systemlandschaften, in denen an mehreren Releases gleichzeitig gearbeitet wird, können Änderungen in unterschiedlichen Entwicklungssystemen vorgenommen werden. So können im Entwicklungssystem Neuerungen entwickelt werden und gleichzeitig in einem Wartungssystem für die produktive Systemlandschaft Fehler korrigiert oder Verbesserungen vorangetrieben werden. Wichtig ist in diesem Fall der regelmäßige Abgleich der Systemstände. Da Arbeiten parallel ausgeführt wurden, sind Änderungen nicht über einfache Transporte von Aufträgen ins jeweils andere System möglich, da die Gefahr besteht, dass aktuelle Softwarestände überschrieben werden und Inkonsistenzen entstehen. Um dies zu vermeiden, können Sie einen kontrollierten Abgleich in das jeweilige Zielsystem durchführen. Dieser Vorgang heißt „Parallelabgleich“, „Duale Landschaftssynchronisierung“, „Transportnachbereitung“ bzw. „Retrofit“.

Change Request Management Retrofit.pdf (1.5 MiB)

IT Service Management & Change Request Management My Messages Widget

How to create and use own widget variant configurations?

The “My Messages Widget” feature can be used as very helpful end-user´s inbox. You are able to configure own widget variants to satisfy all business needs.
However, you have to do some developments to make these customer specific variants useable. This short guide explains which development and configurations activities need to be done to make own widget variants useable.

IT Service Management My Messages Widget.pdf (540.6 KiB)