Cloud Integration erlaubt uns die Veränderung über die Nachricht zu machen, so wie Mappings, oder die Konvertierung von einer Struktur zu der anderen. Cloud Integration ist nicht nur stark für die Manipulation der Datei, sondern auch für die Merkmale der Überwachung. Zusätzlich zu Debug- oder Trace-Modus wie in jeder Entwicklungs-IDE ermöglicht es uns auch, die notwendigen Informationen zu überwachen, ohne dass ein Debugging erforderlich ist.

Für jeden Service können wir das Log-Level auf 5 verschiedene Modi einstellen.

Die Standard-Log-Konfiguration ist auf Info eingestellt. Info ermöglicht es uns, den Status jedes Prozesses zu sehen, wie z.B. abgeschlossen, abgebrochen, fehlgeschlagen usw. In diesem Modus können wir weder die Header noch den Body sehen. Es ist wichtig, die Daten aus Sicherheitsgründen zu schützen und den Speicherverbrauch zu reduzieren.

Aber wenn der Prozess fehlschlägt, wie können wir das Problem herausfinden?
Trace-Modus ist nützlich, wenn dieselbe Request-Message empfangen werden kann. Bevor Nachrichten erhalten werden, sollte dieser Modus aktiviert werden. Im Trace können sowohl der Body als auch die Header bei jedem Schritt betrachtet werden.

Der Prozess, der einen Fehler verursacht, wird angezeigt. In diesem Modus ist es viel einfacher und schneller, den Schritt zu identifizieren, in dem der Fehler auftritt.

Allerdings erlaubt CPI uns, nur 10-Minuten im Trace zu bleiben, danach wechselt es automatisch wieder in den vorherigen Modus (Info, Error oder None). Zusätzlich ist die Nachricht nach einer Stunde nicht mehr erreichbar. Während der Entwicklung nutzen wir Trace sehr oft. In der Produktion können wir den gleichen Prozess nicht wieder triggern, wenn er einen Fehler bekommt. Aus Sicherheitsgründen ist es auch nicht empfohlen, die vollständige Nachricht in der Produktion offenzulegen.

Wie können wir in diesem Fall herausfinden, welche Nachricht einen Fehler enthält, ohne die gesamte Nachricht offenzulegen? Folgendes bietet SAP an:

Es gibt einige vorgefertigte Properties zum Überwachen und Filtern von Nachrichten. Diese Funktion ist sehr hilfreich, um den Status bestimmter Nachrichten zu verstehen und die Nachrichten im Monitoring zu filtern. Wir können diese Properties nach Bedarf anpassen. In diesem Beispiel wird die „Application Message ID“ durch die

Bestellnummer festgelegt, und der Bestelltyp wird als „Application Message Type“ bestimmt. Wenn diese Bestellung einen Fehler enthält, können wir die Bestellnummer direkt herausfinden, ohne die gesamte Nachricht offenzulegen.

Falls diese vorgefertigten Properties nicht ausreichen oder zusätzliche kundenspezifische Properties benötigt werden, können wir auch Custom-Monitoring-Header hinzufügen. Diese benutzerdefinierten Header gelten nicht als echte Header, und werden nicht an das Empfängersystem gesendet. Sie werden ausschließlich intern zu Monitoring-Zwecken verwendet.

Zusätzlich können wir die Nachrichten anhand von Monitoring-Properties und Custom-Headern filtern. Zum Beispiel haben wir 7 Nachrichten im Status „Completed“ mit dem Message Type „Initial Order“.

Allerdings haben wir nur eine Nachricht mit der Nummer 1000000 erhalten.

Normalerweise ist es nicht möglich, den Inhalt einer Nachricht während oder nach dem Prozess einzusehen. In einigen Fällen müssen wir jedoch den Nachrichteninhalt sehen, insbesondere wenn sich die Nachricht im Fehlerstatus befindet. Dafür können wir ein Attachment zu Monitoring-Zwecken erstellen. Attachments können in jedem Textformat vorliegen und sind konfigurierbar. Sie helfen uns bei der Identifizierung von Fehlern. Außerdem können Attachments so eingerichtet werden, dass sie nur im Fehlerfall angelegt werden.

Typische Szenarien sind:
– Einsicht in den gesamten Nachrichteninhalt an wichtigen Stellen, z. B. vor dem Mapping und nach dem Mapping.
– Im Fehlerfall ist der komplette Nachrichteninhalt an der Fehlerstelle.

Standardmäßig zeigt die Cloud Integration-Schnittstelle keine Nachrichten oder Header für die Benutzer an. Dies ist sowohl aus Sicherheitsgründen als auch für das Speichermanagement wichtig.

In einigen Fällen muss jedoch eine fehlgeschlagene Nachricht ohne Trace- oder Debug-Modus erkannt werden, insbesondere in der Produktionsumgebung. Um dies zu ermöglichen, können im Info-Modus die notwendigen Felder als Custom-Properties und Attachments festgelegt werden. Damit können wir identifizieren, welche Nachricht fehlgeschlagen ist.

Cloud Integration speichert Logs maximal für 1 Monat. Dieser Zeitraum dient dazu, Fehler zu bearbeiten und Probleme zu lösen.

The post Monitoring in SAP Cloud Integration appeared first on Rhein-Ruhr-Informatik.

SAP BTP ermöglicht die Bereitstellung verschiedener Services und Anwendungen, die jeweils eigene Role Collection enthalten. Diese Services werden häufig in unterschiedlichen Subaccounts betrieben. Zwar ist es möglich, Benutzer und Rollen separat in jedem Subaccount zu verwalten, jedoch gibt es auch eine zentralisierte Alternative.

Durch den Aufbau einer Vertrauensbeziehung zwischen dem Identity Service und den BTP-Subaccounts kann die Benutzer- und Rollenverwaltung über einen einzigen Identity Provider erfolgen.

In diesem Beitrag zeige ich Ihnen, wie man Role Collection Mapping zwischen BTP und dem Identity Authentication Service (IAS) einrichtet. Dadurch kann man die Rollenzuweisung für mehrere Subaccounts zentral über einen Identity Provider steuern.

Voraussetzungen

Wenn Sie über einen Identity Provider verfügen, können Sie diesen als benutzerdefinierten Provider für ein BTP-Subaccount konfigurieren. Er kann dann als Quelle für Benutzer und Role Collection verwendet werden.
Für die Einrichtung von Role Collection Mapping gelten folgende Voraussetzungen:

• Sie müssen im betreffenden Subaccount, der mit den SAP Cloud Identity Services verknüpft (vertrauend) wird, die Rolle Subaccount Administrator besitzen.
• Der SAP Cloud Identity Services-Mandant kann in einem anderen Subaccount abonniert sein, muss jedoch zum gleichen Global Account gehören und sich in derselben Region befinden.

Die Schritte zur Konfiguration der Vertrauensbeziehung (Trust Configuration) zwischen Ihrem Subaccount und dem SAP IAS-Mandanten finden Sie in folgendem SAP-Hilfedokument:

👉 SAML-Vertrauensbeziehung zwischen SAP-BTP-Unterkonto und IAS konfigurieren | SAP Help Portal

Hinweis: Um die Role Collection Mapping nutzen zu können, müssen Sie sich mit einem Benutzer anmelden, der im Identity Provider definiert ist – nicht mit einem BTP-Benutzer.

Konfigurationen

1. BTP Role Collections

Bevor ein Role Collection Mapping erstellt wird, stellen Sie sicher, dass Sie über alle benötigten Rollen verfügen, um auf die „Role Collections“ in Ihrem Subaccount zugreifen zu können.

Navigiere zu:

<Ihr Subaccount>          →    Security     →   Role Collections 

Sie können die Standard Role Collection verwenden, die für BTP-Anwendungen vordefiniert sind.

Alternativ können Sie eine neue benutzerdefinierte Role Collection erstellen, indem Sie oben rechts auf die Schaltfläche Create klicken.

SAP BTP Role Collections

In diesem Beispiel wird eine neue benutzerdefinierte Role Collection mit dem Namen „My_Custom_Role“ erstellt.

• SAP Cloud Identity Services

Bevor Sie mit der Konfiguration der Role Collection Mapping beginnen, müssen Sie sicherstellen, dass Sie benötigte Attribute an die Anwendung senden. Navigieren Sie in SAP Cloud Identity Service zu:

 Application & Resources   →  <Ihr Anwendung>  →  Single Sign-On  →  Assertion Attributes

Anwendungsseite in den SAP Cloud Identity Services

Unter den Assertion-Attributen muss ein „Groups“-Attribut vorhanden sein. Dieses Attribut wird an die Anwendung als BTP Role übermittelt.

Assertion Attributes einer Anwendung in den SAP Cloud Identity Services

Anschließend sollten Sie eine Gruppe für die BTP Role erstellen, die Sie zuordnen möchten. Navigieren Sie zu:
                        Users & Authorizations   →  Groups

Erstellen Sie eine neue Gruppe, wenn es bereits eine Gruppe existiert, fügen Sie die Benutzer hinzu, die diese Rolle erhalten sollen.

Gruppen und Benutzer in den SAP Cloud Identity Services

• BTP Role Collection Mapping

Jetzt sind wir bereit, das Role Collection Mapping durchzuführen. Navigieren Sie in Ihrem SAP BTP Subaccount zu
                        <Ihr Subaccount>   →   Security   →   Trust Configuration,

und klicken Sie auf den benutzerdefinierten Identity Provider, den Sie zu Beginn eingerichtet haben.

SAP BTP Trust Configurations

Klicken Sie auf New Role Collection Mapping und wählen Sie Ihre gewünschte BTP Role Collection aus (1). Dabei kann es sich sowohl um eine Standard- als auch um eine benutzerdefinierte Role Collection handeln.

Für das Feld „Attribute“ geben Sie bitte den Namen des Attributs an, das Sie im Identity Authentication Service (IAS) als Gruppenattribut definiert haben (2). In der Regel bleibt dies auf „Groups“ gesetzt.

Im Feld „Value“ geben Sie den Namen der IAS-Gruppe an, die der ausgewählten BTP Role Collection zugeordnet werden soll (3).

Speichern Sie anschließend die Konfiguration.

SAP BTP Role Collection Mapping

Die erstellten Mappings können Sie unter Role Collections einsehen.

SAP BTP Role Collections mit IAS-Gruppen verknüpft

Fazit:

• Sie können die zugewiesenen Rollen zentral im SAP Identity Authentication Service (IAS) verwalten, indem Sie die Mitglieder der entsprechenden IAS-Gruppe pflegen.
• Im BTP Subaccount sind die durch IAS zugewiesenen Benutzerrollen nicht direkt sichtbar. Diese Rollen werden dynamisch zugewiesen, sobald sich ein Benutzer über den IAS bei Ihrer Anwendung authentifiziert.

Hinweis:

Der Benutzer im IAS muss ebenfalls im entsprechenden SAP BTP Subaccount vorhanden sein. Weitere Informationen zur Benutzeranlage in BTP finden Sie unter folgendem Link:

👉 Arbeiten mit Benutzern | SAP Help Portal

Wir hoffen, dass Ihnen dieser Beitrag dabei hilft, Ihre BTP Role Collections effizient über Ihren Identity Provider zu verwalten!

Feyza Sahin

The post Verwaltung von BTP Role Collections über den SAP Cloud Identity Service appeared first on Rhein-Ruhr-Informatik.