Salesforce ist Ihr digitaler Front-Tier-Kern für Ihren Kundenerfolg, und Sie integrieren ERP-Systeme wie SAP, Webshops wie Amazon oder eBay, Zahlungssysteme wie PayPal, soziale Medien wie Facebook oder LinkedIn, Legacy-Datenpools wie Datenbanken, Dateien oder FTP in und aus Ihrem Salesforce, um mithilfe einer Middleware eine vernetzte und störungsfreie Kundenerfahrung zu erhalten. Es funktioniert einwandfrei, aber eines Tages stellen Sie fest, dass einige Daten, die von der Middleware gesendet wurden, fehlen. Sie sind sich nicht sicher, welche Daten auf Ihrer Salesforce-Seite angekommen sind und fragen sich: „Wo kann ich die Daten sehen, die von der Middleware gesendet wurden?“. Sie stellen die Frage nicht „Welche Daten wurden von der Middleware gesendet?“, denn die Middleware bietet Ihnen eine gute Überwachungsfunktion, um zu sehen, welche Daten die Middleware-Plattform verlassen.
Sie haben ein Personal- und Abrechnungssystem an Ihr Salesforce-System angeschlossen und müssen einen Datenverlauf für Ihre Wirtschaftsprüfungsabteilung aufbewahren, um den Nachweis für eine regelmäßig in Ihrem Unternehmen durchgeführte staatliche Sicherheits- und Rechnungsprüfung zu erbringen. Für einen solchen Prüfungsprozess reichen die Daten auf der einen Seite, z.B. auf der Absenderseite (Middleware), nicht aus und erfüllen nicht den Prüfungsstandard der Behörden. Diese verlangen von Ihnen, dass Sie die andere Seite, z.B. die Daten, die auf der Salesforce-Seite ankommen, zur Verfügung stellen. Wie werden Sie eine solche Protokollierung und Rückverfolgung der historischen Daten auf der Salesforce-Seite bereitstellen?
Da Sie eine Middleware verwenden, verfügen Sie über eine nette Funktion zur Benachrichtigung, wenn die Nachricht beim Senden an Salesforce fehlschlägt. Sie lieben diese Funktion, weil Sie nicht alle fünf Minuten aktiv auf die Überwachung Ihrer Middleware schauen müssen. Eines Tages stellen Sie fest, dass einige der Warnungen seltsame technische Fehlertexte enthalten wie:
“java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.AbstractStringBuilder.substring(AbstractStringBuilder.java:868)
at java.lang.StringBuilder.substring(StringBuilder.java:72)
at java.lang.AbstractStringBuilder.subSequence(AbstractStringBuilder.java:849)”
Sie erwarten jedoch eine klare Fehlermeldung wie „Angebot xx kann aufgrund eines ungültigen Vertriebsgebietscodes nicht gebucht werden“. Welchen der beiden Fehlertexte würden Sie gerne sehen?
Solche Situationen können und werden eines Tages bei Ihrer Salesforce-Integration auftreten, und wenn das passiert, werden Sie dann dieselbe Frage stellen, anstatt eine Lösung zur Behebung des Problems anzubieten? Lesen Sie den folgenden Aufsatz, wenn Sie die Lösung und die Antwort sehen wollen.
Wie sieht eine Middleware-Integration aus?
Werfen wir einen Blick auf die Salesforce-Integration mithilfe der Middleware und verstehen Sie. Für die Verbindung zu Salesforce stellt die Middleware einen technischen Konnektor bereit, der die SOAP- oder REST-API der Salesforce-Standard-API aufrufen und nutzen kann. Dabei wird das für APIs übliche Anfrage/Antwort-Muster verwendet, und jeder Aufruf wartet, bis der Vorgang auf der Salesforce-Seite abgeschlossen ist. Dies ist die Natur des synchronen API-Aufrufs, der dem Muster der eng gekoppelten Architektur folgt. Mit der Standard-API von Salesforce können Sie die vier grundlegenden sogenannten CRUD-Operationen durchführen, d. h. Sie können ein sObject erstellen, lesen, aktualisieren und löschen.
Neben diesen vier grundlegenden CRUD-Operationen gibt es keine weiteren zusätzlichen Fähigkeiten und Funktionen, die auf Ihrer Salesforce-Seite verfügbar sind. Sie werden sich vielleicht fragen, wie Sie mehr als diese vier grundlegenden CRUD-Vorgänge durchführen können? Ihre Integration muss zum Beispiel einen Kontakt aktualisieren, der in Ihrem ERP-System wie SAP geändert wurde. Vor der Aktualisierung müssen Sie jedoch in der Zuordnungsregel prüfen, ob der Kontakt den Status „Freigegeben“ hat und von der Vermittlergruppe „Vertriebsinnendienst“ gepflegt wird. Nachdem Sie den Kontakt aktualisiert haben, möchten Sie einige Bereinigungsvorgänge durchführen, um den Status in „Synchronisiert“ zu ändern. Das bedeutet, dass Sie den Kontakt nicht nur mit einigen Daten aktualisieren müssen, die in SAP geändert wurden. Sie benötigen eine Vor- und Nachbearbeitungslogik, die parallel zur Integration ausgeführt wird. Wie können Sie diese zusätzliche Geschäftslogik vor und nach der Integration ausführen?
Was fehlt hier?
Da Ihr Salesforce mit all den Anwendungen von Drittanbietern und Ihrer eigenen Anwendung zu einer so wichtigen digitalen Frontschicht für Ihren individuellen Erfolg wird, möchten Sie eine Integration der Unternehmensklasse haben, die über den Ansatz der API-Verbindung hinausgeht. In unserem anderen Artikel erfahren Sie mehr über die Einschränkungen und Auswirkungen der reinen API-Anbindung https://apsara-consulting.com/beyond-api/.
Für eine Integration der Unternehmensklasse benötigen Sie mehr als nur die API-Konnektivität. Möglicherweise müssen Sie Ihrer einfachen API-Integration Geschäftslogik hinzufügen. Möglicherweise benötigen Sie Überwachung, Warnmeldungen und eine einfache Möglichkeit, Fehler auf Ihrer Salesforce-Seite zu behandeln. Sie könnten in eine dringende Notfallsituation geraten, in der die Middleware nicht funktioniert und daher die Nachricht nicht rechtzeitig zur Verarbeitung zurücksenden kann. In diesem Fall wäre es eine große Hilfe, wenn Sie die Daten auf der Salesforce-Seite nach Bedarf ändern und eine erneute Verarbeitung vornehmen könnten. Darüber hinaus benötigen Sie aus architektonischer Sicht ein loses Kopplungsmuster, um den Massendatentransfer zu bewältigen, was nur durch die Verwendung einer asynchronen API möglich ist.
Warum eine entkoppelnde Diensteschicht erforderlich ist
Die oben erwähnten zusätzlichen Mehrwertdienste werden für eine Integration der Unternehmensklasse benötigt, die auf der Salesforce-Plattform nicht verfügbar ist und die Middleware nicht bieten kann. Um solche Dienste bereitzustellen, wird eine Entkopplungsschicht auf der Salesforce-Plattform benötigt, die die eingehenden Daten als Nachrichten zur Verarbeitung zu einem geeigneten Zeitpunkt bereitstellen kann. Da eine solche Schicht auf der Salesforce-Plattform nicht existiert, hat SKYVVA eine solche Schicht geschaffen, um alle Funktionen wie im obigen Diagramm beschrieben bereitzustellen.
Die Serviceschicht ist die technische Grundlage für jede Funktionalität, die eine asynchrone Ausführung der API-Verarbeitung ermöglicht. Ein asynchrones Muster ist ein entscheidender Faktor in der Integrationsarchitektur, da es die Fähigkeit zur Entkopplung und Unabhängigkeit des Betriebs bietet und somit lose gekoppelt ist. Lose gekoppelte Operationen hingegen haben einen großen Vorteil und architektonische Vorteile gegenüber dem Muster der engen Kopplung, da sie den Client sofort aus der Blockierung befreien. Der Client muss nicht warten, bis die aufgerufene Operation beendet ist. Weniger Abhängigkeit und lose Kopplung führen zu einer geringeren Kohäsion und Bindung der miteinander verbundenen Operationen, was in Bezug auf Ressourcenverbrauch und Leistung der beste verfügbare Ansatz für das Integrationsprinzip ist.
Die lose Kopplung der Architektur ist nur eines der herausragenden Merkmale, die sich aus dem Einsatz eines Service Laver auf der Salesforce-Seite ergeben. Weitere Vorteile sind z.B. die Möglichkeit, die Verarbeitung der Nachrichten auf einen späteren Zeitpunkt zu verschieben. Echtzeit und die sofortige Verarbeitung von Nachrichten klingt großartig und eignet sich am besten für einige Anwendungsfälle, in denen der Benutzer auf eine sofortige Antwort wartet. Bei der Unternehmensintegration, bei der der Endbenutzer nicht involviert ist, brauchen Sie jedoch nicht immer eine sofortige Antwort, da diese nutzlos ist und einfach nicht benötigt wird.
Stellen Sie sich vor, Sie haben einen Webshop und müssen täglich hunderte von Produktpreisen aktualisieren. Wie können Sie das in Echtzeit tun? Dies ist technisch nicht in Echtzeit möglich, da Sie viele Salesforce-Governor-Grenzwerte wie die Anzahl der API-Aufrufe pro 24 Stunden, den verfügbaren Betriebssystem-Thread zur Bearbeitung einer solchen Massenanfrage und schließlich die Leistung Ihres Salesforce-Organisation und bricht damit die Leistung für Ihre Endbenutzer in den Geschäftszeiten.
In einer solchen Situation, in der es ausreicht, die aktualisierten Preise für alle Produkte am Morgen zu haben, können Sie die Batch- und Bündelungstechnik verwenden, um Pakete von beispielsweise 1.000 Preisaktualisierungen zu senden und die Nachrichten in der Nacht ab 22:00 Uhr jeden Tag zu verarbeiten. Eine solche Zeitplanung ist mit der Zeitplanungsfunktion von SKYVVA leicht zu konfigurieren. Der Vorteil besteht darin, dass die Verarbeitung von Massendaten in eine Zeit verlagert wird, die für eine solche Art der Datenverarbeitung geeignet ist. Ohne eine Serviceschicht, wie sie SKYVVA bereitstellt, kann ein solcher Anwendungsfall nicht über den Salesforce-Standard und nur über die API-Anbindung abgewickelt werden.
Mit einer Serviceschicht auf der Salesforce-Seite stehen Ihnen viele zusätzliche Mehrwertfunktionen wie die oben beschriebenen zur Verfügung, die Sie beim täglichen Betrieb und der Wartung des Integrationsszenarios unterstützen. In der folgenden Beschreibung werden einige wichtige zusätzliche Mehrwertfunktionen näher erläutert.
Zusätzliche Funktionalitäten, die Sie einfach benötigen
Die verschiedenen Mehrwertfunktionen helfen und vereinfachen die Wartung und den Betrieb Ihrer täglichen Integration mit Ihrer Salesforce-Plattform. Natürlich könnten Sie sagen, dass Sie das nicht brauchen, weil alles reibungslos funktioniert. Aber vergessen Sie nicht, dass eines Tages Probleme auftauchen werden, und zwar schneller, als Sie denken können. In dieser Situation werden Sie den zusätzlichen Nutzen nicht missen wollen, wie die folgenden Beispiele unten zeigen.
- End-to-End Monitoring
Sie haben ein zweites Auge, um zu sehen, was auf der Salesforce-Seite passiert. Mit der zusätzlichen Überwachungsschicht haben Sie eine echte Ende-zu-Ende-Überwachung und einen 100%igen Überblick über beide Seiten der verbundenen Plattform. - Reprocessing
Sie haben die Möglichkeit, fehlgeschlagene Nachrichten selbstständig neu zu verarbeiten, falls die Middleware nicht funktioniert und die Daten nicht erneut senden kann. Dies dient der Behebung eines Notfalls, in dem Sie eine schnelle Lösung innerhalb von Salesforce finden müssen, um die Daten, die aufgrund einer Inkonsistenz der Geschäftsdaten fehlgeschlagen sind, erneut zu verarbeiten. - Alerting
Sie erhalten eine echte geschäftliche Fehlermeldung, die sich auf Fehler bezieht, die auf Ihrer Salesforce-Seite aufgetreten sind, und nicht auf einen Fehler, der in der Middleware aufgetreten ist. Die Warnung wird von der Salesforce-Seite gesendet und ist daher eine echte und authentische Warnung, die den Geschäftsdatenfehler auf Ihrer Salesforce-Plattform abdeckt. - Workflow
Definieren Sie eine Regel und Vorbedingung für die Verarbeitung der Nachricht, damit Sie verhindern können, dass falsche und unsaubere Daten Ihre Geschäftsdaten auf der Salesforce-Seite durcheinander bringen. Komplexe Geschäftsvalidierung kann als Vorbedingung laufen, bevor die Daten gebucht werden, und nachdem die Daten gebucht wurden, können Sie eine Nachbearbeitungslogik mit dem SKYVVA-Workflow durchführen. - Business logic
Wenn Sie der Datenbuchung Geschäftslogik hinzufügen müssen, stellt Salesforce Ihnen großartige und flexible Tools wie Apex, Trigger, Process Builder und Flow zur Verfügung. Verwenden Sie eines davon, um Ihrer reinen Datenverarbeitung in Verbindung mit der SKYVVA-Schnittstelle Geschäftslogik hinzuzufügen. - Batch and Scheduling
Wenn Ihre Anforderungen an die Datensynchronisierung ein großes Volumen an Datenaktualisierungen umfassen, ist es nicht richtig und technisch nicht möglich, einen Echtzeitansatz zu verwenden. In diesem Fall sollten Sie die Verarbeitung dieser Massendaten in ein späteres freies Zeitfenster verschieben, um die Leistung der Salesforce-Organisation nicht zu beeinträchtigen und damit die Endbenutzer während ihrer Geschäftszeiten nicht zu belasten. Stattdessen sollten Sie die Verarbeitung auf einen geeigneten Zeitpunkt z.B. nachts ab 22:00 Uhr verschieben.
Es gibt noch weitere Mehrwertfunktionen, die SKYVVA als Integrationsservices zur Salesforce-Plattform hinzugefügt hat. Um diesen Artikel übersichtlich, kurz und verständlich zu halten, werden nur diese sechs Mehrwertfunktionen näher erläutert.
Value-added #1 – End-to-End Monitoring
Um den Mehrwert der Überwachungsfunktion zu zeigen, müssen wir ein reales Schnittstellenbeispiel verwenden, bei dem die verbundenen Systeme SAP-ERP (Sender), SAP-PI (Middleware) und Ihre Salesforce Instanz (Empfänger) sind. Das Szenario besteht darin, Kundendaten in SAP zu ändern, und die Änderungen werden sofort zurück nach Salesforce synchronisiert. Das folgende Diagramm zeigt den beispielhaften Ablauf.
Auf diesem Bildschirm sehen wir die in SAP geänderten Daten für den Kunden 301557 und die alte Adresse in Salesforce. Wir erwarten, dass die geänderte Adresse aus Salesforce auf der Salesforce-Seite aktualisiert wird.
Werfen Sie nun einen Blick auf die Überwachung innerhalb des verbundenen Systems, wie in der folgenden Abbildung dargestellt. In diesem Beispiel wird die Integration in Salesforce über den Standard-API-Ansatz durchgeführt. In diesem Bildschirm können wir die verschiedenen Überwachungen auf dem Sender, z.B. SAP-ERP, auf der Middleware, z.B. SAP-PI, sehen, aber auf der Salesforce-Seite gibt es keine Überwachungsmöglichkeit mit der Standard Salesforce API. Was Sie tun können, ist, direkt das sObject Account zu überprüfen, um zu sehen, ob die Adressdaten geändert wurden. Wenn Sie die Adresse des Accounts überprüfen, werden die Änderungen nicht in Salesforce aktualisiert. Was ist also passiert und was können Sie tun?
Was Sie in diesem Fall tun können, ist, den Debug-Trace aufzurufen und zu versuchen, die Ursache zu finden, warum die Adresse nicht aktualisiert wurde. Wahrscheinlich werden Sie etwas finden, wahrscheinlich aber auch nicht. Als Salesforce-Benutzer oder -Administrator können Sie sich nicht beim SAP-PI-Middleware-Team oder beim SAP-ERP-Team beschweren, denn alle werden Ihnen durch ihre Überwachung beweisen, dass die Daten erfolgreich gesendet wurden, was Sie an der grünen Flagge sehen können. Was können Sie also tun, um die Ursache auf einfache Weise zu finden?
Leider gibt es bei Verwendung des Standard-API-Ansatzes mit der Middleware keine Überwachungsmöglichkeit innerhalb von Salesforce. Die einzige Möglichkeit besteht darin, Ihr erfahrenes Apex-Entwicklerteam zu beauftragen, die Ursache für dieses Problem zu finden. Beachten Sie, dass wir in diesem Fall die asynchrone Technik auf SAP-ERP mit IDOC verwenden und auf SAP-PI wurde die Schnittstelle ebenfalls als asynchrone Schnittstelle konzipiert. Es besteht keine Notwendigkeit, dieses Szenario mit einer synchronen Schnittstelle zu entwerfen, da SAP-IDOC eine asynchrone Technik ist. Daher wird es keine Antwort des API-Aufrufs geben, die dem Absender, z.B. SAP-PI, einen Fehler oder eine Ausnahme mitteilt. Die Nachricht wurde erfolgreich von SAP-PI an Salesforce gesendet, und aufgrund der Art der asynchronen Verarbeitung sind auf SAP-PI-Seite keine weiteren Schritte erforderlich.
Wie lässt sich diese Situation also lösen? Schauen wir uns nun das gleiche Szenario an, das wir mit SKYVVA nachgebaut haben. In diesem Fall verwenden Sie den SKYVVA-Konnektor auf der SAP-PI/PO-Seite. Auf der Salesforce-Seite verwenden Sie die SKYVVA-Service-Schicht.
Wenn die Nachricht von der SAP-PI/PO-Middleware eintrifft, geht sie an die SKYVVA-Nachrichtenschicht, wo sie sofort verarbeitet wird. Vom Nachrichtenfluss her gibt es keinen Unterschied zu dem Szenario, an dem SKYVVA nicht beteiligt war. Der wesentliche Unterschied besteht darin, dass jetzt die SKYVVA-Schicht den Überwachungsdienst bereitstellen kann. Wie sieht es nun aus?
Wie Sie auf dem Bildschirm sehen können, haben wir auch eine Überwachung in Salesforce, wo Sie sofort sehen können, was die Ursache war. Der Fehler ist klar und verständlich für den Salesforce-Benutzer und Administrator. Jetzt finden Sie den Fehler innerhalb von Minuten statt Stunden, ohne Ihr Apex-Entwicklerteam einzubeziehen. Dies ist eine echte End-2-End-Überwachung, die Ihr Middleware-Integrationsszenario verbessert.
Value-added #2 – Reprocessing
Bleiben wir bei dem obigen Beispiel, das wir zur Darstellung der Überwachung verwendet haben. Werfen wir einen Blick auf die rote Meldung in der SKYVVA-Überwachung. Nehmen wir an, dass Sie als Salesforce-Benutzer oder -Administrator den Geschäftsfehler klar verstehen und die Adressänderung vornehmen müssen, weil Sie das Angebot noch heute vor Ende des Geschäftstages an den Kunden senden müssen. Sie können nicht bis zum nächsten Tag warten und riskieren, den Auftrag zu verlieren. Sie nehmen Ihr Telefon und rufen Ihren SAP-ERP-Kollegen an, um die falsche Nachricht noch einmal zu senden. Sie erreichen ihn, aber leider hat er das Büro bereits verlassen, weil es kurz vor Büroschluss war. Ihr SAP-ERP-Kollege kann die Nachricht heute nicht noch einmal senden und verspricht, sie morgen früh zu senden. Aber das wird Ihnen nicht helfen, denn morgen früh ist es zu spät für Ihre Notsituation. Was können Sie also tun?
Da Sie die Schnittstelle mit SKYVVA umgebaut haben, verwenden Sie einfach die Funktion zur erneuten Verarbeitung. Öffnen Sie die Nachricht, ändern und speichern Sie die Daten und führen Sie eine erneute Verarbeitung durch.
Klicken Sie auf die Schaltfläche „Erneut bearbeiten“ und bestätigen Sie mit der Schaltfläche „Ja“.
Jetzt sehen Sie eine grüne Meldung (Status Completed) nach der erneuten Verarbeitung.
Jetzt können Sie von hier aus direkt zum Geschäftsdatensatz navigieren, um die Änderung für die Adressaktualisierung zu sehen.
Die neue Adresse wird nun nach der erneuten Verarbeitung aktualisiert und Sie können die neue Adresse verwenden, um das Angebot über Ihren automatischen Angebotsprozess zu versenden. Beachten Sie, dass wir aus Gründen der Einfachheit und Klarheit bei der Demonstration der Wiederverarbeitungsfunktion die Änderungen nicht an SAP zurücksenden. Dies ist zwar möglich und sinnvoll, würde aber den Text zu sehr in die Länge ziehen, nur um die Wiederverarbeitungsfunktion zu zeigen. Beachten Sie auch, dass die hier gezeigte Wiederverarbeitung eine manuelle Wiederverarbeitung ist. In diesem Beispiel müssen Sie die manuelle Nachbearbeitung durchführen, weil die Daten falsch sind und Sie sie korrigieren müssen. Es gibt aber auch andere Fehler, bei denen Sie keine manuelle Nachbearbeitung vornehmen müssen, sondern dies dem Nachbearbeitungsjob überlassen, den Sie einfach planen können. Werfen Sie einen Blick auf die Planungsfunktion des Wiederaufbereitungsauftrags.
Dies ist der Nachrichtenverarbeitungsauftrag, den Sie bei Bedarf einfach starten und beenden können.
Value-added #3 – Alerting
Die Überwachungsfunktion ist so großartig, um zu sehen, was auf beiden Seiten passiert. Das Ärgerliche an der Überwachung ist, dass man immer aktiv darauf achten muss. Wäre es nicht toll, wenn es eine Benachrichtigung gäbe, wenn etwas schief läuft, und man einen Fehlerhinweis als E-Mail erhalten könnte?
Im obigen Szenario verfügt SAP-ERP über eine Warnmeldung, SAP-PI/PO über eine Warnmeldung, aber in Salesforce gibt es keine Warnmeldung, die von der Standard-API bereitgestellt wird. Sie würden sagen, dass es ausreicht, die Warnung in der Middleware zu haben. Schauen wir uns die Alert-Situation im Detail an.
Ein Warnhinweis sollte Ihnen den tatsächlichen Grund und die Ursache eines Fehlers nennen, der jederzeit an verschiedenen Stellen auftreten kann. Der Fehler kann in SAP-ERP, in SAP-PI/ PO und in Salesforce auftreten, und Sie benötigen den ursprünglichen Fehlertext. In der obigen Situation meldet die Middleware den Fehler, der in der Middleware aufgetreten ist, und nicht wirklich, was in Salesforce passiert ist. Sie kann den Fehler aus Salesforce wiedergeben, aber dieser Ansatz birgt ein Risiko. Die Middleware hat ihre eigene Logik und ihren eigenen Code, die bei der Übertragung der Nachricht an Salesforce fehlerhaft sein können. In diesem Fall würde sie einen eigenen Fehler innerhalb der Middleware melden, wie zum Beispiel „java.lang.StringIndexOutOfBoundsException: String index out of range: -1“, was nichts mit dem tatsächlichen Fehler auf der Salesforce-Seite zu tun hat.
Was ist hier das Problem? Die Meldung ist nicht authentisch und könnte einfach falsch sein, weil Sie eine Meldung erhalten, die Ihnen sagt, dass das Problem oder der Fehler auf der Middleware, aber nicht auf der Salesforce-Seite aufgetreten ist. Wenn die Middleware aus irgendeinem Grund nicht mehr funktioniert, kann es sein, dass Sie eine verzögerte Meldung erhalten, die erst vor ein paar Stunden in Salesforce aufgetreten ist. Dies ist von entscheidender Bedeutung, wenn Sie ein Echtzeit-Szenario haben, das auch Echtzeit-Warnungen von der Quelle der Wahrheit benötigt. Mit der Middleware dazwischen handelt es sich um eine Art Alarmweiterleitung von Salesforce an Sie, aber nicht um einen Alarm, der von Salesforce direkt an Sie geliefert wird. Anhand dieses Beispiels können Sie einige Nachteile der Alarmierungsfunktion erkennen.
- Ungenauer Warnhinweis und manchmal einfach die falsche Warnung
- Nicht echtzeitfähig genug für den Fall, dass die Middleware stecken bleibt oder ihre Leistung beeinträchtigt wird
- Nicht direkt, sondern indirekt durch Weiterleitung durch die Middleware
Wie können wir diese Probleme überwinden? Der einzig richtige Ansatz, um Warnungen pünktlich, korrekt und mit der ursprünglichen Ursache zu liefern, besteht darin, die Alarmierungskomponente auch direkt in Salesforce zu haben. Wie Sie in der obigen Abbildung sehen können, hat jede Komponente, z.B. SAP-ERP und SAP-PI/PO, ihre eigene Warnkomponente. Es gibt einen guten Grund, für jede Plattform eine eigene Warnkomponente zu haben. Lassen Sie uns nun sehen, wie wir eine solche native Warnungskomponente in Salesforce haben können.
SKYVVA hat mit seinem Service-Layer die native Warungskomponente hinzugefügt, um eine echte Warnung zu liefern. Warnungen werden direkt und in Echtzeit von Salesforce an Sie gesendet, ohne jegliche Verzögerung. Sie erhalten den ursprünglichen Fehlertext und sehen nie etwas wie:
“java.lang.StringIndexOutOfBoundsException: String index out of range: -1”.
Der Warnhinweis kann auf der Ebene der Integration oder der Schnittstelle granular definiert werden. Die Integration ist eine logische Gruppe von Schnittstellen. Es gibt vier verschiedene Möglichkeiten, die Zustellung von Warnmeldungen zu definieren (siehe unten):
- Externe E-Mail verwenden
- Verwendung eines internen Mail-Links zu einem Benutzer
- Aufgabe verwenden
- Verwendung einer Salesforce Chatter-Gruppe
Hier ist ein Beispiel, eines E-Mail-Warnhinweises.
Sie können auf den Link klicken und direkt zu den Details der Nachricht springen, um die fehlgeschlagene Nachricht erneut zu bearbeiten. Mit der Option zur Verwendung von Chatter-Gruppen können Sie die Social-Media-Funktion nutzen, um die Zustellung Ihrer Benachrichtigungen zu organisieren. Personen, die der Gruppe folgen, werden benachrichtigt, und es ist kein kompliziertes Einrichtungsverfahren erforderlich. Es gibt auch andere Benachrichtigungsfunktionen für spezifische SKYVVA-Funktionen wie die Batch- und CDC-Verarbeitung, um den Posteingang des Warenkorbs oder die Änderungszeigertabelle für Datenänderungen zu beobachten.
Value-added #4 – Workflow
Wenn Sie die Standard-API von Salesforce verwenden, um z.B. ein sObject zu erstellen, zu lesen, zu aktualisieren oder zu löschen, gibt es keine Validierung oder Prüfungen vor dem Erstellen, Aktualisieren oder Löschen eines Geschäftsdatensatzes. Das ist genau das, was eine Service-Schicht für Ihren Integrationsbedarf leisten kann. Sie geht über die Konnektivität hinaus und bietet Ihnen und Ihrem Salesforce-Team eine einfache Möglichkeit, Ihren täglichen Integrationsbedarf zu entwickeln, zu pflegen und zu betreiben. Das ist es, was die SKYVVA Service-Schicht der Salesforce Lightning-Plattform hinzufügt, die das richtige und robuste Tool für die Integration von und nach Salesforce vermissen lässt.führt es aus und ändert den sObject-Datensatz sofort. In den meisten Integrationsszenarien müssen Sie jedoch eine Validierung durchführen, bevor Sie Ihren Geschäftsdatensatz ändern, da Sie sonst Fehler machen und Dateninkonsistenzen erzeugen könnten.
Schauen Sie sich das Beispiel an, das mit dem eingebauten SKYVVA-Workflow einfach gelöst werden kann, um eine Vorbedingungsprüfung durchzuführen, bevor ein Asset geändert wird. Hier können verschiedene Bedingungen definiert werden, die aus einem komplexen Ausdruck mit Formeln bestehen. Eine Kette von regelbasierten Schnittstellenverarbeitungen kann eingerichtet werden und bietet Ihnen eine leistungsfähige Möglichkeit, komplexes Nachrichtenverarbeitungsverhalten als die einfache CRUD-Operation hinzuzufügen. Sie können jede komplexe Regel definieren, die zuerst validiert werden muss, bevor Sie das sObject ändern.
Mit dem Workflow können Sie nicht nur eine Regel oder Bedingung für die Schnittstellenverarbeitung definieren. Sie können einen Ablauf definieren, der mehrere Schritte umfasst, die in die Verarbeitung der Nachricht einfließen. Nehmen wir an, Sie wollen das Konto und den Kontakt nacheinander ändern. In diesem Fall können Sie einen Workflow definieren, der die Account- und Kontaktdaten in einer Nachricht empfängt und diese Nachricht an den Verarbeitungsschritt der Account- und Kontaktschnittstelle weitergibt. Auf diese Weise haben Sie eine Kette von Verarbeitungsschritten definiert, die komplexe Vorgänge mit einem einzigen API-Aufruf abwickeln können.
Sie können die verschiedenen Einstellungen und das Laufzeitverhalten für die Workflow-Engine definieren. So können Sie beispielsweise einen transaktionsbasierten Verarbeitungsablauf entwerfen und alle Vorgänge innerhalb des Ablaufs zurücksetzen, wenn ein Fehler auftritt. Dadurch wird die transaktionale Konsistenz gewährleistet.
Value-added #5 – Business Logik
Eine Nachricht wird als Nutzlast von der Middleware an Ihr Salesforce übertragen und über die Salesforce-Standard-API können Sie ein sObject CRUD (Create, Read, Update, Delete) ausführen. Die CRUD-Operation ist die grundlegende und elementare Aktion, die Sie mit dem Geschäftsdatensatz in Salesforce durchführen können. Manchmal reicht es aus, ein sObject zu CRUD, wenn Ihre Anforderungen einfach sind. Manchmal reicht das nicht aus, wenn Ihr Integrationsszenario eine Geschäftsanforderung behandeln soll, die über die CRUD-Operation hinausgeht.
Mit dem SKYVVA-Workflow können Sie eine regelbasierte Schnittstellenverarbeitung definieren. Hier können Sie die integrierten Funktionen von Salesforce nutzen, um die Geschäftslogik zur Nachrichtenverarbeitung hinzuzufügen. Wenn Ihr Integrationsszenario über die CRUD-Operation hinausgeht, benötigen Sie eine leistungsfähige Technik, um Ihre Geschäftslogik hinzuzufügen, wie Sie es mit einer Programmiersprache tun können. In diesem Fall können Sie eine Apex-Klasse mit der Schnittstelle verknüpfen, und wenn die Nachricht in der SKYVVA-Schicht eintrifft, wird die Verarbeitung mit der Logik Ihrer Apex-Klasse ausgeführt, in der Sie Ihre Geschäftslogik implementieren können.
Sie können die verfügbaren Programmier- und Deklarationswerkzeuge nutzen, um die Geschäftslogik zu Ihrer Datenintegration hinzuzufügen. Wenn Sie ein Entwickler sind und in Apex programmieren können, können Sie Apex-Trigger und Apex-Klassen verwenden. Wenn Sie ein Administrator und kein erfahrener Entwickler sind, können Sie nicht deklarative Tools wie den Process Builder und Flow verwenden. Über die Schnittstelle können Sie einen Salesforce-Flow des Typs „Autolaunched“ verknüpfen und die Geschäftslogik ohne jegliche Kodierung mithilfe des grafischen Flows erstellen.
Value-added #6 – Stapelverarbeitung und Terminplanung
Die Integration unter Verwendung von Middleware wird meist dazu verwendet, ein Szenario von Anwendung zu Anwendung zu verbinden. Dies bedeutet, dass ein Echtzeit-Szenario, bei dem der Endbenutzer auf der anderen Seite sitzt und wartet, nicht üblich ist und daher nicht immer eine Echtzeit- und sofortige Datenverarbeitung erforderlich ist. Was manchmal für die Integration von Massendaten zwischen Anwendungssystemen benötigt wird, sind Batch- und Hintergrundverarbeitung, um die Ressourcen und die Leistung zu optimieren und das Netzwerk, die CPI und den Datenspeicher zu nutzen.
Basierend auf dem Integrationsszenario machen einige Anwendungsfälle durchaus Sinn, das Echtzeit-Verarbeitungsmuster zu verwenden. Wenn zum Beispiel (1. Szenario) ein Benutzer auf der Salesforce-Seite die Verfügbarkeit eines Produkts in SAP-ERP sehen möchte, ist es sinnvoll, eine API aufzurufen und auf die Antwort zu warten. Eine solche Anfrage ist ein kurzzeitiger Vorgang und wird das Salesforce-Timeout-Limit nicht erreichen. Wenn Sie den Preis durch eine nächtliche Operation aktualisieren wollen (2. Szenario), dann macht es keinen Sinn, ein Echtzeit-Verarbeitungsmuster zu verwenden, um z.B. hunderte von Produktpreisen zu aktualisieren. Dies wäre erstens technisch nicht möglich, weil Salesforce eine Zeitüberschreitung zulässt, und zweitens nicht sinnvoll, weil kein Benutzer darauf wartet, den aktualisierten Preis sofort zu sehen. Es reicht, wenn der Preis am nächsten frühen Morgen aktualisiert wird.
In der Tat ist es keine Frage, ob der Echtzeit- (enge Kopplung) oder der Batch-/Background-Ansatz (lose Kopplung) besser ist als der andere. Beide Muster passen perfekt, wenn das gegebene Szenario geeignet ist. Machen Sie es in Echtzeit oder Batch, je nach Ihren geschäftlichen Anforderungen. Das Problem mit der Standard-API ist, dass es nicht möglich ist, die Verarbeitung der API zu verzögern oder sie im Hintergrund zu einem späteren Zeitpunkt laufen zu lassen, z. B. nachts um 22.00 Uhr jeden Tag. Der Mechanismus dafür fehlt einfach im Salesforce-Standard.
Die SKYVVA-Serviceschicht fügt der Salesforce-Plattform eine Planer- und Auftragsverarbeitungskomponente hinzu, die die Batch- und Planungsverarbeitung übernimmt.
Sie können den Zeitplan auf unterschiedliche Weise definieren, um Ihre geschäftlichen Anforderungen zu erfüllen. Sie können z. B. alle 15 Minuten einen Lauf durchführen. Sie können einmal zu einer bestimmten Zeit, z. B. um 1:00 Uhr nachts, oder stündlich, z. B. zwischen 22:00 Uhr und 4:00 Uhr morgens, laufen lassen.
Sie können die Tage in der Woche und im Monat auswählen, die Sie ausschließen möchten. Auf diese Weise können Sie flexibel festlegen, wann die Verarbeitung von Nachrichten je nach Ihren Anforderungen beginnen soll. Sie sind nicht gezwungen, alles sofort zu verarbeiten, wenn es sinnvoller wäre, die Daten wie eine Massenpreisaktualisierung in der Nacht zu verarbeiten. So können Sie die Verarbeitungslast anpassen und verteilen und Ihre Salesforce-Ressourcen und CPU-Zeit besser ausnutzen.
Für jede Art von Aufgabe, die Sie benötigen, sind verschiedene Zeitpläne verfügbar. Mit dem Stapelverarbeitungs- und Wiederverarbeitungsplaner können Sie beispielsweise Nachrichtenpakete mit z.B. 10.000 pro Paket schieben und die Verarbeitung in der Nacht von 22:00 Uhr bis 6:00 Uhr morgens für jede Stunde planen. Dies nutzt die Ressourcen und verteilt die Last und hält die Leistung Ihrer Salesforce-Instanz für die Endbenutzer während ihrer Arbeitszeit reibungslos aufrecht.
Das Starten und Stoppen des Zeitplans ist einfach durch einen Klick auf das Symbol. Um den Zeitplan einzustellen, müssen Sie nur auf das Symbol klicken. Alle verfügbaren Zeitpläne für die verschiedenen Aufgaben werden automatisch erstellt.
Zusammenfassung
Alle sechs beschriebenen Mehrwertfunktionen heben Ihre Integrationsqualität auf die nächsthöhere Ebene und geben Ihnen die operativen Instrumente an die Hand, die die tägliche Arbeit erleichtern und vereinfachen. Diese Methode geht über den einfachen API-Integrationsansatz hinaus, bei dem nur eine reine Konnektivität möglich ist. Wenn Sie eine Integration der Unternehmensklasse anstreben, dann ist der reine Middleware-Ansatz definitiv nicht ausreichend.
End-to-End Monitoring und Warnhinweise (Alerting) erhöhen die Qualität und verbessern die Fehlerbehandlung und den täglichen Betrieb enorm. Die Wiederverarbeitung von Nachrichten gibt Ihnen ein praktisches Werkzeug an die Hand, um Notfälle zu behandeln, bei denen das Absendersystem gerade außer Betrieb ist. Mit Workflow und Geschäftslogik können die Einfachheit und die Beschränkungen der CRUD-Operation überwunden und komplexe Geschäftsszenarien leicht implementiert werden, ohne dass viel Codierung auf der falschen Seite stattfindet. Schließlich ermöglicht die Batch- und Scheduling-Funktion, den Sender vom Empfänger zu entkoppeln und so eine geringere Abhängigkeit zu schaffen, was zu einer optimierten Leistung bei der Nachrichtenverarbeitung für große Datenmengen führt.