Kategorie: SAP Solution Manager

Alles Wissenswertes rund um den SAP Solution Manager.

Prüfung kritischer Objekte / Critical Objects Check – Performanceoptimierung

Manchmal zweifle ich.

Nutzt überhaupt irgend jemand den SAP Solution Manager?

Gerade habe ich die Funktion „Prüfung kritischer Objekte / Critical Objects Check“ für 50.000 Objektdefinitionen getestet. Die Laufzeit von mehr als 10 Minuten für das Anlegen von Transportaufträgen, den Wechsel auf den AB „Transport Management“, das Erzeugen von ToCs oder die Freigabe von Transportaufträgen ist definitiv zu lang.

Wir alle wissen ja spätestens seit Einführung der Downgrade Protection (DGP), dass SAP SE gar nicht oder nur unter unrealistischen Laborbedingungen testet. Also hat auch hier SAP SE höchstens zwei bis drei kritische Objekte definiert und war dann mit der Performance sehr zufrieden.

Aber es muss doch da draußen auch Nutzer geben, die 10, 20, 100 oder sogar (wie wir) mehrere tausend kritische Objekte definieren?!

Zumal das Problem seit Einführung von Standard Changes im SAP Solution Manager 7.2 SP5 noch größer geworden ist, schließlich werden viele Anwender diese Änderungsart inklusive Whitelist-Feature nutzen wollen. Aber wenn da die Performance genauso ist, sehe ich schwarz.

Die schlechte Nachricht: SAP HANA hilft hier nicht viel. Das ist einfach nur richtig schlechte Programmierung.

Die gute Nachricht: Das Problem ist durch lokale Optimierungen lösbar:

Es kann so einfach sein.

Funktionsbaustein /TMWFLOW/RCK_CHECK_SM_CALL wird für die Durchführung der Prüfungen genutzt. Allerdings wird er viel zu häufig (einmal pro Transport, einmal pro Aufgabe, einmal pro ToC) aufgerufen. Eine Pufferung (ca. 60 Sekunden Gültigkeit des Puffers, implementiert mittels Enhancement-Technik) wirkt hier wunder.

Funktionsbaustein /TMWFLOW/BCO_READ_OBJECTS wird für das Lesen der Objektdefinitionen genutzt. Mittels Modifikation können folgende Optimierungen durchgeführt werden, die die Performance signifikant verbessern:

  • Die Nutzung sortierter interner Tabellen verhindert Full Table Scan.
  • Die Optimierung des SQL-Statements zum Lesen der ausschließlich benötigten Datensätze verhindert das prozessieren aller Datensätze.
  • Das Entfernen des Sortieren-Befehls aus der Loop-Schleife löste die Bremse.

Funktionsbaustein /TMWFLOW/BCO_CHECK_OBJECTS dient zur Durchführung der Objektprüfung durch Vergleich der Liste der kritischen Objekte mit dem Inhalt des zu prüfenden Transportauftrages. Sobald ein Objekt als kritisch identifiziert wird, wird es aus der Liste des Transportauftrageinhaltes in die Liste der kritischen Objekte verschoben. Diese Verschiebung kostet Zeit/Performance. Zudem ist diese Verschiebung u.U. gar nicht gewollt, da ein Objekt ggf. zu mehreren kritischen Objektdefinitionen passen kann und dann auch mehrfach angemahnt (und genehmigt) werden sollte. Folglich sollten alle Löschoperationen auf den internen Tabellen lt_bao6163 und lt_e071k per Modifikation entfernt werden. Außerdem sollten auch hier sortierte interne Tabellen genutzt werden und sofern möglich auf den Vergleichsoperator „contains pattern“ verzichtet werden.

Funktionsbaustein /TMWFLOW/RCK_APPLY_SPECS wird genutzt um die Liste der kritischen Objekte mit den bereits genehmigten kritischen Objekten abzumischen. Hier sollten ebenfalls sortierte interne Tabellen genutzt werden um performanceoptimal zu arbeiten. Zudem ist hier eine Fehlerkorrektur erforderlich, um zu verhindern, dass Genehmigung nicht wieder verloren gehen und um sicherzustellen, dass jede Objekt- oder Subobjektgenehmigung für nur genau dieses Objekt/Subobjekt angewendet wird.

Die Prüfung eines Transportauftrages mit 40.000 Objekten gegen eine Objektliste mit 40.000 kritischen Objekten dauert jetzt ca. 20 Sekunden statt vorher mehr als 20 Minuten.

Conditional mandatory field checks for tables

In Web UI it is possible to specify mandatory fields which should be checked by Web UI framework on every round trip. This is working for normal fields on details screen as well as for table fields. Developers don’t need to check these fields. They don’t need to create or delete corresponding error messages. Framework is doing it for free.

Please note that fields on detail screen can be configured as mandatory. However configuration is not working for tables. And: Configuration is not working for conditional mandatory fields at all. That is why we sometimes need following solution which is very powerful and easy to implement.

Actions you have to perform as developer:

  1. Redefine method DO_VALIDATE_INPUT of view controller.
  2. Perform some checks to find out whether fields are mandatory or not (in case they are not always mandatory).
  3. Build binding string and attribute path. For tables it is „//<contextnode>/Table[<index>].<fieldname>“. For structure fields it is „//<contextnode>/STRUCT.<fieldname>“ (standard fields from BOL/GenIL) or „//<contextnode>/EXT.<fieldname>“ (AET fields) or „//<contextnode>/<fieldname>“ (virtual fields).
  4. Register mandatory field by using method POST_MANDATORY_FIELD.

Important remark for tables: Sometimes it happens that mandatory checks are getting confused: Framework is not alerting empty fields or framework is alerting even if fields are not empty. Also custom sorting can be skipped or raising short dumps or just going wrong. In general (and especially in these cases) please ensure that you call method CLEAR_LAST_LINE in method ON_NEW_FOCUS before you perform sorting or mandatory checks.

Please note: SAP Solution Manager IT Service Management has an own solution to perform status dependent mandatory field checks. Maybe if we integrate this check here we would enable the framework to display mandatory fields with red color and star. I haven’t tried it yet. But I would expect this helpful behaviour…

Validate partner types / Restrict partner functions to specific partner types only

In ChaRM and ITSM we are using several partner functions. These partner functions can hold contact partners (external business partners, e.g. Requester), employees (internal end-users, e.g. Developer) and organizational units resp. groups (of internal organizational model, e.g. Support Team).

We want to validate that for partner functions which should hold a organizational unit only organizational units can be maintained/selected. We also want to ensure that employees are always business partners with a valid SAP user id assigned. A contact partner should always be a business partner with the role „Contact Partner“.

However this validation cannot be done in SAP CRM standard, because SAP CRM standard is not supporting the check „Organizational Unit only“.

Solution:

Please create your own partner function types using view cluster COMV_PARTNER_PFT (SM34). Note that „0005 Emloyee“ and „0007 Contact Person“ can be used as it is. But „0008 Person Responsible“, „0016 Support Team“ and „0034 Organization Responsible“ needs to be copied in customer namespace 9XXX and corrected. Please ensure following flags:

  • 0005: Not unique at Doc./Item Level, Central Person
  • 0007: Not unique at Doc./Item Level, Contact Person
  • 9008: Unique at Doc./Item Level, Central Person
  • 9016: Not unique at Doc./Item Level, Central Person + Central Person or Org.Unit
  • 9034: Unique at Doc./Item Level, Central Person + Central Person or Org.Unit

Please adjust definition of partner functions in view COMV_PARTNER_FCT (SM30) and exchange partner function type by our (new) types. Note that you are not allowed to do this for SAP standard partner functions.

Please note that it can happen that you have to adjust mapping configuration in view AIC_PARTNER_FCT + CRMV_ORLALL_BTIL as well in case you are changing partner function types. This is specific to ITSM/ChaRM only.

Please note that it can happen that you have to configure business partner relationship assignment or that you have to adjust partner determination based on business partner relationship. (Only needed if you are changing partner function type. If you are in parallel changing business partner relationship. If you are using partner determination based on business partner relationship.)

Depending on you changes, it can also happen that you have to run report CRM_INDEX_REBUILD (if order index fields get changed because of partner function type change).

Please modify function module COM_PARTNER_CHECK_MASTER_DATA:

  • Check for Central Person: Perform check only if check for „Central Person“ is activated and check for „Central Person or Org.Unit“ is deactivated.
  • Check for Central Person or Org.Unit: Perform check only if check for „Central Person“ is deactivated and check for „Central Person or Org.Unit“ is activated.
  • Check for Org.Unit (new check): Perform check only if check for „Central Person“ is activated and check for „Central Person or Org.Unit“ is activated. Here check for object type „O“ using function module BP_BUPA_GET_HROBJECT.

If you want, you can use SAP CRM Web UI message replacement feature to replace error messages COM_PARTNER-135 and COM_PARTNER-136:

  • Replace “Partner &1 (&2) is neither an employee nor an organizational unit” by “Partner &1 cannot be a &2. Please select a group.”
  • Replace “Partner &1 (&2) is not an emloyee” by “Partner &1 cannot be a &2. Please select a person.”

Remark: You can define and use your own partner function types. The given types were just examples.

Remark: This solution is not able to validate a partner function agains a business partner role „Developer“, „Tester“, „Change Manager“ etc. It is not able to validate against corresponding PFCG roles. Therefore this improvement is just a simple but very helpful improvement.

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