Die cloudbasierte CRM-Software Salesforce stellt den Kunden bereits verschiedenste Funktionen im Standard zur Verfügung. Falls die Standardfunktionen einmal nicht mehr ausreichen, kann Salesforce per Customizing individuell angepasst werden. Aber wenn die Unternehmensanforderungen selbst durch das Customizing nicht erfüllt werden, hilft Individualentwicklung. In diesem Beitrag werden die wichtigsten Aspekte der Softwareentwicklung* mit Salesforce thematisiert.
Einstieg in die Softwareentwicklung mit Salesforce
Bei der Softwareentwicklung bedient sich Salesforce einer eigenen Programmiersprache, die sich aber stark an bereits verbreiteten Programmiersprachen orientiert. Das bedeutet: Erfahrene Entwickler haben in den meisten Fällen keine großen Probleme, in die Softwareentwicklung mit Salesforce einzusteigen.
Was die Softwareentwicklung von Salesforce aber noch von anderen unterscheidet: Sie findet auf der Lightning Platform (früher: force.com) statt. Diese Plattform wurde als sogenannte Platform-as-a-Service gebaut.
Mit welchen Programmiersprachen wird Salesforce entwickelt?
Für die Entwicklung auf der Plattform gibt es unterschiedliche Programmiersprachen, die sich in Backend- und Frontendprogrammiersprachen unterteilen:
Apex
Apex ist die Backendprogrammiersprache von Salesforce und ist so gesehen ein Derivat von Java. Entwickler, die bereits mit Java oder C# gearbeitet haben, stehen bei der Softwareentwicklung mit Salesforce also vor keiner großen Herausforderung, da Syntax und Programmiersprache ähnlich sind.
Lediglich Schnittstellen und Besonderheiten, die Salesforce für den Gebrauch innerhalb der Salesforceinstanz bereitstellt, sind für Entwickler neu. Dazu zählen beispielsweise direkte Datenbankzugriffe. Bei Java muss nämlich extern immer eine Datenbank eingebunden werden. Bei Apex hingegen gibt es bereits Datenbanken, die ohne das Einbinden genutzt werden können.
VisualForce
Die Frontendprogrammiersprache VisualForce ist das älteste, noch benutzte Frontend-Framework von Salesforce und hat mit die meisten technischen Limitierungen. Es ist überwiegend dafür zu verwenden, in direkter Kommunikation* mit einem ganz bestimmten Datensatz zu arbeiten. Denn diese Programmiersprache hat noch eine starke direkte Kommunikationsschnittstelle zur Datenbank. Da viele vorgefertigte Components von VisualForce noch der alten Salesforce Classic-Umgebung entsprechen, ist diese Frontendprogrammiersprache allerdings nicht die modernste.
Lightning Components/Aura Components
Das Aura Component Framework – früher bekannt als „Lightning Components“ – ist eine weitere Frontendprogrammiersprache. Lightning Components wurde zu Aura Components umbenannt, da es mittlerweile ein weiteres Framework (nämlich Lightning Web Components) gibt, was ebenfalls komponentenbasiert ist und auf der Lightning-Oberfläche läuft und es deswegen zu Verwechslungen kommen kann. Da Aura Components bereits ein paar Jahre auf dem Markt ist, ist die Programmiersprache schon sehr ausgereift und besitzt einen eigenen Service, um beispielsweise Datensätze anzulegen oder Daten auszulesen.
Lightning Web Components
Der Grund, warum Lightning Components in Aura Components umbenannt wurde, ist Lightning Web Components. Die Besonderheiten von Lightning Web Components ist die starke Orientierung an aktueller Webentwicklung und die Flexibilität.
Was bei den Frontendprogrammiersprachen noch wichtig ist: VisualForce, Lightning Web und Aura Components beinhalten HTML und JavaScript. Der einzige Unterschied zwischen den Programmiersprachen sind die vorgefertigten Code-Komponenten. Diese können vor allem dafür verwendet werden, wiederkehrende Fälle zu vereinfachen. Zum Beispiel gibt es für Tabellen eine vorgefertigte Komponente.
Fehler und Best Practices der Softwareentwicklung mit Salesforce
Der Einstieg in die Softwareentwicklung mit Salesforce ist zwar relativ einfach. Jedoch kann bei der Entwicklung auch einiges schiefgehen. Deswegen wird im Normalfall immer empfohlen, einen Berater über den finalen Code schauen zu lassen.
Gerade für Einsteiger in die Welt der Salesforce-Entwicklung gibt es zwei konkrete Best Practices:
Mehrere Datenbankabfragen
Mit Salesforce ist es möglich, direkt innerhalb des Codes Abfragen an die Datenbank abzuschicken – ohne vor irgendwelchen Hindernissen zu stehen. Zum Beispiel, wenn ein Entwickler gerade dabei ist, Daten zu bearbeiten und dazu noch weitere Datensätze einer anderen Tabelle braucht. Diese können einfach genutzt werden.
Konkreter: Der Entwickler hat eine Liste mit 12 Elementen und jedes Element wird einzeln verarbeitet. Das heißt also, dass für jedes Element separat eine Abfrage an die Datenbank verschickt wird, obwohl es auch mit einer einzigen Abfrage abgehandelt werden könnte. Diese vielen Abfragen führen dazu, dass schnell die sogenannten Apex Governor Limits erreicht werden. Diese sorgen dafür, dass sich nicht mehrere Instanzen auf den Servern in die Quere kommen. Wenn dieses Limit erreicht wird, dann bricht das Konstrukt an Datenbankabfragen ab und es gibt eine Fehlermeldung.
Die Lösung: Die Elemente können entweder als Liste oder als sogenannte Map (also eine Zuweisung von einer Datensatz-ID zu dem gesamten Datensatz) im Vorfeld abgefragt werden. Wenn sich der Entwickler in einer Datenbankabfrageschleife befindet und Daten aus dieser Map oder Liste benötigt, dann sollte er sich nur darauf beziehen.
Apex Datenbankauslöser
Bei der normalen Einführung eines Apex Datenbankauslösers stehen Entwickler oftmals vor folgendem Problem: Wenn es mehrere Datenbankauslöser auf dem gleichen Datensatz gibt, kann der Entwickler nie genau wissen, wann und wie oft welcher Auslöser ausgeführt wird.
Auch hier gibt es eine einfache Lösung: ein einziger Datenbankauslöser pro Objekt pro Tabelle. Wird beispielsweise ein Account geupdatet, dann startet auf diesem Account nur einmal der Auslöser. Dieser Auslöser sorgt dann dafür, dass alle notwendigen Datenverarbeitungsmethoden durchgeführt werden. Ein weiterer Vorteil dieser Vorgehensweise: Rekursionen werden vermieden. Das bedeutet also, dass wenn ein Account mehr als einmal geupdatet wurde, wird er trotzdem nur einmal verarbeitet.
Dieses „1 Auslöser pro Objekt“ passiert unter Zuhilfenahme eines externen Auslöser-Frameworks. Die Datenverarbeitungsmethoden sind sozusagen „Services“, von denen der Auslöser Gebrauch macht.
Vor- und Nachteile der Softwareentwicklung mit Salesforce
Vorteile
Der größte Vorteil der Softwareentwicklung mit Salesforce: Es gibt kaum einen Prozess, der sich nicht mit Code darstellen lässt. Selbst wenn ein Unternehmen* sehr spezifische Anforderungen hat, bietet es sich in den meisten Fällen an, Code zu nutzen. Denn nicht alle Entwickler sind die größten Fans der Salesforce-Standard-Features, gerade wenn es in Richtung Prozessautomatisierung geht – wie beim Process Builder. Dieser ist zwar für simple Automatisierungen empfehlenswert, aber wird es komplexer greifen viele Entwickler auf Code zurück.
Nachteile
Je unerfahrener der Entwickler und je komplexer die Anforderungen, desto häufiger kommt es vor, dass Randfälle nicht beachtet werden. Diese Randfälle können eintreten, weil sich der Prozess verändert hat und auf einmal funktioniert der Code, der vor einem halben Jahr programmiert* wurde, nicht mehr. Das kann auch die Folge sein, wenn sich Administratoren und Entwickler nicht absprechen.
Was muss beachtet werden, wenn von Salesforce Classic auf Lightning umgestellt wird?
Da die Umstellung von Salesforce Classic auf Salesforce Lightning gerade bei vielen Unternehmen aktuell ist, fragen sich viele: Was passiert mit den Eigenentwicklungen durch die Umstellung? Die beruhigende Antwort: All das, was im Backend in Apex programmiert wurde, muss nicht überarbeitet werden, denn Apex hat sich durch den Wechsel von Salesforce Classic auf Lightning nicht geändert. An welcher Stelle aber nochmal nachgearbeitet werden sollte, sind VisualForce Pages. Die können zwar theoretisch weiterhin verwendet werden, aber dann passen die Seiten nicht mehr zum restlichen User Interface.
Über den Autor:
Dennis Grzyb ist Salesforce Consultant im Fachbereich mindforce. In seinem Studium der Wirtschaftsinformatik an der Universität Münster hat er sich unter anderem Wissen über Geschäftsprozessanalyse und -management angeeignet. Darüber hinaus sammelte er Erfahrungen in agiler Softwareentwicklung im Rahmen mehrerer Projekte. In seinem Berateralltag setzt er nun seinen Fokus auf den gezielten und geschulten Einsatz von Code für die Bewältigung von Aufgaben, die sich nicht mehr im Standard umsetzen lassen. Er betreut hoch komplexe Instanzen, die viel auf Customizing und Custom Code basieren, und verhilft diesen Kunden als zertifizierter „Application Architect“ zum Erfolg.