iX 5/2016
S. 126
Praxis
Kundenbeziehungsmanagement
Aufmacherbild

Apex-Programmierung in Salesforce

Kontrollierter Kontakt

Wer komplexere Aufgaben im Salesforce CRM erledigen will, sollte sich mit der integrierten Programmiersprache Apex beschäftigen. Eine Einführung in die Entwicklung eigener Abfragen zeigt exemplarisch, wie das funktioniert.

Salesforce.com bietet seinen Kunden out of the box bereits diverse Standardobjekte wie Accounts, Leads oder Opportunities und Funktionen wie Chatter sowie die mobile Salesforce1-Anwendung an. Der genaue Umfang hängt vom gebuchten Paket ab. Wer die Standardfunktionalität an die Anforderungen seines Unternehmens anpassen möchte, kann das relativ einfach mithilfe von benutzerdefinierten Objekten und Feldern erledigen.

Der letzte Artikel [3] beschrieb, wie man seine Salesforce-Instanz mit den Einzelhandelsdaten von Dunnhumby befüllt und dazu eigene Felder ergänzt beziehungsweise Tabellen hinzufügt. Das war relativ fix via „Point-and-Click“ umgesetzt. Auch wenn nichts programmiert werden musste, kam dabei schon das zum Einsatz, was Salesforce als „die Plattform“ bezeichnet: Force.com. Sie umfasst alle Konfigurationstools, die Programmiersprache Apex sowie die Frameworks Visualforce und das neue Lightning Experience.

Anpassen auf zwei Wegen

Wer Anpassungen an seiner Salesforce-Instanz vornehmen möchte, kann dies grundsätzlich auf zwei verschiedenen Wegen erledigen: auf die beschriebene deklarative Weise, also per Mausklick, oder programmgesteuert mithilfe von Apex-Code. Die Empfehlung von Salesforce an seine Nutzer ist, stets genau zu prüfen, ob eine Anpassung per Klick umgesetzt werden kann, bevor man eine eigene Apex-Lösung entwickelt. Denn die Programmierschnittstelle dient dazu, Anpassung zielgerichteter und detaillierter vorzunehmen, als es mit den Klick-Assistenten möglich wäre.

Im Rahmen dieses Artikels sollen die Accounts für die Haushalte durch ein Widget erweitert werden, das die Funktion hat, dem Marketingmitarbeiter das Ausstellen eines Coupons für den Haushalt vorzuschlagen und ihn gegebenenfalls gleich zu verschicken. Dabei soll man zwischen dem Haushaltsvorstand und allen verknüpften Kontakten wählen können, um auch sicher das an dem Coupon interessierte Haushaltsmitglied zu erwischen. Der Fokus soll auf der Benutzeroberfläche und der dafür nötigen Programmlogik liegen, weniger auf der Auswahl der für jeden Haushalt relevanten Coupons.

Dazu zeigt dieser Artikel, wie man Visualforce-Seiten anlegt und in ihnen einfache Apex-Elemente einsetzt und wie man Apex-Klassen und SQL-Abfragen erstellt. Zudem geht es um die Einbindung des E-Mail-Versands.

Visualforce und Lightning Experience

Listig 1: Apex-Code-Beispiel

<apex:page>
    <p>Dies ist ganz normales <strong>HTML</strong></p>
    <apex:pageBlock title="Dies ist ein PageBlock!">
        Er wird in den passenden Code umgewandelt
        und  passt optisch in die
        Oberfläche von Salesforce.
    </apex:pageBlock>
</apex:page>
Selbst gemacht: Salesforce wandelt das Visualforce-Markup (oben) bei der Auslieferung der Seite in den passenden HTML-Code um, den der Webbrowser darstellen kann (unten) (Abb. 1).

Eine Möglichkeit, eine Salesforce-Komponente zu erstellen, basiert auf Apex-Code und Visualforce. Eine Visualforce-Seite besteht aus einfachem HTML und vorgefertigten Komponenten, die über eine spezielle Markup-Sprache eingebunden werden können. Der Quelltext ist in <apex:page>-Tags eingeschlossen und muss wohlgeformtem XML entsprechen. Listing 1 und Abbildung 1 zeigen den Code und das ausgelieferte Ergebnis.

Das Einbetten von JavaScript ermöglicht dynamische Seiten, darüber hinaus bietet die „Visualforce Component Library“ (siehe „Alle Links“) eine Fülle von fertigen Bausteinen, die über den apex-Namespace angesprochen werden können und sich ohne Aufwand optisch in die gewohnte Oberfläche eingliedern.

Das 2016 eingeführte Lightning-Framework unterstützt Responsive Design (Abb. 2).

Als Nachfolger der bekannten Oberfläche, die nun „Classic“ heißt, kündigte Salesforce im August 2015 Lightning Experience (LEX) an. Lightning basiert auf dem bereits mit der mobilen App von Salesforce, Salesforce1, eingeführten Lightning-Framework, das vor allem durch seine flexible und modern anmutende Darstellung punkten kann. Das Unternehmen beschreibt die Oberfläche als „schnell, schön und individuell“. Größter Vorteil ist die Unterstützung des sogenannten Responsive Webdesign: Für den Desktop entwickelte Anwendungen funktionieren auch auf Smartphones und Tablets. Nachdem das Lightning-Framework über das Setup aktiviert ist, kann der Benutzer frei zwischen alt und neu wechseln.

LEX bringt aber leider noch nicht alle Features mit, die der Anwender von Salesforce Classic gewohnt ist. Salesforce rät darum selbst, den Umstieg gut abzuwägen und eventuell noch ein bisschen abzuwarten.

Darum bezieht sich dieser Artikel im weiteren Verlauf auf die Entwicklung von Visualforce-Seiten für die klassische Oberfläche. Man ist damit aber nicht auf diese beschränkt, das Widget wird auch auf der neuen Oberfläche sichtbar sein, sobald sie in das Account-Layout eingefügt ist.

Models, Views und Controller

Denn das MVC-Paradigma (Models, Views, Controller), das auch in Salesforce Anwendung findet, trennt Anwendungslogik, Datenhaltung und die Präsentation durch eigene Schichten. Das ermöglicht nicht nur eine konsequente Modularisierung der Schichten, sondern erleichtert auch die Kodierung durch klar getrennte Aufgabenbereiche.

Eine Visualforce-Seite übernimmt nach diesem Paradigma die Funktion eines Views. Das PageBlock-Beispiel benötigt noch keinerlei Anwendungslogik oder Daten. Stattdessen kommt dieser View ganz ohne Model oder Controller aus. Will man dynamische Informationen präsentieren, braucht es zunächst einen Controller, der sie zur Verfügung stellt.

In den meisten Fällen muss man dafür nicht unbedingt eigenen Code schreiben. Denn die Force.com-Plattform bietet bereits fertige Standardcontroller, sowohl für die enthaltenen als auch für selbst erzeugte Objekte. Diese bringen alle nötigen Methoden für den gewöhnlichen Umgang mit Objekten mit. Die Bezeichnung von Controllern für Standardobjekte entspricht dem Namen des Objekttyps im Singular. Also beispielsweise Account für den Zugriff auf die Accounts.

Bei selbst definierten Objekten – wie den Coupons – bildet sich der Name ebenso, hier wird jedoch zusätzlich das Suffix __c für „custom“ angehängt: "Coupon__c". Um in einer Seite schnellen Zugriff auf eine Liste von Objekten zu erhalten, ist außerdem das Attribut recordSetVar des <apex:page>-Tags interessant. Das signalisiert der Plattform, dass der sogenannte Standard List Controller für die Coupons zum Einsatz kommen soll. Er übergibt eine Auswahl der Objekte automatisch an die als Wert angegebene Variable. Das sieht im Code dann so aus: