Erweiterung von / Anwendungsentwicklung auf Salesforce

Das, was Salesforce.com deutlich von seinen Mitbewerbern absetzt, ist die Möglichkeit, eigens entwickelten Programmcode auf den Servern von Salesforce auszuführen. So lässt sich die CRM-Funktionalität nach Belieben erweitern oder sogar ganze Applikationen und Websites auf ‚force.com‚ betreiben. Dieser Artikel soll einen Einblick in die Möglichkeiten geben, die einem damit zur Verfügung stehen. Er richtet sich damit an Administratoren und Entwickler.

Zu Anfang empfiehlt es sich einen Developer Account bei Salesforce anzulegen. Damit steht einem die komplette Dokumentation offen und man bekommt eine Entwicklungs-Instanz, die einem vollwertigen Salesforce entspricht. Gut zum Rumprobieren geeignet wäre auch eine Sandbox. Dabei handelt es sich um eine 100% Kopie der Original-Instanz, welche immer wieder zurückgesetzt werden kann. Das Einrichten einer Sandbox geschieht in wenigen Mausklicks. Schon nach einigen Minuten erhält man eine Benachrichtigung per e-mail und die Sandbox kann genutzt werden.

In jedem Fall empfehle ich auch einen Besuch dieser Seite, um einen vollen Überblick über die Salesforce Plattform zu erhalten.

Programmlogik wird auf Salesforce in Apex geschrieben. Die Syntax ist Java-ähnlich. Um den geschriebenen Code bei Datenbank-Operationen, wie dem Einfügen, Editieren und Löschen von Objekten auszuführen, werden trigger angelegt. Typische Anwendungsgebiete sind

  • Validierung von Daten
  • Veränderung von Daten
  • Anstoßen von Prozessen
  • API-Calls

Theoretisch kann die ganze Programm-Logik auch im trigger liegen. Dies wird aber als schlechter Stil angesehen. Der persönliche Anspruch eines jeden sollte es daher sein hier deutlich zu trennen und vom trigger heraus Methoden in Klassen aufzurufen.

Anwendungstests werden ebenso in Apex geschrieben. Testklassen werden mittels ‚@isTest‘ deklariert.

Die Oberfläche von Salesforce.com lässt sich mittels Visualforce Seiten erweitern. Diese können z.B. als Reiter (Tab) eingebunden werden oder als einzelnes Element in einem existierenden Objekt.

Visualforce Seiten lassen sich auch als Site zusammenfassen und so als Website verfügbar machen. Dabei kann die Nutzung entweder uneingeschränkt, auf IP-Ebene oder auf registrierte Nutzer eingestellt werden. Gerade die Vergabe von User-Lizenzen ist aber noch relativ teuer. Sites werden eingesetzt, um komplett eigenständige Applikationen zu bauen oder um einfache Landing-Pages mit direkter CRM-Anbindung schnell umzusetzen. Gute Beispiele für Sites sind zum Einen jegliche Seiten von Salesforce wie die blogs oder auch der ideaExchange, große Portal wie myStarBucksIdea von Starbucks oder die Ergebnisse der Developer-Challenge zur Sites Einführung: GameCraze, H&W-Webshop

Programmieren kann man theoretisch alles im Browser. Bei Visualforce-Seiten ist dies gut handhabbar. Der geschriebene Code wird nach dem Speichern im gleichen Fenster angezeigt und man sieht sofort das Resultat. Wenn es um Apex Code geht ist es angenehmer mittels Eclipse IDE zu programmieren. Dort steht einem dann richtiges Syntax-Highlighting und Auto-Vervollständigung zur Verfügung. Jede Änderung muss allerdings auf den Server gespeichert werden und kann nur dort ausgeführt werden. Dies ist im Gegensatz zu ähnlichen Technologien, die Offline-Kompilierung bieten, ärgerlich und durch die langsame Verbindung über den großen Teich zugleich Zeitraubend.

Beim Schreiben von eigenen Methoden ist man an Governor-Limits gebunden. Diese besagen wie viele SQL-Selects, Datenbank-Operationen, emails, outbound API-calls usw. in einem Ausführungs-Kontext gemacht werden dürfen. Außerdem gibt es eine theoretische Grenze an geschriebenen Zeilen code pro Organisation.

Alle Eigenentwicklungen müssen durch Anwendungstests abgedeckt werden. Um in eine Live-Instanz deployen zu können ist außerdem eine gewisse Code-Coverage von Nöten. Die Test-Klassen müssen mit deployed werden. Um entwickelte Anwendungen in eine Produktiv-Instanz zu bekommen gibt es verschiedene Wege:

– Deploy per Eclipse-IDE. Alle benötigten Komponenten werden in Eclipse markiert und dann in die Ziel-Instanz deployed. Dieses Verfahren ist sehr ‚Anonym‘. Mir ist keine Möglichkeit bekannt wie man nachvollziehen kann wer wann was deployed hat.

Deployment-Connections: Ein relativ neues Feature. Zwischen einer Produktiv-Umgebung und einer Sandbox (Abzug einer Produktiv-Umgebung) wird eine ‚Deployment Connection‘ hergestellt. In der Sandbox wird ein Paket mit den gewünschen Komponenten zusammengestellt und in die Produktiv-Instanz hochgeladen. Auf der Produktiv-Seite kann das Paket angenommen und deployed werden. Das Gute an diesem Verfahren ist, dass Entwickler und deployender Admin zwei verschiedene Personen sein können. Außerdem benötigt jedes Deployment-Vorhaben eine Beschreibung. Damit lassen sich Vorgänge besser dokumentieren.

Die dritte Möglichkeit bringt das Thema auf ein ganz besonderes Feature von Salesforce: Die AppExchange. Dort können Entwicklungen entweder privat oder, gegen eine Gebühr, auch öffentlich abgelegt werden. Für privat abgelegte Pakete kann man zum Verteilen einen Link weiterreichen. Pakete von der AppExchange lassen sich mit wenigen Klicks in die eigene Salesforce-Organisation übernehmen. Dabei ist es egal, ob es sich um eine Produktiv- oder Entwicklerinstanz handelt.

Entwickeln auf Salesforce macht Spaß. Dadurch, dass man sich nicht mit dem Aufsetzen von Entwicklungs-Servern und/oder Datenbanken auseinandersetzen muss ist man wesentlich agiler.

Wenn Sie jetzt Appetit bekommen haben empfehle ich als weiterführende Lektüre das Buch „Development with the Force.com Platform“, ISBN: 0321647734

Informativ ist auch dieses Video, worauf Andreas jüngst ein seinem blog verwiesen hat.

2 thoughts on “Erweiterung von / Anwendungsentwicklung auf Salesforce

  1. Pingback: Ein erster Blick auf Salesforce Chatter « Salesforce-Blog.de

  2. Pingback: Validierung einer Bedingung: Formel vs. Query « Salesforce-Blog.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.