Kontaktiere uns SAP FSM Lifehack: Verwendung eines benutzerdefinierten Objekts zur Verwaltung von Credentials
FSM hat eine Menge großartiger Funktionen, aber auch einige Schwachstellen, vor allem im Verwaltungsbereich, die unbemerkt bleiben.
Daher ist es Sache jedes Beraterteams, sie mit viel Phantasie zu umgehen. Eine davon ist die Speicherung und Pflege von technischen Prüfdaten, den so genannten Credentials. Wenn das Unternehmen das Potenzial von FSM voll ausschöpfen will, kommt es nicht umhin, Geschäftsregeln aufzustellen, die das Rückgrat der Systemautomatisierung bilden. Für einfachere Erweiterungen reicht der Implementierungsberater mit Aktionen wie Objekt erstellen/aktualisieren/löschen, E-Mail senden, Push-Benachrichtigungen usw. aus. Gibt es aber bereits komplexere Anforderungen, wenn z.B. eine Geschäftsregel mit ihrem aktualisierten Objekt eine andere Geschäftsregel aufrufen muss, mehrere Datensätze des Objekts zu aktualisieren sind und Daten an ein anderes System zu senden sind, muss der Berater zu Aktionen wie Webhook und FSM Webhook greifen. Diese Aktion besteht im Wesentlichen darin, die API aufzurufen, die bereits bestimmte Sicherheitselemente enthalten muss. Der Zweck dieses Blogs ist es, Sie zu inspirieren, wie Sie Ihr Management erleichtern können.
Als Beispiel nenne ich die Verwendung von Client ID und Client Secret, die in der FSM Webhook-Aktion eingegeben werden müssen. Die Erstellung von beidem ist im Verwaltungsbereich des Abschnitts „Kunden“ (auf der Ebene „Konto“) möglich. Das System generiert die Client-ID und das Client-Geheimnis, und hier entsteht die erste große Unannehmlichkeit. Es ist möglich, zu einem späteren Zeitpunkt auf die Kunden-ID zuzugreifen, aber wenn Sie das Kundengeheimnis nicht speichern, wenn es erzeugt wird, können Sie nicht mehr darauf zugreifen. Dies ist umso ärgerlicher, wenn mehrere Berater an der Einrichtung des Systems beteiligt sind, die diese Informationen kennen müssen.
Ein weiterer großer Nachteil ist, dass bei der Übertragung der erstellten Geschäftsregel vom Entwicklungssystem auf das Test- oder Produktionssystem das Client Secret erneut in das FSM Webhook-Ereignis eingegeben werden muss. Die Erfahrung hat uns gelehrt, dass viele manuelle Schritte die Wahrscheinlichkeit eines unvorhergesehenen Fehlers erhöhen, also haben meine Kollegen und ich eine Lösung gefunden.
Erstellen eines benutzerdefinierten Objekts
Wir haben ein neues benutzerdefiniertes Objekt mit dem Namen Credentials zum Speichern von Zugangsdaten mit folgenden Feldern erstellt: Name, Beschreibung, Benutzer, Passwort, Schlüssel.
Hinweis: Das Key Field ist für Client ID und Client Secret nicht erforderlich. Wir verwenden dieses Feld für Autorisierungstoken für externe Systeme wie ERP, Google Forms usw.
Wir werden dann die erhaltene Client-ID und das Client Secret als Datensatz eines neuen Objekts mit einem eindeutigen Namen erstellen.
Die auf diese Weise gespeicherten Anmeldeinformationen erleichtern den Administratoren die Zusammenarbeit und die Verwaltung der Sicherheit, da es möglich ist, regelmäßig eine neue ID + Secret zu generieren und die Systemsicherheit durch Ändern des Datensatzes dieses Objekts einfach wiederherzustellen, ohne alle Geschäftsregeln, die FSM Webhook enthalten, mühsam zu durchsuchen und die darin fest kodierten Anmeldeinformationen einzeln aktualisieren zu müssen.
Daten in Variablen der Geschäftsregeln auswählen
Anstatt den Wert der beiden Daten in einer Geschäftsregel fest zu kodieren, erstellen wir ein SELECT über unser neues Objekt in Variables. Es ist möglich, eine Variable des Typs „Value“ separat für Client-ID und Client Secret zu erstellen, aber wir haben uns für eine Variable des Typs „Array“ entschieden, da wir Geschäftsregeln verwenden, bei denen wir bis zu vier verschiedene Datensätze des Credentials-Objekts erfassen.
Wählen Sie ein Beispiel für Client ID und Client Secret:
SELECT a.udf.z_f_udo_credentials_user AS clientId, a.udf.z_f_udo_credentials_password AS clientSecret FROM UdoValue a WHERE a.udf.z_f_udo_credentials_name = ‚Client ID and Client Secret for API calls‘
In Fällen, in denen Sie mehrere Berechtigungsnachweise abrufen müssen, können Sie einen JOIN auf dasselbe UdoValue-Objekt anwenden und die Objekte anhand derselben UdoValue.meta abgleichen. Die Regel lautet: ein Datensatz für jeden neuen JOIN:
SELECT a.udf.z_f_udo_credentials_user AS ClientID, a.udf.z_f_udo_credentials_password AS ClientSecret, b.udf.z_f_udo_credentials_key AS GoogleForms FROM UdoValue a JOIN UdoValue b ON a.meta = b.meta
WHERE a.udf.z_f_udo_credentials_name = ‚Client ID und Client Secret für API-Aufrufe‘ AND b.udf.z_f_udo_credentials_name = ‚GOOGLE_FORMS‘
Hinzufügen von Daten zur Aktion
Der letzte Schritt besteht darin, eine Aktion des Typs FSM Webhook zu erstellen, bei der wir die aus dem Select abgerufenen Werte in den entsprechenden Feldern dieser Aktion verwenden – Client Id und Client Secret. In unserem Fall sind dies: $ {creds [0].clientId} und $ {creds [0].clientSecret}
Tipp: Im Feld Client Secret wird der geschriebene Wert nicht angezeigt. Ich empfehle daher, die angegebene Formel aufzuschreiben und dann einfach in das angegebene Feld zu kopieren.
Filip Žarnovický, CX-Berater
