NO CODE/LOW CODE BEI SAP UND SALESFORCE: DAS EINE FUNKTIONIERT, DAS ANDERE NICHT

No Code/Low Code bei SAP und Salesforce: das Eine funktioniert, das Andere nicht Sie schrieben Quellcode, der kompiliert und zur Laufzeit ausgeführt wurde. Die Technologien und Werkzeuge zur Erstellung von Software haben sich im Laufe der Jahre verändert, aber die Grundsätze und Anforderungen sind dieselben geblieben. Um Software zu schreiben, musste man die Logik dahinter verstehen, was ein allgemeines Wissen über IT-Infrastruktur, Kenntnisse über das zugrunde liegende Betriebssystem/Webbrowser, Verständnis für funktionale und/oder objektorientierte Programmiermodelle, Datenbankkenntnisse und vieles mehr erforderte. Dies benötigt jahrelanges Lernen, und um ein wirklich großer Entwickler zu werden, brauchte man obendrein jahrelange Erfahrung.

Seit Jahrzehnten haben wir einen Mangel an qualifizierten IT-Ressourcen, insbesondere an erfahrenen Softwareentwicklern. Da dieser Mangel den Fortschritt bei der Entwicklung von Anwendungen, die Unternehmen bei der Verbesserung ihrer Geschäftsabläufe helfen, verzögerte, wurden No-Code-Tools eingeführt – Anwendungen ohne Codierung, so dass auch ein Endbenutzer die für seine Arbeit erforderlichen Programme erstellen kann. Eines der ersten Tools dieser Art war Microsoft Access, mit dem Unternehmen in den 1990er Jahren datenbankgestützte Anwendungen ohne Programmierung erstellen konnten.

Nach dem gleichen Prinzip funktionieren Low-Code-Tools, mit denen Sie 90 % der Arbeit ohne Code erledigen und spezifische Verbesserungen mit nur minimalem Programmieraufwand und Fachwissen hinzufügen können.

In den 2020er Jahren begannen alle großen Softwareanbieter und -plattformen, No-Code-Tool anzubieten (z. B. Microsoft Power Apps). Heute sind kleinere Unternehmen auf dem Markt, die sich auf No-Code-Tools spezialisiert haben (Neptune, Mendix, usw.).

In diesem Blog vergleichen wir die No-Code-Ansätze zur Verwaltung von SAP und Salesforce und erfahren, warum der eine funktioniert und der andere nicht.

SAP Build

SAP hat AppGyver übernommen und es in sein Cloud-Angebot integriert. Es heißt jetzt SAP Build und läuft auf der SAP Business Technology Platform (BTP). Im Großen und Ganzen funktioniert Build folgendermaßen:

• Man beginnt mit einer leeren Blatt auf Ihrem Bildschirm, auf dem man die UI-Elemente wie Labels, Schaltflächen, Checkboxen oder Tabellen zieht und ablegt.
• Man verbindet diese UI-Elemente mit Daten und Ereignisse.
• Man implementiert die Navigation zwischen den Screens.
• Wenn Sie das Backend Ihrer neuen Frontend-Anwendung auf SAP BTP erstellen möchten, müssen Sie dies in einem separaten Schritt tun. Wenn Ihre Benutzeroberfläche 10 Felder hat, müssen Sie diese für das Backend ein zweites Mal modellieren (und vergessen Sie nicht, dass die Datentypen und Feldlängen übereinstimmen müssen!)
• Wenn Sie ein bestehendes Backend wie SAP S/4HANA oder ECC 6.0 integrieren möchten, können Sie OData, REST oder die SAP Integration Suite (für nichtSAP Systeme) nutzen. Dies erfordert ein gutes Verständnis der einzelnen verfügbaren Dienste. Wenn kein Dienst die Bedürfnisse erfüllt, muss man einen entwickeln. Leider werden BAPIs oder Funktionsbausteine nicht direkt unterstützt.
  

  The SAP Build No-Code Tool

  SAP Build ist nur ein Beispiel für viele ähnliche Tools, die im Bereich SAP eingesetzt werden, darunter Lösungen wie Neptune.

Salesforce

Salesforce hat einen radikal anderen Ansatz für No-Code. Der große Vorteil besteht darin, dass die No-Code/Low-Code-Tools in die Plattform integriert sind und einen wesentlichen Bestandteil der Plattform bilden. Im Großen und Ganzen erstellt man eine Anwendung folgendermaßen:

• Im Salesforce Setup erstellt man ein neues Geschäftsobjekt, das das reale Objekt darstellt, das die Anwendung anzeigen soll.
• Man fügt die Felder zu dem neuen Objekt hinzu und legt den Datentyp, die Länge usw. fest.
• Man legt die Aktionen fest, die man ausführen möchte, und welche anderen Objekte damit verbunden sind.

Fertig. Der Benutzer muss keine Designentscheidungen treffen, da Salesforce diese übernimmt.

Definieren des Datenmodells, der Aktionen und der Benutzeroberfläche an einer zentralen Stelle in Salesforce

Vergleich der Ansätze

SAP Build gibt Ihnen viel mehr Flexibilität, wenn es um die Definition der Benutzeroberfläche geht, aber das ist normalerweise keine gute Idee. Wir kennen viele fantastische Softwareentwickler, die wirklich gut in dem sind, was sie tun, aber selbst ihnen fällt es schwer, eine anständige, benutzerfreundliche Benutzeroberfläche zu erstellen (dafür gibt es ja UX-Designer!). Wenn schon Softwareentwickler vor einer Herausforderung stehen, wie können wir dann von Endbenutzern erwarten, dass sie eine Benutzeroberfläche erstellen, die die grundlegenden Anforderungen erfüllt? Der Drag-and-Drop-Ansatz von Build kann auch dazu führen, dass die Anwendungen anders aussehen, sich anders anfühlen und sich anders verhalten, was es für den Endbenutzer sehr schwierig macht, sie zu erlernen und zu benutzen.

Salesforce hingegen lässt einem diese Freiheit nicht. Man legt fest, was man anzeigen möchten und welche Aktionen gewünscht sind, und Salesforce erledigt den Rest. Salesforce erstellt für einen eine Listenansicht und einen Detaildialog – einen zum Bearbeiten des Objekts und einen weiteren zum Erstellen neuer Objekte. Es sorgt dafür, dass ein Datumsfeld eine Datumsauswahl hat und dass die Zahlen rechts ausgerichtet sind. Man muss sich auch keine Gedanken darüber machen, wie die Daten gespeichert werden; das übernimmt Salesforce für einen. Geschickterweise nimmt Salesforce dem Benutzer viel Verantwortung ab und sorgt dafür, dass alle Listen und Detailseiten gleich aussehen. Die Schaltflächen befinden sich immer an der gleichen Stelle, was es den Benutzern erleichtert, neue Anwendungen und Prozesse zu erlernen.

Mit der Salesforce-Plattform können Sie neue Geschäftsprozesse und Anwendungen schneller erstellen als mit SAP Build.

Fazit

Es gibt keinen besseren Weg, um den Unterschied zwischen den beiden Plattformen zu veranschaulichen, als zu vergleichen, wie SAP und Salesforce ihre eigenen internen Lösungen erstellen. Die Fiori-basierten Anwendungen von SAP (ob sie nun auf einem ABAP-Stack oder auf dem BTP laufen) werden auf klassische Weise geschrieben: Entwickler codieren OData-Dienste, JavaScript und XML. Salesforce hingegen verwendet seine eigenen No-Code-Tools zur Erstellung von neuen Lösungen. Erkennen Sie den Unterschied?

Unserer Meinung nach ist Salesforce die bessere Lösung, um neue, benutzerfreundliche Anwendungen zu erstellen, ohne Code schreiben zu müssen. Selbst wenn Sie eine neue Benutzeroberfläche auf der Grundlage von SAP erstellen möchten, kann dies auf der Salesforce-Plattform einfacher und besser geschehen.

Mit Vigience Overcast können Sie Daten, die in SAP S/4HANA, SAP ERP oder einer der cloudbasierten Lösungen auf SAP BTP gespeichert sind, ganz einfach integrieren und sie entweder replizieren oder in Echtzeit in der Salesforce-Benutzeroberfläche anzeigen. Auf diese Weise können Sie eigenständige Anwendungen oder Lösungen erstellen, die Daten von SAP mit Informationen aus Salesforce oder Drittanbieteranwendungen kombinieren. Overcast geht über das hinaus, was SAP Build bietet, da Sie jede der Tausenden von BAPIs, die in SAP verfügbar sind, problemlos integrieren können.

SAP-Daten in Salesforce ohne eine Zeile Code

Da Salesforce DAS System für das Engagement auf dem heutigen Geschäftsmarkt ist, macht es Sinn, darauf benutzerdefinierte Anwendungen zu erstellen, indem man seine No-Code-Infrastruktur nutzt und Overcast zur Integration mit jedem Backend-System einsetzt, insbesondere SAP.

Wenn Sie mehr über die Möglichkeiten erfahren möchten, die sich Ihnen mit Vigience Overcast und der Salesforce-Plattform bieten, nehmen Sie Kontakt mit uns auf und abonnieren Sie unseren Newsletter.