Es gibt sicherlich viele Artikel aus der Sicht von Anwendern oder Beschreibungen der Standard-Features in Salesforce. Sucht man jedoch nach der Perspektive derer, die sich mit der Welt hinter der Kulisse befassen, sprich: den Entwicklern, sucht man oft vergeblich. Daher möchte ich mit diesem Grundlagen-Beitrag den Blick darauf lenken, wie Entwickler mit Salesforce arbeiten können und welche Änderungen darin möglich sind. Beginnen will ich mit einer kurzen Einführung, was Salesforce Entwicklern bietet. Ziel ist es, Entwicklern dadurch eine professionelle Arbeitsweise mit Salesforce zu ermöglichen. In weiteren Beiträgen werde ich auf Details eingehen und versuchen, Erfahrungen weiterzugeben.
Deklarative und programmatische Anpassungen
Anpassungen können in Salesforce entweder über die Benutzeroberfläche vorgenommen werden (deklarativ) oder, in dem man einen eigenen Quelltext in den sogenannten Apex hinzufügt (programmatisch).
Deklarative Änderungen bieten hierbei sehr weitreichende Möglichkeiten. Zum einen lässt sich das Daten-Model hierüber anpassen und erweitern. Zum anderen werden viele Möglichkeiten geboten, verschiedenste Aktionen abhängig von Änderungen der Daten durchzuführen. So können zum Beispiel andere Felder aktualisiert werden, Mitarbeitern Aufgaben zugewiesen oder Emails versandt werden.
Wenn die deklarativen Anpassungsmöglichkeiten nicht mehr genügen, kommen die programmatischen Änderungen ins Spiel. Programmatisch ist hierbei durchaus wörtlich zu nehmen. Es handelt sich hierbei um Quelltext, der in einer Programmiersprache verfasst wird, die Java ähnelt. Dieser kann auf verschiedenste Art zur Ausführung kommen. Sei es durch Bedienelemente in der Benutzeroberfläche, Veränderung von Daten oder zu festgelegten Zeiten. Zusammen mit der Möglichkeit, auf HTML basierende Benutzeroberflächen zu erstellen und zu integrieren, stellt Salesforce in manchen Fällen nur noch eine Plattform zur Ausführung und Laufzeitumgebung dar.
Umgang mit verteilter Logik
Nutzt man die oben genannten Möglichkeiten, um eigene Geschäftsprozesse abzubilden, so kann es schnell dazu kommen, dass sich die dazugehörige Logik auf sehr viele Stellen verteilt. So kann ein Teil auf deklarative Art gelöst sein, während ein darauf aufbauender Teil, programmatisch gelöst werden muss. Während das bei geringen Anpassungen noch kein Problem ist, wird es bei umfangreicheren Anpassungen sehr schnell schwieriger im Blick zu behalten, was nun eigentlich wann geschieht und was zu welchem Geschäftsprozess gehört. Insbesondere dann, wenn verschiedenste Prozesse an den gleichen Daten hängen.
Um hiermit besser umgehen zu können, empfehlen sich zwei Maßnahmen:
- Eine gesonderte Dokumentation, die deutlich macht, wie der Geschäftsprozess in Salesforce abgebildet wurde. Besonders hilfreich sind hierbei Ablaufdiagramme, die zeigen, welche Komponenten zu welcher Zeit betroffen sind und welche Anpassungen damit verknüpft sind.
- Sind Geschäftsprozesse sehr komplex und erfordern ein hohes Maß an Anpassungen, empfiehlt es sich, ein Prefix zu definieren, der allen Änderungen vorangestellt wird.
Die Sandbox
Eine Sandbox in Salesforce stellt eine ganze oder teilweise Kopie der produktiven Umgebung dar. Salesforce unterscheidet hier zwischen Daten, verfügbarem Speicherplatz und Anpassungen. Während die Anpassungen in allen Fällen kopiert werden, gibt es Kopien inklusive aller Daten der Produktivumgebung, eines Teils der Daten oder komplett ohne Daten, aber mit unterschiedlichem Umfang an verfügbarem Speicherplatz.
Darüber hinaus können diese nach unterschiedlichen Zeiträumen neu erstellt werden. So kann zum Beispiel eine komplette Kopie nur einmal pro Monat neu erstellt werden, während Kopien ohne Daten alle 24 Stunden neu erstellt werden können, aber dafür in großem Umfang.
Übertragung von Änderungen zwischen Sandboxen
Um Änderungen zwischen Sandboxen zu übertragen, kann entweder das User Interface benutzt werden oder eines von zwei externen Werkzeugen (Force.com IDE oder Force.com Migration Tool – mehr dazu später).
Strukturierung des Entwicklungsprozesses
Grundsätzlich können in Salesforce deklarative Anpassungen direkt in der Produktivumgebung durchgeführt werden. Im Gegensatz dazu können programmatische Änderungen nur auf einer Sandbox erstellt und später in die Produktivumgebung transportiert werden.
Will man nun mit mehreren Mitarbeitern an verschiedenen Änderungen arbeiten und eine gewisse Qualität gewährleisten, sollte man direkte Änderungen in der Produktivumgebung vermeiden. Außerdem sollten sich Mitarbeiter nicht gegenseitig behindern, während sie an Anpassungen arbeiten.
Um dies zu gewährleisten, empfiehlt sich eine Struktur wie folgende:
Hierbei werden Änderungen auf der Sandbox des jeweiligen Entwicklers entwickelt und vollständig getestet. Ist dies geschehen, werden diese Änderungen auf die QA-Sandbox übertragen. Dort kann nochmals, auf Basis der dort vorhandenen Unternehmensdaten, ein abschließender Test gemacht werden. Ist alles in Ordnung, werden die Änderungen in die Produktivumgebung übertragen.
Dieser Ansatz bietet folgende Vorteile:
- Entwicklung und Test können durchgeführt werden, ohne dass evtl. Fehler das Produktivsystem beeinflussen.
- Entwickler kommen sich nicht gegenseitig in die Quere und können gleichzeitig an verschiedenen Änderungen arbeiten.
- Die Zentrale QA-Instanz erlaubt Integration und Test mehrerer Änderungen, die im Anschluss gemeinsam in die Produktivumgebung übernommen werden sollen.
- Die QA-Instanz, als zentrale Instanz, über die alle Änderungen verlaufen, erlaubt es Werkzeuge zur Versionsverwaltung (z.Bsp. Git) zum Einsatz zu bringen und so zusätzliche Sicherheit zu schaffen. Leider verfügt Salesforce selbst über keinerlei Möglichkeiten hierzu.
Werkzeuge des Entwicklers
Als Entwickler hat man mehrere Möglichkeiten, Quelltexte zu erstellen und anzupassen. Immer verfügbar ist die sogenannte Developer Console, welche sich in einem separaten Browserfenster öffnet. Als weitere Möglichkeit werden die Force.com IDE sowie das Force.com Migration Tool angeboten. Die IDE ist hierbei eine Erweiterung für Eclipse, während das auf Ant basierende Migration Tool hauptsächlich dazu eingesetzt wird, Änderungen zu transportieren.
Beiden externen Werkzeugen ist jedoch gemeinsam, dass sie über die sogenannte Metadata API auf Salesforce zugreifen. Diese erlaubt es, nahezu alle Datenobjekte, Anpassungen, Quelltexte und vieles mehr zur erhalten. Sei es in Form einer XML-Repräsentation oder als direkte Quelltextdateien.
Wer möchte, kann auf diesem Weg seine gänzlich eigene IDE entwickeln oder Salesforce in bestehende Entwicklungsprozesse integrieren.
Fazit
Salesforce bietet sehr viele Möglichkeiten, eigene Änderungen vorzunehmen oder gar vollkommen eigene Funktionalitäten zu schaffen. Es macht es leicht, Änderungen direkt vorzunehmen. Eine Professionalisierung wird jedoch nur unzureichend von Haus aus unterstützt (Versionierung, Transport von Änderungen zwischen Instanzen etc.). Diese wird manchmal sogar erschwert. Da das System keine professionelle Herangehensweise erzwingt, wird von den jeweiligen Entwicklern ein hohes Maß an Disziplin und Eigenverantwortung verlangt. Während diese Probleme bei kleinen Anpassungen in sehr kleinen Teams noch mit vertretbarem organisatorischen und manuellen Aufwand gehandhabt werden können, werden diese umso schwerwiegender, je umfangreicher die Änderungen bzw. das Team ist.
In den kommenden Wochen veröffentliche in an dieser Stelle einen Folge-Artikel darüber, welche Möglichkeiten Salesforce bietet, Unit Tests zu schreiben und welche Herausforderungen damit verbunden sind.
