Gesicherte Suchen teilen

Gesicherte Suchen als Lösung zum Bereitstellen von „Arbeitsvorräten“:

Im SAP Solution Manager 7.0 wurden mittels Varianten des Reports CRM_DNO_SERVICE_MONITOR (Transaktion CRM_DNO_MONITOR) verschiedene Arbeitsvorräte für Endanwender geschaffen. Es gibt mehrere Möglichkeiten, diese Arbeitsvorräte im SAP Web Client UI wieder bereit zu stellen:

  1. Normale Vorgangssuche nach komplexen Kriterien
  2. Gesicherte Suche
  3. MyMessageWidget
  4. Inbox
  5. Servicemonitor

Die Lösung der „Gesichterten Suchen“ entspricht am ehesten dem aus dem SAP GUI und Work Center gewohnten Arbeitsvorrat.

Folgende Suchkriterien sind i.R. zu verwenden:

  • Vorgangsart
  • Status
  • Zugeordnet zu „Ich“ (ggf. alternativ: Mit meiner Beteiligung)

Gesicherte Suchen strukturieren:

Gesicherte Suchen werden aktuell als Flache Liste angezeigt. Eine Verwaltung als Baumstruktur mit Zusatzinformationen (z.B. Anzahl der Treffer) ist möglich: 2468458 – Neues Tray für eigene gesicherte Suche auf Startseite.

Gesicherte Suchen teilen:

Das Teilen von Gesicherten Suchen für alle Anwender einer Benutzerrolle ist mit dem Central Sharing Tool möglich. Allerdings erfüllt das nicht unsere Zwecke, da der Endanwender aktiv werden muss um die geteilten Suchen zu importieren. Außerdem steht die Suche dann zwar als zentrale Suche zur Verfügung, wird aber nicht auf der Startseite als „Von mir gesicherte Suche“ angezeigt.

Aus diesem Grund nutzen wir die andere Lösung mittels Anpassung der Einträge in Tabelle CRMD_SHORTCUT und CRMD_SHORTCUT_T. Zur Automatisierung wurde Report ZWUI_SHARE_SAVED_SEARCHES entwickelt.

Ablauf:

  1. Suche alle gesicherten Suchen welche mit dem Namen „SHARE:“ beginnen. Schränke Suche ggf. auf Benutzerrolle (APPLICATION), Ersteller (OWNER KEY) oder Bezeichnung (DESCRIPTION) ein.
  2. Ändere AUDIENCE TYPE von USER zu ROLE. Trage in AUDIENCE KEY die Benutzerrolle (Wert aus Feld APPLICATION) ein. Pflege Bezeichnung in Tabelle CDMD_SHORTCUT_T (Bezeichnung ohne „SHARE:“).

Hinweise:

  • Anwender welche teilbare gesicherte Suchen erstellen wollen, müssen diese nur mit „SHARE:“ benennen und den Report ausführen. Der Zusatz „SHARE:“ wird hierbei entfernt.
  • Alternative zur Identifizierung mittels „SHARE:“: Alle gesicherte Suchen eines dedizierter User oder eine dedizierte Benutzerrolle.
  • Die so geteilten gesicherten Suchen lassen sich nach Ausführung ändern. Hier dürfen jedoch nur die Suchwerte nicht jedoch die Selektionskriterien geändert werden.
  • Ändern sich auch die Suchkriterien, so müssen neue gesicherte Suchen angelegt werden. Wird der exakt selbe Name gewählt (ohne SHARE:), so wird die Gesicherte Suche überschrieben und ist dann nicht mehr geteilt. Anschließend ist der Name zu ändern + zu speichern, die andere gesicherte Suche (ohne „SHARE:“) zu löschen und der Report auszuführen um eine erneute Teilung zu erwirken. Alternative kann die zu ändernde gesicherte Suche gelöscht werden. Dann wird eine neue gesicherte Suche inkl. Namenszusatz „SHARE:“ erstellt und der Report ausgeführt.
  • Das Überschreiben von geteilten gesicherten Suchen ist nur vom Eigentümer der gesicherten Suche erlaubt, ansonsten erscheint eine Fehlermeldung. Der Eigentümer (OWNER) kann mittels SE16 in Tabelle CRMD_SHORTCUT geändert werden.
  • Beim Speichern von Gesicherten Suchen im Web UI kann nur ein sehr kurzer Name gewählt werden. Tatsächlich kann der Name aber bis zu 80 Zeichen lang sein. Hierzu müssen mittels SE16 die Texte in den Tabellen CRMD_SHORTCUT und CRMD_SHORTCUT_T angepasst werden.
  • Verweise: http://sapuniversity.eu/saved-searches-publish-a-search-to-all-users-of-a-sap-crm-business-role/

Gesicherte Suchen transportieren:

Gesicherte Suchen sind Personalisierungen und damit nicht transportierbar. Wir wollen aber ausnahmsweise einmalig alle Gesicherten Suchen aus DEV nach PRD transportieren, um die GoLive-Aktivitäten maximal zu automatisieren. Hierzu können wir in den GoLive-Workbench-Transport R3TR-TABU-Einträge für CRMD_SHORTCUT, CRMD_SHORTCUT_T und CRMT_DYN_QUERY mit Schlüssel „*“ aufnehmen. Hierdurch werden alle Gesicherten Suchen zum Zeitpunkt der Freigabe transportiert. Es ist keine manuelle GoLive-Aktivität erforderlich.

Der Report ZWUI_SHARE_SAVED_SEARCHES führt aktuell keine Transporte durch. Sofern häufig Änderungen an den geteilten gesicherten Suchen vorgenommen werden und ein Transport benötigt wird, wäre dies eine sinnvolle Erweiterung. Aktuell wird jedoch von einem einmaligen Transport aufgegangen.

*&---------------------------------------------------------------------*
*& Report  ZWUI_SHARE_SAVED_SEARCHES
*&
*&---------------------------------------------------------------------*
*& Share saved search to all users of a business role.
*&---------------------------------------------------------------------*
REPORT zwui_share_saved_searches.

TABLES:
crmd_shortcut.

SELECT-OPTIONS:
s_appl FOR crmd_shortcut-application,
s_owner FOR crmd_shortcut-owner_key,
s_descr FOR crmd_shortcut-description.

PARAMETER:
p_prefix TYPE crmd_shortcut-description DEFAULT 'SHARE:',
p_test TYPE oax DEFAULT abap_true.

*-------------------------------------------------------------------------
START-OF-SELECTION.

DATA(lv_description) = p_prefix && '%'.
DATA(lv_start) = strlen( p_prefix ).

*Get datasets according to search criteria.
SELECT *
INTO TABLE @DATA(lt_shortcut)
FROM crmd_shortcut
WHERE application IN @s_appl AND
owner_type = 'USER' AND
owner_key IN @s_owner AND
description IN @s_descr AND
description LIKE @lv_description.

*-------------------------------------------------------------------------
END-OF-SELECTION.

DATA:
lt_shortcut_update   TYPE TABLE OF crmd_shortcut,
lt_shortcut_t_insert TYPE TABLE OF crmd_shortcut_t.

*process every found entry.
LOOP AT lt_shortcut ASSIGNING FIELD-SYMBOL(<fs_shortcut>).

WRITE: / <fs_shortcut>-description.

*Sharing already done.
IF <fs_shortcut>-audience_type = 'ROLE'.

*Inform end-user.
WRITE: '> Is already shared. Nothing to do.'.

*Share now!
ELSE.

*CRMD_SHORTCUT
<fs_shortcut>-audience_type = 'ROLE'.
<fs_shortcut>-audience_key = <fs_shortcut>-application.
APPEND <fs_shortcut> TO lt_shortcut_update.

*CRMD_SHORTCUT_T
APPEND INITIAL LINE TO lt_shortcut_t_insert ASSIGNING FIELD-SYMBOL(<fs_shortcut_t>).
MOVE-CORRESPONDING <fs_shortcut> TO <fs_shortcut_t>.
<fs_shortcut_t>-langu = sy-langu. "No multi language support.
<fs_shortcut_t>-description = <fs_shortcut>-description+lv_start.
SHIFT <fs_shortcut_t>-description LEFT DELETING LEADING space.

*Inform end-user.
WRITE: |> Is now shared to all users of business role { <fs_shortcut>-audience_key }.|.

ENDIF.

ENDLOOP.

*Perform database update to CRMD_SHORTCUT and CRMD_SHORTCUT_T.
*No update on CRMT_DYN_QUERY needed yet.
IF p_test = abap_false AND lt_shortcut_update IS NOT INITIAL.
UPDATE crmd_shortcut FROM TABLE lt_shortcut_update.
MODIFY crmd_shortcut_t FROM TABLE lt_shortcut_t_insert.

COMMIT WORK AND WAIT.
ENDIF.

Kundenfelder auf mehrere Zuordnungsblöcke verteilen

SAP CRM Geschäftsvorgänge (inkl. SAP Solution Manager ITSM und ChaRM) können sehr einfach um kundeneigene Felder erweitert werden. Die Erweiterung erfolgt üblicherweise mittels Application Enhancement Tool (AET). Hierbei wird die Tabelle CRMD_CUSTOMER_H entsprechend erweitert.

Alternativ können auch CRMD_ORDERADM_H, CRMD_SERVICE_H und andere Teile des Geschäftsvorganges erweitert werden. Alternativ zum AET kann auch die Easy Enhancement Workbench (EEWB) genutzt werden. Oder aber man prägt manuell die Customer-Includes aus oder hängt Append-Strukturen an. Hier ist zu beachten, dass die Erweiterung mittels AET die bevorzugte Variante ist und die einzige Möglichkeit darstellt, um sicherzustellen, dass die neuen Felder auch von der Web UI Suche, dem SAP CRM Interactive Reporting etc. unterstützt werden.

Im SAP Web Client UI ist es vorgesehen, dass diese zusätzlichen Felder entweder im Detailsformular oder im Zuordnungsblock „Kundenspezifische Felder“ (manchmal auch „Benutzerspezifische Felder“ genannt) angezeigt werden. Bei sehr vielen kundeneigenen Feldern ist jedoch eine Verteilung auf mehrere Zuordnungsblöcke sinnvoll, erst recht wenn einige Zuordnungsblöcke abhängig von Berechtigungen ausgeblendet werden sollen. Hierfür sind folgende „Programmieraktivitäten“ durchzuführen:

  1. Paket ZWUI o.ä. anlegen.
  2. Erweiterungsset ZWUI o.ä. anlegen.
  3. Erweiterungsset aktivieren in View BSPWDV_EHSET_ASG. (Dies wird nicht transportiert und muss bei Go-Live wiederholt werden!)
  4. UI-Komponente AIC_CMCR_H erweiteren zu ZAIC_CMCR_H. (AIC_CMCD_H, AIC_INCIDENT_H etc. analog)
  5. Component Usages ZUBTCustomerH_01, ZUBTCustomerH_02, ZUBTCustomerH_03 o.ä. mit Verweis auf UI-Komponente BT_CUSTOMER_H hinzugefügen.
  6. Zuvor angelegte Component Usages der Overview Page zugewiesen.
  7. Kontextknotenbindung für „ZUBTCustomerH*“ implementieren (Component-Controller -> WD_USAGE_INITIALIZE).
  8. Konfiguration der Übersichtsseite und hierbei Einblenden der Zuordnungsblöcke abhängig von der Vorgangsart.
  9. Konfiguration der Zuordnungsblöcke abhängig vom Namen der Component Usage.
  10. Zum Steuern der Sichtbarkeit der neuen Zuordnungsblöcke sei auf Blog Zuordnungsblöcke bzw. Tabs im SAP Web Client UI dynamisch ausblenden verwiesen.

Zuordnungsblöcke bzw. Tabs im SAP Web Client UI dynamisch ausblenden

Mittels UI-Konfiguration lassen sich Zuordnungsblöcke in der Vorgangsbearbeitung flexibel konfigurieren. Teilweise kann die Konfiguration abhängig von der Vorgangsart oder dem Status gestaltet werden, sofern dies von der UI-Komponente vorgesehen ist.

Ein dynamisches Ausblenden von Zuordnungsblöcken, z.B. bei fehlender Berechtigung, ist jedoch nicht vorgesehen. Mit einer kleinen Erweiterung des SAP-Standards ist das aber kein Problem. Diese Erweiterung funktioniert sowohl für SAP CRM als auch für SAP Solution Manager ITSM und SAP Solution Manager ChaRM.

Erweiterung am Ende von Methode cl_crm_uiu_bt_tools=>get_ovviews_header:

*Here we hide one customer_h assignment block according to authority.

data:
  ls_deactive_views like line of lt_deactive_views.

*Perform authority check
AUTHORITY-CHECK OBJECT ...

IF sy-subrc NE 0.
  ls_deactive_views-component = 'BTCUSTOMER_H'.
  ls_deactive_views-viewname = 'ZUBTCustomerH_01.BTCUSTOMER_H/MainWindow'.
  append ls_deactive_views to lt_deactive_views.
endif.

*Compare on component name and view name is not enough, because we need to compare on component usage in case we have more than one BTCUSTOMERH assignment blocks.
data(lt_static_views) = it_static_views.
loop at lt_static_views assigning field-symbol(<fs_static_views>) where viewid cp 'ZUBTCustomerH*'.
  <fs_static_views>-VIEWNAME = <fs_static_views>-viewid.
endloop.

*Rebuild result.
get_ovviews_return_tables( EXPORTING it_static_views = lt_static_views it_deactive_views = lt_deactive_views IMPORTING et_views_to_detach = et_views_to_detach et_views_to_reattach = et_views_to_reattach ).
*Here we hide all unauthorized assignment blocks (tabs).

data:
  ls_deactive_views like line of lt_deactive_views.

loop at it_static_views assigning field-symbol(<fs_static_views>).

*Perform authority check
AUTHORITY-CHECK OBJECT ...

IF sy-subrc NE 0.
  ls_deactive_views-component = <fs_static_views>-component.
  ls_deactive_views-viewname = <fs_static_views>-viewname.
  append ls_deactive_views to lt_deactive_views.
endif.

endloop.

*Rebuild result.
get_ovviews_return_tables( EXPORTING it_static_views = lt_static_views it_deactive_views = lt_deactive_views IMPORTING et_views_to_detach = et_views_to_detach et_views_to_reattach = et_views_to_reattach ).

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.