Die Integration mit SAP ist ein heißes Thema, da Unternehmen, die auf S/4HANA umstellen, eine Lean-Core-Strategie verfolgen, was bedeutet, dass sie beabsichtigen, jede zusätzliche Funktionalität außerhalb von SAP zu entwickeln, wenn sie nicht logischerweise zum Kern gehört. In meinem früheren Artikel über OutSystems und SAP-Integration habe ich mich bereits damit befasst, allerdings eher aus der Sicht der technischen Integration.
Aber was ist der beste pragmatische Ansatz, der Ihrem Unternehmen den größten Nutzen bringt?
SAP ermöglicht es Ihnen, auf seinem Anwendungsserver Code zum Lesen, Ändern, Anlegen und Löschen von Daten auszuführen. Dies ist eine Einbahnstraße, d.h. ein externes System ruft diese Funktionen auf SAP auf. Im vorigen Artikel habe ich über die Unterschiede zwischen der Verwendung von OData und dem RFC-Konnektor geschrieben, mit Vor- und Nachteilen von beiden aus rein architektonischer Sicht.
Für IT-Spezialisten wird es jedoch immer wichtiger, Entscheidungen nicht nur aus technischer Sicht zu treffen, sondern auch die Bedürfnisse des Unternehmens zu berücksichtigen. Eines der Dinge, die das Geschäft verlangt, ist die Verkürzung der Lieferzyklen für den Bedarf. Die SAP-Lieferzeiten von mehr als 6 Monaten sind in schnell wechselnden Umgebungen einfach nicht mehr akzeptabel. Hier kommt die bimodale Entwicklung ins Spiel, mit unterschiedlichen Entwicklungs- und Lieferzeiten für Ihre Kernsysteme und Ihre schnelle und agile Low-Code-Entwicklungsstraße.
Agilität und kurze Markteinführungszeiten sind etwas, wonach sich das Unternehmen sehnt, aber die IT-Organisation kann dieses Versprechen aufgrund formaler Richtlinien nicht einhalten, selbst wenn sie eine Low-Code-Plattform verwendet. In wenigen Wochen können wir in OutSystems ein bahnbrechendes Produkt entwickeln, von dem das Unternehmen begeistert ist und darum bittet, es so schnell wie möglich in Betrieb zu nehmen. Aber die Inbetriebnahme wird plötzlich um Monate verschoben, weil das Produkt mit dem SAP-RFC-Connector erstellt wurde. Der SAP-Architekt des Unternehmens lässt keine RFC-Verbindungen in der Produktion zu, so dass neue OData-Verbindungen von Grund auf erstellt werden müssen, was zu einer enormen Verzögerung führt, die dem Unternehmen nur schwer zu erklären ist.
Normalerweise halten wir uns immer an die Richtlinien der Unternehmen, für die wir arbeiten, aber in diesem Fall habe ich das Bedürfnis, das Wort zu ergreifen und dies zu hinterfragen. Welchen Wert liefert der Architekt für das Unternehmen, indem er diese Verzögerung verursacht? Verhindert er ein ernsthaftes Risiko für das Unternehmen? Gibt es Nachteile für den RFC-Konnektor, die die Stabilität der Kernsysteme gefährden werden? Nichts von alledem, der Architekt sagt nein, weil es eine Richtlinie innerhalb des Unternehmens ist.
Um es ganz klar zu sagen: Der RFC-Konnektor ist ein Stück Software, das seit Jahrzehnten existiert und das Herzstück der SAP-Plattformen ist, einschließlich S/4HANA. SAP selbst nutzt diesen Konnektor für die Kommunikation zwischen SAP-Systemen und Nicht-SAP-Systemen. Tatsächlich ist es ziemlich aufschlussreich, dass die RFC-Technologie eine Schlüsselrolle bei der Verbindung zwischen dem SAP-Gateway-Server und dem SAP-Anwendungsserver spielt, wenn ein OData-Dienst aufgerufen wird.
Einige der Merkmale des RFC-Konnektors:
- Es ist äußerst sicher
- Sie ist rasend schnell
- Es gibt mehr als 50.000 Remote-
- Funktionen, die sofort verwendet werden können
- Sie können Funktionen über benannte Benutzer aufrufen
- Sitzungen können zustandslos oder zustandsabhängig sein
- Die Anzahl der auf dem SAP-Anwendungsserver verwendeten
- Threads kann gedrosselt werden.
- Die Verwendung von qRFC und tRFC ist möglich
Diese Liste ist bei weitem nicht vollständig und zeigt, dass die Technologie robust und vollständig ist. Sie ist so zuverlässig, dass SAP selbst sie ständig einsetzt. Warum also drängen fast alle Unternehmen dogmatisch auf OData, ohne eine offene Diskussion zu führen? Der Hauptgrund, der mir einfällt, ist, dass SAP die Verwendung von OData als den Weg in die Zukunft empfiehlt und dass der RFC-Konnektor in Zukunft möglicherweise nicht mehr verwendet werden wird. Ich verstehe, dass das wirklich wichtig ist, aber im Moment wird der RFC-Konnektor noch in allen SAP-Releases unterstützt, mit der bemerkenswerten Ausnahme der SAP-Cloud-Version – und die Umstellung auf die SAP-Managed-Cloud ist ein Aufwand, der für alle SAP-Unternehmenskunden ein riesiges Projekt sein wird, und es ist nicht wahrscheinlich, dass Unternehmen in den kommenden Jahren diesen Weg einschlagen werden.
Warum also nicht die Verwendung von RFC-Verbindungen erlauben? Dies wird die Inbetriebnahme geschäftskritischer Anwendungen erheblich beschleunigen und frühzeitig einen Mehrwert schaffen. Warum sollten Sie die OData-Verbindungen jetzt aufbauen, mit allen damit verbundenen Kosten und Mühen, wenn Sie dies auch tun können, wenn Sie es tatsächlich brauchen – wenn SAP beispielsweise die Unterstützung einstellt, was in den nächsten zehn Jahren höchst unwahrscheinlich ist?
Neben den zusätzlichen Kosten und der Verzögerung gibt es noch eine weitere Auswirkung: Sobald sich die OutSystems-Anwendung mit dem individuell erstellten OData-Service verbindet, verlieren Sie die Geschwindigkeit, mit der Sie die Anwendung erweitern können. Wenn Sie den RFC-Konnektor verwenden, können Sie in den kommenden Sprints auf der Grundlage des Kundenfeedbacks immer wieder leicht verfügbare SAP-Funktionen hinzufügen. Wenn Sie auf OData umgestellt haben, sind alle Änderungen mit der SAP-Entwicklung verbunden und Sie verlieren jegliche Flexibilität. Das verfehlt den Zweck der Bimodell-Entwicklung und frustriert das Unternehmen, das wieder monatelang auf die versprochene Funktionalität warten muss, während das OutSystems-Team untätig herumsitzt.
Selbst wenn das Unternehmen darauf beharrt, dass OData der richtige Weg ist, schlage ich vor, die Verwendung von RFC im Projektmodus zuzulassen und dies als technische Schuld zu registrieren, die gelöst werden muss, bevor die Entwicklung an das Support-Team übergeben wird. Auf diese Weise kann das Projekt in jedem Sprint schnell Werte liefern, ohne darauf warten zu müssen, dass der OData-Dienst in Betrieb genommen wird; und am Ende des Projekts, wenn die Anwendung vollständig getestet und stabil ist, werden die RFC-Aufrufe durch OData-Dienste ersetzt – OutSystems unterstützt beide Protokolle, so dass die Umstellung einfach ist. Auf diese Weise schaffen Sie schnell einen Mehrwert für Ihr Unternehmen, während das Endprodukt Ihren internen Standards entspricht – das Beste aus beiden Welten!
