Welche Retrofit-ToCs können aus der Importqueue gelöscht werden?

SAP Note 2636996 – Retrofit Transport of Copies remains in Import Queue after performing Manual Retrofit

Extrakt aus dem SAP-Hinweis:

Cause

  • If you perform changes manually in the Retrofit System, then the Transport of Copies generated when releasing the Transport Request from ChaRM will stay in the Import Buffer
  • Performing changes manually in the Retrofit System in this manner is an exceptional situation, and in this case the ChaRM Retrofit scenario does not have a mechanism to delete the Transport of Copies from the Import Buffer of the Retrofit System
  • Transport of Copies deletion will not occur automatically when the Retrofit data is generated and then you decide to make the same changes (which were previously done in the Maintenance Development System) manually in the Retrofit System without using the ChaRM Retrofit Tool
  • This needs to be performed manually at TMS level

Resolution

For each Retrofit Transport of Copies currently remaining in the Import Buffer:

  1. Ensure that the associated changes are fully completed manually in the Retrofit System
  2. Manually remove the Transport of Copies from the Import Buffer using Transaction code STMS

Mein Kommentar dazu:

So ein Quatsch. Natürlich wäre es sinnvoll, die ungenutzten ToCs beim abschließen des Retrofits automatisch aus der Importqueue zu löschen.

Ergänzung zum SAP-Hinweis: Welche ToCs können aus der Importqueue gelöscht werden?

  1. (Ermittle Original-Transport ohne TOC-Status bzw. Import-Returncode aus Tabelle /TMWFLOW/TOCASNG.)
  2. Ermittle Originaltransporten aus Tabelle /TMWFLOW/RFITC gemäß vorheriger Selektion und welche den Retrofitstatus <> „“ [Retrofit bereits verarbeitet] und ggf. <> „D“ [Retrofit nicht automatisch verarbeitet] haben.
  3. Ermittle ToCs aus Tabelle /TMWFLOW/TOCASNG zu Originaltransporten aus vorheriger Selektion. Ermittle außerdem alle ToCs mit Status Inaktiv [Retrofitdaten wurden neu erzeugt].
  4. Die ermittelten ToCs können aus der Importqueue gelöscht werden, sofern noch nicht geschehen.

Genehmigungsprozess im Änderungsdokument für QA-Freigabe nutzen

Ausgangsituation:

Im Änderungsantrag gibt es Genehmigungsprozesse, um mehrstufige oder parallele Genehmigungen abbilden zu können. Im Änderungsdokument gibt es das nicht, wir benötigen das dort aber ebenfalls, um mehrstufige oder parallele Tests/QA-Freigaben abbilden zu können.

Lösung:

Wir stellen den Genehmigungsprozess auch für Änderungsdokumente bereit. Dies funktioniert ohne Entwicklungsaufwand für SAP Solution Manager 7.1 und 7.2. Aufwand: ca. 3 PT

Aktivitäten:

Im Folgenden werden die hierfür erforderlichen Konfigurationsschritte dokumentiert.

  1. Web UI:
    1. Feld Genehmigungsvorgang im Detailformular
    2. Zuordnungsblock Genehmigung in Übersichtsseite
    3. Suchkriterien auf Suchseite
    4. Felder im Änderungsprotokoll
  2. Genehmigungsprozess:
    1. Optional: Genehmigungspartner [i.R. Tester]
    2. Optional: Genehmigungstatusschema [i.R. SAP-Standard]
    3. Genehmigungsschritte (inkl. Vorgänger/Nachfolger)
    4. Genehmigungsvorgänge
    5. Genehmigungsfindungsschema
    6. Optional: Automatische Partnerfindung für Genehmigungsschritte
    7. Optional: Automatische Findung für Genehmigungsvorgang
  3. Statusfluss:
    1. Start der Genehmigung (C4AP) [i.R. Zu Testen]
    2. Statuswechsel bei erfolgreicher Genehmigung (CAAP) [i.R. Erfolgreich getestet]
    3. Statuswechsel bei Ablehnung [i.R. In Entwicklung]
    4. Optional: Statuswechsel bei „Nicht Relevant“
    5. PPF-Aktion für Statuswechsel (ZXXX_APPROVAL_PROCEDURE_STATUS)
    6. Prüfung, ob Genehmigungsvorgang und Partner für Schritte gewählt sind [i.R. Warnung: Angelegt + In Entwicklung; Abbruch: Zu Testen ChaRM-Konsistenzprüfung APPROVER_FILLED]
    7. Genehmigung wiederholen [i.R. in Entwicklung; ChaRM-Aktion APP_PROC_INI; ggf. als PPF-Aktion HF_EXECUTE_ACTION]
    8. Deaktivieren der alten PPF-Aktion zum Genehmigen/Testen mittels Aktion
  4. Workflow/Benachrichtigung:
    1. Automatisches Workflowcustmizing (SWU3)
    2. PPF-Aktion Workflowauslösung (ZXXX_IT_RFC_APPROVAL_WORKFLOW)
    3. Titel und Beschreibung für Workitem ändern (Texte der Aufgaben TS17107931 und TS17107930 in Transaktion PFTC überdefiniert; danach Puffer synchronisieren mittels TA SWU_OBUF)
    4. Workitems per Mail versenden (Report RSWUWFML2 als Job einplanen; User muss E-Mail-Adresse in SU01 haben.)
  5. Berechtigungen für Genehmigungen und Vertretungen:
    1. Berechtigungsobjekt CRM_APPRVL (Vorgang anlegen, Genehmigungsvorgang wählen, Schritte bearbeiten)
    2. Berechtigungsobjekt SM_APP_AP (Genehmigungsvorgang wählen, Schritte hinzufügen/löschen, Genehmigen für sich selbst, Genehmigen für andere)
    3. Berechtigungsobjekt B_BUPR_BZT (Hinzufügen/Löschen, BUR013: Pflegen eigene Vertreter)
    4. Berechtigungsobjekt B_BUPA_RLT (Anzeigen; Auswahl GP)
    5. Berechtigungsobjekt B_BUPA_RLT (Ändern, *: Pflegen Fremdvertretungen)
    6. Erweitertes Genehmigungsverfahren mit exakten Berechtigungen und Vertreterregelung (DNO_CUST04 -> ENH_APP)
    7. Optional: Keine Einschränkung der Vertreter auf eigene Orgeinheit (AGS_WORL_CUSTOM -> IM_BP_SEARCH_RESTRICT_DISABLE = X oder Berechtigungsobjekt SM_SDK_ACT mit SMSDACTION = „PROC“)
  6. Optimierungen (Modifikation/Erweiterung):
    1. Genehmigungsvorgang für Altvorgänge nachträglich auswählen (im SAP-Standard erfolgt Initialisierung des Approval-Sets beim Anlegen des Vorganges. Folglich können für bereits existierende Vorgänge keine Genehmigungsvorgänge gewählt werden. Die Prüfungen verhindern aber ein Weiterprozessieren ohne Genehmigung.) -> Modifikation in Methode CL_SRQM_RFC_REQUESTFORCH0_CN12->ON_NEW_FOCUS + Modifikation in FUBA CRM_APPROVAL_TRIGR_EC
    2. Beenden der Genehmigung sobald der erste Tester ablehnt (im SAP Standard müssen alle Genehmigungsschritte bearbeitet sein. Selbst wenn der erste Tester ablehnt, muss der zweite genehmigen/ablehnen. Einfluss auf das Ergebnis hat dies nicht.) -> Modifikation in FUBA AIC_SRQM_RFC_APPROVAL_STAT_EC

Das Textlog enthält viele unnütze technische Einträge. Die kann man ausblenden.

Hintergrund:

Zahlreiche Aktivitäten im ChaRM fügen Einträge im Textprotokoll hinzu. Nicht alle Einträge sind sinnvoll/hilfreich. Bei zu vielen Einträge leidet jedoch die Übersichtlichkeit.

Anforderung:

Ausblenden von ausgewählten Einträgen. Z.B. Erzeugen von ToCs.

Beispiele:

  • Leerer Auftrag DEVK908714 in Aufgabenplan M000000082 wurde gelöscht
  • Aktion Aufträge freigeben ohne offene Transportaufträge ausgeführt!
  • Aufträge werden gelöscht
  • Für die Aufträge DEVK908722 wurden Kopien DEVK908725 transportiert

Lösung 1:

Das Schreiben von Textprotokolleinträgen erfolgt mittels Methode „cl_hf_helper=>insert_notice“. Übergabeparameter ist die vollständige Textzeile.
Hier kann mittels Mustererkennung (z.B. regulärer Ausdruck) nach bestimmten Einträgen gesucht und das Schreiben unterbunden werden. Nachteil: Mustererkennung ist teilweise aufwendig und sprachabhängig.
Vorteil: Diese Lösung klappt für fast alle Einträge.

Lösung 2:

Das Schreiben von Textprotokolleinträgen erfolgt in den meisten Fällen mit „cl_chm1_instance->handle_message“ welche wiederum u.a. cl_hf_helper=>insert_notice ruft. Übergabeparameter sind hier Nachrichtenklasse, Nachrichtennummer und Nachrichtenparameter.
Hier kann somit die Filterung mittels Nachrichtenklasse/-nummer erfolgen. Nachteil: Funktioniert nicht für Fälle in denen cl_hf_helper=>insert_notice direkt benutzt wird (z.B. Statuswechsel, Protokollierungen des Aufgabenplans). Vorteil: Sehr einfach und sprachunabhängig.

Lösung 3:

Für transportbasierte ChaRM-Aktionen (z.B. Transportauftrag anlegen, freigeben, …) aus dem Transportverwaltung-Zuordnungsblock wird Methode CL_AI_CRM_ACTION_UTILITY->HANDLE_ACTION_LOG verwendet um Nachrichten ins Textlog zu schreiben. Der Text wird hier abhängig vom Aktionsnamen dem Customizing TSOCM_ACT_DEF entnommen. Sind hier keine Nachrichten für die betreffende Aktion gepflegt, wird keine Nachricht geschrieben. Folglich können Nachrichten durch entsprechendes Customizing ausgeblendet oder geändert werden. Beispieltext: „Aufträge DEVK908729 angelegt“

Lösung 4:

In der Regel lösen alle Aktionen des Aufgabenplanes eine Protokollierung im Textlog aus. Um hier Nachrichten auszufiltern oder zu ändern, ist Funktionsbaustein /TMWFLOW/APPL_STAT_MESSAGE am Ende zu erweitern. Es ist hierbei zu beachten, dass Nachrichtenklasse und –nummer der Pseudo-Konsistenzbedingung 0POSITIVE_FEEDBACK oder 0NEGATIVE_FEEDBACK aus Tabelle TSOCM_COND_DEF entnommen werden und für alle Aktionen gleich sind. Hier muss also eine Einbeziehung des Aktionsnamens (L_ACTION_MESSAGE-TASK_ID) sowie ggf. weiterer Parameter erfolgen, um eine sinnvolle Filterung zu ermöglichen. Funktionsbaustein /TMWFLOW/APPL_STAT_MESSAGE wird von Methode CL_AI_CRM_ACTION_UTILITY-> HANDLE_ACTION_LOG für Aktionen des Tansportmanagement-ABs und von Methode IF_EX_SOCM_PROCESS_ACTION~PROCESS_ACTION der ChaRM-Proxy-Klassen für ChaRM-Aktionen mit Aufgabenplaninteraktionen gerufen. Methode IF_EX_SOCM_PROCESS_ACTION~PROCESS_ACTION nutzt wiederum cl_chm1_instance->handle_message aus Lösung 2. Beispieltext: „Die Aktion Transportauftrag anlegen in System DEV 100 des Typs Ausgangssysteme ist erfolgreich abgeschlossen.“

Lösung 5:

Es gibt noch einzelne weitere Stellen, die eine Protokollierung im Textlog vornehmen. Beispielhaft sei auf CL_AIC_CM_S_SYSTEMLANDSCA_IMPL->LOGON_SYSTEM beim Anmelden am System verwiesen. Ein Eingriff ist hier in der Regel nur mittels spezifischer Modifikation möglich. Beispieltext: „Systemanmeldungsprotokoll. Zielsystem: DEV 100“

Vorschlag A: Lösung 2 mit selbstpflegender Customizingtabelle

  • Aufwand: 4h
  • Customizingtabelle mit Pflegedialog (Klasse, Type, Nummer, Parameter 1-4, Text, Flag [Aktiv, Inaktiv, Unbestimmt])
  • Enhancement in cl_chm1_instance->handle_message am Anfang
  • Algorithmus zum automatischen Befüllen mit bisher unbekannten Nachrichten
  • Logik zum ausblenden/ausfiltern von Nachrichten gemäß Customizingtabelle
  • Test

Vorschlag B: Zusätzlich Lösung 4 implementieren 

  • Aufwand 1h (zusätzlich)
  • Customizingtabelle um Feld TASK_ID ergänzen
  • Lösung aus cl_chm1_instance->handle_message in leicht abgewandelter Form auch am Ende von FUBA /TMWFLOW/APPL_STAT_MESSAGE implementieren.

Code-Schnipsel:

METHOD CL_CHM1_INSTANCE->HANDLE_MESSAGE .

ENHANCEMENT 1  ZSM_TEXT_LOG_FILTER.    "active version

DATA:
ls_tlf TYPE ZSM_TLF.

*Build message text.
MESSAGE ID im_message-msgid
TYPE     im_message-msgty
NUMBER   im_message-msgno

INTO     me->msg_text

WITH     im_message-msgv1
im_message-msgv2
im_message-msgv3
im_message-msgv4.

*Get customizing entry.
*We are not looking at message parameters actually...maybe in future.
SELECT SINGLE *
INTO ls_tlf
FROM ZSM_TLF
WHERE MSGID = im_message-msgid AND
MSGNO = im_message-msgno AND
MSGTY = im_message-msgty.

*Create customizing entry if not existing yet.
IF sy-subrc <> 0.
ls_tlf-MSGID = im_message-msgid.
ls_tlf-MSGNO = im_message-msgno.
ls_tlf-MSGTY = im_message-msgty.
ls_tlf-ACTIVE_FLAG = ''.
ls_tlf-MSGV1 = im_message-msgv1.
ls_tlf-MSGV2 = im_message-msgv2.
ls_tlf-MSGV3 = im_message-msgv3.
ls_tlf-MSGV4 = im_message-msgv4.
ls_tlf-langu = sy-langu.
ls_tlf-MSGTX = me->msg_text.
INSERT INTO ZSM_TLF values ls_tlf.
ENDIF.

*Check whether message should be filtered out.
IF ls_tlf-active_flag = '-'.

*   write message into ppf-log
CALL METHOD cl_log_ppf=>add_message
EXPORTING
ip_problemclass = '4'
ip_handle       = im_appl_log.

*  Exit routine without writing message to text log.
RETURN.

ENDIF.

ENDENHANCEMENT.

MESSAGE ID     im_message-msgid
TYPE   im_message-msgty
NUMBER im_message-msgno

INTO me->msg_text

WITH   im_message-msgv1
im_message-msgv2
im_message-msgv3
im_message-msgv4.

*   write message into ppf-log
CALL METHOD cl_log_ppf=>add_message
EXPORTING
ip_problemclass = '4'
ip_handle       = im_appl_log.

DATA  l_text255 TYPE char255.
l_text255 = me->msg_text.
*   write message into action-log (text in change document)
CALL METHOD cl_hf_helper=>insert_notice
EXPORTING
im_text = l_text255
im_guid = me->if_socm_instance_attributes~change_document_id.

ENDMETHOD.

E-Mail-Benachrichtigungen richtig konfigurieren

Eine sehr wichtige Funktionalität im SAP Solution Manager ITSM und SAP Solution Manager ChaRM ist die Versendung von E-Mail-Benachrichtigungen beim Statuswechsel. Früher mussten hier umständlich Smartform-Entwicklungen getätigt werden. Das geht mittlerweile dank der HTML-Mail-Forms deutlich einfacher. Dennoch ist die Konfiguration immer noch sehr aufwändig und fehleranfällig.

Hiermit gebe ich Ihnen gern ein paar Tipps an die Hand, um den Aufwand zu reduzieren und die Fehler zu minimieren:

  1. Deaktivieren Sie BADI CRM_ACTION_BADI in Transaktion SE19, da sonst die Benachrichtigung nicht korrekt funktioniert, sobald der Empfänger in mehreren Partnerfunktionen eingetragen ist.
  2. Definieren Sie möglichst wenige Mail-Formulare. In der Regel reicht ein einziges Formular mit Vorgangsnummer, Vorgangsbezeichnung und Anwenderstatus aus.
  3. Überlegen Sie sich eine sinnvolle Namenskonvention für die PPF-Aktionen, z.B. <Vorgangsart>_SEND_MAIL_<Rolle>_<Status>.
  4. Achten Sie auf folgende Eigenschaften der PPF-Aktionen:
    1. Sortiernummer größer als zugehörige [oder alle] Statuswechselaktion[en], da E-Mail nach dem Statuswechsel versendet werden soll.
    2. Verarbeitung beim Sichern
    3. Automatisch einplanen
    4. Partnerabhängig mit korrekter Partnerfunktion
    5. Einmalig: Max. 1 Aktion je Aktionsdefinition
      Mehrmalig: Max. 1 unverarbeitete Aktion je Aktionsdefinition
    6. Pflege der ID des zuvor angelegten MAIL-Formulars als Parameter der Verarbeitungsmethode SEND_MAIL_WITH_MAIL_FORMS (Registrierung des Mailformulars im Transportauftrag nicht vergessen! Standardmäßig werden Mail-Formulare nicht transportiert.)
  5. Planen Sie die Aktionen mit folgenden Bedingungen ein. Verwenden Sie für die Bedingungsdefinitionen am besten die gleichen Namen wie für die PPF-Aktionen. Es ist sehr unwahrscheinlich und zudem sehr gefährlich, dass Sie die Bedingungen für andere Aktionen wiederverwenden.
    1. Einmalige Aktionen beim Anlegen
      • Einplanbedingung: Keine
      • Startbedingung: keine
    2. Einmalige Aktionen bei Statuswechsel im Vordergrund mittels PPF-Aktion
      • Einplanbedingung: Keine
        Einplanbedingung: Vorangehender Status
      • Startbedingung: Aktueller Status
    3. Einmalige Aktionen bei Statuswechsel im Hintergrund durch Massenänderung CRM_SOCM_SERVIE_REPORT oder Folgebeleg SET_PREDOC oder Genehmigungsprozess oder Dropdownbox
      • Einplanbedingung: Keine
        Einplanbedingung: Aktueller Status
      • Startbedingung: Aktueller Status
    4. Einmalige Aktionen
      • Einplanbedingung: Keine
        Einplanbedingung: Vorangehender oder Aktueller Status
      • Startbedingung: Aktueller Status
    5. Mehrmalige Aktion bei Statuswechsel im Vordergrund mittels PPF-Aktion
      • Einplanbedingung: Vorangehender Status
      • Startbedingung: Aktueller Status
    6. Mehrmalige Aktion bei Statuswechsel im Hintergrund durch Massenänderung CRM_SOCM_SERVIE_REPORT oder Folgebeleg SET_PREDOC oder Genehmigungsprozess oder Dropdownbox
      • Einplanbedingung: Aktueller Status
      • Startbedingung: Aktueller Status und „STATUS_CHANGE = X“
    7. Mehrmalige Aktion
      • Einplanbedingung: Vorangehender oder Aktueller Status
      • Startbedingung: Aktueller Status und „STATUS_CHANGE = X“
    8. Beliebige Aktion
      • Einplanbedingung: Vorangehender oder Aktueller Status
      • Startbedingung: Aktueller Status und „STATUS_CHANGE = X“
    9. Hinweise:
      • Der Statuswechsel „CR: Laufende Implementierung -> Realisiert“ erfolgt im Hintergrund durch die Folgebelege
      • Der Statuswechsel „CR: Zu Genehmigen -> Genehmigt“ erfolgt im Hintergrund durch den Genehmigungsprozess
      • Incident, Problem und Service Request nutzen in der Regel keine PPF-Aktionen für den Statuswechsel. Das Verhalten ist hier analog zu den Hintergrundänderungen.
  6. Vergessen Sie das Testen nicht:
    1. Bedenken Sie beim Testen, dass der Empfänger verschieden vom Absender sein muss. Tragen Sie daher bei der Empfängerpartnerfunktion einen Geschäftspartner mit einer abweichenden E-Mail-Adresse ein.
    2. Spielen Sie die Prozesse (z.B. Änderungsantrag und Änderungsdokumente) einmal komplett mit den entsprechenden Statuswechseln durch.
    3. Durchlaufen Sie Schleifen mindestens zweimal. Vergessen Sie Sonderfälle wie das Zurückziehen oder den Vorabimport nicht.
    4. Führen Sie Statuswechsel einmal online und einmal per Massenänderung (z.B. Bestätigen von Änderungsdokument und Änderungsantrag) durch.

SAP CRM Web Client UI Session Timeout

Die aktuelle SAP CRM Web Client UI Sitzung wird im SAP CRM, im SAP Solution Manager IT Service Management und im SAP Solution Manager Change Request Management standardmäßig nach 30 Minuten Inaktivität automatisch beendet.

Um dieses Verhalten zu ändern, ist der Profilparameter „rdisp/plugin_auto_logout“ in Transaktion RZ11 entsprechend zu ändern. Zum Beispiel bewirkt ein Wert von 3600, dass die Sitzung eine Stunde lang erhalten bleibt.

Bitte beachten Sie, dass inaktive Sitzungen Systemressourcen belegen und eine Veränderung dieses Parameters negative Auswirkungen auf die Performance Ihres Systems haben kann. Außerdem bleiben Objektsperren die ganze Zeit erhalten.

Sollte die Sitzung trotz Änderung des Wertes früher als geplant ablaufen, prüfen Sie bitte auch die Profilparameter „icm/keep_alive_timeout“ und „icm/server_port_0 -> TIMEOUT“ (Siehe auch Transaktion SMICM -> Springen -> Parameter). Bitte stellen Sie außerdem sicher, dass die Änderungen entweder sofort wirken oder dass das System neu gestartet wird. Bitte stellen Sie außerdem sicher, dass die Änderungen bei einem Systemneustart erhalten bleiben.

Bitte beachten Sie, dass Sie zusätzlich im Technischen Profil der Benutzerrolle (SPRO -> CRM -> UI-Framework -> Technische Rollendefinition -> Technisches Profil) einstellen können, wie lange die Sitzung erhalten bleiben soll, wenn das SAP CRM Web Client UI verlassen wird (Browser schließen oder Navigation zu externer Webseite). Hier sollte der Wert auf wenige Sekunden eingestellt werden. Andernfalls werden Ihre Anwender vermehrt das Phänomen haben, dass Vorgänge von vermeintlich korrekt geschlossenen Sitzungen gesperrt sind und erst nach längerer Zeit wieder freigegeben werden.