Logging-Praktiken für SAP Cloud Integration
Wie wir in der ehemaligen CPI Kopiervorlagen zum iFlow Logging verwenden und was unser Groovy Logging-Skript leistet
Bei der Arbeit mit der Cloud Integration Capability der SAP Integration Suite sehen wir alltäglich, dass das Standard-Logging und -Monitoring der SAP nicht ausreicht.
Das größte Problem liegt darin, dass SAP Cloud Integration standardmäßig fast nichts zu erfolgreichen Nachrichten protokolliert. Auch im Fehlerfall protokolliert SAP Cloud Integration lediglich die unmittelbare Fehlermeldung, was oft nicht ausreicht, um die genaue Ursache des Fehlers zu ermitteln. In solchen Situationen bleibt häufig nur die Option, die Nachricht erneut an die Cloud zu senden und dabei den erweiterten TRACE-Modus zu aktivieren, um zusätzliche Informationen zu erfassen und die Fehlerursache zu identifizieren.
Dadurch ist es unmöglich oder nicht praktikabel, den Integrationsstatus von Geschäftsobjekten nachzuvollziehen und den Erfolg oder Misserfolg von Integrationsvorgängen zu einem Geschäftsobjekt zurück zu verfolgen. Man muss das sendende oder empfangende System prüfen, um den Status eines Prozesses oder Objektes zu erkennen.
Wie wir in der ehemaligen CPI Kopiervorlagen zum iFlow Logging verwenden und was unser Groovy Logging-Skript leistet
Bei der Arbeit mit der Cloud Integration Capability der SAP Integration Suite sehen wir alltäglich, dass das Standard-Logging und -Monitoring der SAP nicht ausreicht.
Das größte Problem liegt darin, dass SAP Cloud Integration standardmäßig fast nichts zu erfolgreichen Nachrichten protokolliert. Auch im Fehlerfall protokolliert SAP Cloud Integration lediglich die unmittelbare Fehlermeldung, was oft nicht ausreicht, um die genaue Ursache des Fehlers zu ermitteln. In solchen Situationen bleibt häufig nur die Option, die Nachricht erneut an die Cloud zu senden und dabei den erweiterten TRACE-Modus zu aktivieren, um zusätzliche Informationen zu erfassen und die Fehlerursache zu identifizieren.
Dadurch ist es unmöglich oder nicht praktikabel, den Integrationsstatus von Geschäftsobjekten nachzuvollziehen und den Erfolg oder Misserfolg von Integrationsvorgängen zu einem Geschäftsobjekt zurück zu verfolgen. Man muss das sendende oder empfangende System prüfen, um den Status eines Prozesses oder Objektes zu erkennen.
Wie wir in der ehemaligen CPI Kopiervorlagen zum iFlow Logging verwenden und was unser Groovy Logging-Skript leistet
Bei der Arbeit mit der Cloud Integration Capability der SAP Integration Suite sehen wir alltäglich, dass das Standard-Logging und -Monitoring der SAP nicht ausreicht.
Das größte Problem liegt darin, dass SAP Cloud Integration standardmäßig fast nichts zu erfolgreichen Nachrichten protokolliert. Auch im Fehlerfall protokolliert SAP Cloud Integration lediglich die unmittelbare Fehlermeldung, was oft nicht ausreicht, um die genaue Ursache des Fehlers zu ermitteln. In solchen Situationen bleibt häufig nur die Option, die Nachricht erneut an die Cloud zu senden und dabei den erweiterten TRACE-Modus zu aktivieren, um zusätzliche Informationen zu erfassen und die Fehlerursache zu identifizieren.
Dadurch ist es unmöglich oder nicht praktikabel, den Integrationsstatus von Geschäftsobjekten nachzuvollziehen und den Erfolg oder Misserfolg von Integrationsvorgängen zu einem Geschäftsobjekt zurück zu verfolgen. Man muss das sendende oder empfangende System prüfen, um den Status eines Prozesses oder Objektes zu erkennen.
Unsere Expertise
Unser iFlow Logging Groovy-Skript
Oft sehen wir, dass in den Cloud Integration Entwicklungs-Tenants unserer Kunden viele redundante Logging-Skripte verwendet werden, weil jeder Entwickler und Berater eine eigene Version mit den gerade benötigten Funktionen schreibt. Wiederverwendbarkeit und kontinuierliche Fortschritte an der Qualität der Skripte werden vergeudet.
Wir bieten ein universelles Logging-Skript an, welches einmalig in einem Cloud Integration Tenant deployt wird. Dafür verwenden wir eine globale Script Collection.
Jeder iFlow verwendet dann dieses eine globale Logging-Skript und konfiguriert über Properties dessen Funktionen.
Der Template iFlow:
Kopiervorlage für iFlow Logging
Wir liefern mit unserem iFlow Logging Skript einen Template-iFlow aus und passen ihn an Ihre Namenskonventionen und andere Besonderheiten an. Diese Kopiervorlage zeigt dann die Regeln für Logging in Ihrem System und sollte für jede neue Integration kopiert werden.
Auf diese Weise bleiben die Logging-Praktiken im ganzen System einheitlich und Entwickler müssen nicht wiederholt die gleichen Logging-Funktionen neu einrichten oder aufrufen.
Globales Groovy Logging-Skript
Ein Skript für alle Anwendungen: rufen Sie an jeder wichtigen Stelle jedes iFlows das gleiche Skript auf und steuern Sie dessen Funktionen mit Properties.
Template iFlow für Logging, Namenskonventionen und Good Practices
Gemeinsam erstellen wir eine Kopiervorlage für alle neuen iFlows, um Good Practices, Namenskonventionen und Logging zu vereinheitlichen.
Payload / Body Logging, wo und wann Sie es brauchen
Fügen Sie Logging-Schritte an wichtigen Stellen ein, wir empfehlen mindestens einen ganz zum Beginn und Ende jedes iFlows. Schalten Sie dann nach Bedarf das Logging der Message Bodies für alle oder einzelne Schritte ein und aus.
Custom Header Property Logging für Metadaten
Definieren Sie für jeden Logging-Step im iFlow, welche Properties und Header Sie dort loggen wollen. Diese Metadaten finden Sie dann direkt im Message Monitoring Log. Sie sind sogar suchbar. “Was ist der Status von Bestellung X?” – wir zeigen Ihnen, wie Sie sie finden.
Bis zu 89 Logging-Schritte pro iFlow
Unser Logging-Skript unterstützt aktuell bis zu 89 Logging Steps pro iFlow. Wir empfehlen Namen beginnend mit Log_010 bis Log_099 für Info-Logs und Err_010 bis Err_099 für die erwarteten Fehlerfälle. Err_000 bis Err_009 bleiben für Exception SubFlows reserviert.
Anonymisierung von Message Bodies
Falls ein iFlow personenbezogene Daten loggen würde, können Sie diese durch Sternchen (“*”) ersetzen, indem Sie einfach die Liste der betroffenen Feldnamen auflisten. Dies wird bisher für XML und JSON Formate unterstützt.
(Fast) nie wieder TRACE Logs?
Statt einen iFlow wiederholt für 10 Minuten auf TRACE zu schalten, um einen Fehler zu verstehen, können Sie mit unserer Lösung relevante Daten direkt in das Message Processing Log schreiben, einschließlich der Message Bodies. Das ersetzt nach unserer Erfahrung fast alle Anwendungen für TRACE Logs.
Interne Debugging-Logs
Unser Skript ist über Jahre getestet und bei mehreren Kunden eingesetzt worden.
Für alle zukünftigen Änderungen am Skript, oder falls doch noch ein Fehlerfall entdeckt wird, stehen interne Debugging-Logs ebenfalls bereit.
Ein Skript für alle Anwendungen: rufen Sie an jeder wichtigen Stelle jedes iFlows das gleiche Skript auf und steuern Sie dessen Funktionen mit Properties.
Template iFlow für Logging, Namenskonventionen und Good Practices
Gemeinsam erstellen wir eine Kopiervorlage für alle neuen iFlows, um Good Practices, Namenskonventionen und Logging zu vereinheitlichen.
Fügen Sie Logging-Schritte an wichtigen Stellen ein, wir empfehlen mindestens einen ganz zum Beginn und Ende jedes iFlows. Schalten Sie dann nach Bedarf das Logging der Message Bodies für alle oder einzelne Schritte ein und aus.
Custom Header Property Logging für Metadaten
Definieren Sie für jeden Logging-Step im iFlow, welche Properties und Header Sie dort loggen wollen. Diese Metadaten finden Sie dann direkt im Message Monitoring Log. Sie sind sogar suchbar. “Was ist der Status von Bestellung X?” – wir zeigen Ihnen, wie Sie sie finden.
Unser Logging-Skript unterstützt aktuell bis zu 89 Logging Steps pro iFlow. Wir empfehlen Namen beginnend mit Log_010 bis Log_099 für Info-Logs und Err_010 bis Err_099 für die erwarteten Fehlerfälle. Err_000 bis Err_009 bleiben für Exception SubFlows reserviert.
Falls ein iFlow personenbezogene Daten loggen würde, können Sie diese durch Sternchen (“*”) ersetzen, indem Sie einfach die Liste der betroffenen Feldnamen auflisten. Dies wird bisher für XML und JSON Formate unterstützt.
Statt einen iFlow wiederholt für 10 Minuten auf TRACE zu schalten, um einen Fehler zu verstehen, können Sie mit unserer Lösung relevante Daten direkt in das Message Processing Log schreiben, einschließlich der Message Bodies. Das ersetzt nach unserer Erfahrung fast alle Anwendungen für TRACE Logs.
Unser Skript ist über Jahre getestet und bei mehreren Kunden eingesetzt worden.
Für alle zukünftigen Änderungen am Skript, oder falls doch noch ein Fehlerfall entdeckt wird, stehen interne Debugging-Logs ebenfalls bereit.
Ein Skript für alle Anwendungen: rufen Sie an jeder wichtigen Stelle jedes iFlows das gleiche Skript auf und steuern Sie dessen Funktionen mit Properties.
Template iFlow für Logging, Namenskonventionen und Good Practices
Gemeinsam erstellen wir eine Kopiervorlage für alle neuen iFlows, um Good Practices, Namenskonventionen und Logging zu vereinheitlichen.
Fügen Sie Logging-Schritte an wichtigen Stellen ein, wir empfehlen mindestens einen ganz zum Beginn und Ende jedes iFlows. Schalten Sie dann nach Bedarf das Logging der Message Bodies für alle oder einzelne Schritte ein und aus.
Custom Header Property Logging für Metadaten
Definieren Sie für jeden Logging-Step im iFlow, welche Properties und Header Sie dort loggen wollen. Diese Metadaten finden Sie dann direkt im Message Monitoring Log. Sie sind sogar suchbar. “Was ist der Status von Bestellung X?” – wir zeigen Ihnen, wie Sie sie finden.
Bis zu 89 Logging-Schritte pro iFlow
Unser Logging-Skript unterstützt aktuell bis zu 89 Logging Steps pro iFlow. Wir empfehlen Namen beginnend mit Log_010 bis Log_099 für Info-Logs und Err_010 bis Err_099 für die erwarteten Fehlerfälle. Err_000 bis Err_009 bleiben für Exception SubFlows reserviert.
Falls ein iFlow personenbezogene Daten loggen würde, können Sie diese durch Sternchen (“*”) ersetzen, indem Sie einfach die Liste der betroffenen Feldnamen auflisten. Dies wird bisher für XML und JSON Formate unterstützt.
Statt einen iFlow wiederholt für 10 Minuten auf TRACE zu schalten, um einen Fehler zu verstehen, können Sie mit unserer Lösung relevante Daten direkt in das Message Processing Log schreiben, einschließlich der Message Bodies. Das ersetzt nach unserer Erfahrung fast alle Anwendungen für TRACE Logs.
Unser Skript ist über Jahre getestet und bei mehreren Kunden eingesetzt worden.
Für alle zukünftigen Änderungen am Skript, oder falls doch noch ein Fehlerfall entdeckt wird, stehen interne Debugging-Logs ebenfalls bereit.
Wenn Sie mit uns zusammenarbeiten, dann bekommen Sie
FAQ Logging
1. Wie funktioniert Logging in SAP Cloud Integration?
SAP selbst loggt nur Fehlermeldungen, aber keine Details zur Nachricht, die einen Fehler verursacht hat. Dadurch ist es häufig schwer oder unmöglich, die nötigen Testdaten zur Fehlerdiagnose zu extrahieren. Sie können ein eigenes Groovy-Skript schreiben, das beliebige Teile jeder Nachricht loggt, von spezifischen Metadaten wie einer Kundennummer oder Auftragsnummer bis hin zur gesamten Nachricht. Dabei gibt es aber einige wichtige Good Practices zu beachten.
2. Welche Good Practices gibt es zum Logging in der SAP Cloud Integration?
- Legen Sie einen zentralen iFlow als Kopiervorlage an (Template-iFlow), in dem Sie das Logging so implementieren, wie Sie möchten. Alle neuen iFlows werden dann aus Kopien dieser Vorlage aufgebaut, damit die Logging-Lösung bereits eingebaut ist.
- Schreiben oder kaufen Sie ein einzelnes zentrales Logging-Skript in der Skriptsprache Groovy und legen Sie es in einer Script Collection ab, damit alle iFlows darauf zugreifen können und neue Features und Bug Fixes nicht in einzelnen iFlows ausgerollt werden müssen.
- Loggen Sie nicht immer alle Payloads bzw. Message Bodies, um den Speicherplatz Ihrer Integration Suite nicht zu füllen. Schreiben oder kaufen Sie ein Skript, das einstellbar die Payloads loggen kann, wann Sie es brauchen.
- Loggen Sie wichtige Metadaten in Custom Header Properties, damit sie in den Message Processing Logs gefiltert werden können.
- Denken Sie an die Anonymisierung personenbezogener Daten im Logging!
Wenn Sie mit uns zusammenarbeiten, dann bekommen Sie
FAQ Logging
1. Wie funktioniert Logging in SAP Cloud Integration?
SAP selbst loggt nur Fehlermeldungen, aber keine Details zur Nachricht, die einen Fehler verursacht hat. Dadurch ist es häufig schwer oder unmöglich, die nötigen Testdaten zur Fehlerdiagnose zu extrahieren. Sie können ein eigenes Groovy-Skript schreiben, das beliebige Teile jeder Nachricht loggt, von spezifischen Metadaten wie einer Kundennummer oder Auftragsnummer bis hin zur gesamten Nachricht. Dabei gibt es aber einige wichtige Good Practices zu beachten.
2. Welche Good Practices gibt es zum Logging in der SAP Cloud Integration?
- Legen Sie einen zentralen iFlow als Kopiervorlage an (Template-iFlow), in dem Sie das Logging so implementieren, wie Sie möchten. Alle neuen iFlows werden dann aus Kopien dieser Vorlage aufgebaut, damit die Logging-Lösung bereits eingebaut ist.
- Schreiben oder kaufen Sie ein einzelnes zentrales Logging-Skript in der Skriptsprache Groovy und legen Sie es in einer Script Collection ab, damit alle iFlows darauf zugreifen können und neue Features und Bug Fixes nicht in einzelnen iFlows ausgerollt werden müssen.
- Loggen Sie nicht immer alle Payloads bzw. Message Bodies, um den Speicherplatz Ihrer Integration Suite nicht zu füllen. Schreiben oder kaufen Sie ein Skript, das einstellbar die Payloads loggen kann, wann Sie es brauchen.
- Loggen Sie wichtige Metadaten in Custom Header Properties, damit sie in den Message Processing Logs gefiltert werden können.
- Denken Sie an die Anonymisierung personenbezogener Daten im Logging!
FAQ Logging
1. Wie funktioniert Logging in SAP Cloud Integration?
SAP selbst loggt nur Fehlermeldungen, aber keine Details zur Nachricht, die einen Fehler verursacht hat. Dadurch ist es häufig schwer oder unmöglich, die nötigen Testdaten zur Fehlerdiagnose zu extrahieren. Sie können ein eigenes Groovy-Skript schreiben, das beliebige Teile jeder Nachricht loggt, von spezifischen Metadaten wie einer Kundennummer oder Auftragsnummer bis hin zur gesamten Nachricht. Dabei gibt es aber einige wichtige Good Practices zu beachten.
2. Welche Good Practices gibt es zum Logging in der SAP Cloud Integration?
- Legen Sie einen zentralen iFlow als Kopiervorlage an (Template-iFlow), in dem Sie das Logging so implementieren, wie Sie möchten. Alle neuen iFlows werden dann aus Kopien dieser Vorlage aufgebaut, damit die Logging-Lösung bereits eingebaut ist.
- Schreiben oder kaufen Sie ein einzelnes zentrales Logging-Skript in der Skriptsprache Groovy und legen Sie es in einer Script Collection ab, damit alle iFlows darauf zugreifen können und neue Features und Bug Fixes nicht in einzelnen iFlows ausgerollt werden müssen.
- Loggen Sie nicht immer alle Payloads bzw. Message Bodies, um den Speicherplatz Ihrer Integration Suite nicht zu füllen. Schreiben oder kaufen Sie ein Skript, das einstellbar die Payloads loggen kann, wann Sie es brauchen.
- Loggen Sie wichtige Metadaten in Custom Header Properties, damit sie in den Message Processing Logs gefiltert werden können.
- Denken Sie an die Anonymisierung personenbezogener Daten im Logging!
