Salesforce.com Entwicklerhandbuch. On-Demand-Anwendungen mit Apex

8445-7.book Page 1 Wednesday, February 21, 2007 4:00 PM Andreas Holubek, Christian Metzger Salesforce.com – Entwicklerh...

Author: Andreas Holubek | Christian Metzger

99 downloads 1254 Views 12MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

8445-7.book Page 1 Wednesday, February 21, 2007 4:00 PM

Andreas Holubek, Christian Metzger Salesforce.com – Entwicklerhandbuch



Andreas Holubek, Christian Metzger

Salesforce.com Entwicklerhandbuch On-Demand-Anwendungen mit Apex und Apex Code


Andreas Holubek, Christian Metzger: Salesforce.com Entwicklerhandbuch ISBN: 978-3-935084-45-7

© 2007 entwickler.press Ein Imprint der Software & Support Verlag GmbH

http://www.entwickler-press.de http://www.software-support.biz

Ihr Kontakt zum Verlag und Lektorat: [email protected]

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Korrektorat: mediaService, Siegen Satz: mediaService, Siegen Umschlaggestaltung: Melanie Hahn, Maria Rudi Belichtung, Druck & Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.


Inhaltsverzeichnis V

Vorwort

9

1

Einleitung

11

1.1

Überblick über die Apex-Plattform von Salesforce.com

11

1.2

Anwendungen für die Apex-Plattform

13

1.3

Der Weg durch das Buch

14

2

Salesforce.com planen, einrichten und konfigurieren

15

2.1

Überblick über die Planung, die Einrichtung und das Customizing von Salesforce.com

15

2.2

Die Planung der Einführung von Salesforce.com

15

2.3

Customizing von Salesforce.com Benutzerdefinierte Felder Validierungsregeln Seitenlayouts Suchlayouts Schaltflächen und Links

17 18 20 21 23 24

2.4

Zugriffsrechte und Sichtbarkeit von Daten Tipps und Tricks zum Vorgehen

25 29

2.5

Einrichten und Verwalten von Workflows Workflow-Regeln Genehmigungsprozesse Aufgaben Benachrichtigungen Feldaktualisierungen Ausgehende Nachrichten

31 31 31 32 32 32 33

2.6

Beispiel Rollout-Plan für eine Salesforce.com-Einführung Vorbereitung Systemkonfiguration Datenmanagement/Migration Einführung Nachverfolgung

33 33 35 46 48 51

3

Initial Load

53

3.1

Vorhandene Datenquellen

53

3.2

Probleme des Initial Load Datenaktualität Datenqualität Heterogene Quellen

55 55 56 58

Salesforce.com Entwicklerhandbuch

5


Inhaltsverzeichnis

6

Qualitative Abgrenzung Quantitative Abgrenzung Lade-Programme

60 61 62

3.3

Ablauf des Initial Load selbst

63

3.4

Ein einfaches Beispiel für einen Initial Load

65

3.5

10 Tipps zum Initial Load Administrator-Rechte Scripte „Fingerabdruck“ Preisbucheinträge Account OwnerId Importdaten archivieren Validieren. Validieren. Validieren. Lade-Programme erst spät schreiben Lade-Programme für periodischen Abgleich vorbereiten Kein direkter API-Zugriff im Lade-Programm

70 70 70 71 71 71 72 72 72 72 73

4

Anwendungen mit dem Apex Builder – Grundlagen

75

4.1

Apex Builder im Überblick

75

4.2

Bestandteile einer Anwendung Benutzerdefiniertes Objekt (Custom Object) Benutzerdefinierte Felder Seitenlayout für das Objekt und Felder bestimmen Tabs (Seiten) Benutzerdefinierte Links (Custom Links) Bilder und Dokumente Anwendungen Layouts für Suche und Übersichten S-Controls

76 77 82 98 105 112 116 118 121 122

4.3

Entwicklungstipps Best Practices Migration von Daten beim Einfügen einer Master-Detail-Beziehung

126 126 127

5

Anwendungen mit dem Apex Builder – das Projekt

129

5.1

Beispielanwendung – Issue Tracking

129

5.2

Entwicklung der Objekte

130

5.3

Seiten entwickeln

140

5.4

Anwendung entwickeln

147

5.5

Packen und private Veröffentlichung der Anwendung

148

5.6

Veröffentlichung der Anwendung im öffentlichen AppExchange Directory

154

5.7

Testanwendung (Test Drive Organisation)

159

6

Apex Toolkit für Eclipse

161

6.1

Überblick

161


Inhaltsverzeichnis

6.2

Installation und Apex-Projekt

161

6.3

Abfragen

163

6.4

S-Controls

163

7

S-Controls und das Ajax Toolkit

165

7.1

Überblick

165

7.2

JavaScript

165

7.3

Struktur einer JavaScript-Anwendung

166

7.4

Ajax Toolkit anwenden

167

7.5

Abfragen und Ergebnisse anzeigen

169

8

Anwendungen entwickeln mit dem Apex Web Service API

171

8.1

Web Services Überblick Web Service Description Language (WSDL) Nachrichten WSDL zu Language-Generatoren Salesforce WSDL

171 171 172 175 176 177

8.2

Eine erste Verbindung Vorbereitungen Verbindung mit Salesforce.com aufbauen Umgang mit Verbindungsdaten

178 178 184 187

8.3

Fallstudie: Verwendung des Web Service API für einen Angebotsrechner Spezifikation der Aufgabenstellung Verwendung des Salesforce API Nutzen der Generizität des Ansatzes

188 188 195 211

9

Batchprozesse und Salesforce.com DataExchange

213

9.1

Hinter den Kulissen Daten up-to-date halten Auswertungen Maschinelle Batch-Verarbeitung ist unverzichtbar

213 213 213 214

9.2

Design des Abgleichs Was – Wie – Wo abgleichen? CRUD in Salesforce Eindeutigkeit Das Delete-Problem Eine Fallstudie Architektur-Empfehlungen für den Abgleich Fehlerbehandlung Performanz Helferlein

215 215 217 218 218 219 223 224 227 228

9.3

Salesforce.com DataExchange Anforderungen Beispiel: Kommando-Datei und Trace

228 228 230


7


Inhaltsverzeichnis

10

8

und Kommando: Extract Kommando: Insert Kommando: Update Kommando: Delete Kommando: Selective_Delete Kommando: Mixed_Mode Kommandos: MetaInfo/Extract_Numbers Download von Salesforce.com DataExchange

233 233 234 235 236 236 237 238 238 239 239

Apex Code – On-Demand-Programmiersprache

241

10.1 Überblick

241

10.2 Apex Code schreiben und veröffentlichen Apex Code – Webschnittstelle Apex Code – Eclipse-Integration

242 243 243

10.3 Ein einleitendes Beispiel Das Beispiel Apex Code Package anlegen (Apex Code) Account-Objekt suchen (Apex Code) Neuen Kontakt anlegen (Apex Code) S-Control anlegen (Apex Builder) Web-Tab anlegen (Apex Builder) Test (Salesforce.com)

244 244 245 245 245 246 247 247

10.4 Apex-On-Demand-Sprache Hinweise Datentypen, SObjects, Variablen und Ausdrücke Arrays, Sets und Maps Ablaufsteuerung SOQL-Abfragen Benutzerdefinierte Methoden Data Manipulation Language (DML)-Anweisungen Transaktionen Exception Handling (Ausnahmen) System-Statische Methoden

248 248 248 252 256 257 259 259 261 262 263

10.5 Apex Packages

264

10.6 Objekte sperren

264

10.7 Apex Code mittels AJAX ausführen

265

10.8 Trigger

265

10.9 Test und Code Coverage

265

A

Literaturverzeichnis

267

B

Die Autoren

268

Stichwortverzeichnis

269


V

Vorwort

Die Apex-Plattform von Salesforce.com ist eine der ersten greifbaren Implementierungen der On-Demand Idee für den globalen Austausch von Businessanwendungen und deren Entwicklung. Viele der vorhandenen Ideen und Konzepte der Softwareentwicklung lassen sich natürlich weiter verwenden. Das Bündeln der Anwendungen in einem zentralen Verzeichnis, dem AppExchange Directory, ist jedoch eine spannende Sache. Die Idee hinter dem Buch entstand nicht zuletzt aus den verschiedenen Herangehensweisen an die Apex-Plattform. Zum einen kann der Leser die integrierte Entwicklung mit dem Apex Builder kennen lernen, zum anderen aber auch die Entwicklung von eigenen externen Anwendungen, welche das Apex API nutzen. Mit Ihrem Salesforce.com-Account werden zudem schon vorgefertigte Anwendungen, wie das Customer Relationship Management (CRM), mitgeliefert. Nicht zuletzt deshalb haben wir uns entschieden, auch der Anpassung des Salesforce.com-Account einen Teil des Buches zu widmen. Solch ein Buch entsteht nicht über Nacht, noch wird es im eigentlichen Sinne von nur zwei Autoren geschrieben. Viele Ideen, Hinweise und auch Schriftstücke sind innerhalb der arlanis Software AG entstanden und wurden von uns mit benutzt. Wie möchten uns an dieser Stelle für die immense Mitarbeit an den Kapiteln bei Diane Cremille, Reinhard Greeven und Georg Spengler bedanken. Nicht zuletzt haben wir auch immer wieder verschiedene Teile, Lösungen und Ideen diskutiert und von verschiedenen Seiten beleuchtet. So geht ein freundliches Danke an dieser Stelle auch an Jörg Selig und Michael Kammholz. Von Seiten Salesforce.com danken wir besonders dem deutschen Accountmanager Herrn Wolfgang Kiene, der in vielen Meetings und Besprechungen unsere Arbeit unterstützt hat. Unser besonderer Dank geht auch an Judith Przibill und Daniel Hejda von der Firma W.C. Heraeus GmbH, die in vielen Besprechungen während eines großen Einführungsprojektes uns mit Anregungen und Ideen zur Seite standen. Ein wenig ist so ein Buch wie Software. Trotz großer Sorgfalt kann man nicht verhindern, dass der ein oder andere Bug übrig bleibt. Wenn Sie also Kritik, Anmerkungen oder auch Wünsche haben, senden Sie uns einfach eine Mail. Wir werden versuchen, dies alles in den kommenden Versionen zu berücksichtigen. Die jeweils letzten Ergänzungen und auch die Beispiele können Sie unter http://www.arlanis.com/deutsch/books.php finden.

Andreas Holubek, Christian Metzger Im Januar 2007


9



1 1.1

Einleitung Überblick über die Apex-Plattform von Salesforce.com

Die Apex-Plattform von Salesforce.com [SF01] ist ein Service, um Anwendungen zu entwickeln, anzupassen und nicht zuletzt diese über das Internet auszutauschen. Einer der größten Vorteile dieser Herangehensweise ist, dass die Anwendungen vorher nicht erst installiert oder irgendwie an die vorhandene physische Hardware oder das Betriebssystem angepasst werden müssen: Ein Webbrowser reicht aus. Anwendungen sind On-Demand verfügbar, können beliebig oft genutzt und auch frei zur Nutzung gegeben werden. Das daraus entstehende Netzwerk von Anwendungen ist einer der Schlüssel auch zum eigenen Erfolg. Dabei besteht der Service im Wesentlichen aus zwei Teilen: dem AppExchange Directory [SF02] und der Apex-Plattform. Das AppExchange Directory ist vorstellbar wie ein großer Marktplatz, auf denen die Apex-Anwendungen angeboten werden. Eigene Anwendungen können hier veröffentlicht werden. Apex als Directory ist eine offene, Communitygetriebene Basis, um Anwendungen zu verteilen, nach Anwendungen zu suchen, aber auch eine Anwendung einer großen Basis von möglichen Benutzern zum Anschauen zur Verfügung zu stellen.

Abbildung 1.1: Überblick über die vorhandenen Anwendungen


11


1 – Einleitung

Der zweite Teil ist die Apex-Plattform. Darunter ist die Technologie hinter Salesforce.com zu verstehen. Auf Basis dieser Plattform werden die einzelnen Anwendungen ausgeführt, können neue Anwendungen geschrieben oder auch vorhandene Anwendungen angepasst werden. Auf den Webseiten wird dazu eine Menge an Informationen bereitgestellt [SF03].

Abbildung 1.2: Dokumente, Beispiele und mehr

Wirft man einen Blick etwas tiefer unter die Haube der Apex-Plattform, werden die beteiligten Konzepte und Möglichkeiten sichtbar. Vieles davon kann direkt oder auch unbewusst genutzt werden. So macht man sich als Entwickler einer Apex-Anwendung normalerweise keine Gedanken darüber, wie viele Benutzer gleichzeitig meine Anwendung nutzen, wie viel Speicherplatz dafür notwendig ist oder auch wie die Daten und Anwendungen in Fall eines Stromausfalls gesichert werden. Die Apex-Plattform ist hauptsächlich für datenzentrierte Anwendungen entwickelt worden. So sind alte Bekannte wie Formulare, Seitenlayouts, Datenbanktabellen oder Businessregeln vorhanden und können zu komplexen Anwendungen assembliert werden. Die wichtigsten Konzepte hinter der Apex-Plattform sind jedoch: 쮿

Multitenancy – Hierunter wird ein Model verstanden, bei der alle Anwender und Anwendungen eine einzige, gemeinsame Infrastruktur und Codebasis teilen.

쮿

Apex Builder – Mit dem Apex Builder wird das Metadaten getriebene Entwicklungsmodel bezeichnet, mit dessen Hilfe Anwendungen geschrieben werden können. Die Entwicklung der Anwendungen geschieht mit vorhandenen „Blue Prints“, wobei kein Quelltext benötigt wird.

쮿

Apex API – Das Web Service API bietet einen direkten Zugriff auf die Daten, welche in der Apex-Plattform gespeichert worden. Aus der Technologie heraus kann der Zugriff mit fast jeder Programmiersprache erfolgen.

쮿

Apex OS – Hiermit wird die Möglichkeit beschrieben, mehrere Anwendungen innerhalb eines Salesforce.com-Account gleichzeitig zu betreiben. Diese Anwendungen nutzen dasselbe Datenmodell, Sicherheitsmodell und die gleiche Oberfläche. Beliebige Benutzer können gleichzeitig einen Salesforce.com-Account verwenden.

12


Anwendungen für die Apex-Plattform 쮿

Apex Code – Apex Code ist die On-Demand Programmiersprache. Mit ihr ist es möglich, Module zu entwerfen, welche auf den Salesforce.com-Servern installiert und abgearbeitet werden.

쮿

AppExchange Directory – Eine Bibliothek, in der Anwendungen aufbewahrt werden. Besucher können sich diese Anwendungen anschauen, sie ausprobieren und installieren. Entwickler können dort Anwendungen einem breiten Publikum und Interessenkreis zugänglich machen.

1.2

Anwendungen für die Apex-Plattform

Salesforce.com bringt für einen Salesforce.com-Account von Haus aus mehrere, vorinstallierte, Anwendungen mit. Bekannt geworden vor allem durch das Customer Relationship Management (CRM) ist aber normalerweise auch noch ein Service & SupportBereich vorhanden. Die richtige Stärke spielt die Apex-Plattform jedoch durch die Vielzahl von speziellen Anwendungen aus, welche durch die Kunden entstanden sind. Grundsätzlich können die Anwendungen in eine von drei Kategorien eingeteilt werden. Native Anwendungen Native Anwendungen werden ausschließlich mit Hilfe der Metadaten und dem Apex Builder entwickelt. Sie benutzen weder das interne API direkt noch haben diese Referenzen oder Links auf andere Anwendungen. Composite Anwendungen Composite Anwendungen bestehen aus einer Kombination von Metadaten und low level Funktionalität des Apex API. Solche Anwendungen ermöglichen zum Beispiel die Entwicklung von kundenspezifischen Oberflächen oder die Integration neuer Komponenten für das Benutzerinterface. Interessant ist diese Möglichkeit auch, wenn existierende On-Demand Anwendungen nach Apex portiert werden. Externe Services oder auch externe Komponenten können weiter verwendet werden. Client Anwendungen Die so bezeichneten Clientanwendungen nutzen exklusiv das Apex Client API und arbeiten außerhalb der Kontrolle von Salesforce.com. Solche Anwendungen benutzen zum Beispiel das Web Service API und haben eine von Salesforce.com getrennte Benutzeroberfläche. In diesem Buch wird auf alle Formen einer Apex-Anwendung eingegangen. Sie als Leser und Entwickler können so bestimmen, welcher Typ von Anwendung am besten zur Lösung Ihres Problems geeignet ist.


13


1 – Einleitung

1.3

Der Weg durch das Buch

Natürlich können wir Ihnen nur eine Empfehlung für den Weg durch das Buch geben, das vorweg. In getrennten Kapiteln wird auf die einzelnen Möglichkeiten von Salesforce.com und die verschiedenen Typen einer Apex-Anwendung eingegangen. Wenn Sie zum Beispiel vorhandene Anwendungen anpassen und somit tiefer in Salesforce.com und die Apex-Plattform einsteigen möchten, ist das zweite Kapitel genau das Richtige für Sie. Das 4. Kapitel beschreibt die Möglichkeiten des Apex Builder. Einerseits können mit dem Builder vorhandene Anwendungen verändert als auch neue Native oder Composite Anwendungen erstellt werden. Die Grundlagen dieses Kapitel können später auch als Nachschlagewerk für die einzelnen Artefakte, Feld-, Objekt- und Tabtypen genutzt werden. Wenn Sie jedoch gleich einmal eine neue Anwendung mit dem Apex Builder entwickeln und ausprobieren möchten, kann das fünfte Kapitel genutzt werden. Hier wird ein Issue-Tracking vollständig von Grund auf entwickelt, verpackt und genutzt. Mit Hilfe der Grundlagen aus dem dritten Kapitel lässt sich die Beispielanwendung im Anschluss durch eigene Experimente erweitern. Zwischenzeitlich erfolgt im 6. und 7. Kapitel eine kleine Erholungspause für den Leser; es werden die Möglichkeiten des Salesforce.com Eclipse Plugin sowie Details zur Entwicklung von S-Controls und AJAX vorgestellt. Kapitel 8 und 9 widmen sich speziell den Clientanwendungen und dem Apex-API. Nach einer Einführung in die Thematik wird der Umgang mit Batchprozessen, dem Salesforce.com Data Exchange sowie die direkte Nutzung des Service API beleuchtet. Sind Sie neu in der Apex-Plattform-Welt, empfiehlt sich jedoch die hier im Buch festgelegte Reihenfolge aller Kapitel. Möchten Sie aber ein spezielles Projekt durchführen und haben schon eine Idee, welche technologischen Möglichkeiten genutzt werden sollen, kann als Einstieg das 2., 3., 5. oder 8. Kapitel gewählt werden. Nun denn, Viel Spaß beim Lesen!

14


2 2.1

Salesforce.com planen, einrichten und konfigurieren

Überblick über die Planung, die Einrichtung und das Customizing von Salesforce.com

Dieses Kapitel gibt einen Überblick über die Planung einer Salesforce.com-Einführung sowie die Einrichtung, das Customizing und das Erstellen von Workflows innerhalb von Salesforce.com. Es wird nicht auf die programmatischen Eingriffsmöglichkeiten innerhalb von Salesforce.com eingegangen, diese werden in weiteren Kapiteln des Buches ausführlich erläutert. Prinzipiell enthält jeder der hier enthaltenen Teile ein Schlusskapitel mit „Tipps und Tricks“, die sich im Laufe der Jahre im Umgang mit und bei der Einführung von Salesforce.com ergeben haben. Ziel ist es, dem Erstbenutzer oder Systemadministrator unnütze Tätigkeiten oder grundlegende Entscheidungen mit maximaler Transparenz zu ermöglichen. Mehrere Projekte bei zum Teil großen international agierenden Kunden sind als Erfahrungsschatz in dieses Kapitel eingeflossen. Die Aufteilung dieses Kapitels ist wie folgt: 쮿

Planen

쮿

Einrichten

쮿

Customizing

쮿

Rechtevergabe

쮿

Workflows

쮿

Beispiel Rollout-Plan

2.2

Die Planung der Einführung von Salesforce.com

Grundsätzlich gilt, was auch bei anderen Einführungs-Projekten immer schon galt: Je mehr Endbenutzer nachher mit dem realisierten System mit unterschiedlichen Aufgaben, Workflows und Vertriebs- bzw. Verwaltungsprozessen arbeiten sollen, desto wichtiger ist im Vorfeld das Design, die Dokumentation und das Pflichtenheft. Salesforce.com ermöglicht sehr einfach das Ändern, Hinzufügen oder Entfernen von einzelnen Feldern oder Feldinhalten, was leider auch gerne dazu verleitet, dies ‚eben mal schnell’ zu tun. Es hat sich in der Praxis gezeigt, dass gerade bei Einführung eines sol-


15


2 – Salesforce.com planen, einrichten und konfigurieren

chen Systems mit hunderten oder mehr Endusern dies eher hinderlich als sinnvoll sein kann. Gutes Projektmanagement ist hier genauso gefragt wie bei allen großen Projekten; Salesforce.com erleichtert jedoch an vielen Stellen die Umsetzung des Customizing erheblich und auch die Vorteile eines On-Demand-Systems seien hier noch einmal kurz zusammengefasst. Dieser Leitfaden soll den Leser in die Lage versetzten, eine Grobschätzung über die anfallenden Aufwände einer Salesforce.com-Einführung abgeben zu können. Die hier angegebenen Werte dienen als Richtwerte für weitere Diskussionen und sind nicht verbindlich. Im Wesentlichen sollten Sie sich mit den umfangreichen Möglichkeiten von Salesforce.com vertraut machen, bei der Implementierung sollte Ihnen ein erfahrenes Consulting-Unternehmen beratend zur Seite stehen, um den bestmöglichen Nutzen (im Rahmen einer Kosten/Nutzen-Analyse) bezogen auf die individuellen Bedürfnisse aus Salesforce.com herauszuholen. Was aus unserer Sicht unbedingt beachtet werden muss ist, dass eine CRM-Lösung immer nur so gut ist, wie die Menschen, die damit arbeiten. Es ergeben sich zwangsweise Veränderungen bei der Einführung von Salesforce.com und da gilt es, die Menschen in die entsprechenden Planungsprozesse zu involvieren und Aufklärungsarbeit zu leisten. Wird zum Beispiel ein bestehendes System abgelöst, kommt es häufig zu Schwierigkeiten im Umgang mit der neuen Lösung, da sie nun eben anders funktioniert als die Vorherige. Ebenso ist zu bedenken, dass es wenig Sinn macht, alle alten Prozesse genau in einem Salesforce.com-System abzubilden und dabei eventuell auch Lösungen zu implementieren, die gegen die innere Logik von Salesforce.com verstoßen. Ein BPR-Prozess (Business Process Reengineering) ist daher unerlässlich in der Vorphase. Basierend auf unseren Erfahrungen bei diversen Salesforce.com-Einführungen schlagen wir für eine Umsetzung der Salesforce.com-Einführung folgende Grundregeln, die beachtet werden sollten, vor: 쮿

Der Kunde sollte sich dabei im Klaren sein, dass bei einer Salesforce.com-Einführung ein nicht unerheblicher Zeitaufwand notwendig ist, um sich mit den Funktionalitäten von Salesforce.com im Detail vertraut zu machen und diese, bezogen auf die individuellen Anforderungen, intern anzupassen und umzusetzen.

쮿

Analyse der Sales-Prozesse und Umsetzungsplanung auf Basis von Salesforce.com

쮿

Der Kunde sollte einen internen Administrator mit Vertreter selbstständig ausbilden mit dem Ziel, eigenständige Administration und Erweiterung von Salesforce.com durchführen zu können.

쮿

Es benötigt Zeit und Aufwand für die Migration und Datenbereinigung

쮿

Zeit und Aufwand beim Kunden für die Schulung, das individuelle Training und die Einführung des Systems

16


Customizing von Salesforce.com

2.3


Das Customizing, das in diesem Teil beschrieben ist, beinhaltet im Wesentlichen eine Darstellung der Möglichkeiten, die Salesforce.com zur Verfügung stellt. Hier wird nicht in aller epischen Breite jedes Feature erläutert werden, wir verweisen hier auch auf das deutsche Benutzerhandbuch von Salesforce.com. Grundsätzlich erfolgt ein Überblick über das Anpassen von Seitenlayouts, die Erstellung und Konfiguration neuer Datenfelder, die dann auch befüllt, berechnet oder befragt werden können, und die Anlage von Berichten und Dashboards. Salesforce.com unterscheidet zwischen dem 'Anpassen' von standardmäßig zur Verfügung gestellten Objekten

Abbildung 2.1: Das Anwendungs-Setup 'Anpassen'

und 'Aufbauen' von neuen, benutzerdefinierten Objekten, Anwendungen und Custom S-Controls.

Abbildung 2.2: Das Anwendungs-Setup 'Aufbauen'

Unter dem Menüpunkt 'Exchange' verbirgt sich die Integration mit Apex und unter dem Menüpunkt 'Integrieren' das AppExchangeAPI.


17



Wählt man ein Standardobjekt aus, wie zum Beispiel 'Verträge', so kann man im Wesentlichen folgende Änderungen und Anpassungen vornehmen. Diese stehen stellvertretend für alle Standard- und auch die benutzerdefinierten Objekte zur Verfügung. 쮿

Benutzerdefinierte Felder

쮿

Validierungsregeln

쮿

Seitenlayouts

쮿

Suchlayouts

쮿

Schaltflächen und Links

Wichtig: Zu allen Standardobjekten gibt es immer auch individuelle Anpassungsvorgaben, die unter den einzelnen Menüpunkten angewählt werden können. Hierzu empfehlen wir die Lektüre des Benutzerhandbuches bzw. werden viele der Prozesse in ihren Möglichkeiten und im Detail auch im Rollout-Plan am Ende dieses Kapitels beschrieben. Im Folgenden wird auf die oben genannten Punkte im Einzelnen eingegangen.

2.3.1

Benutzerdefinierte Felder

Sie können zu Ihrem Unternehmensdatensatz weitere Felder hinzufügen. Diese Felder werden als „benutzerdefinierte Felder“ bezeichnet. Sie ermöglichen es Ihnen, Salesforce.com individuell an die Bedürfnisse Ihres Unternehmens anzupassen. Natürlich können alle benutzerdefinierten Felder auch als 쮿

schreibgeschützt,

쮿

Pflichtfelder

쮿

sowie mit einem Standardwert

vorgegeben werden. Nachschlagebeziehung Hier kann der Benutzer eine Beziehung mit einem anderen Objekt innerhalb von Salesforce.com erstellen. Dadurch haben Benutzer die Möglichkeit, auf eine -Schaltfläche zu klicken und einen Wert aus einer Popup-Liste auszuwählen. Wichtig: Bei Salesforce.com-Standard-Objekten (z.B. Leads, Accounts, Kontakte etc.) geht nur eine Nachschlagebeziehung als Custom-Feld. Bei Custom-Objects (neu angelegten Objekten innerhalb von Salesforce.com, z.B. Rechnung oder Auftrag) geht auch eine sogenannte Master-Detail-Beziehung. Hier erstellt der Nutzer eine erforderliche („Master-Detail“) Beziehung mit einem anderen Objekt. Dadurch haben Benutzer die Möglichkeit, auf eine 'Lupen'-Schaltfläche zu klicken und einen Wert aus einer PopupListe auszuwählen.

18



Abbildung 2.3: Das Anlegen von neuen Feldern

Kontrollkästchen Hiermit können Benutzer ein Kontrollkästchen aktivieren und auf diese Weise ein wahres oder falsches Attribut eines Datensatzes kennzeichnen. Wenn Sie für Berichte oder Listenansichtsfilter ein Kontrollkästchen benutzen, verwenden Sie 1 für aktivierte Werte und 0 für deaktivierte Werte. Währung Ermöglicht es dem Benutzer, einen Betrag in Euro oder in einer anderen Währung einzugeben. Salesforce.com formatiert eingegebene Werte automatisch als Währungsbeträge. Dies kann besonders dann hilfreich sein, wenn Sie Daten in Excel oder ein anderes Tabellenkalkulationsprogramm exportieren. Datum Ermöglicht es dem Benutzer, ein Datum selbst einzugeben oder ein Datum aus dem Popup-Kalender auszuwählen. Datum/Uhrzeit Ermöglicht es dem Benutzer, ein Datum und eine Uhrzeit selbst einzugeben oder ein Datum aus dem Popup-Kalender auszuwählen. E-Mail Ermöglicht Benutzern die Eingabe einer E-Mail-Adresse. Salesforce.com prüft die eingegebene Adresse auf korrektes Format. Wenn Benutzer auf dieses Feld klicken, wird ihr E-Mail-Programm automatisch gestartet und eine E-Mail an diese Adresse gesendet.


19



Zahl Ermöglicht dem Benutzer die Eingabe einer beliebigen Zahl. Beachten Sie bitte, dass Salesforce.com diesen Wert als reelle Zahl behandelt und alle führenden Nullstellen entfernt. Prozent Ermöglicht dem Benutzer die Eingabe einer Prozentzahl, z. B. „10“. Salesforce.com fügt automatisch ein Prozentzeichen an die eingegebene Zahl an. Telefon Ermöglicht dem Benutzer die Eingabe einer beliebigen Telefonnummer. Salesforce.com formatiert den eingegebenen Wert automatisch als Telefonnummer. Auswahlliste Eine Auswahlliste ist eine benutzerdefinierte Liste, in der der Benutzer Werte aus einer vordefinierten Eintragsliste auswählen kann. Sie können die Werte jeder Standardauswahlliste ändern und an den Sprachgebrauch Ihres Teams anpassen. Weiterhin kann Enterprise Edition mehrere Geschäftsprozesse verwalten, indem es eine Teilmenge der Werte einer Auswahlliste in eine Satzart einbindet und die Satzarten den Benutzern entsprechend ihres Profils zur Verfügung stellt. Außerdem ist es möglich, abhängige Auswahllisten zu gestalten, die abhängig von der Vorauswahl in einer übergeordneten Auswahlliste nur Teile zur Auswahl anbieten. Text Ermöglicht dem Benutzer die Eingabe einer beliebigen Kombination von Buchstaben und Zahlen, die bis zu 255 Zeichen lang sein kann. Textfeld (lang) Texteingaben bis max. 32000 Zeichen sind hier möglich. Textbereich Ermöglicht dem Benutzer die Eingabe von bis zu 255 Zeichen in mehreren Textzeilen. URL Ermöglicht dem Benutzer die Eingabe einer gültigen Internetadresse. Sobald ein Benutzer auf dieses Feld klickt, wird der URL in einem separaten Browserfenster geöffnet. Das Anpassen der Listenwerte und Erstellen von benutzerdefinierten Feldern sollte im Anwendungs-Setup erfolgen.

2.3.2 Validierungsregeln Die von Salesforce.com vorgesehen Validierungsregeln beziehen sich immer auf Feldinhalte. Validierungsregeln erleichtern die Verbesserung der Datenqualität, indem sie verhindern, dass die Benutzer die falschen Daten speichern. Sie können eine oder mehrere Validierungsregeln definieren, die aus einer Fehlerbedingung und der entsprechenden Fehlermeldung bestehen. Validierungsregeln werden beim Speichern des Datensatzes ausgeführt. Wenn eine Fehlerbedingung erfüllt ist, wird der Speichervorgang abgebrochen und eine Fehlermeldung angezeigt.

20



Einsatzbeispiele: 쮿

Felder bedingt erforderlich machen, je nach dem Wert eines anderen Felds.

쮿

Sicherstellen, dass die Zahlen in einem angegebenen Bereich liegen, beispielsweise, dass der Rabatt weniger als 30 % beträgt.

쮿

Erzwingen, dass die Datumsfelder in der korrekten chronologischen Reihenfolge vorliegen, sodass beispielsweise das Startdatum vor dem Enddatum liegen muss.

Abbildung 2.4: Das Anlegen von Validierungsregeln

2.3.3

Seitenlayouts

Verschiedene Seitenlayouts werden vor allem verwendet, um unterschiedlichen Nutzern eine eigene, angepasste Sicht auf die Salesforce.com-Objekte zu ermöglichen. Man verwendet Seitenlayouts, um zum Beispiel die Sicht auf Leads für den des Telesales von der des Marketings zu unterscheiden. Prinzipiell sind beliebig viele Seitenlayouts möglich innerhalb einer Salesforce.comInstanz. Aus Übersichtgründen wird jedoch empfohlen hier die Menge zu begrenzen, da gegebenenfalls in einzelnen Layouts Felder hinzugefügt und entfernt werden müssen, was zu einem erhöhten administratorischen Aufwand führt, wenn dies in sehr vielen Layouts zu erfolgen hat.


21



Bei der Bearbeitung von Seitenlayouts werden vor allen die folgenden Eigenschaften festgelegt: 쮿

Ansicht von Feldern

쮿

Festlegung auf Pflichtfeld oder Schreibschutz

쮿

Die Strukturierung Ihres Seitenlayouts (Einteilung in Abschnitte und Abteilungen)

쮿

Ansicht von so genannten Themenlisten (Ansicht verlinkter Objekte)

쮿

Die Felder, die von Themenlisten angezeigt werden

Abbildung 2.5: Das Anpassen von Seitenlayouts

Die Einteilung erfolgt im Wesentlichen durch 'Drag und Drop'-Funktionen. Hiermit werden Felder ein- bzw. ausgeblendet. Sie können auch einzelne Felder der Themenlisten anpassen, die Sortierung ändern oder Standardwerte festlegen.

22



Abbildung 2.6: Details der Bearbeitung der Themenliste am Beispiel des Aktivitätsverlaufs

2.3.4 Suchlayouts Das Bearbeiten und Steuern von Suchlayouts hat im Wesentlichen zur Aufgabe, dass Sie hier festlegen, welche Felder als Resultate der Suchfunktion in Salesforce.com angezeigt werden sollen. Wichtig ist dies im Besonderen, wenn Sie viele benutzerdefinierte Felder in Ihrem System verwenden, die wichtig sind für die eindeutige Erkennung eines gesuchten Objektes. Beispiel: Sie haben ein Lead-Objekt und wollen immer den Leadstatus sehen als Ergebnis einer Suche, dann legen Sie dies fest bei den Suchlayouts wie im folgenden Beispiel:


23



Abbildung 2.7: Suchlayouts in der Übersicht am Beispiel von Leads

2.3.5

Schaltflächen und Links

Neu im Winter-Release 07 sind die Bearbeitung und Anpassung von Schaltflächen und Links. Im Einzelnen können Buttons (Schaltflächen), die im System standardmäßig vorhanden sind, angepasst bzw. überschrieben werden durch eigene Funktionen. Außerdem können Custom S-Controls an einzelne Schaltflächen angegliedert werden, so dass zuzüglich die Custom-Funktionalität ausgeführt werden kann. Ebenso erlaubt das System die Einstellung von Custom-Links, Apex Code, HTML-Verweisen, die Sie selbstständig in die Seite einbauen können. Schaltflächen können auf Detailseiten, Themenlisten und Listenansichten angezeigt werden: 쮿

Um Schaltflächen auf Detailseiten anzupassen, bearbeiten Sie das Layout der jeweiligen Objekt-Seite.

쮿

Um Schaltflächen in Themenlisten anzupassen, bearbeiten Sie die Themenlisteneigenschaften auf dem Seitenlayout, auf dem die Objekt-Themenliste angezeigt wird.

쮿

Um Schaltflächen in Listenansichten anzupassen, bearbeiten Sie das Layout der ObjektListenansicht unter Suchlayouts.

Abbildung 2.8: Bearbeiten von Standard-Schaltflächen

24


Zugriffsrechte und Sichtbarkeit von Daten

2.4


In Salesforce.com gibt es vielfältige Möglichkeiten um festzulegen, wer auf welche Daten zugreifen darf und wer welche Daten sehen darf. Auf den ersten Blick sind diese Möglichkeiten verwirrend und für den Neueinsteiger in Salesforce.com nur schwer zu durchblicken. Prinzipiell gilt aber Folgendes: 쮿

Eine Tabelle, also alle Salesforce.com Objekte eines Typs (z. B. Leads), sind für einen Benutzer sichtbar, wenn sein Profil das vorsieht.

쮿

Einzelne Datensätze einer Tabelle, also Salesforce.com Objekte (z.B. bestimmte Leads), sind für einen Benutzer sichtbar, abhängig davon, ob der Benutzer Owner des Datensatzes ist, welche Rolle er hat, wie das Freigabemodell für die Tabelle festgelegt ist oder ob es eine Freigaberegel gibt, die ihm erlaubt, das Objekt zu sehen.

쮿

Einzelne Datensätze einer Tabelle, also Salesforce.com Objekte (z.B. bestimmte Leads), sind für einen Benutzer editierbar, wenn das Profil des Benutzers das vorsieht und wenn das Rollen- und Freigabemodell dies zulässt.

쮿

Ein bestimmtes Feld eines Datensatzes ist für einen Benutzer sichtbar, wenn es für sein Profil als „visible“ definiert ist und wenn es auf dem Layout, das für sein Profil (und den Datensatztyp) festgelegt ist, liegt.

쮿

Ein Feld kann editiert werden, wenn es für das Profil nicht als read-only definiert ist und wenn das zugewiesene Layout das vorsieht.

Alle hier verwendeten Salesforce.com-Fachbegriffe werden nun im Detail beschrieben: Datensatzbesitzer (Ownership) (1) Die meisten Standard-Objekte, z.B. Accounts, Leads, Opportunities, haben einen „Inhaber“ (Owner), ebenso auch die Objekte Aufgabe und Ereignis, hier heißt das Feld jedoch „Zugeordnet zu“. Auch jedes benutzerdefiniertes Objekt hat per Default ein Feld „Inhaber“, das beim Erzeugen der neuen Tabelle automatisch zugefügt wird. Der Inhaber gibt Information darüber, wem der Datensatz gehört, wer also per se den Datensatz sehen und ändern kann (vorausgesetzt, die Rechte sind nicht über das Profil eingeschränkt). Das Freigabemodell bezieht sich immer auf den Inhaber eines Datensatzes. Nur Objekte wie z.B. Produkt, die niemandem gehören, sondern einfach nur vielen Benutzern zur Verfügung stehen und bei der Arbeit verwendet werden können, haben keinen expliziten Inhaber. Der Inhaber ist nicht zu verwechseln mit dem Benutzer, der den Datensatz erstellt hat (Ersteller) oder dem Benutzer, der den Datensatz zuletzt geändert hat. Alle drei Personen können verschieden sein. Beispiel: Tom ist Verkäufer und ist zuständig für den Account „Test Firma“. Tom wird auf die Firma aufmerksam auf einer Messe, als er eine Visitenkarte bekommt. Seine Sekretärin gibt die Firma in Salesforce.com ein. Damit ist die Sekretärin als „Ersteller“ bei dem Account „Test Firma“ eingegeben. Da Tom aber zuständig für diese Firma


25



sein wird, ist er als „Inhaber“ eingetragen. Tom gibt später Bemerkungen ein und wird dadurch in das Feld „Zuletzt geändert von“ eingetragen. Wieder einige Zeit später wird Tom versetzt und der Account „Test Firma“ wird von nun ab von Jerry betreut, der jetzt auch als „Inhaber“ eingetragen wird. Zu diesem Zeitpunkt sind in den Feldern „Ersteller“, „Zuletzt geändert von“ und „Inhaber“ drei verschiedene Salesforce.com-Benutzer eingetragen. Profile (2) Das Profil eines Benutzers legt fest, auf welchen Objekten und Feldern er arbeiten soll. Das Profil ist mehr oder weniger eine Abbildung der Job-Description: Ein Verkäufer hat z.B. mit Accounts, Kontakten und Opportunities zu tun, sein Support-Mitarbeiter mit Account, Kontakten und Kundenvorgängen. Salesforce.com liefert in der Grundauslieferung bereits Beispiel-Profile mit, die verändert werden können; das Wichtigste hiervon ist der „Administrator“, das Profil, das dem Benutzer zugewiesen wird, der die Administration von Salesforce.com übernimmt. Profile können angelegt und geändert werden im Bereich Setup unter →Einrichten der Verwaltung →Benutzer verwalten →Profile Ein Profil legt Folgendes fest: 쮿

Welche benutzerdefinierten Anwendungen für Nutzer mit diesem Profil sichtbar sind und welche als Standard gewählt ist.

쮿

Welche Registerkarten sichtbar sind.

쮿

Welche administrativen Berechtigungen gegeben sind. Hierzu zählen Berechtigungen wie die zum Erstellen und Verwaltung von Benutzern, Briefköpfen, Reports usw.

쮿

Welche Allgemeinen Benutzungsberechtigungen gegeben sind. Hierzu zählen Rechte, Daten zu exportieren oder importieren sowie die Bearbeitung von Preis, die Verwaltung von Leads oder Verträgen usw.

쮿

Auf welche Standard- und benutzerdefinierten Objekte zugegriffen werden kann. Dabei kann ausgewählt werden zwischen dem Recht zum Lesen, zum Erstellen, zum Editieren und zum Löschen. Hiermit kann u. a. ein Read-Only Profil definiert werden.

쮿

Welche Datensatzypen für dieses Profil zur Auswahl stehen sollen, und welcher Default ist.

쮿

Welches Seitenlayout pro Objekt dem Benutzer, der dieses Profil hat, zugeordnet ist.

Sichtbarkeit von Datenfeldern / Feldebensicherheit (3) Beim Anlegen oder Ändern von Feldern in Standard- oder benutzerdefinierten Objekten kann pro Feld festgelegt werden, welches Profil das Feld sehen kann (Sichtbar: ja/nein) und für welches Profil das Feld schreibbar (Schreibschutz: ja/nein) ist. Diese Einstellungen haben Vorrang gegenüber Einstellungen, die hier im Folgenden dieses Kapitels beschrieben werden. Näheres zum Anlegen von benutzerdefinierten Feldern siehe Kapitel 4.

26



Layouts und Datensatztypen (4) Das Layout legt fest, wie die Daten einem Benutzer präsentiert werden. Standard- sowie benutzerdefinierte Felder können darauf platziert werden und können als Pflichtfeld definiert oder mit einem Schreibschutz versehen werden. Näheres zum Anlegen und Ändern von Layouts siehe auch Kapitel 4. Über Datensatztypen können vor allem die Picklisten für bestimmte Benutzergruppen eingeschränkt werden, sowie die das Layout der Objekte gesteuert werden. Außerdem bieten Datensatztypen die Möglichkeit, Daten abhängig von Inhalt darzustellen. Beispiel: Es wurden auf dem Account zwei Recordtypen definiert: Datensatztyp_Account_de Datensatztyp_Account_us Tabelle 2.1: Recordtypen in Salesforce.com

sowie drei Layouts: Layout_Account_de

Auf diesem Layout steht die PLZ vor dem Ort und die Pickliste Bundesland enthält nur deutsche Bundesländer

Layout_Account_us

Auf diesem Layout steht die PLZ hinter dem Ort und die Pickliste Bundesland enthält nur amerikanische Bundesstaaten

Layout_Account_admin Hier ist die Anordnung egal, aber es werden auch Felder angezeigt, die auf anderen Layouts ausgeblendet sind Tabelle 2.2: Unterschiedliche Layouts

Es bietet sich nun die Möglichkeit, deutsche Datensätze immer mit dem Typ „Datensatztyp_ Account_de“ anzulegen sowie britische immer mit dem Typ „Datensatztyp_Account_uk“ und bei der Anzeige wird die jeweils länderspezifisch korrekte Anzeige herangezogen. Welcher Benutzer welche Profile und welche Datensatztypen sehen kann wird über eine Matrix gesteuert. Beispiel: Datensatztypen Profile

Datensatztyp_Account_de

Datensatztyp_Account_us

Adminstrator

Layount_Account_admin

Layount_Account_admin

Marketing

Layout_Account_us

Layout_Account_us

Vertrieb

Layout_Account_de

Layout_Account_us

Tabelle 2.3: Profile und Datensatztypen in Salesforce.com


27



Freigabemodelle (5) Das Freigabemodell legt pro Objekt (Standard oder benutzerdefiniert) fest, wer die Daten sehen kann: Beim Freigabemodell „readonly“ kann ein Benutzer nur die Daten sehen, für die er Owner ist, oder Daten von Benutzern, die in der Rollenhierarchie unter ihm angeordnet sind oder Daten von Benutzern, die über Freigaberegeln sichtbar sind. Beim Freigabemodell „Public read / write“ kann ein Benutzer alle Daten des gesamten Unternehmens sehen, unabhängig davon, wer Inhaber ist. Beim Freigabemodell „Public readonly“ kann ein Benutzer zwar alle Daten sehen, aber er kann nur die Daten editieren, bei denen er Inhaber ist, oder Daten von Benutzern, die in der Rollenhierarchie unter dem Benutzer liegen, oder Daten, die über Freigaberegeln im Zugriff liegen. Freigabemodelle können angelegt und geändert werden im Bereich Setup unter →Einrichten der Verwaltung →Sicherheitssteuerung →Freigaberegeln und dort in der Sektion unternehmensweite Standardeinstellungen. Rollen (6) Über Rollen wird definiert, welche Daten eines Unternehmens ein Benutzer sehen kann. Die Sichtbarkeit ist dabei grundsätzlich davon abhängig, welches Freigabemodell für das jeweilige Objekt gewählt ist. Rollen können angelegt und geändert werden im Bereich Setup unter →Einrichten der Verwaltung →Benutzer verwalten →Rollen Zur Definition der Rollenhierarchie können verschiedene Konzepte zugrunde gelegt werden. Salesforce.com schlägt Folgende vor: 쮿

Rollenhierarchie, die eine Gebietsstruktur abbildet

쮿

Rollenhierarchie, die davon ausgeht, dass nach verschiedenen Produktgruppen strukturiert wird

쮿

Rollenhierarchie, die eine Vertriebsstruktur abbildet. Bei der Definition der Rollenhierarchie ist vor allem zu beachten, dass darüber die Sichtbarkeit der Daten für Benutzer gesteuert wird.

Öffentliche Gruppen und Freigaberegeln (7) Häufig kommt es vor, dass in Unternehmen mit restriktiven Rollenkonzepten Benutzer Daten nicht sehen können, die sie aber sehen müssen. Ein typisches Beispiel dafür ist der Fall, dass zwei Vertriebsarbeiter sich ab und zu gegenseitig vertreten und daher auch die Daten des anderen sehen sollen. Wenn die beiden aber dieselbe Rolle haben und als Freigabemodell auf Account privat gewählt ist, so sind die Accounts des anderen per se nicht sichtbar. Salesforce.com bietet hier eine Möglichkeit dies zu umgehen, in dem man mehrere Benutzer einer Gruppe zusammenfasst und Ihnen Zugriff auf die Daten der Gruppe gewährt.

28



Gruppen können sein: 쮿

alle Inhaber einer Rolle

쮿

alle Inhaber einer Rolle und ihr nachgeordnete Positionen

쮿

eine Öffentliche Gruppe. Die Öffentliche Gruppe ist eine frei definierbare Gruppe von Salesforce.com-Anwendern, die unabhängig von deren Profil oder Rolle sein kann.

Der Zugriff kann dabei wieder eingeschränkt werden, man kann entweder vollen Lese-/ Schreib-Zugriff oder nur Lesezugriff gewähren. Eine Freigaberegel gilt immer genau für ein Objekt. Bis zum Winterrelease 2007 war das nur auf die Objekte Account, Lead, Opportunity möglich, seither aber auch auf alle anderen Objekte und vor allem auch auf selbstdefinierte Objekte. Öffentliche Gruppen und Freigaberegeln können angelegt und geändert werden im Bereich Setup unter →Einrichten der Verwaltung →Sicherheitssteuerung →Freigaberegeln Territory Management (8) Erst seit dem Winter Release 2007 verfügbar. Es bietet die Möglichkeit, über ein Objekt Namens „Territory“ den Aufbau der Gebietsstruktur eines Unternehmens exakt abzubilden. Mitarbeiter können dann Gebieten zugeordnet werden. Das gesamte Zugriffmodell wird dann automatisch über diese Gebietsstruktur berechnet. Somit können besonders einfach Änderungen im der Gebietsstruktur oder in der Mitarbeiterzuweisung an Gebiete vollzogen werden. Diese Feature ist nicht automatisch freigeschaltet, sondern muss explizit von Salesforce.com angefordert werden.

2.4.1

Tipps und Tricks zum Vorgehen

Ein gutes Design ist unerläßlich, da man vor allem bei großen Unternehmen mit vielen Usern hier schnell die Übersicht verliert. Man sollte sich vorher eine gute Übersicht darüber verschaffen, welcher Mitarbeiter mit welchen Objekten arbeiten soll und wer Einsicht in Daten von anderen bekommen darf. Bei der Abbildung auf Salesforce.com ist es empfehlenswert, die Zahl der Profile gering zu halten und die Erstellung der Profile an den Anfang der Implementierung zu stellen. Die Verwendung von Datensatztypen ist eine gute Möglichkeit, um Picklisten übersichtlicher zu machen, falls verschiedene Benutzergruppen nur Teilmengen verwenden (z. B. bei Verwendung in verschiedenen Ländern). Günstig ist es, wenn pro Profil nur ein Datensatztyp verwendet wird, weil sonst beim Neuanlegen von Datensätzen einmal mehr geklickt werden muss, um den Datensatztyp auszuwählen. Eine Rollenhierarchie muss nicht 1:1 die tatsächliche Firmenstruktur abbilden, es ist vielmehr wichtig, sich Gedanken über die Sichtbarkeit der Daten in Hinblick auf Reporting zu machen.


29



Eine zu tiefe Hierarchie fördert wenig die Übersichtlichkeit. Wenn es möglich ist, sollten Rollen nicht per se für einzelne Personen gebildet werden. Negativ-Beispiel:

Abbildung 2.9: Negativ-Beispiel

Das entspricht zwar der Realität, aber so kann die Sekretärin die Daten der Vertriebsmitarbeiter nicht einsehen.

Abbildung 2.10: Reales Beispiel

Jetzt sieht die Sekretärin zwar die Daten, aber sie soll nie Inhaber eines Datensatzes sein, sondern Reports über alle Datensätze der Vertriebsmitarbeiter ziehen können. Sie hat also grundsätzlich dieselbe Sicht auf die Daten wie der Vertriebsleiter. Daher ist in diesem Fall besser:

Abbildung 2.11: Praktisches Beispiel

30


Einrichten und Verwalten von Workflows

2.5

Einrichten und Verwalten von Workflows

Mit Workflows lassen sich komplexe Geschäftsprozesse und Genehmigungsverfahren (seit dem Release Winter 07) erheblich leichter implementieren.

Abbildung 2.12: Workflow-Setup-Optionen

2.5.1

Workflow-Regeln

Workflow-Regeln verwenden Workflow-Benachrichtigungen und -Aufgaben, wenn ihre festgelegten Bedingungen erfüllt werden. Weitere Informationen über die Verwendung von Workflow-Regeln finden Sie unter Verwalten der Workflow-Regeln. Anmerkung: Workflow-Regeln können abhängig von Ihren Regeleinstellungen jederzeit ausgelöst werden, wenn ein Datensatz gespeichert oder erstellt wird. Regeln, die nach dem Speichern von Datensätzen erstellt werden, werden jedoch für diese Datensätze nicht mehr nachträglich ausgelöst.

2.5.2 Genehmigungsprozesse Bereiten Sie Genehmigungsprozesse gut vor an Hand der folgenden Checkliste: 쮿

Bereiten Sie eine E-Mail-Vorlage für Genehmigungsanfragen vor.

쮿

Bestimmen Sie den Absender der Genehmigungsanfrage.

쮿

Bestimmen Sie die zugeordnete Person, die letzten Endes genehmigen wird.

쮿

Bestimmen Sie die delegierte Person für den Genehmigungsprozess.

쮿

Legen Sie fest, ob für Ihren Genehmigungsprozess ein Filter erforderlich ist.

쮿

Entwerfen Sie Aktionen für das ursprüngliche Einreichen.

쮿

Legen Sie fest, ob die Benutzer Anfragen über ein mobiles Endgerät genehmigen können.

쮿

Legen Sie fest, ob die Benutzer Datensätze bearbeiten können, die zur Genehmigung anstehen.

쮿

Legen Sie fest, ob Datensätze automatisch genehmigt bzw. abgelehnt werden sollen.

쮿

Bestimmen Sie, wie viele Ebenen der Prozess haben soll.

쮿

Geben Sie die Aktionen an, die bei Genehmigung bzw. Ablehnung einer Genehmigungsanfrage durchgeführt bzw. weitergeleitet werden sollen.


31



2.5.3

Aufgaben

Workflow-Aufgaben ähneln den Aufgabenvorlagen. Sie enthalten die Informationen, die eine Workflow-Regel verwendet, um bestimmten Benutzern eine Aufgabe zuzuweisen, sobald bestimmte Geschäftsaktionen die Regel auslösen. Workflow-Aufgaben liefern das Thema, den Status, die Priorität und das Fälligkeitsdatum für die Aufgaben, die eine Regel zuweist. Weitere Informationen über die Verwendung von Workflow-Aufgaben finden Sie unter Verwalten von Workflow-Aufgaben.

2.5.4 Benachrichtigungen Workflow-Benachrichtigungen sind E-Mails, die von einer Workflow-Regel unter Verwendung einer E-Mail-Vorlage generiert werden. Die E-Mails werden an bestimmte Empfänger gesendet (entweder Salesforce.com-Benutzer oder andere Personen), sobald bestimmte Geschäftsaktionen eine Workflow-Regel auslösen. Weitere Informationen über die Verwendung von Workflow-Benachrichtigungen finden Sie unter Verwalten von Workflow-Benachrichtigungen.

2.5.5

Feldaktualisierungen

Feldaktualisierungen sind Werte, die beim erfolgreichen Auslösen einer Workflow-Regel in einem Feld aktualisiert werden bzw. automatisch eingestellt werden. So gehen Sie im Normalfall vor: Geben Sie das Objekt und das zu aktualisierende Feld an sowie den Wert, der auf das Feld angewendet werden soll, wenn eine Workflow-Regel oder ein Genehmigungsprozess ausgelöst wird. Die verfügbaren Optionen hängen vom Typ des ausgewählten Felds ab.

Abbildung 2.13: Aktualisierungsregel bei einem Workflow

32


Beispiel Rollout-Plan für eine Salesforce.com-Einführung

2.5.6

Ausgehende Nachrichten

Bei ausgehenden Nachrichten handelt es sich um SOAP-Messages, die Salesforce.com automatisch beim Auslösen an externe Systeme sendet. Hierzu sollte man in jedem Falle noch einmal detailliert die weiteren Kapitel dieses Buches lesen.

2.6


Im Beispiel-Rollout-Plan wird exemplarisch der komplette Einführungsprozess einer Salesforce.com-Realisierung in allen Einzelschritten beschrieben. Dies kann auch als eine Art Checkliste für Projektmanager dienen. Die unterschiedlichen Phasen einer Einführung sollten möglichst mit Workshops und Abstimmungsmeetings vorbereitet und in einem Feinkonzept dokumentiert werden. Dies erleichtert die Arbeit, sofern nicht alles vor Ort erfolgen kann und soll.

2.6.1

Vorbereitung

Bestimmen des Datums der Liveschaltung (1) Das Liveschaltungsdatum ist der Termin, an dem alle Benutzer für den Einsatz von Salesforce.com bereit sein sollten. Dieses Datum steuert alle anderen Einführungsaktivitäten, und Sie können rückwärts von diesem Datum ausgehend alle weiteren Aktivitäten planen.

Identifizieren des Projektleiters, des Administrator und Teammitglieder (2) Bestimmen des Projektmanagers Der Projektmanager leitet den gesamten Einführungsprozess und sollte jemand sein, der Informationen über Ihre Geschäftsprozesse zusammentragen, Benutzer und ihre Rollen bestimmen und die Einführung des CRMDienstes kontrollieren kann. Bestimmen der Administratoren Dabei sollte es sich um den Projektmanager sowie um jede weitere Person handeln, die den Dienst verwaltet (Benutzer hinzufügt, Kennwörter zurücksetzt, den Dienst verwaltet usw.). Es ist empfehlenswert, mindestens zwei Administratoren zu bestimmen; für größere Unternehmen mit hunderten oder mehr Benutzern werden entsprechend mehr Administratoren benötigt. Bestimmen des Datenmigrationsspezialisten Der Mitarbeiter, der für die Verwaltung des Datenexports und -imports von Ihrem alten System in Salesforce.com verantwortlich ist Bestimmen der Lösungsmanager Ein oder mehrere Benutzer, die die Wissensdatenbank verwalten. Dabei handelt es sich um Produktexperten aus dem Supportteam, die über hervorragende schriftliche Kommunikationsfähigkeiten verfügen.


33



Bestimmen der Marketing-Benutzer Nur als Marketing-Benutzer eingerichtete Benutzer können Kampagnen erstellen und verwalten. Um einen Mitarbeiter als MarketingBenutzer einrichten zu können, müssen Sie zunächst Marketing-Benutzer-Lizenzen für Salesforce.com erwerben. Bestimmen der Offline Edition-Benutzer Benutzer der Offline Edition können jederzeit und von überall ihre Geschäfte machen, ganz ohne Kabel. Um Mitarbeitern Zugang zur Offline Edition zu geben, müssen Sie zuerst die Offline Edition Software konfigurieren und installieren auf den individuellen PCs. Bestimmen der Wireless Edition-Benutzer Wireless Edition-Benutzer können über ein drahtloses Gerät in Echtzeit auf die aktuellsten Kundendaten zugreifen. Um Mitarbeitern Zugang zur Wireless Edition zu geben, müssen Sie zuerst Wireless EditionBenutzer-Lizenzen für Salesforce.com erwerben.

Hinzufügen von Lizenzen (3) Bestimmen Sie alle Benutzer, die mit Salesforce.com arbeiten werden, und stellen Sie sicher, dass Sie über eine ausreichende Anzahl von Lizenzen verfügen. Informationen zum Lizenzmodell und den unterschiedlichen Lizenztypen (Unlimited, Enterprise und Professionell-Edition) finden Sie unter www.Salesforce.com. Zu den Benutzern zählen alle Personen, die Zugriff auf die Kundeninformationen haben oder in systeminternen Workflows referenziert werden.

Absolvieren von Schulungen (4) Salesforce.com bietet eine Reihe von kostenlosen Online-Schulungskursen für verschiedene Benutzertypen wie Standardbenutzer, Administratoren und Manager an. Bevor Sie Besprechungen einplanen oder mit dem Setup beginnen, sollten Projektmanager und Administratoren an den Schulungen „Grundlagen für Administratoren“ teilnehmen. Außerdem sollten Marketing-Benutzer und Administratoren an den Kampagnen-Schulungen teilnehmen. Administratoren können auch von der Schulung für Lead-Administratoren profitieren. Lösungsmanager und Administratoren sollten an der Schulung für Supportadministratoren teilnehmen. Dies stellt sicher, dass Sie das Setup von Salesforce.com sowie die Durchführung einer gründlichen Prüfung der Geschäftsprozesse erfolgreich bewerkstelligen können. Sie können auch an den anderen Schulungen teilnehmen, um soviel wie möglich über Salesforce.com zu lernen. Über den Link „Schulung“, der sich oben auf jeder Seite von Salesforce.com befindet, können Sie sich für eine Schulung anmelden. Wichtig: Alle Salesforce.com-Schulungen betreffen immer nur den Standard ohne spezifisches Customizing, das vielleicht bei Ihnen im Hause angewendet wurde. Daher machen alle Standard- und Online-Schulungen am Anfang viel Sinn, aber sobald Sie mit der Realisierung Ihrer individuellen Anpassungen begonnen haben, stimmen die PageLayouts natürlich nicht mehr überein und eine Online-Schulung wird immer weniger sinnvoll für Endbenutzer und Marketinguser.

34



Überprüfen der technischen Anforderungen (5) Anforderungen für den Einsatz von Salesforce.com: Betriebssystem Sie benötigen lediglich einen Computer, auf dem ein Webbrowser ausgeführt werden kann. Die Hardware oder das verwendete Betriebssystem sind bedingt nebensächlich. Browser Um die bestmögliche Leistung zu erzielen, empfehlen wir Microsoft Internet Explorer 5.5 oder höher. Es können auch andere Browser wie Firefox oder Opera verwendet werden. In Einzelfällen kann es jedoch zu Problemen bei der Ausführung von S-Controls auf anderen als dem Microsoft Browser kommen. Prinzipiell garantiert Salesforce.com den Betrieb nur mit den aktuellen Microsoft Internet Explorern. Anforderungen für die Synchronisation von Salesforce.com mit Outlook Sie können die aktuellste Version von Intellisync für Salesforce.com über Salesforce.com herunterladen. Outlook Sie können Ihre Salesforce.com-Daten mit Outlook Version 2000, XP oder 2003 synchronisieren.

Überprüfen der Geschäftsprozesse (6) Das Überprüfen der Geschäftsprozesse umfasst eine Reihe von Fragen, die unter dem Aspekt beantwortet werden, wie Salesforce.com in Ihrem Unternehmen eingesetzt wird. Am Ende des Prozesses sollten Sie alle Informationen gesammelt haben, die zum erfolgreichen Einrichten und Einführen von Salesforce.com erforderlich sind. Wir empfehlen allen Unternehmen, die Salesforce.com einsetzen, die Erfassung der Geschäftsprozesse zumindest nachzuprüfen. Für größere Unternehmen mit komplexeren Geschäftsprozessen ist eventuell eine formelle Überprüfung der Geschäftsprozesse erforderlich, die eine Besprechung mit den einzelnen Verantwortlichen erfordert.

2.6.2 Systemkonfiguration Überprüfen Ihrer Firmeninformationen (1) Die Firmeninformationen enthalten die Kontaktinformationen des Unternehmens, die während der Anmeldung eingegeben wurden. Sie geben außerdem das StandardGebietsschema (für die Zahlen- und Datumsformatierung), die Standard-Sprache, die Standard-Zeitzone und das Währungsgebiet (für die Formatierung von Währungen) für Ihr Unternehmen vor.

Definieren der Rollenhierarchie (2) Definieren Sie die Rollenhierarchie Ihres Unternehmens, um festzulegen, welche Benutzer welche Unternehmensdaten einsehen können. Benutzer auf einer bestimmten Rollenebene können alle Daten anzeigen, bearbeiten und zur Berichtserstellung nutzen, deren Inhaber diesen Benutzern innerhalb der Hierarchie untergeordnet oder zugeteilt sind.


35



Die Rollenhierarchie Ihres Unternehmens steuert: 쮿

wie Vertriebs-Opportunities in Prognosen und Opportunity-Pipeline-Berichten dargestellt werden,

쮿

wer Informationen, deren Inhaber andere Benutzer sind, anzeigen, bearbeiten und für die Berichtserstellung nutzen kann.

Es ist nicht erforderlich, für jeden Benutzer individuelle Rollen zu erstellen. Stattdessen können Sie sich stärker auf das Erstellen einer Rollenhierarchie konzentrieren, anhand derer der Datenzugriff gesteuert wird. Siehe dazu auch in diesem Kapitel Zugriffsregeln und Rollen-Management.

Hinzufügen von Benutzern (3) Erstellen Sie Salesforce.com-Benutzernamen für jeden, der den Dienst verwenden möchte. Tragen Sie alle erforderlichen Informationen ein, weisen Sie jedem Benutzer eine Rolle in der Hierarchie zu, und spezifizieren Sie für jeden Benutzer ein Profil, um seine Benutzerberechtigungen festzulegen. Aktivieren Sie für Benutzer, die Kampagnen verwalten, das Feld „Marketing-Benutzer“. Aktivieren Sie für Benutzer, die mit der Offline Edition arbeiten, das Feld „Offline-Benutzer“. Aktivieren Sie für Benutzer, die mit der Wireless Edition arbeiten, das Feld „Drahtlos-Benutzer“. Aktivieren Sie danach das Feld „Kennwörter erstellen und Benutzer per E-Mail benachrichtigen“, um jedem Benutzer automatisch den Benutzernamen und das Kennwort per E-Mail zu senden. Sie können außerdem auswählen, dass die Benutzernamen und Kennwörter später gesendet werden über die Benutzerliste.

Definieren des Freigabemodells und der Zugriffsregeln (4) Im Freigabemodell wird festgelegt, wie für die Benutzer in Ihrem Unternehmen der gemeinsame Zugriff auf Accounts, Kontakte, Leads und Opportunities erfolgen soll. Das Freigabemodell besteht aus verschiedenen Komponenten: 쮿

Unternehmensweite Standardeinstellungen – Dabei werden unterschiedliche Zugriffsebenen für Accounts und Kontakte eingestellt, Leads und Opportunities. Diese Einstellungen werden im gesamten Unternehmen angewendet.

쮿

Öffentliche Gruppen – Öffentliche Gruppen werden in den Freigabe-Regeln verwendet, um anzugeben, welche Benutzer Daten anzeigen können, deren Inhaber Mitglieder einer bestimmten Rolle sind.

쮿

Freigabe-Regeln – Wenn Sie unternehmensweit Standardeinstellungen wie „Öffentlicher Lesezugriff“ oder „Privat“ festgelegt haben, können Sie Freigabe-Regeln erstellen, um einen breiteren Zugang zu Daten zu ermöglichen, deren Inhaber Benutzer in bestimmten Rollen oder Gruppen sind.

Hinweis: Unabhängig von den Einstellungen Ihres Freigabemodells können Benutzer jederzeit sämtliche Daten, deren Inhaber in der Rollenhierarchie unter ihnen stehen, anzeigen lassen, bearbeiten und zur Berichtserstellung nutzen. Es kann jedoch nur über den jeweiligen Inhaber bzw. den Benutzern, die in der Rollenhierarchie über ihnen stehen, und den Administratoren auf private Opportunities zugegriffen werden. Auf private Kontakte kann nur von den jeweiligen Inhabern und den Administratoren zugegriffen werden.

36



Festlegen der Kennwortrichtlinien (5) Sie können verschiedene Kennwort- und Anmeldeeinstellungen festlegen, um die Sicherheit Ihrer Unternehmensdaten in Salesforce.com zu erhöhen. Diese Einstellungen umfassen auch die Möglichkeit, die Anzahl der ungültigen Anmeldeversuche anzugeben, die ein einzelner Benutzer ausführen kann, bevor sein Benutzerkonto gesperrt wird, bzw. die Frist, nach der ein Benutzerkennwort abläuft.

Einrichten von Unternehmensmitteilungen und nützlichen Links (6) Als Administrator können Sie Ankündigungen und hilfreiche Internetlinks eingeben, die für jeden Benutzer in Ihrem Unternehmen sichtbar sind. Die Ankündigungen werden auf der Startseite im Bereich „Mitteilungen und Warnungen“ angezeigt, die Links zu anderen Websites im Bereich „Nützliche Links“.

Anpassen der Standardauswahllisten, Erstellen von benutzerdefinierten Feldern (7) Die Details hierzu finden Sie im Customizing Teil dieses Kapitels. Führen Sie alle nötigen Feldänderungen durch und stimmen Sie diese mit den Mitarbeitern Ihres Teams ab.

Festlegen der Feldebenensicherheit (8) Verwenden Sie die Feldebenensicherheit, um den Benutzerzugriff für das Anzeigen und Bearbeiten bestimmter Felder auf Details- und Bearbeitungsseiten sowie in Listenansichten, Berichten, der Offline Edition, Suchergebnissen und beim Synchronisieren von Daten einzuschränken. Die Feldebenensicherheit basiert auf den Benutzerprofilen, d.h., jeder Benutzer mit einem bestimmten Profil verfügt über den gleichen Gesamtzugriff auf Salesforce.com-Felder.

Anpassen der Seitenlayouts (9) Um Salesforce.com exakt auf die Anforderungen Ihres Unternehmens abzustimmen, können Sie das Layout von Feldern und Themenlisten anpassen, die auf den verschiedenen Registerkarten enthalten sind. Sie können die Themenlisten anzeigen, ausblenden oder neu sortieren. Sowohl für Standard- als auch für benutzerdefinierte Felder können Sie die Anzeigereihenfolge ändern und festlegen, welche Felder angezeigt oder ausgeblendet werden sollen bzw. welche Felder obligatorisch und welche schreibgeschützt sind.

Einrichten von E-Mail-Vorlagen (10) Als Administrator können Sie Briefköpfe und E-Mail-Vorlagen für die E-Mail-Funktionen von Salesforce.com erstellen. Die Funktionalität der E-Mail-Vorlagen ist der Einrichtung eines Serienbriefes vergleichbar. Prinzipiell stehen sämtliche Salesforce.com-Felder der einzelnen Objekte zur Verfügung. Die Verwendung gemeinsamer Vorlagen unterstützt Sie bei der Standardisierung der Kommunikation mit dem Kunden und bei der Erhöhung der Effizienz des Unternehmens. Die von Salesforce.com bereitgestellten E-Mail-Funktionen ermöglichen das Senden von E-Mails von den Detailseiten für Accounts, Kontakte, Opportunities und Kundenvorgänge aus. Außerdem wird der Vorgang automatisch als Aktivität in der Liste „Aktivitätsverlauf“ protokolliert.


37



Wenn Sie die Zuordnungsregeln für Leads bzw. die Online-Leaderfassung oder die Funktionalität Web-To-Lead verwenden möchten, benötigen E-Mail-Vorlagen für folgende Vorgänge: 쮿

Benachrichtigen von Kunden, dass ihr Online-Lead eingegangen ist (Autoreply).

쮿

Benachrichtigen von Benutzern oder Warteschlangen, dass ihnen Leads zugewiesen wurden.

Wenn Sie automatische Supportfunktionen verwenden möchten, benötigen Sie E-MailVorlagen für folgende Vorgänge: 쮿

Benachrichtigen von Kunden, dass ihr Online-Kundenvorgang eingegangen ist.

쮿

Benachrichtigen von Kunden, dass als Folge ihres Anrufs oder E-Mails ein Kundenvorgang manuell erstellt wurde.

쮿

Benachrichtigen von Kunden, dass ihnen Kundenvorgänge zugewiesen wurden.

쮿

Benachrichtigen der betreffenden Person in Ihrem Team, dass ein Kundenvorgang eskaliert wurde.

Einrichten von Serienbriefvorlagen (11) Mit der Salesforce.com Office Edition 2.0 können Sie Serienbriefvorlagen in Microsoft Word ab Version XP aufwärts erstellen und dabei die Informationen aus den Datensätzen von Salesforce.com verwenden. Als Administrator können Sie mit Hilfe spezieller Verknüpfungsfelder Vorlagen erstellen und diese in Salesforce.com laden. Die Benutzer können dann Dokumente starten aus Salesforce.com heraus, Microsoft Word wird geöffnet und die Platzhalter sind bereits befüllt.

Anpassen der Lead-Einstellungen (12) Die Lead-Einstellungen müssen angepasst werden, um für Ihr Unternehmen die Standardwerte für die Lead-Verwaltung festzulegen. Sie können beispielsweise den Standardinhaber für alle Leads festlegen, die über die Zuordnungsregel nicht korrekt zugewiesen wurden.

Einrichten der Lead-Warteschlangen (13) Mit Hilfe von Lead-Warteschlangen kann Ihre Vertriebsabteilung Leads auf verschiedene Vertriebsteams verteilen. Sie können Leads manuell oder – falls sie über Web-toLead-Funktionalität erstellt wurden – mit Hilfe einer Zuordnungsregel automatisch in verschiedene Warteschlangen stellen. Ein Lead verbleibt so lange in der Warteschlange, bis er von Mitgliedern dieser Warteschlange abgerufen wird. Nur zugewiesene Mitglieder können die Inhaberschaft an Leads innerhalb der Warteschlange übernehmen. Stellen Sie deshalb sicher, dass jeder Vertriebsmitarbeiter der richtigen Warteschlange zugeordnet ist. Ihr Unternehmen kann festlegen, dass Warteschlangen nach geographischen Kriterien, vertikalen Märkten, der Unternehmensgröße oder nach anderen Kriterien strukturiert sind.

38



Einrichten der Zuordnungsregeln für Leads (14) Zuordnungsregeln für Leads ermöglichen es Ihnen, Leads an die richtigen Warteschlangen oder Benutzer weiterzuleiten. Basierend auf den speziellen Kriterien für den betreffenden Lead (z.B. „Branche gleich Finance & Insurances“) können Sie sicherstellen, dass Leads bei der Web-Erfassung korrekt zugeordnet werden. Sie können Benutzer oder Warteschlangenmitglieder nach automatischer Zuweisung durch eine Zuordnungsregel per E-Mail benachrichtigen lassen.

Einrichten der Online-Leaderfassung (15) Online-Leaderfassung ermöglicht Ihrer Firma, Informationen über potenzielle Kunden direkt über die Unternehmenswebsite zu erfassen und automatisch bis zu 500 neue Leads pro Tag anzulegen. Sie können eingehende Web-Leads automatisch mit Hilfe einer Zuordnungsregel zuweisen, so dass jeder Lead dem richtigen Vertriebsmitarbeiter/team zugewiesen wird und von diesem schnell und korrekt beantwortet werden kann. Des Weiteren können Sie die Online-Leaderfassung nutzen, um sog. „jump pages“ oder „microsites“ zu erstellen, die Lead-Informationen als Teil einer Kampagne erfassen. In diesem Fall können Sie den neu erfassten Lead direkt mit einer bestehenden Kampagne verknüpfen. Sie können auch automatische Antwortregeln für die Online-Leaderfassung erstellen, um die E-Mail-Vorlage festzulegen, die für Antwortschreiben verwendet werden soll, wenn Leads online erfasst werden. Sie können Antwortregeln basierend auf beliebigen Attributen des eingehenden Leads erstellen.

Überprüfen der automatischen Supportfunktionen (16) Die Supportkomponente von Salesforce.com enthält eine Vielzahl von automatischen Funktionen, mit deren Hilfe Sie Ihre Arbeit automatisch verwalten, effektiv mit Kunden kommunizieren und die Teamproduktivität erhöhen können. Anhand der Anweisungen auf den nächsten Seiten können Sie alle Supportfunktionen einrichten. E-Mail-Vorlagen Wenn Sie automatische Funktionen verwenden möchten, benötigt Ihr Unternehmen E-Mail-Vorlagen für folgende Vorgänge: 쮿

Benachrichtigen von Kunden, dass ihr Online-Kundenvorgang eingegangen ist.

쮿

Benachrichtigen von Kunden, dass als Folge ihres Anrufs oder E-Mails ein Kundenvorgang manuell erstellt wurde.

쮿

Benachrichtigen von Kunden, dass ihnen Kundenvorgänge zugewiesen wurden.

쮿

Benachrichtigen der betreffenden Person in Ihrem Team, dass ein Kundenvorgang eskaliert wurde.

Kundenvorgangswarteschlangen Ermöglicht es Ihnen, die verschiedenen Kundenvorgänge zu verwalten oder unterschiedliche Serviceebenen festzulegen, indem Kundenvorgänge auf bestimmte Warteschlangen (und nicht auf bestimmte Benutzer) verteilt werden.


39



Supporteinstellungen Legen Sie die Standardeinstellungen für den Support und die E-Mail-Vorlagen fest, die für die korrekte Funktionsweise der automatischen Supportfunktionen benötigt werden. Zuordnungsregeln für Kundenvorgänge Ermöglichen es Ihnen, Kundenvorgänge automatisch verschiedenen Benutzern zuzuweisen bzw. Kundenvorgänge in Warteschlangen zu stellen, die auf bestimmten Kundenvorgangskriterien basieren. Eskalationsregeln für Kundenvorgänge Helfen Ihnen bei der Festlegung, wie schnell die Probleme Ihrer Kunden gelöst werden sollen, und eskalieren automatisch Kundenvorgänge, die nicht innerhalb einer bestimmten Frist gelöst wurden. Online-Vorgangserfassung und Selbstbedienungsportal Ermöglicht es Ihren Kunden, Fragen und Probleme direkt auf Ihrer Website einzugeben und anhand dieser Informationen automatisch einen Kundenvorgang zu erstellen.

Einrichten von Kundenvorgangswarteschlangen (17) Kundenvorgangswarteschlangen können Ihnen dabei helfen, die Arbeit des Kundensupports zu verwalten. Sie können eingehende Kundenvorgänge verschiedenen Warteschlangen zuordnen. Das kann manuell oder automatisch durch eine Zuordnungsregel für Kundenvorgänge erfolgen. Die Kundenvorgänge verbleiben so lange in der Warteschlange, bis sie einem individuellen Benutzer zugeordnet werden. Die Zuordnung erfolgt entweder durch den Administrator oder einen anderen Benutzer. Bei der erstmaligen Zuordnung der Kundenvorgänge zu den unterschiedlichen Warteschlangen können Sie Prioritäten festlegen und sicherstellen, dass diese Vorgänge von den entsprechenden Mitarbeitern bearbeitet werden. Als Administrator können Sie Warteschlangen erstellen, die auf dem Fachwissen der Supportmitarbeiter basieren, z. B. die beiden Warteschlangen „Technischer Support Ebene 1“ und „Technischer Support Ebene 2“. Sie können auch Warteschlangen einrichten, die auf den Serviceverträgen Ihrer Kunden basieren, z. B. die beiden Warteschlangen „Serviceebene Gold“ und „Serviceebene Silber“.

Anpassen von Supporteinstellungen (18) Als Nächstes müssen Sie die Supporteinstellungen anpassen, um die Standardeinstellungen für den Support und die E-Mail-Vorlagen für Ihr Unternehmen festzulegen. Vervollständigen Sie die Supporteinstellungen, damit die automatischen Funktionen korrekt funktionieren.

Einrichten der Zuordnungsregeln für Kundenvorgänge (19) Zuordnungsregeln für Kundenvorgänge ermöglichen es Ihnen, Kundenvorgänge an die richtigen Warteschlangen oder Benutzer weiterzuleiten. Basierend auf den speziellen Kriterien für diesen Kundenvorgang (z.B. „Produktbereich gleich Website“) können Sie sicherstellen, dass Kundenvorgänge bei der Web-Erfassung korrekt zugeordnet werden.

40



Wenn die Benutzer einen Kundenvorgang erstellen oder bearbeiten, können Sie ihn mit Hilfe einer Zuordnungsregel automatisch zuweisen lassen.

Einrichten der Eskalationsregeln für Kundenvorgänge (20) Mit Hilfe von Eskalationsregeln für Kundenvorgänge können Sie sicherstellen, dass Ihr Team auf Kundenmeldungen schnellstmöglich reagiert. In einer Eskalationsregel können Sie festlegen, dass Kundenvorgänge mit speziellen Informationen automatisch eskaliert werden sollen, wenn sie innerhalb einer bestimmten Frist nicht gelöst werden können. Beispielsweise können Sie festlegen, dass alle Kundenvorgänge mit „Serviceebene gleich Gold“ eskaliert werden, wenn innerhalb von 4 Stunden keine Lösung möglich ist. Außerdem können Sie die Geschäftszeiten für Ihr Supportteam festlegen, so dass die Eskalationsregeln nur während dieser Geschäftszeiten gelten.

Einrichten der Online-Vorgangserfassung (21) Online-Vorgangserfassung ermöglicht Ihrer Firma, Kundenfeedback und -anfragen direkt über die Unternehmenswebsite zu erfassen und automatisch bis zu 500 neue Kundenvorgänge pro Tag anzulegen. Die Online-Erfassung der Kundenvorgangsinformationen ermöglicht es Ihnen, Kundenanfragen zu verwalten und zu verfolgen und außerdem schnell auf jeden Kunden zu reagieren. Dies resultiert in einer größeren Kundenzufriedenheit und einer höheren Teamproduktivität. Darüber hinaus können Sie auch automatische Antwortregeln für die Online-Vorgangserfassung erstellen, um die E-Mail-Vorlage festzulegen, die für Antwortschreiben an Kunden verwendet werden soll, die Kundenvorgänge online senden. Sie können Antwortregeln basierend auf beliebigen Attributen des eingehenden Kundenvorgangs erstellen.

Einrichten von Lösungen (22) Lösungen sind detaillierte Beschreibungen eines Kundenproblems und der Behebung des Problems. Lösungen ermöglichen es Ihnen, das Wissen Ihrer Kundensupportteams zu dokumentieren und weiterzugeben, so dass ein und dasselbe Problem nicht ständig neu gelöst werden muss. Indem eine ganze Sammlung von Lösungen erstellt und gepflegt wird, kann Ihr Kundensupportteam schnell auf häufige Kundenprobleme reagieren und damit die Teamproduktivität erhöhen. Der Schlüssel zum Erstellen und Verfassen guter Lösungen sind wiederverwendbare, leicht auffindbare und technisch korrekte Lösungen. Tipps & Hinweise für Lösungen Das Erstellen und Pflegen von guten Lösungen ist der Schlüssel zur schnellen und exakten Auflösung von Kundenvorgängen und erhöht damit die Produktivität Ihres Teams. Befolgen Sie die unten genannten Tipps zur Erstellung und Überprüfung Ihrer Lösungen.


41



Strukturieren von Lösungen Alle Lösungen in Ihrem Unternehmen sollten auf derselben Basisstruktur aufbauen. Position 쮿

Geben Sie eine kurze Erklärung, worum es in der Lösung geht.

쮿

Beschreiben Sie das Problem des Kunden bzw. was der Kunde versucht.

Details 쮿

Formulieren Sie die Frage bzw. das Problem des Kunden erneut, und verwenden Sie ggf. eine andere Formulierung.

쮿

Nennen Sie alle Informationen, um das Kundenproblem genau zu beschreiben und zu lösen.

쮿

Nennen Sie alle Symptome – was kennzeichnet die Situation des Kunden?

쮿

Nennen Sie den Produktbereich – wo tritt das Problem auf?

쮿

Erklären Sie die Ursache – was ist die Hauptursache des Problems?

쮿

Erklären Sie die Lösung – wie wird das Problem gelöst?

쮿

Wenn dazu mehrere Schritte erforderlich sind, nummerieren Sie sie, und beschreiben Sie jeden Schritt in einer separaten Zeile.

Lösungsmanager 쮿

Lösungsmanager sollten erfahrene Supportmitarbeiter mit tiefgehendem Produktwissen und hervorragenden schriftlichen Kommunikationsfähigkeiten sein.

쮿

Sie sind für das Überprüfen aller Lösungen verantwortlich und schulen andere Mitarbeiter im Verfassen guter Lösungen.

쮿

Administratoren können Benutzer zu Lösungsmanagern machen, indem sie auf Mein Setup | Benutzer & Rollen | Benutzer verwalten klicken. Anschließend kann das Profil des Benutzers zu „Lösungsmanager“ geändert werden.

Lösungsrichtlinien Halten Sie sich beim Erstellen und Überprüfen von Lösungen an die folgenden fünf Richtlinien: 쮿

Sprache: Verwenden Sie eine Sprache, die der „normale“ Kunde versteht.

쮿

Struktur: Halten Sie sich an Ihren Unternehmensstandard für Lösungen.

쮿

Inhalt: Stellen Sie sich den Inhalt wie den Haupttext einer E-Mail vor und entfernen Sie alle kundenspezifischen Informationen.

쮿

"Optisch eingängig": Erstellen Sie eine leicht lesbare Lösung – beginnen Sie für jeden neuen Gedanken eine neue Zeile, nummerieren Sie Arbeitsschritte.

쮿

Auffindbar: Verwenden Sie Stichwörter, anhand derer andere Vertriebsmitarbeiter und Benutzer schnell nach einer Lösung suchen können.

42



Prozess der Lösungsüberprüfung Verwenden Sie diesen Prozess für das Überprüfen von Lösungen: 쮿

Überprüfen auf doppelte Lösungen – Geben Sie in der Lösungssuche ein paar Stichwörter ein, um festzustellen, ob es sich um einen noch nicht beschriebenen Fall handelt.

쮿

Richtlinien – Stellen Sie sicher, dass die Richtlinien – wie links beschrieben – eingehalten werden.

쮿

Status – Ändern Sie den Status zum nächsten verfügbaren Status.

쮿

Veröffentlichen – Aktivieren Sie das Kontrollkästchen „Veröffentlicht“, um die Lösung Ihren Kunden über das Selbstbedienungsportal zur Verfügung zu stellen.

Beispiellösungen Das folgende Beispiel verwendet die Standardstruktur und -richtlinien für Lösungen: Fragestellung: Wie kann ich weitere Benutzerlizenzen für mein Unternehmen hinzufügen? Administratoren sind in der Lage, weitere Benutzerlizenzen hinzuzufügen. Gehen Sie zu „Mein Setup“, und klicken Sie auf den Link „Benutzer & Rollen“. Klicken Sie auf den Link „Lizenzen hinzufügen“. Geben Sie die Anzahl der zusätzlichen Lizenzen ein, und klicken Sie auf „Weiter“. Aktualisieren Sie die Rechnungsdaten Ihres Unternehmens, und klicken Sie auf „Weiter“. Wählen Sie eine Zahlungsart aus, und klicken Sie auf „Weiter“. Um den Vorgang abzuschließen, klicken Sie auf „Fertig stellen“. Besondere Funktionen: 쮿

Sie können an jede Lösung eine Datei anhängen, damit diese mit der Lösung versendet werden kann. Passen Sie die E-Mail-Antwortvorlage für Kundenvorgänge an, und beziehen Sie das Feld ein.

쮿

Hyperlinks lassen sich problemlos in Lösungen integrieren, wenn Sie sie im URLFormat eingeben.

Einrichten von benutzerdefinierten Berichten (23) Berichte sind leistungsfähige Tools, die Sie dabei unterstützen, die Daten in Ihrem Unternehmen anzuzeigen und zu analysieren. Salesforce.com stellt Ihnen zahlreiche Standardberichte zur Verfügung, Sie können ferner benutzerdefinierte Berichte erstellen. Die Berichte sind flexibel verwendbar, Sie können Daten im Tabellen-, Überblicks- oder Matrixformat aufbereiten. Weiterhin können verschiedene Diagramme und Grafiken erstellt werden. Durch die Möglichkeit, benutzerdefinierte Felder hinzuzufügen, erweitert sich das Leistungsspektrum der Berichte. Die Berichte werden in Ordner unterteilt. Mit Hilfe des Berichts-Managers kann der Administrator des Unternehmens neue Ordner hinzufügen, Ordner individuell anpassen und festlegen, welche Benutzergruppen die Berichte in jedem Ordner ansehen können.


43


2 – Salesforce.com planen, einrichten und konfigurieren 쮿

Meine persönlichen benutzerdefinierten Berichte – benutzerdefinierte Berichte, die Sie erstellt und gespeichert haben.

쮿

Ungespeicherte öffentliche Berichte – benutzerdefinierte Berichte, die von einem Administrator erstellt, gemeinsam verwendet, aber nicht im Bereich mit den benutzerdefinierten Berichten gespeichert werden.

쮿

Account- und Kontaktberichte

쮿

Opportunity- und Prognoseberichte

쮿

Umsatzberichte

쮿

Lead-Berichte

쮿

Supportberichte

쮿

Kampagnenberichte

Auf der Registerkarte „Berichte“ können Sie Folgendes tun: 쮿

Berichte in verschiedenen Ordnern anzeigen und auswählen

쮿

Alle von Ihnen angepassten und gespeicherten Berichte anzeigen und auswählen

쮿

Die Registerkarte „Ordner“ durch Verschieben von Berichtsordnern nach oben oder unten positionieren

Mit der Registerkarte „Berichte“ können Sie neue Berichtsordner erstellen, festlegen, welche Berichte jedem Ordner zugeordnet werden und welche Benutzer Berichte in den verschiedenen Ordnern anzeigen können. Innerhalb eines bestehenden Berichts können Sie Folgendes tun: 쮿

Ihre Berichtsdaten anzeigen

쮿

Die Berichtsparameter ändern und den Bericht erneut ausführen

쮿

Die Unternehmenshierarchie nach Rollen aufgliedern

쮿

Ihren Bericht nach Excel exportieren

쮿

Eine Tabelle anzeigen

쮿

Den Bericht speichern

쮿

Nach benutzerdefinierten Feldern anzeigen und sortieren

쮿

Berichte der Geschäftsführung anzeigen

쮿

Eine vierteljährliche Prognosenübersicht anzeigen (einschließlich Aufgliederungsfunktionalität)

쮿

Berichte über Opportunity-Quellen erstellen (einschließlich Lead-Quellen)

쮿

Einen benutzerdefinierten Opportunity-Bericht erstellen

쮿

Einen Bericht über Aufgaben und Aktivitäten erstellen (einschließlich aller Aktivitäten)

44



Zu den wichtigsten Berichten zählen: Aufgaben und Termine Verwenden Sie diesen Bericht, um Ihre Aktivitäten oder die Aktivitäten des Teams anzuzeigen. Um im Bericht auch die Kommentare zu den einzelnen Aktivitäten anzuzeigen, klicken Sie auf „Benutzerdefiniert“, wechseln zu Schritt 4 des Berichtsassistenten, aktivieren das Feld „Vollständige Kommentare“, und klicken abschließend auf „Bericht ausführen“. Der geänderte Bericht wird angezeigt. Verteilerliste Führen Sie diesen Bericht zum Sammeln der Adressen aus, die unter Microsoft Word für eine Serienmail verwendet werden sollen. Exportieren Sie den Bericht nach Excel. Wichtigste Kontakte Führen Sie diesen Bericht aus, um festzustellen, welche Kontakte mit Ihren Opportunities verknüpft sind. Opportunity-Pipeline Führen Sie diesen Bericht aus, um Ihre Vertriebs-Pipeline anzuzeigen. Sie können den Bericht benutzerspezifisch anpassen, um die Pipeline für Vertriebsmitarbeiter, Phasen oder einem beliebigen von Ihnen erstellten Feld anzuzeigen. Teilnahme an Schulungen: Eine weitergehende Einweisung in das Arbeiten mit Berichten erhalten Sie in den Schulungen. Sie können sich auch an das Kundensupportteam von Salesforce.com wenden, indem Sie auf einer beliebigen Salesforce.com-Seite oben rechts auf den Link „Support“ klicken.

Einrichten von Webintegrationslinks (24) Als Administrator können Sie Webintegrationslinks erstellen, um die Daten anderer Systeme in Salesforce.com zu integrieren. Die Links können auf externe URLs, auf das Intranet oder auf andere Salesforce.com-Seiten verweisen. Sie können außerdem Salesforce.com-Felder einfügen, die an die URL weitergegeben werden. Die Webintegrationslinks werden auf der Detailseite im Bereich „Nützliche Links“ angezeigt. So können Sie beispielsweise einen Link für Accounts erstellen, mit dem bei Yahoo nach dem Namen eines Accounts gesucht wird. Der entsprechende Link dafür ist http:// search.yahoo.com/bin/search?p={!Account_Name}.

Vereinbarung über das System-Setup (25) Demonstrieren Sie das erste Salesforce.com-Setup allen relevanten Teammitgliedern, um einen Konsens bezüglich des Designs zu erzielen. Dies ist ein entscheidender Schritt zur Akzeptanz von Salesforce.com. Nachdem Sie individuelle Auswahllisten erstellt und benutzerdefinierte Felder hinzugefügt haben, stellen Sie die vorgenommenen Änderungen der Gruppe vor, die die Geschäftsprozesse überprüft hat, und holen Sie deren Genehmigung ein. Nehmen Sie alle erforderlichen Änderungen vor, und lassen Sie auch diese bestätigen.


45



2.6.3 Datenmanagement/Migration Die Details zu den technischen Fragen einer Datenmigration werden in den anderen Kapiteln dieses Buches behandelt. Hier erscheint nur der Überblick der Informationen, die ein Projektmanager während der Einführung kennen muss, sowie die in Salesforce.com integrierte Importfunktionalität, die über das User-Interface zu bedienen ist (Import-Assistent).

Einigung auf Namenskonventionen (1) Namenskonventionen für Accounts: Wir empfehlen Ihnen, für jedes Unternehmen mehrere Accounts zu erstellen – einen Haupt- bzw. übergeordneten Account, in dem die Informationen zur Hauptniederlassung gespeichert werden, sowie zusätzliche Accounts für jeden Standort. Auf diese Weise können Sie einzelne Kontakte und Opportunities mit dem richtigen Standort verbinden. Für ein Unternehmen mit drei verschiedenen Standorten können Sie vier verschiedene Accounts erstellen – einen für die Hauptniederlassung und drei zusätzliche Accounts für jeden Standort. Verwenden Sie für jeden Account denselben Namen (z. B. Acme.com), und geben Sie den Standort (z. B. Hauptniederlassung oder Berlin) in das Feld „Accountstandort“ ein. Sie können auch über das Feld „Übergeordneter Account“ jeden der drei Standorte mit der Hauptniederlassung verbinden. Mit Hilfe der Accounthierarchiefunktion erhalten Sie dann einen umfassenden Überblick über das übergeordnete Unternehmen und all seine Standorte. Namenskonventionen für Opportunities: Sie sollten jede Opportunity mit dem Namen des Unternehmens, gefolgt vom Produkt, benennen (z. B. Acme.com - 25 Lizenzen). Auf diese Weise können Benutzer schnell nach Opportunities suchen, wenn sie versuchen, Aufgaben und Ereignisse mit einer bestimmten Opportunity zu verbinden.

Teilnahme an einer Schulung über den erweiterten Import (2) Ihr Experte für Datenmigration sollte an der Import-Schulung für Fortgeschrittene teilnehmen. Die Import-Assistenten enthalten zwar Schritt-für-Schritt-Anweisungen, doch dieser Kurs behandelt den Import detailliert und bietet Tipps und Hinweise.

Lektüre des Benutzerhandbuchs mit hilfreichen Tipps zum Import (3) Das Import-Handbuch enthält Anweisungen und Tipps zum Vorbereiten und Importieren von Daten. Tipps & Hinweise zum Importieren von Unternehmensdaten Für den schnellen Einstieg in Salesforce.com können Administratoren die bestehenden Kontakte und Accounts aus allgemein üblichen Manager-Anwendungen wie Outlook, ACT!, GoldMine sowie aus Palm-Geräten importieren.

46



Öffnen des Import-Assistenten als Systemadministrator: 쮿

Melden Sie sich bei Salesforce.com an.

쮿

Klicken Sie oben rechts auf Mein Setup.

쮿

Klicken Sie auf den Link Tools und Dienstprogramme.

쮿

Klicken Sie auf Unternehmensaccounts und -kontakte importieren (nur für Administratoren verfügbar).

쮿

Überprüfen Sie die Schritte des Importvorgangs.

쮿

Starten Sie den Import-Assistenten.

Testen Ihrer Importdatei Bevor Sie Ihre gesamten Unternehmensdaten importieren, sollten Sie eine kleine Testdatei mit fünf Datensätzen importieren, um sicherzustellen, dass die Daten in Salesforce.com korrekt zugeordnet werden. Vermeiden von doppelten Accounts und Kontakten Der Import-Assistent versucht, alle doppelten Accounts und Kontakte beim Import aufzulösen. Folgende Regeln werden für die Feststellung verwendet, ob zwei Datensätze identisch sind; wichtig ist hierbei Folgendes: 쮿

Groß- und Kleinschreibung werden ignoriert. „Salesforce.com“ ist demnach identisch mit „SALESFORCE.COM“.

쮿

Satzzeichen werden ignoriert. „ABB“ ist demnach identisch mit „A.B.B.“.

쮿

Folgende Wörter in Accountnamen werden ignoriert, wenn davor oder dahinter ein Leer oder Satzzeichen steht bzw. wenn sie am Anfang oder Ende eines Namens auftreten.

쮿

Ignorierte Wörter: Fa., Unternehmen, Gesellschaft, Gruppe, AG, Aktiengesellschaft, International, Intl, Gesellschaft, GbR, GmbH, KG, Die, Beispiel: „Börse, Die“ stimmt mit „Die Börse“ überein, aber nicht mit „DieBörse“.

쮿

„com“ wird nicht ignoriert, so dass aus „Salesforce“ und „Salesforce.com“ zwei verschiedene Accounts entstehen.

쮿

In einem privaten Freigabemodell werden für jeden Inhaber eines bestimmten Accounts oder Kontakts doppelte Accounts und Kontakte erstellt.

쮿

Damit Sie die Datensätze anderer Benutzer importieren können, müssen diese aktiv sein und dürfen in Salesforce.com nicht nur Lesezugriff haben. Benutzer, die nur Lesezugriff haben, können keine Inhaber von Datensätzen sein.

Überschreiben von Daten 쮿

Der Import-Assistent überschreibt keine vorhandenen Accountfelder, sofern Sie nicht das Kontrollkästchen Accountwerte überschreiben aktivieren.

쮿

Bei Kontakten, die denselben Accountnamen und -standort sowie denselben Vorund Nachnamen (bzw. vollständigen Namen) haben, werden die vorhandenen Daten mit den Daten der Importdatei zusammengeführt.

쮿

Der Assistent führt außerdem doppelte Datensätze in Ihrer Importdatei zusammen.


47



Importieren von Notizen 쮿

Jede Notiz kann maximal 4000 Zeichen enthalten.

쮿

Sie können keine Notizen importieren, die eingebettete Anführungszeichen enthalten. Zum Beispiel: Dies ist eine Notiz mit „eingebetteten“ Anführungszeichen.

쮿

Geben Sie den Notizspalten in Ihrer Datei den Titel „Kontaktnotiz“ oder „Accountnotiz“.

Importieren von Listenwerten 쮿

Jeder Wert kann erfolgreich in eine Auswahlliste importiert werden.

쮿

Ihr Administrator kann später die Listenwerte aktualisieren, damit sie mit den importierten Daten übereinstimmen.

Importieren von Daten (4) Als Administrator können Sie bei jedem Import bis zu 50.000 Datensätze importieren. Wir empfehlen Ihnen, zunächst einen Testimport einiger Datensätze durchzuführen, um die Datenzuordnung zu überprüfen. Hinweis: Einzelne Benutzer können außerdem eigene Daten importieren, und zwar bis zu 500 Datensätze pro Importvorgang. Sie können entscheiden, ob Ihre Benutzer dies selbständig handhaben sollen. Es hat sich gezeigt, dass Unternehmen, die die Datenmigration für ihr Team übernehmen, in der Regel eine höhere Akzeptanzrate aufweisen; aber sobald Salesforce.com einmal akzeptiert wurde, möchten die Benutzer vielleicht zusätzliche Dateien aus ihren Daten importieren.

2.6.4 Einführung Die Einführung mit dem Team, das zur Entwicklung und Konfiguration bereit stand, und den geplanten Endanwendern ist integraler Bestandteil des Prozesses und sollte die erfolgreiche Umsetzung und das Customizing abschließen.

Aktivieren aller Benutzer (1) Wenn Sie zuvor Benutzer erstellt und diese nicht aktiviert und/oder ihnen ihr Kennwort nicht gesendet haben, müssen Sie dies jetzt nachholen, damit die Benutzer sich für Schulungen anmelden und mit der Verwendung von Salesforce.com beginnen können.

Einladen der Benutzer zur Teilnahme an Schulungen (2) Weisen Sie Benutzer per E-Mail darauf hin, an Schulungen teilzunehmen (siehe nachstehendes Beispiel). Zur Erinnerung: Alle Benutzer müssen über ihren Benutzernamen und ihr Kennwort verfügen. Falls Benutzer ihre Kennwörter vergessen haben, gehen Sie zur Seite Benutzer, und setzen Sie die Kennwörter für diese Benutzer zurück.

48



Planen eines Kickoff-Meetings (3) Planen Sie ein Kickoff-Meeting, um die unternehmensspezifischen Geschäftsprozesse durchzugehen. Dieses Meeting ist für alle Benutzer verpflichtend und ein weiterer entscheidender Schritt für die erfolgreiche Einführung von Salesforce.com (siehe nachstehende Beispiel-E-Mail). Betrachten Sie dieses Meeting als Ihr Kickoff, und planen Sie es kurz vor oder direkt an „Ihrem Liveschaltungstermin“. Alle Benutzer sollten kurz vorher an einer Schulung teilgenommen haben und bereit sein, Salesforce.com aktiv zu verwenden. Beispiel für eine Kickoff-Tagesordnung: 쮿

Einführung durch die Unternehmensleitung

쮿

Site-Übersicht von Salesforce.com

쮿

Überprüfen der Anpassung

쮿

Diskussionen der Ziele und Metriken

쮿

Verfügbare Ressourcen

쮿

Fragen und Antworten

Einführung durch die Unternehmensleitung Legen Sie die Gründe für die Auswahl von Salesforce.com dar. Site-Übersicht von Salesforce.com Geben Sie einen Überblick über Salesforce.com. Navigieren Sie kurz zu allen Bildschirmen. Überprüfen der Anpassung Behandeln Sie die durchgeführten Anpassungen, die nach Überprüfung der Geschäftsprozesse vorgenommen wurden. Navigieren Sie zu allen entsprechenden Bildschirmen. Gehen Sie die Prozesse durch, die für die Verwendung des Systems implementiert werden müssen. Diskussionen der Ziele und Metriken In der Regel wird innerhalb der ersten Wochen, in denen Salesforce.com verwendet wird, festgelegt, wie Ihr Team Salesforce.com nutzen wird. Es ist sehr wichtig, sich bereits in diesem Stadium an die korrekte Handhabung zu gewöhnen! Sorgen Sie deshalb dafür, dass Ihre Benutzer einen Leitfaden zu den Zielen erhalten, die sie kurz- und langfristig mit Salesforce.com erreichen sollen. Setzen Sie den Benutzern Ziele, und geben Sie diese im Verlauf des Meetings bekannt. Teilen Sie ihnen beispielsweise mit, dass sie bis zu einem bestimmten Datum eine bestimmte Anzahl von Opportunities und Prognosen eingetragen haben müssen sowie eine bestimmte Anzahl und bestimmte Typen (Anrufe, Präsentationen usw.) von Aktivitäten pro Tag, Woche und Monat. Überprüfen Sie auch Ihre Geschäftsprozess-Richtlinien für Salesforce.com, und behandeln Sie alle Probleme, die mit der Verwendung des Dienstes zusammenhängen. Unten sind einige Beispielaufgaben aufgeführt, die Sie Ihren Benutzern stellen können, sobald diese mit der Verwendung des Dienstes beginnen. Verfügbare Ressourcen Gehen Sie alle verfügbaren Optionen durch. Verwenden Sie einige Zeit darauf, die Nutzung aller verfügbaren Optionen in der Online-Hilfe zu behandeln, und erklären Sie jeden Bereich detailliert.


49



Aufgaben für die Benutzer: Absolvieren von Schulungen (mindestens eine, zumindest des Standards oder der Berichte)

Abbildung 2.14: Liste der Standard-Schulungen, die innerhalb von Salesforce.com vorhanden sind

Wichtige Daten eingeben 쮿

Fügen Sie Ihre Opportunities hinzu, die dieses Quartal schließen.

쮿

Erstellen Sie Ihre Prognose für dieses und das nächste Quartal.

쮿

Fügen Sie Ihre Quotenzuordnungen für dieses und das nächste Quartal hinzu.

쮿

Fügen Sie Ihre Aufgaben & Besprechungen bis zum Ende des aktuellen Monats hinzu.

Synchronisieren Ihrer Daten Wenn Sie Outlook oder ein Palm-Gerät verwenden, müssen Sie lernen, wie Sie Ihren Kalender und Ihre Aufgaben synchronisieren. Persönliche Gestaltung 쮿

Passen Sie Salesforce.com an Ihre persönlichen Bedürfnisse an, so dass Ihre wichtigsten Informationen angezeigt werden.

쮿

Festlegen Ihrer E-Mail-Signatur

쮿

Eingeben von häufig verwendeten E-Mail-Vorlagen

쮿

Leiten Sie Ihre Word-Vorlagen an Ihren Administrator für Serienbriefe weiter.

쮿

Festlegen Ihres Gebietsschemas und Ihrer Zeitzone

쮿

Erstellen Sie eigene benutzerdefinierte Berichte.

50



2.6.5 Nachverfolgung Nach der Einführung gibt es einige Dinge, die Sie regelmäßig überwachen oder kontrollieren sollten als Systemadministrator oder Verantwortlicher für die Einführung des Systems.

Überwachen von Benutzeraktivitäten (1) Als Administrator können Sie sehen, wann Ihre Benutzer sich zuletzt angemeldet und an welchen Schulungen sie teilgenommen haben. Auf diese Weise können Sie überprüfen, ob die Benutzer Salesforce.com so verwenden, wie in Ihren Zielen und Metriken vorgesehen.

Abhalten von Nachverfolgungs-Besprechungen (2) Diese Besprechungen können während der ersten vier Wochen, die Salesforce.com eingesetzt wird, einmal wöchentlich persönlich oder per Telefon gehalten werden. Hauptziel ist es, sich zu vergewissern, dass alle das System verwenden und es auch korrekt nutzen, sowie alle anfallenden Fragen oder Probleme zu klären. Vergewissern Sie sich, dass alle an den unten aufgeführten Aufgaben arbeiten oder sie bereits abgeschlossen haben. Überwachen Sie im besonderen die Aufgaben, die wir oben erstellt haben, wie: 쮿

Aufgaben für die Benutzer

쮿

Wichtige Daten eingeben

쮿

Synchronisieren Ihrer Daten

쮿

Persönliche Gestaltung

Wir wünschen Ihnen viel Erfolg in der Nachverfolgung und in der Umsetzung Ihrer Salesforce.com-Projekte!


51



3

Initial Load

Wenn ein Salesforce.com-Account neu in Betrieb genommen wird, kann man fast nie davon ausgehen, auf einer „grünen Wiese“ anfangen zu können. Stattdessen wird man Daten benutzen wollen und müssen, die in verschiedenen Systemen bereits vorhanden sind und (wenn auch nur teilweise) in diesen Salesforce.com-Account übernommen werden sollen. Ein Gesichtspunkt eher soziologisch-psychologischer Art sei hier nicht verschwiegen: Die Endbenutzer werden in der Regel erst nach dem Initial Load beginnen, mit Salesforce.com ernsthaft zu arbeiten. Was sie zu diesem Zeitpunkt an Funktionalität, aber insbesondere auch an Datenbasis vorfinden, entscheidet wesentlich über Akzeptanz und damit Erfolg der Salesforce.com-Einführung. Erfahrungsgemäß ist das Team, das den Initial Load verantwortet, ein idealer Prügelknabe für sämtliche Fehler und Unzulänglichkeiten, auch wenn es sie gar nicht zu verantworten hat oder überhaupt nicht beeinflussen konnte. Grund genug jedenfalls, den Initial Load als wichtigen Meilenstein zu behandeln. Die folgenden Erläuterungen mögen dazu helfen, dass dieser nicht zu einem Stolperstein wird.

3.1

Vorhandene Datenquellen

Quellen der initialen Salesforce.com-Daten sind oft ERP-Systeme (Enterprise Resource Planning) wie z.B. SAP, BAAN, Navision, aber auch CRM-Systeme (Customer Relation Management) wie Act!, ISV und andere. Nicht vergessen darf man, dass fast immer, meist sogar in beträchtlichem Umfang, wertvolle Informationen in Excel-Spreadsheets abgelegt sind. Wichtige Datenquellen für den Initial Load sind: Kundenstammdaten – Sie kommen in der Regel aus einem ERP-System, werden aber fast immer ergänzt oder korrigiert aus zusätzlichen Quellen. Zwei Beispiele mögen das veranschaulichen: 1. Die im ERP-System gespeicherten Adressen sind meistens lediglich relevant als Rechnungs- oder Lieferadressen, nicht aber als Kontakt-Adressen für verkäuferische Belange. Daher werden sie oft aus anderen Datenbeständen angereichert bzw. korrigiert. 2. Aus Sicht von Salesforce.com gibt es potentielle Kunden („Leads“) , die eng mit Kunden- und Kontaktdaten verknüpft sind, während in ERP-System Kunden meist nur bekannt sind, wenn sie mindestens einen Auftrag erteilt haben; auch hier muss man oft auf alternative Quellen zurückgreifen.


53


3 – Initial Load

Artikelstammdaten – Hier kann es sein, dass ein Artikel in Salesforce.com benutzt werden soll, den es im ERP-System nicht gibt. Dazu ein Beispiel: Ein Verkäufer verhandelt mit einem Kunden über die neue Entwicklung eines Produkts, das schon beschrieben ist und gegebenenfalls auch eine vorläufige Artikelnummer hat; der Verkäufer soll aber Salesforce-Angebote auch über solche Artikel kreieren können. Kontaktpersonen – Hier geht es um die – für den Verkauf enorm wichtigen – Daten von Personen, mit denen Verkaufs-Kontakte bestanden oder bestehen. Eine alte Verkäuferweisheit sagt: „Verkäufer verkaufen nicht an Firmen, sondern an Personen“, und somit müssen gerade diese Daten auch in Salesforce.com zur Verfügung stehen. Dabei kann es zu Zuordnungsproblemen in Bezug auf Salesforce.com kommen, da dort die Kontaktpersonen einmal im Objekt Contact, ein andermal im Objekt Lead abgelegt werden, je nachdem, ob es sich lediglich um einen Interessenten oder bereits bestehenden Kunden handelt. Aktivitätenhistorie – Im Verlauf des Verkaufsprozesses kommt es zu den verschiedensten bzw. verschiedenartigsten Kontakten mit dem Kunden, die von gewissenhaften Verkäufern sorgfältig protokolliert werden. Da gibt es: 쮿

Meeting-Protokolle,

쮿

Aufzeichnungen zu Telefongesprächen,

쮿

E-Mails,

쮿

Angebote,

쮿

juristische Briefwechsel,

쮿

Produktbeschreibungen,

쮿

etc.

Diese Daten erzählen die Geschichte und berichten von den Umständen erfolgreicher oder gescheiterter Verkaufsbemühungen und sind daher gute Quellen, um Erfahrungen zu gewinnen, aber auch Einzelvorgänge rekonstruieren zu können. Da CRM-Systeme diese Notizen bzw. Verweise auf solche Dokumente speichern können, liegen sie oft schon in elektronischer Form vor und können demnach auch nach Salesforce.com geladen werden. Und, das Wichtigste zuletzt: Auftragsdaten (Angebote/Aufträge/Rechnungen/Lieferscheine/...) – sind die begleitenden Dokumente im Verkaufsprozess, um den sich ja letztlich alles dreht. Sie dokumentieren die geldwerten Möglichkeiten und den Erfolg der verkäuferischen Tätigkeit. Auch hier wird ein Anfangsbestand benötigt, der die gerade im Ablauf befindlichen Vorgänge und meist auch historische Daten in Salesforce.com vorhält. Wenn Salesforce.com auch vornehmlich Verkauf und Marketing unterstützt, so sind dort auch Zahlen versammelt, die die betriebswirtschaftliche Steuerung des Unternehmens unterstützen können und somit auch für andere Personengruppen aus Management und Controling von Interesse sind. In unseren Projekten haben wir beobachten können, dass die leidenschaftlich ausgefochtenen Themen beim Initial Load im Bereich Kunden-, Kontakt-, Aktivitäten-Daten lie-

54


Probleme des Initial Load

gen, während im späteren Betrieb die Auftragsdaten im weitesten Sinne an Bedeutung gewinnen. Das Management und Controlling hat die Möglichkeiten von Salesforce.com erkannt und wirft Fragen auf, warum die aus Salesforce.com gewonnenen aggregierten Daten nicht bis auf zwei Stellen hinter dem Komma mit denen aus der Buchhaltung übereinstimmen und dergleichen. Welche weiteren Daten für den Initial Load wichtig sind, hängt natürlich weitgehend davon ab, was das betreffende Unternehmen verkauft oder produziert. Aber wichtig sind oft: 쮿

Vertrags-Dokumente (DOC, PDF, ...)

쮿

Auftragsplanungs-Daten (Budgetierung, Erfolgskontrolle)

쮿

Kategorisierungen je nach benötigten Auswertungen

쮿

usw.

3.2


Ist abschließend festgelegt, welche Daten im Salesforce.com beim Start vorhanden sein müssen, heißt das noch lange nicht, dass sie tatsächlich geladen werden können. Tatsächlich ist der Prozess, der schließlich zur Identifikation der Daten führt, die nach Salesforce.com geladen werden können und sollen, ein recht langwieriger. Er macht nach unserer Erfahrung ca. 75% der Zeit aus, die man für den Initial Load ansetzt. Dieser Prozess ist eine Art „Crash-Kurs“ in Sachen „die eigenen Daten kennenlernen“. Wir haben erlebt, dass neue Mitarbeiter im Unternehmen (und gerade neue Mitarbeiter kommen oft mit der Idee, Salesforce.com einzuführen) diese Phase benutzen, um Daten und Abläufe kennenzulernen oder besser zu verstehen. Das ist an sich sehr positiv, belastet aber das Zeitbudget bei der Einführung. Da dieser Punkt so wichtig und zeitaufwendig ist, sind wir in unseren Projekten, in denen wir Unternehmen beim Initial Load von Salesforce.com unterstützen, dazu übergegangen, die Validierungs-Phase bewusst mit einem erheblichen Aufwand anzusetzen. Gleichzeitig versuchen wir aber mit maschineller Unterstützung und speziellen Analyseprogrammen, möglichst effektiv voranzukommen. Wie man diese Zeit reduzieren kann, wird noch ausgeführt werden. Im Folgenden wird die Problematik unter verschiedenen Aspekten beleuchtet.

3.2.1

Datenaktualität

Die zu ladenden Datenbestände stammen oft aus recht alten Systemen: Dort hat sich im Lauf der Jahre (oder Jahrzehnte) einiges angesammelt. Befinden sich z.B. die Kontaktdaten, d.h. Daten über Personen, in einem solchen System, ist die Wahrscheinlichkeit groß, dass ein großer Teil von ihnen unbrauchbar ist. Und es ist schwierig, in wirtschaftlich vertretbarer Weise zu ermitteln, was aktuelle Bestände sind und was nicht. Es kann hinzukommen und ist sogar wahrscheinlich, dass solche Systeme vom Hersteller nicht mehr unterstützt werden und kaum jemand sich mit deren Interna auskennt. Oft sind nur rudimentäre Dumps möglich, an die man dann mittels anderer Applikationen die Fragen stellt, die bei der Aktualitätsbestimmung helfen.


55


3 – Initial Load

3.2.2

Datenqualität

Erfahrungsgemäß schlägt bei der Portierung von Daten von einem System in das andere die Stunde der Wahrheit. Hier stellt sich heraus, ob die Daten aus der Quelle die Qualität aufweisen, die man im neuen System gerne sehen würde, zumindest am Anfang. Eindeutigkeit – Zunächst ein Beispiel: Für das Laden sei eine Datei mit allen relevanten Kundenmerkmalen vonnöten, die auch eine eindeutige Kunden-Id (Kundennummer) beinhaltet. Eine Analyse zeigt, dass es mehrere Kunden-Ids gibt, die mehrfach vorkommen. Das kann zum einen daran liegen, dass der Query an das Quellsystem fehlerhaft war, aber auch daran, dass die Daten dort schon falsch sind. Diese Problematik taucht bei allen Dateien auf, in denen eindeutige Schlüsselbegriffe nötig sind, also vorzugsweise Stammdaten wie Kunden, Artikel, aber auch Parameterdateien wie Zahlungs- und Liefer-Konditionen-Schlüssel und dergleichen. Auch Flussdaten, insbesondere Aufträge und Lieferscheine, müssen in der Regel eine eindeutige Identifikation haben. Diese eindeutigen Schlüssel sind in Salesforce.com, wie auch in anderen CRM-Systemen nötig, um (insbesondere bei Batch-Abläufen) Objekte (z.B. einen Account) auffinden zu können mit dem Zweck, Änderungen in den Daten vorzunehmen oder sie zu löschen. Hier streifen wir das Thema des periodischen maschinellen Datenabgleichs, das in einem späteren Kapitel noch genauer erläutert wird. Datendomänen – Hier geht es zum einen darum, welche Arten von Daten in bestimmten Datenfeldern enthalten sein dürfen. In bestimmten Feldern (z.B. Umsatzbeträgen) dürfen nur Zahlen enthalten sein, manchmal mit, manchmal ohne Dezimalstellen, nur positiv oder auch negativ. Oder es muss ein Datum, eine gültige E-Mail enthalten. Zum anderen ist manchmal festgelegt, dass ein Feld nur bestimmte Inhalte aufweisen darf, zum Beispiel in der Anrede nur „Herr“ oder „Frau“ oder in einem Status-Feld „aktiv“ oder „inaktiv“. Das würde in Salesforce.com über eine Pickliste bzw. ein boolesches Feld dargestellt. Erfahrungsgemäß genügen für den Initial Load angelieferte Daten fast niemals den gewünschten Regeln; zumindest sind sie oft einfach leer, was die Frage aufwirft, was ein leeres Feld bedeutet. Gerade in alten Datenbeständen herrscht da oft ein ziemlicher Wildwuchs. Hier ein (eher harmloses) Beispiel, was sich in einem Anrede-Feld befinden kann (diese Ausgabe wurde mit einem Analyseprogramm erzeugt): Anrede

Häufigkeit

... (empty or spaces) ...

19482

e

1

F

227102

H

365889

Tabelle 3.1: Häufigkeit von Feldinhalten am Beispiel

56



Das „e“ ist wohl ein Ausreißer, und bei gut 612 000 untersuchten Datensätzen sind knapp 20 000 Leerfelder nicht viel; aber trotzdem wäre zu klären, wenn im Salesforce.com die Anrede nur mit „Herr“ oder „Frau“ gefüllt werden darf, wie hier zu verfahren ist. Etwas schwieriger wird es bei dieser Liste von vorgefundenen Schlussfloskeln: Best regarrds Kind regards MFG Mit freundlichen Grüßen Mit freundlichen Grüßen, Regards With best regrads regards s mit freundlichen Grüßen with best regards mit freundlichen Grüssen Mit freundlichen Grüssen Sincerely yours With kind regards Best regards, Yours sincerely Best regards With best regards, Mit freundlichen Grüßen With best regards

Hier wird man um eine Datenbereinigung nicht herumkommen, sei es, dass sie in den Quelldaten korrigiert werden, sei es, dass die Konvertierprogramme die Umschlüsselung vornehmen. Referentielle Integrität – Das oben erwähnte Problem der Eindeutigkeit verschärft sich, wenn Daten aufeinander verweisen. Nehmen wir als Beispiel eine Datei mit Auftragsköpfen, die in einem Feld eine Kundennummer enthält. Will man solche Daten korrekt nach Salesforce.com laden, muss sichergestellt sein, dass es alle Kunden auch gibt, auf die in den Aufträgen verwiesen wird. Hier haben wir ein Beispiel, wo in Kundendaten mittels Kundennummer ein Verweis auf einen anderen Kunden zu finden ist (nämlich den in der Kundenhierarchie übergeordneten Kunden), dieser aber nicht bekannt ist. Auch hier wurde das Ergebnis maschinell ermittelt:


57


3 – Initial Load

Unbekannte Verweise

Kunde

194900

Nestlé Deutschland AG

604000

Coca-Cola Erfrischungsgetränke AG

604000

Coca-Cola GmbH, Hpt. Verw.

708200

Deutsche Autoleasing GmbH

882800

Hewlett-Packard Holding GmbH

Tabelle 3.2: Unbekannte Verweise am Beispiel

Wie kann es zu so etwas kommen? Gründe können sein: 쮿

die Daten sind tatsächlich fehlerhaft,

쮿

fehlerhafter Export aus einem anderen System,

쮿

übergeordnete Kunden befinden sich in einem anderen System,

쮿

Daten wurden archiviert, aber nicht korrekt zeitlich abgegrenzt,

쮿

...

3.2.3

Heterogene Quellen

Besondere Sorgfalt erfordert die Vorbereitung des Initial Load, wenn Datenbestände aus verschiedenen Quellen nach Salesforce.com konsolidiert werden sollen. Fallstudie – In einem unserer Projekte kamen die Kunden- und Kontaktdaten aus drei verschiedenen Systemen mit unterschiedlichen Kundennummern. Nennen wir die drei Systeme „A“, „B“ und „C“. Im Hintergrund steht noch ein System „D“, das seine Daten in einem nächtlichen Abgleich nach „A“ liefert (leider nicht zuverlässig). „A“ ist das Buchhaltungs-System; dort entstehen die Fakturen. „B“ ist ein System, das eher der Verkaufssteuerung dient, aber auch auf Daten von „A“ angewiesen ist. „C“ ist ein sehr altes System, das vom Hersteller nicht mehr gepflegt wird und mit dem sich nur ein Mitarbeiter in der IT auskennt; es steht unter Verdacht, viele Karteileichen zu enthalten. Alle Systeme beziehen sich auf den gleichen Kundenstamm, haben jedoch für denselben Kunden eine jeweils unterschiedliche Kunden-Nummer. Es ist jedoch nicht sichergestellt, dass Kunden aus System „C“ auch in „A“ und „B“ vorhanden sein müssen. Kunden in „B“ sollten auch in „A“ zu finden sein. In Salesforce.com sind die Kundennummern aus System „A“ maßgeblich; sie sollen im Salesforce.com-Objekt „Account“ als „AccountNumber“ eingetragen werden.

58



Die Aufgabenstellung war nun, 쮿

Daten von Kunden und zugehörigen Kontakt-Personen aus den System „B“ und „C“ zu extrahieren,

쮿

die Kunden in „A“ zu identifizieren, zu denen sie gehören, und

쮿

daraus konsistente, bereinigte Daten zusammenzustellen, die nach Salesforce.com geladen werden können.

Die Daten lagen als drei CSV- bzw. Excel-Dateien vor: 쮿

„A“: ~ 10 000 Sätze – 1.5 MB; pro Kunde ein Satz; keine Ansprechpartnerdaten

쮿

„B“: ~ 10 000 Sätze – 1.5 MB; pro Kunde ein Satz, dort auch Ansprechpartnerdaten

쮿

„C“: ~ 615 000 Sätze – 350 MB(!); pro Ansprechpartner ein Satz; ggf. mehrere Ansprechpartner zu einem Kunden

Abbildung 3.1: Ablauf bei heterogenen Datenquellen


59


3 – Initial Load

Wie in der Abbildung 3.1 gezeigt: 쮿

werden die Datenbestände „C“ und „B“ durchforstet,

쮿

im Abgleich verschiedene Versuche unternommen, in „A“ bzw. auch „B“ die Kunden zu finden (die, wie bereits gesagt, andere Kundennummernkreise haben, die sich aber nach einem Algorithmus ineinander überführen lassen),

쮿

(wenn das nicht gelingt, wird dieser Tatbestand in einen Fehlerbericht eingetragen) dann werden

쮿

die „guten“ Daten zusammengeführt,

쮿

jeweils in Zwischendateien gleichen Aufbaus („Kunden+Kontakte“) gespeichert,

쮿

zu einer Datei zusammengemischt, und schließlich

쮿

in die Datei „konsolidierte Kunden+Kontakte“ weggeschrieben.

Hier sei – als Zwischenresümee – festgehalten: 쮿

Dieser Prozess ist iterativ (in unserem Projekt wurde er viermal durchlaufen), weil die Algorithmen verfeinert, Fehler in den ursprünglichen Daten („A“, „B“, „C“) korrigiert und auch Fehler in den Abgleichprogrammen beseitigt werden mussten.

쮿

Bisher wurde kein einziges Byte nach Salesforce.com geladen, d.h., wir sind immer noch in der Phase der Validierung; der Prozess des eigentlichen Initial Load wird weiter unten beschrieben.

쮿

Wenn man als IT-Spezialist mit der Aufgabe des Initial Load betraut ist, ist gerade hier eine Phase regen Austausches mit Nicht-IT-Leuten erforderlich; denn wer sollte sonst besser die Datenqualität beurteilen können?

쮿

Schließlich ist klar, dass Verarbeitungen wie: 왘 Bearbeitung großer Datenmengen, 왘 Lookups in andere Datenbestände, 왘 visueller Direkt-Zugriff auf erzeugte Dateien, damit man das Resultat schnell und

sicher beurteilen kann, 왘 Ad-hoc-Auswertungen des Resultats,

in dem Maße effektiv durchgeführt werden können, wie man über dafür spezialisierte Software verfügt; wir können in unseren Projekten glücklicherweise darauf zurückgreifen, doch dazu mehr im 9. Kapitel.

3.2.4

Qualitative Abgrenzung

In engem Zusammenhang mit dem oben erläuterten Problem der referentiellen Integrität steht die Frage, wie ich die Datenbestände, die zu übernehmen sind, qualitativ abgrenze. Fast immer will man Historien-Daten mit übernehmen, die sich aber in Archiven befinden. Und wenn sich zum Beispiel historische Auftragsdaten und historische Kunden-

60



daten in verschiedenen Archiven finden, ist die „Chance“ nicht schlecht, dass der Zeitpunkt, ab wann archiviert wurde, sich bei beiden unterscheidet, insbesondere, wenn diese Daten in verschiedenen Systemen archiviert wurden. Das kann dann im konkreten Fall dazu führen, dass man alte Aufträge nach Salesforce.com laden will, aber die Kunden dazu nicht mehr auf einfache Weise findet. Ein anderes Problem, das in diese Rubrik gehört: Nehmen wir an, dass wir Produkte aus verschiedenen Systemen zusammenführen müssen. Da muss entschieden werden, ob man bei der Konsolidierung die Produktdaten additiv oder integrativ zusammenführen soll, d.h. man davon ausgehen kann, dass es sich jeweils um verschiedene oder die gleichen Produkte handelt oder je nachdem. Integration – In diesem Fall muss – wie oben in der Fallstudie anhand von Kunden- und Kontaktdaten aufgezeigt – ein Konsolidierungs-Algorithmus gefunden werden. Addition – Hier dagegen ist zu entscheiden, was in Salesforce.com die eindeutige Artikelnummer werden soll. Oder ob man überhaupt auf einer eindeutigen Artikelnummer aus Sicht von Salesforce.com bestehen kann. Dann muss man auf jeden Fall sicherstellen, dass es eine Regel für den Zugriff im Salesforce.com gibt, um einen Artikel sicher eindeutig zu identifizieren. Ein Beispiel: 쮿

in einem Unternehmen kommen die Artikel aus drei verschiedenen ERP-Systemen

쮿

eine Eindeutigkeit der Artikelnummer ist nicht gewährleistet

In einem solchen Fall legen wir im Salesforce.com-Objekt „Product2“ ein CustomField an, z.B. „ERP__c“, das immer mit gefüllt wird, wenn Produkte in Salesforce.com neu erzeugt werden. Über einen Salesforce-Query a la select Id, Name, ProductCode from Product2 where ProductCode = “4711" and ERP__c = “SAP"

kann man dann das Produkt sicher finden.

3.2.5

Quantitative Abgrenzung

Da 쮿

es in Salesforce.com eine Mengenbegrenzung der Daten gibt und man für größere Datenmengen entsprechend mehr Geld zahlen muss und

쮿

bei sehr großen Datenmengen sich die Zugriffszeiten verschlechtern,

muss man sich stets Gedanken machen, in welchem Umfang Daten in Salesforce.com eingeladen werden sollen.


61


3 – Initial Load

Tatsächlich benötigte Daten – Unter diesem Gesichtspunkt sollte überprüft werden, welche Daten wirklich in Salesforce.com benutzt (und geladen) werden: je weniger je besser: 쮿

Muss man wirklich drei Preise im Artikel haben mit 5 Währungen? Das führt zu 15 PricebookEntries!

쮿

Müssen wirklich historische Aktivitäten bis auf E-Mail-Inhalte herunter im Zugriff sein?

쮿

Reicht bei Dokumenten nicht manchmal ein Hinweis, wo sie zu finden sind, ohne dass ein Online-Zugriff heraus aus Salesforce.com möglich ist

쮿

....

Historie – Wie weit sollen Historiendaten zurückreichen? Zukunft – Mit welchen Datenmengen rechnen wir?

3.2.6

Lade-Programme

Für den Initial Load müssen Programme geschrieben und/oder entsprechende Tools parametriert werden. In unseren Projekten führen wir den unmittelbaren Austausch mit Salesforce.com grundsätzlich mit einem Utility-Programm durch, das 쮿

entweder eine CSV-Datei liest und über das Apex API nach Salesforce.com übermittelt

쮿

oder umgekehrt Daten aus Salesforce.com ausliest und als CSV-Datei zur Verfügung stellt, ähnlich wie der Sforce Data Loader.

Die oben genannten Lade-Programme benutzen also niemals direkt das API zu Salesforce.com, sondern erzeugen Text-Dateien für das genannte Utility-Programm bzw. verarbeiten von dem Utility-Programm erzeugte Dateien. Das hat den Vorteil, dass man Daten, die nach Salesforce.com geladen werden sollen, zwecks visueller Überprüfung einfach in einen Text-Editor oder nach Excel laden kann. Die Aufgaben der eigentlichen Lade-Programme sind im Wesentlichen: 쮿

Lesen der Import-Daten + Erzeugung einer Lade-Datei für Salesforce

쮿

Umschlüsseln von Feldern nach vereinbarten Regeln

쮿

Zugriff auf weitere („Lookup“-)Dateien, wenn man z.B. Salesforce-IDs mit in die Lade-Datei bringen muss.

Ansonsten hängen weitere Aufgaben der Lade-Programme natürlich davon ab, mit welchen konkreten Datenbeständen und Anforderungen man es zu tun hat.

62



3.3


Wenn alle Import-Daten in gewünschter Qualität vorhanden sind, kann der eigentliche Initial Load stattfinden. Eines vorweg: Die Erfahrung hat uns gezeigt, dass ein Initial Load mindestens zweimal stattfindet, eher öfter, da die visuelle Prüfung der Ergebnisse des Lade-Vorgangs in Salesforce.com oft Fehler zeigt, die bisher nicht aufgefallen sind. Schauen wir uns folgendes Beispiel an:

Abbildung 3.2: Zielschema in Salesforce

Die in Abbildung 3.2 gezeigten Salesforce.com-Objekte sollen mit Daten befüllt werden. Die notwendigen Daten stehen in Form von vier CSV-Dateien bereit. Als Resultat sollen sich im Salesforce.com befinden: 쮿

die Kundendaten („Account“)

쮿

die Artikeldaten („Product2“)

쮿

die Auftragsköpfe („Opportunity“); mit Verweisen auf den zugehörigen Kunden

쮿

die Auftragspositionen („OpportunityLineItem“); mit Verweisen auf die zugehörigen Artikel und Auftragsköpfe

In diesem Beispiel wird nicht berücksichtigt, dass zu neuen Product2-Objekten noch jeweils Preisbucheinträge geladen werden müssen.


63


3 – Initial Load

Der Ladeprozess wird dann wie in Abbildung 3.3 aussehen:

Abbildung 3.3: Schema des Ladeprozesses

Im Einzelnen soll Folgendes geschehen: 쮿

Kundendaten in „Account“-Objekte laden.

쮿

Artikeldaten in „Product2“-Objekte laden.

쮿

Aus Salesforce.com zwei Dateien extrahieren, die für alle Kunden bzw. Artikel die Nummer plus Salesforce-ID enthalten; Letztere wird beim Laden automatisch erzeugt.

쮿

Laden der Auftragsköpfe (mit den Salesforce-IDs der zugehörigen Kunden) in „Opportunity“-Objekte.

쮿

Aus Salesforce.com eine Datei extrahieren, die für alle Auftragsköpfe die Nummer plus Salesforce-ID enthält; Letztere wird beim Laden automatisch erzeugt.

쮿

Laden der Auftragspositionen (mit den Salesforce-IDs der zugehörigen Aufträge und Produkte) in „OpportunityLineItem“-Objekte.

64



Zusammenfassend gesagt ist der Prozess des Initial Load eine Art (Batch-)Dialog mit Salesforce.com: 쮿

Daten werden hochgeladen,

쮿

zweispaltige Listen mit Nummer und Salesforce-ID werden extrahiert,

쮿

zu ladende weitere Daten werden bei Bedarf um diese Salesforce-IDs angereichert und

쮿

diese werden dann ihrerseits an Salesforce.com übergeben.

3.4


Im Folgenden soll an einem einfachen Beispiel gezeigt werden, wie ein solcher Initial Load abläuft. Es stehen Kontakt-Informationen auf einer CSV-Datei zur Verfügung, die nach Salesforce.com in Objekte des Typs Lead geladen werden sollen. Diese Datei sieht etwa so aus: "LastName","FirstName","Company","Street","City","PostalCode", "Phone","Email" "Meier","Franz","@@test_lead_company@@","","","","", [email protected] "Schulz","Günter","@@test_lead_company@@", "Bahnhofstr. 1","Frankfurt/M","60123" ... "","Guido","@@test_lead_company@@", "Mühlweg 234","München","88888","",""

In der ersten Zeile befinden sich die Feld-Namen aus dem Salesforce-Lead-Object, in die die Daten geladen werden sollen; ab der zweiten Zeile folgen die eigentlichen Daten. Die zweite Datenzeile ist hier aus Darstellungsgründen gekürzt, ist in der Datei selbst aber mit weiteren Daten gefüllt. Diese Datei kann von der Buchseite, aus dem Internet geladen werden [AR01]. Zum Laden kommt ein freies Tool namens Sforce Data Loader (SDL) zur Anwendung, dessen Gebrauch schrittweise erklärt wird. Man kann es aus dem Internet herunterladen [SDL]. SDL beinhaltet einen Wizard, der den Anwender dabei unterstützt, den Ladevorgang auf den Weg zu bringen, und eine Rückmeldung über Erfolg bzw. Misserfolg liefert.


65


3 – Initial Load

Zunächst erscheint nach dem Aufruf des SDL die Startmaske:

Abbildung 3.4: Aufruf des Sforce Data Loader

Nach Drücken von INSERT ist die Login-Maske zu sehen:

Abbildung 3.5: SDL: Login

66



Nach Eingabe der Login-Daten und Drücken von LOG IN kommt – sofern die Anmeldung erfolgreich war – die Rückmeldung „Login completed successfully“, der Button NEXT wird anwählbar und man kann weitergehen.

Abbildung 3.6: SDL; Dateiauswahl

Nach Auswahl des Salesforce.com-Objekts „Lead“ und Drücken des BROWSE-Buttons öffnet sich ein Fenster, in dem man den Pfad zur Lade-Datei (das ist die oben beschriebene CSV-Datei) angeben kann. Es ist eine Rückmeldung zu bestätigen:

Abbildung 3.7: SDL: Rückmeldung, was geladen wird

Nun sind die Angaben zum Mapping zu machen.


67


3 – Initial Load

Abbildung 3.8: SDL; Mapping Teil 1

Man drückt in der linken Maske CREATE OR EDIT MAP, anschließend AUTO-MATCH FIELDS TO COLUMNS und OK in der rechten. Als Bestätigung erscheint die Maske mit dem ausgefüllten „Current Field Mapping“:

Abbildung 3.9: SDL; Mapping Teil 2

68



Nach NEXT geht es weiter wie folgt:

Abbildung 3.10: SDL: Festlegen, an welche Position die Ergebnis-Dateien geschrieben werden sollen

In der oben gezeigten Maske wird erfragt, in welchem Verzeichnis die Ergebnis-Dateien erzeugt werden sollen. Zum Verständnis: Das Utility SFD erzeugt immer zwei AusgabeDateien, deren eine alle erfolgreich geladenen Sätze aufnimmt und deren zweite die abgewiesenen Sätze enthält inklusive einer neuen Spalte, in der der Ablehnungsgrund steht. Nach FINISH erfolgt eine letzte Sicherheits-Abfrage:

Abbildung 3.11: SDE: Sicherheitsabfrage vor dem Start

Das Laden beginnt nach der Bestätigung sofort. Bei größeren Eingabe-Dateien wird eine Fortschrittsanzeige ausgegeben und ständig aktualisiert. Im vorliegenden Beispiel kommt sofort die Bestätigungsmeldung:

Abbildung 3.12: SDL; Ergebnisanzeige


69


3 – Initial Load

Nun kann man die oben erwähnten Resultat-Dateien (im Excel-Look) anschauen. Da in diesem Falle von drei Sätzen zwei abgewiesen wurden, ist es sicherlich interessant, VIEW ERRORS zu drücken:

Abbildung 3.13: SDE; Beispiel einer Fehlerdatei

Aus layout-technischen Gründen sind nur die letzten Spalten angezeigt. Zwei Fehler wurden erkannt: 쮿

Die E-Mail-Adresse guenter@[email protected] wurde nicht akzeptiert.

쮿

Das Pflichtfeld „LastName“ war leer.

An diesem einfachen Beispiel sollte dargelegt werden, wie man tatsächlich die Daten in Salesforce.com hineinbringt und mit welchen Reaktionen auf „schlechte“ Daten man rechnen muss.

3.5

10 Tipps zum Initial Load

3.5.1

Administrator-Rechte

Sorgen Sie dafür, dass der Salesforce.com-Benutzer, unter dem Sie die Daten laden, über Administrator-Rechte verfügt; ist das nicht der Fall, kommen Sie unter Umständen in Salesforce.com an Daten nicht heran, die Sie benötigen.

3.5.2

Scripte

Alles, von dem Sie denken, dass Sie es nur einmal machen müssen, müssen Sie dann doch mehrfach machen (Murphys Gesetz). Daher sollten Sie sich die Zeit nehmen und ein Script (auf Windows: eine BAT-Datei) zusammenstellen, das (als eine Art „Workflow“) die verschiedenen Ladeprogramme in der nötigen Reihenfolge aufruft. Anders gesagt: Man sollte sich nicht auf den händischen Start der verschiedenen Verarbeitungsschritte verlassen. Denn ein Script zahlt sich aus, weil 쮿

jeder „endgültige“ Initial Load mindestens zweimal stattfindet und

쮿

ein erprobtes Lade-Script davor bewahrt, komplizierte Abfolgen schlicht zu vergessen.

70



3.5.3

„Fingerabdruck“

Hinterlassen Sie in allen wichtigen Objekten beim Laden einen „Fingerabdruck“. Wir benutzen bei unseren Projekten ein 20 Byte langes (unsichtbares) Textfeld namens „flag__c“, das von jedem unserer Lade-Programme nach dem Schema „XXXyyyymmddhhss“ mit Datum und Uhrzeit des Ladebeginns gefüllt wird, also z.B. mit „LOD20061210153320“. Das erleichtert die Identifizierung von Objekten, die in unserem Ladeprozess erzeugt oder geändert wurden, und hilft damit bei der Fehlersuche, beim Löschen vor einem weiteren Load und nebenbei auch bei der Suche von Verantwortlichen für falsche Daten.

3.5.4

Preisbucheinträge

Wenn Sie neue Produkte laden („Product2“), vergessen Sie nicht, dass Sie gleichzeitig Preisbucheinträge erzeugen müssen. Andernfalls haben End-Benutzer keinen Zugriff auf Produkte. Das Laden eines Artikels sieht daher fast immer so aus: 쮿

laden Product2

쮿

generierte ID von Salesforce.com holen

쮿

Salesforce-IDs der relevanten Preisbücher holen (das Standard-Pricebook muss immer dabei sein)

쮿

Laden der Pricebook-Entries, pro Kombination von Produkt, Preisbuch und Währung einen Eintrag

Beispiel einer Loader-Datei für „PriceBookEntries“:

Abbildung 3.14: PricebookEntry-Ladedatei

3.5.5

Account OwnerId

Wenn Sie Kunden („Account“) laden, klären Sie frühzeitig ab, welcher Benutzer als „OwnerId“ eines Kunden einzutragen ist; wird das versäumt, kann es dazu kommen, dass die Anwender am Bildschirm Kunden nicht sehen können, die sie eigentlich sehen sollten.


71


3 – Initial Load

3.5.6

Importdaten archivieren

Archivieren Sie die zum Import angelieferten Daten sowie Reports, die gegebenenfalls bei der Validierung erzeugt worden sind. Das hilft, wenn man Ladevorgänge wiederholen muss, und auch bei Streitigkeiten, ob die angelieferten Dateien tatsächlich enthielten, was sie enthalten sollten.

3.5.7

Validieren. Validieren. Validieren.

Validieren Sie die Daten, bevor sie diese laden. Nehmen Sie sich dazu viel Zeit: Sie können dadurch die Wahrscheinlichkeit senken, dass der Ladeprozess wiederholt werden muss. Und – wie oben erwähnt – je besser die Eingabedaten validiert sind, desto besser wird die Qualität der geladenen Daten, desto höher die Zufriedenheit der End-Anwender.

3.5.8

Lade-Programme erst spät schreiben

Schreiben Sie die Lade-Programme erst, wenn der Validierungsgrad der Daten hoch ist. Es ist insgesamt aufwendiger, Änderungen in schon geschriebenen Programmen durchführen zu müssen, als wenn man vorher mehr Zeit darauf verwendet, die notwendigen Algorithmen abzuklären.

3.5.9

Lade-Programme für periodischen Abgleich vorbereiten

Schreiben Sie die Initial-Lade-Programme so, dass man sie auch für den periodischen Datenabgleich benutzen kann. Das kostet zwar ein wenig mehr Entwicklungszeit, entlohnt Sie aber damit, dass Sie sich gegebenenfalls Entwicklung und Wartung eines weiteren Programms sparen. Was ist damit gemeint? Beim periodischen Abgleich führen die Abgleichdaten entweder zur Änderung eines bestehenden oder zur Erzeugung eines neuen Salesforce.com-Objekts, zum Beispiel einem Account. Der Initial Load kann als Spezialfall des Datenabgleichs betrachtet werden, bei dem die Salesforce.com-Datenbank leer ist, also z.B. noch keine Account-Objekte enthält. Das Lade-Programm erzeugt dann stets Daten, die zu neuen Accounts führen. Diese beiden Fälle (Änden oder Erzeugen) will das Apex API von Salesforce.com unterschiedlich behandelt wissen, was auch verständlich ist: denn bei einem Update eines bestehenden Accounts müssen Sie die Salesforce-ID des betreffenden Accounts mitgeben, andernfalls dürfen Sie keine Id angeben. Folgt man der Logik, die wir unter 3.2.6 für Ladeprogramme dargelegt haben und auch empfehlen, würde das Lade-Programm zwei CSV-Dateien zu erzeugen haben, die dann von dem Utility-Programm in zwei Aufrufen geladen werden, nämlich die Datei mit den neu zu erzeugenden Accounts und die Datei mit den zu ändernden Accounts.

72



Wenn man nun ein Lade-Programm von vornherein in die Lage versetzt, zu unterscheiden, was Änderungen an bestehenden Kunden bzw. Daten für neue Kunden sind und ggf. zwei Dateien auszugeben, hat man zwei Fliegen mit einer Klappe geschlagen. Die Information, ob ein Account schon existiert, kann leicht mittels eines Query aus Salesforce.com in Form einer einfachen Datei mit zwei Spalten gewonnen werden, zum Beispiel wie folgt: "ID","AccountNumber" "00120000003racRAAQ","203875" "00120000003sVMAAA2","093734" "00120000003sakDAAQ","108625" ...

Diese Datei kann das Lade-Programm leicht beauskunften, indem es schaut, ob ein Eintrag für eine konkrete AccountNumber vorliegt. Wenn ja, ist es ein Update, sonst ein Create. Und für den Initial Load ist diese Datei einfach leer bzw. hat nur die erste Zeile.

3.5.10 Kein direkter API-Zugriff im Lade-Programm Vermeiden Sie es, in Lade-Programmen direkt auf das Apex API von Salesforce.com zuzugreifen. Überlassen Sie das dem Sforce Data Loader oder einem gesonderten Utility (siehe Kapitel 9). Das hat den großen Vorteil, dass man die Daten, unmittelbar bevor sie nach Salesforce.com geladen werden sollen, für Testzwecke zwecks visueller Überprüfung einfach in einen Text-Editor oder nach Excel einlesen kann.


73



4 4.1

Anwendungen mit dem Apex Builder – Grundlagen

Apex Builder im Überblick

Apex an sich stellt eine Plattform für die Entwicklung datenzentrierter Anwendungen dar. Hierbei werden verschiedene Herangehensweisen unterstützt. In diesem Kapitel wird die Entwicklung von benutzerdefinierten Anwendungen auf Basis des Apex Builder vorgestellt. Ähnlich der Anpassung der vorhandenen Anwendungen wie zum Beispiel „Sales“ wird der in Salesforce.com integrierte Builder zur Entwicklung von neuen Komponenten und der Zusammenfassung zu einer Anwendung genutzt. Die so entwickelten Anwendungen werden auch als „native Anwendungen“ bezeichnet. Hiermit wird beschrieben, dass diese ausschließlich durch die Metadaten beschrieben sind und keine Beziehungen zu anderen Anwendungen haben oder das interne Salesforce API benutzen. Solche Anwendungen können vollständig mit dem visuellen Apex Builder entwickelt werden. Die Entwicklung einer benutzerdefinierten Anwendung unter Salesforce.com unterliegt dabei verschiedenen Konzepten, welche maßgeblich von der datenzentrierten Herangehensweise bestimmt werden. Die benutzerdefinierten Anwendungen selber werden vollständig auf der Apex-Plattform ausgeführt und benötigen keinen externen Service, Hard- und Software oder irgendeine Form von Infrastruktur, selbst wenn diese von sehr vielen Anwendern gleichzeitig genutzt werden. Eine erste Limitierung ergibt sich jedoch aus der Vorgabe, aus den „Blue Prints“, die implizit hinter einer solchen Herangehensweise liegen. So ist eine unbegrenzte Anpassung der vorhandenen Artefakte möglich, sollte jedoch zum Beispiel ein spezieller Feldtyp oder eine spezielle Form von BusinessLogik nicht durch die Apex-Plattform definiert sein, kann diese auch nicht verwendet werden. Metadaten getrieben – Mit dem von Metadaten getriebenen Ansatz wird eine vollständige Anwendung mit Hilfe von deklarativen Constraints beschrieben. Die vom Entwickler definierten Constraints wiederum setzen auf vorhandene Beschreibungen auf. So sind bei der Beschreibung neuer Objekte lediglich die Angabe der Metadaten des Objektes und die Feldinformationen notwendig. Wie das Objekt gespeichert, wo Datensätze abgelegt werden oder wie die grundlegende Struktur eines solchen Objektes definiert ist, liegt außerhalb der Kenntnis des Entwicklers. Datenzentrierter Ansatz – Anwendungen, welche mit dem Apex Builder entwickelt werden, sind datenzentriert. Das bedeutet, das gesamte Design der Anwendung wird um die einzelnen Datenobjekte herum angelegt. Die Entwicklung startet demzufolge mit der Definition der zu erfassenden Daten und ihrer Gruppierung zu Datenobjekten. Das kann zum Beispiel ein Adressobjekt mit den typischen Feldern Stadt, Postleitzahl und Straße sein. Zwischen den einzelnen Datenobjekten können weiterhin Beziehungen gebildet werden. So ist es möglich, komplexere Datenstrukturen abzubilden.


75


4 – Anwendungen mit dem Apex Builder – Grundlagen

Kein Quelltext – Bei der Entwicklung einer Salesforce.com-Anwendung ist kein Quelltext im herkömmlichen Sinne notwendig. Alle Artefakte und Eigenschaften werden deklarativ über den Apex Builder beschrieben. Die dadurch entstandenen Metadaten beschreiben gleichzeitig die Anwendung und werden auch zur Laufzeit genutzt. Visuelle Definition der Benutzeroberfläche – Ähnlich der Beschreibung der benutzerdefinierten Objekte mit Hilfe von Metadaten lassen sich auch ganze Benutzeroberflächen beschreiben. Eine Eigenschaft einer solchen Herangehensweise ist, dass alle Oberflächen ein ähnliches grundsätzliches Aussehen haben. In datenzentrierten Anwendungen hat dies den Vorteil, dass man sich relativ leicht auch in neuen Bildschirmmasken zurechtfindet und diese fast sofort intuitiv nutzen kann. Ein Vorteil der Arbeit mit dem Apex Builder ist, dass selbst komplexe und detailreiche Anwendungen mittels einem einfachen „Point und Click“ entwickelt werden können. Der Zugriff auf den Quelltext wird dabei nicht benötigt. Dies ermöglicht die Entwicklung von Anwendungen auch für Leute, welche nicht über detailliertes Wissen von Programmiersprachen verfügen. Erfahrenen Entwicklern hilft es bei der Programmierung von Anwendungen, die Produktivität wird erhöht. Limitierungen ergeben sich aus dieser Herangehensweise in der Form, das alle Artefakte und Möglichkeiten vorher durch die Apex-Plattform definiert werden müssen. Entwickler können den zugrunde liegenden Quelltext nicht ändern. Zum Beispiel kann nicht geändert werden, wie Seiten dargestellt werden oder wie die Daten physisch gespeichert werden. Oft ist diese Limitierung jedoch auch vorteilhaft. Verschiedene Anwendungen haben von natur aus ein ähnliches Aussehen und Verhalten. Möchten Sie sich einen Überblick über die Möglichkeiten der Entwicklung von Salesforce.com-Anwendungen verschaffen, kann mit diesem Kapitel begonnen werden. Hier finden Sie alle Artefakte, ihre Beschreibung und Möglichkeiten zum Einsatz und zur Anpassung. Mit Hilfe dieses Wissen können Sie anfangen, eine eigene Anwendung zu planen und zu entwickeln. Am Ende des Kapitels finden Sie Hinweise und Tipps, welche Ihnen möglicherweise bei der täglichen Arbeit helfen werden. Wenn Sie jedoch lieber erst einmal von einer funktionierenden Anwendung ausgehen möchten, kann mit dem nächsten Kapitel begonnen werden. Im nächsten Kapitel wird eine Issue-Tracking-Anwendung von Grund auf gebaut, in Betrieb genommen und genutzt. Ausgehend von dem funktionierenden Beispiel können Sie im Anschluss weitere Ergänzungen vornehmen.

4.2

Bestandteile einer Anwendung

Mit den einzelnen veränderbaren Bestandteilen von Salesforce.com lassen sich vorhandene Anwendungen anpassen, erweitern oder völlig neue Anwendungen erzeugen. Dabei stehen verschiedene Grundelemente zur Verfügung: 쮿

Custom Object – Ein benutzerdefiniertes Objekt erlaubt die Definition eigener Datenbehälter, ähnlich einer Tabelle in einer relationalen Datenbank.

쮿

Tabs – Tabs dienen zur Aufnahme und grafischen Repräsentation von benutzerdefinierten Objekten.

76


Bestandteile einer Anwendung 쮿

Dokumentbibliothek – In der Dokumentbibliothek verwalten sie Textfragmente, Bilder und Informationen, die allen Anwendungen zur Verfügung stehen.

쮿

S-Control – Ein S-Control ermöglicht die Definition von wieder verwendbaren Fragmenten einer Anwendung. Auch kann hier mehr Funktionalität durch benutzerspezifischen Quellcode der Anwendung hinzugefügt werden.

쮿

Anwendung – In der Anwendung werden Benutzerobjekte, Dokumente, Tabs und S-Controls zusammengefasst und unter einem Namen präsentiert.

Im folgenden Abschnitt wird detailliert auf jedes der Elemente eingegangen. Im darauf folgenden Abschnitt wird exemplarisch eine Anwendung – Issue Tracking – entwickelt werden.

4.2.1

Benutzerdefiniertes Objekt (Custom Object)

Ein benutzerdefiniertes Objekt erlaubt die Definition einer Datenstruktur. Das ist vorstellbar mit der Struktur einer Tabelle in einer relationalen Datenbank. Ein solches benutzerdefiniertes Objekt hat einen Namen und eine Menge von Feldern.

Ein neues benutzerdefiniertes Objekt anlegen Um ein benutzerdefiniertes Objekt zu erzeugen, muss im Apex Builder der entsprechende Link angewählt werden.

Abbildung 4.1: Auswahl und Start des „Neues Objekt“ Wizard

Daraufhin wird ein Wizard gestartet, der alle Angaben erfragt und im Fehlerfall weitere Informationen zur Verfügung stellt.

Abbildung 4.2: Neues benutzerdefiniertes Objekt anlegen (Wizard Seite 1)


77



Beim Anlegen eines neuen Objektes (erste Seite des Wizard) müssen verschiedene erste Informationen zur Verfügung gestellt werden. Auffallend sind auch die roten Striche auf der linken Seite bei einigen Eingabefeldern. Hierbei handelt es sich um Pflichtfelder, also Felder, die unbedingt ausgefüllt werden müssen. Jedoch ist es empfehlenswert, so viele Informationen wie möglich zur Verfügung zu stellen. Diese Vorgehensweise erleichtert die spätere Erweiterung und Vervollständigung von Anwendungen erheblich. Bei der Erzeugung eines neuen Objektes sind die folgenden Angaben zu machen: Label; Einzahl (Pflichtfeld) – Hier muss ein möglichst kurzer Name des Objektes angegeben werden. Dieser Name wird zum Beispiel zur Anzeige in Tabs, Seiten und Reports verwendet. Je kürzer und aussagekräftiger der Name ist, je besser ist er im Allgemeinen für die tägliche Nutzung der Anwendung geeignet. Label; Mehrzahl (Pflichtfeld) – Hier muss die Mehrzahl des vorherigen Namens zur Verfügung gestellt werden. Ansonsten gelten die gleichen Eigenschaften und Empfehlungen wie bei der vorherigen Angabe. Geschlecht (Pflichtfeld) – Um möglichst schöne Oberflächen und Reports zu erzeugen, ist auch das Geschlecht des Objektes von Interesse. An dieser Stelle kann es angegeben werden. Objektname (Pflichtfeld) – Der Objektname ist der Name, der für die interne Repräsentation und Speicherung genutzt wird. Das ist ähnlich dem Namen einer Tabelle in einer relationalen Datenbank. Einmal angegeben, kann er nicht mehr geändert werden. Auch muss der Objektname eindeutig im gesamten Namensraum der Objekte in Ihrem Salesforce.com-Account1 sein. Beschreibung (Optional) – Eine zusätzliche Beschreibung ist sehr hilfreich bei der späteren Nutzung des Objektes. An dieser Stelle kann ein beliebiger, beschreibender Text angegeben werden. Besondere Bedeutung hat bei der Erzeugung eines neuen Objektes der Objektname. Da er im gesamten Namensraum von Ihrem Salesforce.com-Account eindeutig sein muss, ist hier besondere Sorgfalt bei der Planung erforderlich. Die Nutzung eines Präfix für eine Familie von Objekten sollte in Betracht gezogen werden. Wird jedoch ein schon vorhandener Name für das Objekt angegeben, erfolgt automatisch der entsprechende Hinweis des Salesforce.com-Systems.

Abbildung 4.3: Objektname ist bereits vergeben

1

78

Mit einem Salesforce.com-Account wird hier Ihr Salesforce.com-Zugang und dessen benutzerdefinierte Eigenschaften beschrieben. So ist der Objektname zwar eindeutig bei Ihrem Salesforce.comAccount, jedoch können verschiedene Accounts dieselben Namen unabhängig voneinander benutzen.



Nachdem alle grundlegenden Angaben zum Objekt selbst gemacht wurden, kann die nächste Seite des Wizard aufgerufen werden. Hier werden Informationen zur Identifikation der Datensätze erfragt. Jeder Datensatz muss eine eindeutige Identifikation zulassen.

Abbildung 4.4: Definition des Namens des Datensatzes und dessen Typ

Die folgenden Eigenschaften müssen in diesem Schritt definiert und ergänzt werden: Der Name des Datensatzes wird an verschiedenen Stellen verwendet, so zum Beispiel bei Tabellenüberschriften, Lookups oder auch Suchresultaten. So sollte ein aussagekräftiger Name gewählt werden. Zu beachten ist außerdem, dass über das Salesforce API dieses Feld immer mit dem Feldnamen „Name“ angesprochen wird. Der Datentyp des Feldes kann entweder Text oder eine automatisch erzeugte Nummer sein. Wird der Datentyp „Text“ verwendet, kann der Anwender später beliebige Texte2 eingeben.

Abbildung 4.5: Automatische Nummerierung von Datensätzen

Eine weitere interessante Möglichkeit ist die Vergabe von automatischen Feldinhalten. Hierzu kann die Angabe „Auto Number“ gewählt werden. In einem weiteren Feld ist die Angabe der Formatierung möglich. Die Formatierungsregeln entsprechen dabei den Regeln für die Formatierung von Feldern, mit automatisch erzeugtem Inhalt. Diese Felder werden genauer im weiteren Verlauf des Buches beschrieben. Im Abbildung 4.5 wird die automatisch erzeugte Nummer nach einem vom Entwickler definierten Präfix angehangen. Die dabei entstehenden Texte sehen zum Beispiel wie folgt aus: „Task#100, Task#101, ...“. Zusätzlich kann die Startzahl vergeben werden, hier die 100. Nachdem das Objekt selbst und die Identifikation des Datensatzes festgelegt worden ist, kann mit dem dritten Schritt fortgefahren werden. Hier werden optionale Eigenschaften und weiterführende Informationen für das Objekt festgelegt.

2

Wobei „Text“ hier eher einem kurzen Textstring, mit einer überschaubaren Anzahl von Zeichen, entspricht.


79



Abbildung 4.6: Weitere Eigenschaften des Objektes festlegen

Die optionalen und weiterführenden Eigenschaften können wie folgt beschrieben werden: Mit Enable Reports kann gesteuert werden, ob das Objekt für Reporte genutzt werden kann. Mittels Track Activity wird gesteuert, ob Anwender zusätzliche Informationen zum Datensatz anlegen können. Diese zusätzlichen Informationen bestehen aus Tasks und Events. Wenn diese Checkbox aktiviert wird, werden automatisch alle benötigten weiteren Objekte, ihre Struktur und Darstellung generiert.

Abbildung 4.7: Task- und Eventinformationen zum Datensatz in der Oberfläche nach Fertigstellung des Objektes

In Abbildung 4.7 ist das Ergebnis dieser Einstellung zu sehen. Der Benutzer kann zusätzliche Informationen zum Objekt festhalten. Der Deployment Status beschreibt den aktuellen sichtbaren Status des Objektes. Während der Entwicklung von benutzerdefinierten Objekten ist es meist nicht sinnvoll, dass Anwender diese schon benutzen. Während der Erzeugung neuer Objekte oder der Veränderung existierender sollte der Status „In Deployment“ gewählt werden. In diesem Status werden die Objekte zum Beispiel auf Tabs, Suchresultaten und Reports verborgen. Nach dem Fertigstellen eines Objektes sollte der Status auf „Deployed“ geändert werden. Somit wird allen Anwendern erlaubt, mit diesem Objekt und den zugehörigen Eigenschaften zu arbeiten. Mit Add Notes & Attachments kann erlaubt werden, dass Anwender des Objektes Notizen und Anlagen zum Datensatz anlegen können.

80



Abbildung 4.8: Notizen und Anlagen zum Datensatz in der Oberfläche nach Fertigstellung des Objektes

Die Einstellung Launch New Custom Tab Wizard ist ein Hilfsmittel, welches im Anschluss an das Anlegen des Objektes direkt zur Erzeugung eines Tabs für das Objekt führt oder führen kann. Jedoch kann auch zu einem beliebigen späteren Zeitpunkt ein Tab erzeugt und verändert werden. In einem weiteren Kapitel wird speziell auf die Verwendung dieses Controls eingegangen. Wenn alle Einstellungen vorgenommen wurden, kann das benutzerdefinierte Objekt tatsächlich in dem Salesforce.com-Account angelegt werden. Dazu befindet sich auf dieser Seite der „Save“ Button. Nach der Fertigstellung werden alle Informationen auf einer Seite zusammengefasst und angezeigt. So sind neben den erfassten Informationen aus dem Wizard auch Standardinformationen und Felder hinzugefügt worden. Standardfelder beinhalten einerseits Informationen zum Anwender, welches den Datensatz erzeugt hat, „Created By“, als Letzter geändert hat, „Last Modified By“, als auch das im Wizard angegebene „Name“ Feld zur Identifikation des Datensatzes.

Objekte löschen Im Objektüberblick können ganze Objekte gelöscht werden. Jedoch muss beachtet werden, dass alle gespeicherten Informationen unwiderruflich verloren gehen. Alle Oberflächenelemente, Reports und Tabs werden automatisch gelöscht. Nicht zuletzt werden auch Referenzen und Beziehungen zum Objekt entfernt.

Abbildung 4.9: Löschen eines Objektes

Als eine Vorsichtsmaßnahme empfiehlt sich daher der vorherige Export der Daten. Im Anschluss kann das Objekt mehr oder weniger sicher gelöscht werden. Zu beachten ist jedoch, dass lediglich die Daten bei einem Export gesichert werden, aber keine Informationen zur Benutzeroberfläche.


81



4.2.2 Benutzerdefinierte Felder Benutzerdefinierte Felder anlegen Nach der Erzeugung eines neuen benutzerdefinierten Objektes sind außer den Standardfeldern keine weiteren Felder enthalten. Mittels des „New Field“ Wizard kann jederzeit ein Feld hinzugefügt werden.

Abbildung 4.10: Objektübersicht mit Feldanzeige

Zu beachten ist jedoch, dass einige Felder wie Master-Detail-Beziehungen besondere Anforderungen an die Datensätze stellen. Werden solche Felder während der Nutzung der Anwendung hinzugefügt, kann es zu einem erhöhten Migrationsaufwand kommen. Im ersten Schritt muss der Typ des Feldes festgelegt werden. Die einzelnen Feldtypen mit ihren Eigenschaften und Besonderheiten werden später im Kapitel genauer beschrieben.

Abbildung 4.11: Auswahl des Typs des Feldes

Zur Verdeutlichung wird an dieser Stelle mit dem Feldtyp „Checkbox“ weiter gearbeitet. Nach der Anwahl der nächsten Seite im Wizard müssen die Eigenschaften des Feldes festgelegt werden. Je nach Typ stehen unterschiedliche Eigenschaften zur Verfügung, mit optionalen sowie Pflichtangaben. Bei einer Checkbox müssen lediglich einige wenige Details festgelegt werden.

Abbildung 4.12: Eigenschaften für das Feld festlegen

Welche speziellen Eigenschaften ein Feldtyp hat wird später im Kapitel behandelt. Verschiedene Feldtypen bestehen aus mehr als einer Wizard-Seite. An dieser Stelle werden jedoch lediglich das Label und der Feldname für die Checkbox gefordert.

82



Während das Label frei gewählt werden kann, müssen beim Feldnamen einige Restriktionen beachtet werden. Diese haben ihren Ursprung in der physischen Repräsentation des Objektes in Salesforce.com. So sind Sonderzeichen, Leerzeichen oder auch Steuerzeichen nicht erlaubt. Eine fehlerhafte Eingabe des Feldnamens ist jedoch nicht möglich, da der Wizard diesen während des Übergangs zur nächsten Seite zurückweisen wird. Nach der Angabe aller benötigten Informationen zum Feld selbst können die Benutzungsrechte, die Sicherheitseinstellungen für das Feld vergeben werden. Dazu muss auf die nächste Seite des Wizard gegangen werden.

Abbildung 4.13: Angabe der Sicherheitseinstellungen für das Feld

Für jedes Profil in dem Salesforce.com-Account kann die Sichtbarkeit und die Schreibrechte einzeln vergeben werden. Per Standard ist das Feld für alle Profile sichtbar und kann von allen Profilen verändert werden. Wird im Salesforce.com ein neues Profil muss ein vorhandenes Profil angegeben werden, von dem alle Eigenschaften geerbt werden. Diese Vererbung der Eigenschaften bestimmt auch, ob das neu angelegte Profil auf dieses Feld zugreifen kann oder dieses Feld sichtbar ist. Die Zugriffsrechte auf das Feld können auch zu einem späteren Zeitpunkt noch verändert oder gesetzt werden. Sind alle Sicherheitseinstellungen für das Feld getroffen, kann mit dem nächsten Wizard Schritt fortgefahren werden. In diesem Schritt wird das Layout für die Anzeige des Feldes festgelegt.

Abbildung 4.14: Festlegung der Seiteneigenschaften für die Darstellung


83



Genauer gesagt kann bestimmt werden, ob das Feld auf einer Seite sichtbar ist oder nicht. Wenn das Feld sichtbar sein soll, dann wird es automatisch an das Ende einer zweispaltig formatierten Feldmenge angeordnet. Eine weitere grafische Verfeinerung dieser Eigenschaften ist nur über das dazugehörige Seitenlayout möglich. Nach Abschluss dieser Einstellungen ist die Definition des neuen Feldes abgeschlossen. Mittels „Save“ werden alle Einstellungen übernommen und zurückgekehrt zum Überblick über das Objekt. Alternativ kann mit der Bearbeitung eines neuen Feldes fortgefahren oder alle Feldinformationen verworfen werden.

Überblick über die Feldtypen Bevor speziell die einzelnen Feldtypen behandelt werden, soll an dieser Stelle ein kurzer Überblick über die Möglichkeiten erfolgen. Es muss jedoch beachtet werden, dass neue Versionen von Salesforce.com neue oder veränderte Feldtypen mitbringen können. Datentyp

Beschreibung

Auto Number

Eine von Salesforce.com generierte Sequenznummer

Formula

Das Ergebnis einer Formel, berechnet aus einer Menge von Feldern

Master-Detail Relationship

Relation zu einer Menge von anderen (Detail) Objekten

Lookup Relationship

Relation zu einem anderen Objekt

Checkbox

Angabe eines boolschen Wertes, Wahr oder Falsch

Currency

Angabe eines Wertes als Währung, automatisch formatiert

Date

Angabe eines Datums oder Auswahl eines Datums von einem Kalender

Date/Time

Angabe eines Datums mit Zeit oder Auswahl von einem Kalender

Email

Angabe einer E-Mail-Adresse

Number

Angabe einer Zahl

Percent

Angabe einer Zahl als Prozentwert

Phone

Angabe einer Telefonnummer

Picklist

Auswahlmöglichkeit aus einer definierten Menge von angegebenen Werten

Picklist (Multi-Select)

Auswahlmöglichkeit aus einer definierten Menge von angegebenen Werten. Die Auswahl mehrerer Elemente ist möglich.

Text

Eingabemöglichkeit für Text

Text Area

Eingabemöglichkeit für Texte bis zu 255 Zeichen auf mehreren Zeilen

Text Area (long)

Eingabemöglichkeit für Texte bis zu 32000 Zeichen auf mehreren Zeilen

URL

Angabe einer URL

Tabelle 4.1: Feldtypen im Überblick

Ein benutzerdefiniertes Objekt kann eine beliebige Kombination der Felder enthalten. Die maximale Anzahl der Felder je benutzerdefiniertem Objekt ist abhängig von der Salesforce.com-Version und der Edition.

84



Checkbox Der Typ Checkbox erlaubt dem Anwender die Angabe eines booleschen Wertes. Dabei bedeutet angewählt „ja“, abgewählt „nein“.

Abbildung 4.15: Checkbox in der Anwendung (Edit, ReadOnly)

Die folgenden Einstellungen können am Feld vorgenommen werden und haben die jeweils beschriebene Bedeutung:

Abbildung 4.16: Optionen des Feldtyps Checkbox

Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. Default Value (Optional) – Wenn ein neuer Datensatz erzeugt wird, erhält das Feld den hier angegebenen voreingestellten Wert.

Currency In Felder von diesem Typ können Währungsbeträge eingegeben werden. Diese werden im Anschluss korrekt nach den Vorgaben des Entwicklers und der Währung formatiert.

Abbildung 4.17: Currency-Feld in der Anwendung (Edit, ReadOnly)

Abbildung 4.18: Optionen des Feldtyps Currency


85



Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. Length (Pflichtfeld) – Die Längenangabe kennzeichnet die Anzahl von Stellen, die auf der linken Seite des Dezimalpunktes angegeben werden können. Decimal Places (Pflichtfeld) – Mit Hilfe dieser Angabe wird die maximal mögliche Anzahl von Stellen auf der rechten Seite des Dezimalpunktes angegeben.

Date In dieses Feld können Datumswerte eingetragen werden. Alternativ wird in der Oberfläche ein Element zur grafischen Auswahl eines Datumswertes zur Verfügung gestellt.

Abbildung 4.19: Date-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.20: Optionen des Feldtyps Date

Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung.

Date/Time In dieses Feld können Datums- und Zeitwerte eingetragen werden. Alternativ wird in der Oberfläche ein Element zur grafischen Auswahl eines Datums- und Zeitwertes zur Verfügung gestellt.

Abbildung 4.21: DateTime-Feld in der Anwendung (Edit, ReadOnly)

86




Abbildung 4.22: Optionen des Feldtyps DateTime


E-Mail E-Mail-Adressen können in ein Feld von diesem Typ eingetragen werden. Salesforce.com wird automatisch nach der Eingabe überprüfen, ob der Wert ein korrektes Format besitzt. In der Oberfläche kann ein Anwender direkt die Adresse anwählen. Dadurch wird das eingestellte E-Mail-Programm geöffnet und kann zum Versenden der Nachricht genutzt werden.

Abbildung 4.23: E-Mail-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.24: Optionen des Feldtyps E-Mail

Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt.


87



Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. External ID (Optional) – Ist dieses Feld angeschaltet, wird ein externer Benutzerindex auf das Feld gelegt. Dieser Index wird an alle Import Wizards gegeben und ist über das API aufrufbar. Mit Hilfe dieser Erweiterung können doppelte Datensätze vermieden werden. Im Weiteren ist der Aufbau von externen Lookups möglich.

Number In dieses Feld können beliebige Zahlen eingetragen werden. Führende Nullen werden automatisch nach der Eingabe entfernt.

Abbildung 4.25: Number-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.26: Optionen des Feldtyps Number


88



External ID (Optional) – Ist dieses Feld angeschaltet, wird ein externer Benutzerindex auf das Feld gelegt. Dieser Index wird an alle Import Wizards gegeben und ist über das API aufrufbar. Mit Hilfe dieser Erweiterung können doppelte Datensätze vermieden werden. Im Weiteren ist der Aufbau von externen Lookups möglich.

Percent Mit diesem Feldtyp wird ein gültiger Prozentwert beschrieben. Nach der Eingabe wird automatisch das Prozentzeichen zur Zahl hinzugefügt.

Abbildung 4.27: Percent-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.28: Optionen des Feldtyps Percent


Phone In ein Feld vom Type Phone können Telefonnummern eingegeben werden. Salesforce.com wird die Telefonnummer automatisch entsprechend formatieren.

Abbildung 4.29: Phone-Feld in der Anwendung (Edit, ReadOnly)


89




Abbildung 4.30: Optionen des Feldtyps Phone


Picklist, Picklist (Multi-Select) Eine Picklist beschreibt eine Menge von gültigen Werten, welche in einem entsprechenden Feld eingetragen werden können. Mit Hilfe dieses Feldes kann der Anwender aus einer vordefinierten Menge von Werten auswählen. Dabei ist je nach speziellem Feldtyp eine einfache oder mehrfache Auswahl möglich.

Abbildung 4.31: Picklist-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.32: Optionen des Feldtyps Picklist

90



Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. Values (Pflichtfeld) – Die einzelnen zur Auswahl stehenden Werte können hier eingetragen werden. Sort values alphabetically (Optional) – Normalerweise erfolgt die Anzeige der auswählbare Werte in der Reihenfolge, in der diese eingegeben worden sind. Ist dieses Feld aktiviert, erfolgt die Ausgabe der wählbaren Werte in alphabetischer Reihenfolge. Use first value (Optional) – Dieser Eintrag kann angeschaltet werden, wenn der erste Auswahlwert als gewählter Standardwert in der Auswahlbox erscheinen soll. # Visible Lines (Pflichtfeld) – Die Anzahl der sichtbaren Zeilen der Auswahlbox wird in diesem Feld angegeben.

Text, Text Area, Text Area (long) In ein Feld vom Typ Text kann eine beliebige Kombination von Buchstaben, Sonderzeichen und Zahlen eingegeben werden. Dabei steht Text für einzeilige Texte und Text-Area für Texte, bestehend aus mehreren Zeilen. Das Limit für die Eingabemenge liegt beim Text in 255 Zeichen bei Textfeldern mit dem Suffix „long“ bei 32000 Zeichen.

Abbildung 4.33: Text-Feld in der Anwendung (Edit, ReadOnly)

Die folgenden Einstellungen können am Feld vorgenommen werden und haben die jeweils beschriebene Bedeutung. Je nach gewähltem Feldtyp, Text, Text-Area oder TextArea-Long stehen verschiedene Kombinationen der Optionen zur Verfügung.

Abbildung 4.34: Optionen des Feldtyps Text-Area (long)


91



Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. External Id (Optional) – Ist dieses Feld angeschaltet, wird ein externer Benutzerindex auf das Feld gelegt. Dieser Index wird an alle Import Wizards gegeben und ist über das API aufrufbar. Mit Hilfe dieser Erweiterung können doppelte Datensätze vermieden werden. Im Weiteren ist der Aufbau von externen Lookups möglich. Length (Pflichtfeld) – In diesem Feld kann die maximale Länge des Textes spezifiziert werden. # Visible Lines (Pflichtfeld) – Die Anzahl der sichtbaren Zeilen des Texteditors wird in diesem Feld angegeben.

URL Felder dieses Typs können eine gültige Webadresse aufnehmen. Wenn der Anwender in der Oberfläche in solch ein Feld mit der Maus klickt, wird automatisch der im System eingestellte Webbrowser geöffnet und zur angegebenen Adresse navigiert.

Abbildung 4.35: URL-Feld in der Anwendung (Edit, ReadOnly)


Abbildung 4.36: Optionen des Feldtyps URL


92



Automatikfeld (Number) Felder mit automatischer Nummerierung werden beim Anlegen des Datensatzes mit einem benutzerdefinierten Wert vorinitialisiert. Dieser Wert wird aus einer Inhaltsbeschreibung und einer fortlaufenden Nummer gebildet.

Abbildung 4.37: Automatikfeld in der Anwendung (ReadOnly)


Abbildung 4.38: Optionen des Feldtyps Auto-Number

Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. Starting Number (Optional) – Hier kann eine Startzahl angegeben werden. Generate ... for existing (Optional) – Sollten schon Datensätze existieren, kann mit dieser Option bestimmt werden, ob vorhandene Datensätze auch nummeriert werden sollen. Display Format (Pflichtfeld) – Das Display Format beschreibt die Darstellung. Im Display Format kann ein beliebiger Text mit einer eingeschlossenen Menge von Ersetzungszeichen angegeben werden. Zum Beispiel wird der Text „Task#{0}“ zu einer automatischen Vergabe von „Task#0, Task#1, Task#2, ...“ usw. führen. Die Ersetzungszeichen sind wie folgt definiert: Zeichen

Beschreibung

{0}

Pflichtangabe

Mit dieser Angabe wird die Sequenz von Zahlen beschrieben. Die Anzahl der Nullen in den Klammern beschreibt die minimale Anzahl an Zeichen, welche dargestellt werden.

{YY} {YYYY}

Optional

Informationen zum Jahr werden mit dieser Angebe eingefügt. Dabei kann zwischen der kurzen Darstellung, zum Beispiel 06 für 2006, oder der vollständigen Angabe gewählt werden.


93



Zeichen

Beschreibung

{MM}

Optional

Hiermit werden Informationen zum Monat eingefügt. Zum Beispiel wird 02 für Februar oder 03 für März eingefügt werden.

{DD}

Optional

Der aktuelle Tag, zum Beispiel 01 bis 31 für Januar, wird mit dieser Angabe eingefügt.

Tabelle 4.2: Ersetzungszeichen für automatische Nummerierung

Formeln Mittels eines Formelfeldes lassen sich beliebige Berechnungen, basierend auf einer definierten Menge von Ausgangsfeldern, durchführen. Wenn sich der Inhalt eines dieser der Formel zugrunde liegenden Felder ändert, wird auch die Formel neu berechnet und der angezeigte Wert wird erneuert. Interessant ist jedoch die Berechnung der Formel selbst. Geht man strikt mathematisch vor, also dem Potenzieren vor der Punktrechnung, sollte das Ergebnis eigentlich 64 lauten. Wir erkennen hier, dass die Abarbeitung der Formel von links nach rechts erfolgt und somit das Ergebnis 1024 präsentiert wird. Mit dem Setzen von Klammern an die entsprechenden Stellen kann jedoch leicht die gewünschte Reihenfolge erzwungen werden.

Abbildung 4.39: Formula-Feld in der Anwendung (ReadOnly)

In mehren Schritten kann der Typ und der Inhalt der Formel definiert werden. Die folgenden Einstellungen können am Feld in einem ersten Schritt vorgenommen werden und haben die jeweils beschriebene Bedeutung:

Abbildung 4.40: Optionen des Feldtyps Formula

94



Field Label (Pflichtfeld) – Dieser Text stellt die vom Anwender sichtbare Beschreibung dar. Das Label wird für die Erklärung des Oberflächenelementes, Tabs und Reports verwendet. Field Name (Pflichtfeld) – Der Feldname dient der internen Repräsentation des Feldes. Hier ist die Nutzung von Sonderzeichen, Leerzeichen oder auch Steuerelementen nicht erlaubt. Options (Pflichtfeld) – Hier kann angegeben werden, wie viel Stellen nach dem Dezimalpunkt angezeigt werden sollen. Diese Einstellung kann nicht gemacht werden, wenn der Rückgabewert Text oder Date angewählt worden ist. Formula Return Type (Pflichtfeld) – Der Typ des Rückgabewertes wird hier festgelegt. Dabei stehen sowohl numerische, Date/Time als Text als Rückgabewert zur Verfügung. In einem weiteren Schritt muss jetzt die Formel selbst definiert werden. Dabei steht als Hilfsmittel ein Formeleditor im einfachen oder erweiterten Modus zur Verfügung. Das Umschalten zwischen beiden Modi ist jederzeit möglich, die bereits entwickelte Formel geht nicht verloren. Die folgenden Einstellungen können am Feld im zweiten Schritt vorgenommen werden und haben die jeweils beschriebene Bedeutung:

Abbildung 4.41: Eingabe und Überprüfung der Formel

(Formula) (Pflichtfeld) – Mit Hilfe des Formeleditors kann an dieser Stelle die Formel eingegeben werden. Durch Betätigung des Button „Validate Syntax“ wird die Formel überprüft und in eine interne Repräsentation übersetzt. Somit kann zur Entwicklungszeit eine Kontrolle auf Korrektheit der Eingabe erfolgen. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung.


95



Lookup-Beziehungen Ein Lookup-Feld definiert eine Beziehung zu einem anderen Objekt. Damit können zwei Datensätze über eine von Entwickler definierte Beziehung miteinander verbunden werden. Der Anwender wird später bei der Nutzung einen Auswahlbutton vorfinden. Nach der Betätigung desselben wird ihm eine Liste der möglichen Datensätze präsentiert. Die Form der Liste sowie die darin enthaltene Informationsmenge sind während der Entwicklungszeit wählbar.

Abbildung 4.42: Lookup-Feld in der Anwendung (Edit, Select, ReadOnly)

Bei der Darstellung des Datensatzes wird in einem Lookup-Feld automatisch ein entsprechender Link generiert. Durch die Betätigung dieses Links kann direkt zum dahinter liegenden Datensatz gesprungen werden. Während der Entwicklung muss in einem ersten Schritt das zu referenzierende Objekt ausgewählt werden.

Abbildung 4.43: Angabe des zu referenzierenden Objektes

Die folgenden Einstellungen können am Feld im zweiten Schritt vorgenommen werden und haben die jeweils beschriebene Bedeutung:

Abbildung 4.44: Eigenschaften des Feldes


96



Master-Detail-Beziehungen Wenn logisch zu einem Objekt eine Menge von Detailobjekten gehören, kann diese Art von Beziehung gewählt werden. Im Detailobjekt wird die Quelle gewählt, daraufhin wird in der Oberfläche automatisch eine neue Liste mit den Detaildatensätzen zur Verfügung gestellt. Die möglichen Detailobjekte befinden sich unterhalb des eigentlichen Datensatzes. Die Erzeugung von bestimmten Detailobjekten, wie Tasks und Anhänge, können direkt mit der Definition eines neuen Objektes definiert werden und müssen somit nicht separat angegeben werden.

Abbildung 4.45: Master-Detail-Darstellung in der Anwendung

In einem ersten Schritt wird der Master für das Detailobjekt gewählt:

Abbildung 4.46: Master für das Detailobjekt wählen

Die folgenden Einstellungen können am Feld im zweiten Schritt vorgenommen werden und haben die jeweils beschriebene Bedeutung:

Abbildung 4.47: Optionen des Feldtyps Master-Detail



97



4.2.3 Seitenlayout für das Objekt und Felder bestimmen Überblick Nach der Entwicklung eines benutzerdefinierten Objektes muss auch für dessen Darstellung gesorgt werden. Zu jedem neu angelegten Objekt wird automatisch eine Seite mit einem vordefinierten Layout angelegt. Dieses Layout ist relativ einfach gehalten und sorgt im Wesentlichen für eine erste Anzeige der Felder. Sollte das Feld nicht sichtbar sein, sollte in einem ersten Schritt überprüft werden, ob die entsprechende Einstellung für das Feld („zum Seitenlayout hinzufügen“) eingeschaltet ist. Ein Seitenlayout für ein Objekt enthält Bereiche für Sektionen, Felder und abhängige Objekte. Die einzelnen Bereiche haben folgende Bedeutung: 쮿

Feld – Ein Bereich für ein Feld entspricht im Wesentlichen dem Feld eines Objektes selbst und dessen Lage in der Sektion.

쮿

Sektion – Mehrere Felder können innerhalb zu einer Sektion gruppiert werden. Innerhalb eines Layouts sind mehrere Sektionen möglich.

쮿

Abhängige Objekte – Abhängige Objekte, genauer gesagt Master-Detail Beziehungen, werden in dieser speziellen Sektion aufgeführt und angeordnet.

Betrachtet man sich alles zusammen, ergibt sich das immer wiederkehrende Layout einer Salesforce.com Anwendung. Nach dem Erzeugen eines neuen Objektes kann am besten mit der automatisch generierten Layoutseite fortgefahren werden. Hier finden sich alle zuvor definierten Felder, in einer mehr oder weniger passenden Anordnung und Reihenfolge.

Abbildung 4.48: Objektüberblick mit Seitenlayouts

Nach der Navigation auf die Layoutseite finden sich alle zuvor beschriebenen Elemente wieder. Die Abbildung 4.49 zeigt exemplarisch eine solche Layoutseite. Um in den Editiermodus zu gelangen, muss lediglich der Link „Edit“ angewählt werden. Hier hat man neben der Möglichkeit, den Seitennamen zu ändern, auch die Möglichkeit, Sektion zu erzeugen oder Felder anzuordnen.

98



Abbildung 4.49: Seite mit Layoutelementen im Entwurfsmodus

Die gleiche Seite in der Anwendung lässt den Übergang von Editiermodus zur Ansicht erkennen.

Abbildung 4.50: Seite in der Anwendung


99



Es ist jedoch auch deutlich ersichtlich, dass während des Entwurfs ein relativ gutes Abbild der späteren Seite zu sehen ist.

Layout neu anlegen und Benutzerprofil zuweisen Zusätzlich zum vorhandenen Layout können beliebige weitere Layouts für das Objekt angelegt werden. Das ist immer dann nützlich, wenn das Objekt auf verschiedenen Tabs dargestellt werden soll. Mit Hilfe neuer Layouts können auch Informationen von vorhandenen Objekten, zum Beispiel die durch die Salesforce.com-Standardanwendung definierten, in die neue Anwendungen integriert werden. Verschiedene Layouts ermöglichen zudem eine unterschiedliche Visualisierung von Objekten, zum Beispiel für verschiedene Benutzergruppen. Ein neues Layout wird durch die Betätigung des Link „New“ erzeugt. Dabei können die folgenden Einstellungen vorgenommen werden:

Abbildung 4.51: Einstellungen für ein neues Layout

Existing Page Layout (Optional) – Hier kann ein bereits vorhandenes Layout angegeben werden, von dem alle Einstellungen übernommen werden. Es ist stets empfehlenswert, diese Option zu nutzen. Der Aufbau eines völlig neuen Layouts kann sonst sehr mühselig werden. Page Layout Name (Pflichtfeld) – Für das neue Layout muss noch ein Name in diesem Feld angegeben werden. Hierbei muss ein eindeutiger, noch nicht vorhandener Name gewählt werden. Nach der Entwicklung von Layouts für das Objekt kann festgelegt werden, welches Benutzerprofil welches Layout sieht (also welcher Benutzer welche Eingabemaske vorfindet). Dazu kann der Link „Page Layout Assignment“ angewählt werden. Nach der Betätigung dieses Links wird eine weitere Seite geöffnet, welche die Zusammenhänge beschreibt. Zu jedem vorhandenen Benutzerprofil kann ein Layout gewählt werden. Wenn ein neues Benutzerprofil angelegt wird, bekommt es automatisch das Layout des Masterprofils. Wenn alle Layouts zu den entsprechenden Profilen zugeordnet worden sind, kann die Aktion mittels Save abgeschlossen werden. Soll die Zuordnung nicht erfolgen, kann diese mit Cancel abgebrochen werden.

Abbildung 4.52: Zuweisung eines Seitenlayouts zu einem Benutzerprofil

100



Sektionen Eine Sektion beschreibt eine Gruppe von Feldern sowie zugrunde liegende Formatierungsangaben. Mit Hilfe von Sektionen können sowohl logisch zusammengehörende Felder gruppiert als auch die Seite in eine grobe Formatierung gebracht werden. Wenn ein neues Objekt angelegt wurde, ist wenigstens eine Sektion zur Verfügung. In dieser wurden alle während des Entwurfs angelegten Felder aufgenommen.

Abbildung 4.53: Automatisch erzeugte Sektion mit allen Feldern

Um eine vorhandene Sektion zu verändern, kann der Link „Edit“ in der rechten oberen Ecke der Kopfleiste gewählt werden. Genau so ist das Löschen einer Sektion mit der Anwahl des Links „Delete“ möglich. Vorsicht ist hierbei geboten, da eine einmal gelöschte Sektion nicht wiederhergestellt werden kann, alle Angaben gehen verloren. Wird eine Sektion gelöscht, werden alle Felder, die sich darin befinden, in die Liste der noch nicht zugeordneten Felder bewegt (normalerweise das Feld rechts unten). Von hier aus können diese in eine neue Sektion eingefügt oder zu vorhandenen Sektionen hinzugefügt werden. Ein Feld kann jedoch auch durch eine Drag&Drop-Aktion zwischen zwei Sektionen oder in die Liste der nicht zugewiesenen Felder bewegt werden. Sind mehrere Sektionen für ein Layout definiert worden, kann die Anordnung der Sektionen untereinander mit Hilfe der Maus verändert werden. Durch einfaches Klicken in den Sektionskopf mit der linken Maustaste, gedrückt halten der Maustaste und anschließende Bewegung kann die Sektion vor oder hinter eine bereits vorhandene Sektion bewegt werden. Um eine neue Sektion zu erzeugen muss auf der Layoutseite der Link „Create New Section“ angewählt werden. Im Anschluss öffnet sich ein Fenster, in dem verschiedene Einstellungen möglich sind.

Abbildung 4.54: Neue Sektion anlegen

Name – Der Name der Sektion kann in dieser Zeile eingegeben werden. Hierbei sollte ein möglichst aussagekräftiger Name gewählt werden, welcher zu den Feldern passt. Dieser wird möglicherweise in der Benutzeroberfläche gezeigt und soll dem Benutzer einen ersten Aufschluss über den Inhalt der Sektion geben.


101



Columns – Hier kann die Anzahl der Spalten in der Sektion gewählt werden. Normalerweise empfiehlt sich für eine Menge von kleineren Feldern die zweispaltige Anordnung. Sollen größere Felder, wie zum Beispiel Text, im Layout dargestellt werden, empfiehlt sich die Wahl einer einspaltigen Anordnung. Tab Order – Mit dieser Einstellung wählt man die Reihenfolge, in welcher die Felder bei Betätigung der Tabulatortaste aktiviert werden. Left-Right bezeichnet hierbei die Vorgehensweise, bei der erst die Felder einer Zeile (von links nach rechts) aktiviert werden. Die Reihenfolge Top-Down aktiviert dabei erst die Felder einer Spalte (von oben nach unten). Show... on Detail Page – Mit dieser Einstellung wird angegeben, ob die Kopfzeile bei der Übersichtsanzeige des Datensatzes dargestellt werden soll. Wenn die Kopfzeile nicht aktiviert wird, verschmelzen optisch zwei Sektionen zu einer. Der Betrachter erkennt aus der Seite nicht, dass es sich um mehrere Sektionen handelt. So kann zum Beispiel eine einspaltige Sektion, für einen Text, optisch direkt an eine zweispaltige Sektion für kleinere Felder angefügt werden. Show... on Edit Page – Hiermit wird angegeben, wie im Editiermodus mit der Kopfzeile der Sektion umgegangen wird. Es treffen die gleichen Eigenschaften wie bei der vorherigen Angabe zu.

Felder Die Felder werden innerhalb der Sektionen gemäß der gewählten Spaltenanzahl dargestellt. Dabei können verschiedene Zeichen der Visualisierung hinzugefügt werden. Ein Stern steht für ein Pflichtfeld, das bedeutet, der Benutzer muss das Feld ausfüllen. So muss zum Beispiel immer ein Objektname angegeben werden. Ein kleines Schloss symbolisiert, dass das Feld nicht veränderbar ist.

Abbildung 4.55: Informationen zu den Feldern

Eine Sonderstellung nimmt das Feld mit dem logischen Namen „Name“ ein. Einerseits trägt dieses Feld immer den internen Namen „Name“ (obwohl während der Eingabe ein anderer gewählt worden ist) und andererseits kann dieses Feld nicht entfernt werden. Diese Eigenschaften sind auch nur logisch, handelt es sich hierbei doch um die primäre Identifikation des Datensatzes. Wenn Sie sich jetzt nicht daran erinnern können, dieses Feld angelegt zu haben, nun, das geschieht automatisch bei der Erzeugung eines neuen Objektes bei der Definition des Namens des Datensatzes. Spezielle Eigenschaften eines Feldes, genauer gesagt alle, welche für die Verwendung in einer Oberfläche von Bedeutung sind, können über den Link „Edit Field Properties“ verändert werden. Die beiden veränderbaren Eigenschaften bedingen einander. Das bedeutet, es kann jeweils nur eine Eigenschaft aktiviert werden. Ein Read-Only-Feld, was unbedingt vom Benutzer eingegeben werden muss, macht ja auch wirklich keinen Sinn.

102



Abbildung 4.56: Eigenschaften eines Feldes festlegen

Read-Only – Diese Einstellung kennzeichnet das Feld als nicht veränderbar. Es kann lediglich gelesen werde. Neben dem Namenfeld betrifft dies auch automatisch generierte Felder. Required – Mit dieser Einstellung wird angezeigt, das es sich um ein Pflichtfeld handelt. Der Benutzer muss zwingend eine Angabe machen. Die Eigenschaften des Feldes „Name“ können aus den erwähnten Gründen nicht verändert werden. Eine weitere Ausnahme sind Felder, welche automatisch berechnet werden. So zum Beispiel Formeln oder auch Änderungsangaben (Last Modified By). Hier sind die Einstellungen durch den Typ des Feldes vorgegeben. Eine Änderung macht ebenfalls keinen Sinn.

Abbildung 4.57: Vorhandene und zugeordnete Felder des Objekts

Ein weiterer wichtiger Bereich auf der Layoutseite ist die Anzeige der verfügbaren Felder. Diese Feldanzeige befindet sich normalerweise in der rechten unteren Ecke und stellt den aktuellen Status jedes einzelnen Feldes dar. Dabei sind hell hinterlegte Felder bereits einer Sektion zugeordnet, dunkel hinterlegte Felder müssen noch zugeordnet werden. Ein einmal zugeordnetes Feld kann nicht einer weiteren Sektion zugeordnet werden.

Zugehörige Objekte (Master-Detail) Einem Objekt können durch eine beliebige Anzahl abhängiger Objekte weitere Informationen hinzugefügt werden. Ist irgendeine Master-Detail-Beziehung während der Entwicklung des Datenmodels definiert worden, wird automatisch eine entsprechende Sektion für die abhängigen Objekte unter allen anderen Sektionen eingefügt.

Abbildung 4.58: Layoutinformationen zu den abhängigen Objekten


103



Innerhalb dieser Sektion kann die Position, genauer gesagt die Reihenfolge, der abhängigen Objekte beliebig gebildet werden. Mittels der Option „Overwrite...“ kann bestimmt werden, ob der zukünftige Benutzer eigene Entscheidungen zur Darstellung der Felder treffen kann. Wenn nicht gewünscht ist, dass der Benutzer auswählen kann, ob Felder angezeigt oder verborgen werden, sollte diese Angabe eingeschalten werden. Die Darstellung des abhängigen Objektes und damit eigentlich die Darstellung der abhängigen Datensätze kann in einem weiteren Schritt festgelegt werden. Dazu wird lediglich der Link „Edit Related List Properties“ angewählt. Die folgenden Einstellungen können verändert werden:

Abbildung 4.59: Eigenschaften einer Master-Detail-Anzeige

Auswahl der Felder – Mittels dieser Selektion können die Felder bestimmt werden, welche in der Oberfläche zum Detailobjekt angezeigt werden. Als Faustregel sollten hier nicht zu viel angegeben werden, da dies die Übersichtlichkeit der eigentlichen Informationen zum Objekt beeinträchtigen kann. Diese Einstellung kann jeder Benutzer später in der Anwendung selbst verändern, wenn nicht das „Overwrite...“ Flag gesetzt worden ist. Sort By – Innerhalb der selektierten Felder kann ein Feld bestimmt werden, nach dem die Liste geordnet wird. Wird hier nichts angegeben, wird automatisch das „Name“Feld genommen. Descending – Mit diesem Flag kann gewählt werden, ob die Sortierung aufsteigend oder absteigend erfolgen soll. Action – Hier erfolgt die Angabe, auf welcher Objektlayoutseite die Einstellungen gelten sollen. In einem weiteren Bereich (meist rechts unten angeordnet) auf der Layoutseite werden die vorhandenen und genutzten abhängigen Objekte angezeigt. Dabei sind hell unterlegte Einträge Objekte, welche bereits verwendet werden, dunkel hinterlegte Einträge sind Objekte, die noch nicht verwendet werden. Ein einmal genutztes abhängiges Objekt kann nicht ein weiteres Mal auf dieser Seite verwendet werden.

104



Abbildung 4.60: Vorhandene und zugeordnete Master-Detail-Beziehungen

4.2.4 Tabs (Seiten) Überblick Mit der Entwicklung der benutzerdefinierten Objekte wurde die Repräsentation der Daten definiert. Mit den Layouts für das Objekt wurde im Weiteren die spezielle Darstellung genau dieses Objektes, mit dazugehörigen Detailobjekten, beschrieben. Die Akzeptanz einer Anwendung beim Benutzer hängt jedoch im Wesentlichen von der strukturierten und übersichtlichen Präsentation der Daten ab. Einzelne Objekte wären da wohl die schlechteste Lösung, zudem diese nicht direkt aus der Salesforce.com-Oberfläche erreicht werden können. Die Antwort auf dieses Problem liegt in den Salesforce.com-Tab-Objekten. Hiermit wird eine einzelne Seite beschrieben. Wir werden hier im Buch weiterhin das Wort Tab verwenden, obwohl genauer gesagt eine Seite gemeint ist. Das Wort „Tab“ hat sich jedoch so im Sprachgebrauch verankert, dass eine Umbenennung nur zu Missverständnissen führen würde. Mit Hilfe von Tabs kann der erste zusammenfassende Schritt in Richtung einer Anwendung gegangen werden. Tabs sind direkt aus der Salesforce.com-Oberfläche erreichbar und können beliebigen Anwendungen zugeordnet werden. Dazu aber später mehr. Ein Tab kann eine Menge von verschiedenen Informationen aufnehmen und darstellen. Tabs können grundsätzlich in zwei verschiedene Typen unterteilt werden: 쮿

Objekt-Tab – Ein Objekt-Tab kann ein beliebiges benutzerdefiniertes Objekt ausnehmen und darstellen. Hier kann man sich zum Beispiel einen Account oder Lead vorstellen.

쮿

Web-Tab – Ein Web-Tab kennzeichnet die flexibelste Form der Darstellung. Der gesamte Inhalt kann selbst bestimmt werden. Dazu stehen dem Entwickler Salesforce Controls (S-Controls) und HTML zur Verfügung. Es können aber auch Sprach- und Systemabhängige Konzepte wie ActiveX Controls oder Java genutzt werden.

Die vorhandenen benutzerdefinierten Tabs sind über Setup erreichbar, von hier aus können auch neue Tabs angelegt oder vorhandene verändert werden. Zusätzlich zu den benutzerdefinierten Tabs existiert eine Menge von internen, welche zum Beispiel durch die Salesforce.com-CRM-Anwendung definiert sind. Diese können jedoch lediglich vom Anwender angepasst werden, mehr dazu ist im Kapitel „Salesforce.com einrichten“ zu finden.


105



Abbildung 4.61: Anzeige der vorhanden benutzerdefinierten Tabs

Von der in Abbildung 4.61 gezeigten Seite können neue Tabs erzeugt oder vorhandene verändert werden. Zu beachten ist jedoch, dass nach Fertigstellung eines Tabs nicht mehr alle Optionen für eine Änderung zur Verfügung stehen. So lässt sich zum Beispiel in Objekt-Tabs das dargestellt Objekt nicht mehr ändern. Von Vorteil ist jedoch die einfache Anwendung des Konzeptes, neue Tabs lassen sich in kurzer Zeit erstellen. Das Löschen eines Tabs ist eine endgültige Operation, der Tab ist unwiderruflich verloren.

Objektseiten Ein Objekt-Tab kann ein benutzerdefiniertes Objekt aufnehmen. Dabei spielt es im ersten Moment keine Rolle ob es sich um ein Master- oder ein Detailobjekt handelt. Wenn man sich das spezielle Layout eines Masterobjektes anschaut, so sind dort die Detailinformationen bereits enthalten. Es ist also gute Style, sich auf die eigentlichen Masterobjekte zu beschränken. Obwohl eine beliebige Anzahl von Tabs angelegt werden kann, ist es doch empfehlenswert, eine überschaubare Menge zu wählen. Der spätere Benutzer muss durch die Anwahl des Tabs, am besten eines Tabs, die Informationen erfassen, aber auch wiedergeben können. Wer möchte schon ständig zwischen den verschiedenen Tabs hin und herwechseln, um eine vollständige Information zu erhalten? Ein schönes Beispiel für ein übersichtliches und benutzerfreundliches Design sind die von Salesforce.com beigelegten Standardanwendungen. Der Name des Tabs wird automatisch aus dem Namen des Objektes gebildet, welcher auf dieser Seite dargestellt wird.

106



Abbildung 4.62: Neuen Objekt-Tab definieren

Beim Anlegen eines neuen benutzerdefinierten Objekt-Tabs sind verschieden Angaben notwendig. Select an existing... (Pflichtfeld) – Hier muss ein vorhandenes, benutzerdefiniertes Objekt ausgewählt werden. Dieses Objekt wird später auf dem Tab dargestellt. Ein einmal in einem Tag genutztes Objekt kann nicht noch ein weiteres Mal vergeben werden. Unique Style... (Pflichtfeld) – Jedem Tab wird ein eigener, eindeutiger Style zugeordnet. Die Zuordnung wird in diesem Feld vorgenommen. Ein Style besteht aus einer eindeutigen Farbe und einem zugehörigen Piktogramm. Der Anwender wird später bei der Nutzung des Tabs unbewusst (oder auch bewusst) Farbe und Piktogramm mit dem Objekt verbinden. Das führt zu einer beschleunigten und komfortableren Arbeitsweise mit der Anwendung (da visuell getrieben). Wenn ein Style einem Tab einmal zugeordnet worden ist, steht der Style nicht mehr zur Verfügung. Splash Page (Optional) – Jeder Seite kann eine Splash Page zugeordnet werden. Diese Seite wird beim Aufruf der eigentlichen Seite angezeigt. Der Benutzer hat die Möglichkeit, diese Seite nach dem ersten Anzeigen abzuwählen. Das bedeutet, sie wird kein weiteres Mal angezeigt. Eine solche Seite enthält normalerweise Instruktionen für die Nutzung des Tabs oder auch spezielle Copyrighthinweise. Die Definition einer solchen Splash Page wird im Kapitel „Custom Links“ beschrieben. Eine Splash Page, oder genauer ein Custom Link, muss vor der Verwendung definiert sein. Eine Änderung dieser Angabe ist jederzeit möglich. Description (Optional) – Zu jedem Tab kann eine Beschreibung erfasst werden. Obwohl diese optional ist, sollte gemäß guter Entwicklung hier etwas Text geschrieben werden. In einem weiteren Schritt wird die Sichtbarkeit des neuen Tabs für die verschiedenen Profile festgelegt.


107



Abbildung 4.63: Sichtbarkeit für Profile festlegen

Als günstiger Ausgangspunkt für eine Zuweisung der Sichtbarkeit hat sich die Einstellung „Apply one tab visibility...“ erwiesen. Mit Hilfe dieser Einstellung werden automatisch in allen Profilen die gleichen Werte übernommen. Wenn man zum Beispiel lediglich einem Profil die Sichtbarkeit verbietet kann man ruhig mit Hilfe der globalen Einstellung erst einmal alles auf „An“ setzen und dann mit der einzelnen Einstellung fort fahren. Durch die zweite Einstellung, „Apply a differnt tab...“, kann für jedes einzelne Profil die Sichtbarkeit des Tabs festgelegt werden. In einem weiteren Schritt kann eine erste Zugehörigkeit des Tabs zu einer Anwendung definiert werden. Nach der Fertigstellung der Seite ist es sofort in den angewählten Anwendungen sichtbar. Es ist sicherlich guter Brauch, sich genau zu überlegen, welche Anwendung den neuen Tab bekommt. Nicht jeder Benutzer ist erfreut darüber, wenn urplötzlich neue Tabs auf dem Bildschirm zu sehen sind.

Abbildung 4.64: Tab der Anwendung zuweisen

Im Anschluss muss lediglich noch der Button zum Speichern betätigt werden und schon kann der neue entwickelte Tab genutzt werden.

Beschreibungsseiten Beschreibungsseiten bieten die flexibelste Form bei der Gestaltung einer Anwendung und damit der Oberfläche. Aus diesen Seiten kann praktisch frei entschieden werden, was platziert wird und wo es platziert wird. Eine wichtige Rolle spielen hierbei die Custom Links und Salesforce Controls. Gerade Letztere ermöglicht eine Wiederverwendung von kleinen Komponenten auf einer Seite.

108



Beschreibungsseiten sollten immer dann gewählt werden, wenn keine Darstellung eines benutzerdefinierten Objektes möglich ist. Aus Gründen einer einheitlichen Präsentation und Benutzung sollten Objekte auf den Objekt-Tabs angezeigt werden. Ausgehend von der Übersichtsseite wird in der zweiten Sektion „Web Tabs“ ein neuer Tab erzeugt.

Abbildung 4.65: Wahl des Seitenlayouts

In einem ersten Schritt wird das Seitenlayout gewählt. Je nachdem, was dargestellt werden soll, ist zwischen der ganzen Seite oder dem Salesforce.com-Arbeitsbereich zu wählen. Die zweite Form hat den großen Vorteil, dass die typischen Funktionen von Salesforce.com, wie Suche oder die zuletzt angeschauten Elemente, weiterhin sichtbar sind. Der Benutzer findet sich somit in seiner typischen Salesforce.com-Umgebung wieder. Im nächsten Schritt erfolgen die typischen Angaben zu einem neuen Tab. Diese ähneln sehr stark den Angaben in einem Objekt-Tab und werden an dieser Stelle lediglich in Kurzform erläutert.

Abbildung 4.66: Eigenschaften einer Web-Tab-Seite


109



Tab Type (Pflichtfeld) – In diesem Feld wird der Typ der Seite angegeben. Dabei kann zwischen URL und S-Control gewählt werden. Während eine URL auf eine externe Seite zeigt, kann mittels S-Control eine beliebige, dem Salesforce.com-Account bekannte, Komponente gewählt werden. Tab Label (Pflichtfeld) – Im Gegensatz zu Objekt-Tabs kann kein Name direkt aus einem der beteiligten Elemente extrahiert werden. In diesem Feld wird ein vom Entwickler definierter Name eingetragen. Da dieser Name sehr prominent sichtbar ist, sollte er mit einer gewissen Sorgfalt gewählt werden. Tab Style (Pflichtfeld) – Der Style des Tabs wird hier eingetragen. Jeder Style kann genau einmal vergeben werden. Frame Height (Pflichtfeld) – Für eine Abschätzung des Platzbedarfes der Seite dient dieses Feld. Obwohl es ein Pflichtfeld ist, hat es später in der Anwendung eher hinweisenden Charakter. Wenn der Bildschirm beim Benutzer kleiner als der hier angegebene Wert ist, kann in jedem Fall nicht alles gleichzeitig dargestellt werden. Splash Page (Optional) – Soll vor dem Anzeigen der eigentlichen Seite noch eine Seite mit Informationen angezeigt werden, kann diese hier bestimmt werden. Der Benutzer kann diese Seite während der Benutzung abwählen. Description (Optional) – An dieser Stelle wird eine optionale Beschreibung des Tabs eingetragen. Abhängig vom Typ der gewählten Seite (Tab Type) werden jetzt weitere Angaben zum Inhalt notwendig.

Abbildung 4.67: Eigenschaften einer URL Seite

Bei einem Web-Tab vom Typ URL muss natürlich der Link angegeben werden. Dabei sind keine Einschränkungen vorhanden. Zusätzlich ist auch das Encoding für den Link zu wählen. Die wohl interessanteste Möglichkeit in diesem Zusammenhang sind die so genanten „Merge Fields“. Hierbei handelt sich um Felder, welche an die aufgerufene URL übergeben werden können. Der Inhalt der Seite kann sich somit nach den aktuellen Daten oder anderen aktuellen Informationen der Session richten. Als ein Hilfsmittel steht oberhalb der Eingabebox für den Link ein Merge-Field Explorer bereit. In diesem werden die verfügbaren Feldtypen angezeigt. Die Auswahl eines Feldtyps zeigt wiederum die aktuellen Felder an. Nach der Auswahl eines Feldes wird dessen interne Repräsentation in einer kopierbaren Form angezeigt. Es ist gedacht, die damit bereitgestellte Information per Copy und Paste in die Eingabebox für den Link zu kopieren.

110



Mittels dem „Preview Web Tab“ kann man sich das Ergebnis sofort anzeigen lassen. Werden Daten aus der aktuellen Session benötigt, werden diese automatisch aus den aktuellen Login-Informationen genommen.

Abbildung 4.68: Eigenschaften einer S-Control-Seite

Wurde der Typ S-Control gewählt, ist lediglich eines der zur Verfügung stehenden S-Controls auszuwählen. Die gewählte Komponente wird dann später automatisch im ausgewählten Bereich dargestellt. Wie S-Controls entwickelt und im System angemeldet werden, wird in einem weiteren Kapitel erläutert. Sind die speziellen Informationen zur URL oder zum S-Control erfasst, kann zum nächsten Schritt gegangen werden.

Abbildung 4.69: Zugehörigkeit zu Profilen festlegen

In diesem Schritt wird festgelegt, welche Benutzer mit welchem Profil den neu erzeugten Tab sehen dürfen. Auch hier ist es wieder ratsam, zuerst die globalen Zuweisungen zu erledigen und dann selektiv lokal andere Einstellungen vorzunehmen. Das bedeutet, soll eigentlich niemand den neuen Tab sehen, dann kann mit „Apply one tab...“ erst einmal alles ausgeschaltet werden. Mittels „Apply a different...“ werden im Anschluss einzelne Profile wieder aktiviert.

Abbildung 4.70: Zugehörigkeit zu Anwendungen festlegen


111



Im letzten Schritt wird noch festgelegt, zu welcher Anwendung der Tab hinzugefügt werden soll. Auch hier sollte sparsam mit schnellen Zuweisungen umgegangen werden, nicht jeder Benutzer liebt das plötzliche Erscheinen neuer Seiten in der Anwendung. Mittels Betätigen des Speichern-Buttons werden alle Einstellungen übernommen und die neue Seite steht für die Nutzung bereit.

4.2.5 Benutzerdefinierte Links (Custom Links) An verschiedenen Stellen während der Entwicklung werden benutzerdefinierte Links benötigt. So zum Beispiel bei der Angabe einer Splash Page, wenn ein neuer Tab entwickelt wird. Im Prinzip ist ein benutzerdefinierter Link eine Referenz auf ein komplexes weiteres Artefakt in Salesforce.com. Hinter einem solchen Link lassen sich URLs, damit verbunden HTML Seiten und Komponenten wie S-Controls, verbergen. Zusätzlich erlaubt ein benutzerdefinierter Link die Verwendung ein und desselben Artefakts unter verschiedenen Szenarios. Dabei definiert das Artefakt den Inhalt, also was getan wird, während der Link die Einbettung in die Umgebung sowie die Darstellung beschreibt. Die benutzerdefinierten Links können den verschiedensten Artefakten zugeordnet werden. An dieser Stelle sind diejenigen Links von Interesse, welche unter der Sektion „Home“ zu finden sind. Durch Anwahl des Links „Setup“ gefolgt von „Home“ gelangt man zur Übersicht der derzeitig definierten Links. Von dieser Seite aus können auch neue benutzerdefinierte Links erzeugt und verändert werden.

Abbildung 4.71: Benutzerdefinierte Links

Ein benutzerdefinierter Link wird durch betätigen des Buttons „New“ angelegt. Durch eine Menge von einzelnen Schritten werden die Eigenschaften des Links festgelegt.

Abbildung 4.72: Grundlegende Informationen zum Link

Link Label (Pflichtfeld) – In diesem Feld wird der Name des Links angegeben. Dieser Name muss eindeutig sein, zwei Links können nicht denselben Namen tragen. Link Type (Pflichtfeld) – Hier wird der Typ des Links angegeben. Zur Auswahl stehen S-Control oder URL. Der Typ des Links entscheidet somit auch über dessen Inhalt.

112



Die folgenden Schritte sind abhängig vom gewählten Link-Typ. Der Typ URL ermöglicht die Eingabe einer URL sowie das Anfügen von Parametern.

Abbildung 4.73: URL und Parameter festlegen

In einem Textfeld wird die vollständige URL spezifiziert. Dabei ist es möglich, Variablen zu definieren, welche dann während der Ausführung durch Werte aus Salesforce.com ergänzt werden. In Abbildung 4.73 wird zum Beispiel ein Link definiert, welcher im Google nach Seiten zu einer Firma sucht. Die Firma wird aus dem aktuellen Profil des eingeloggten Salesforce.com-Nutzers genommen. Oberhalb des Eingabefeldes für die URL ist ein Explorer für die möglichen Felder vorhanden. Hier kann man sich schon ein mögliches Feld aussuchen. Im Textfeld „Copy Merge Values“ kann der Wert mit korrekter Formatierung entnommen und anschließend in das Link URL-Feld eingetragen werden. Werden Sonderzeichen verwendet, muss in einem weiteren Feld noch das passende Encoding angegeben werden. Alternativ kann auch der Typ S-Control für den Inhalt des Links gewählt werden. In diesem Fall wird ein vorhandenes S-Control in das entsprechende Eingabefeld eingegeben. Wie S-Controls entwickelt werden und welche Bedeutung diese haben, finden Sie in einem weiteren Kapitel.

Abbildung 4.74: Angabe des S-Control

In einem weiteren Schritt muss angegeben werden, auf welcher Position der Link geöffnet wird.

Abbildung 4.75: Position beim Öffnen des Links festlegen


113



Als mögliche Positionen des Inhaltes beim Öffnen des Links stehen drei verschiedene Varianten zur Auswahl. Als erste Wahlmöglichkeit steht das Öffnen des Links in einem völlig neuen Fenster zur Verfügung. Diese Variante empfiehlt sich, wenn der Inhalt parallel zum eigentlichen Inhalt der Seite sichtbar sein soll. Beispiele für solche Fenster sind Anfrageergebnisse, Hilfetexte oder auch Reports. Der Anwender sollte solche Fenster gefahrlos schließen können. Die zweite Möglichkeit besteht in der vollständigen Ausfüllung der Seite. Die von Salesforce.com bereitgestellten Standardelemente sind nicht weiter zu sehen. Diese Variante sollte genutzt werden, wenn die maximale Fläche für die Präsentation benötigt wird, also zum Beispiel für größere Reports und Tabellen. Eine dritte Möglichkeit beschreibt das Einfügen des Links in den Seitenbereich, wie als Standard von Salesforce.com her bekannt. Die Sidebar wird nicht verborgen. Diese Variante ist immer dann zu wählen, wenn sich der Link möglichst integriert in die Anwendung einfügen soll. Im besten Fall bekommt der Benutzer somit nicht den Eindruck, dass externe Seiten oder spezielle Komponenten verwendet werden. Abhängig von der Wahl der Präsentation des Inhaltes des Links sind weitere Angaben notwendig. Wird der Inhalt des Links nicht in einem separaten Fenster angezeigt, reicht die Angabe der möglichen Höhe des Inhalt aus. Wobei diese Höhenangabe mehr als ein Hinweis zu verstehen ist. Ist der Bildschirm zu klein, kann logischerweise keine Rücksicht auf diese Angabe genommen werden. Wird für den Inhalt des Links die Anzeige als eigenes Fenster gewählt, muss eine vollständige Beschreibung desselben erfolgen. Zu beachten ist außerdem, dass einige Browser Sicherheitseinstellungen und Konfigurationsmöglichkeiten bieten, die solche Fenster nicht oder in veränderter Weise (zum Beispiel als Tab) darstellen.

Abbildung 4.76: Konfiguration des Fensters

114



Width, Height (Optional) – Mit diesen Angaben wird die gewünschte Höhe sowie die gewünschte Breite des Fensters angegeben. Bei der späteren Darstellung wird jedoch auf die aktuellen Bedingungen Rücksicht genommen, so dass die tatsächlichen Werte von den definierten abweichen können. Window Position (Pflichtfeld) – Die Position des Fensters auf dem Bildschirm nach dem Öffnen wird durch diese Auswahlbox spezifiziert. Hierbei sind drei Angaben möglich: immer links oben öffnen, immer maximiert öffnen oder keine Angabe. Im letzten Fall wird die Voreinstellung des Betriebssystems genutzt. Resizeable (Optional) – Diese Einstellung gibt an, ob der Benutzer die Größe verändern darf. Wenn die Möglichkeit zur Veränderung der Größe ausgeschaltet wird, sollte man sich jedoch sicher sein, dass das Fenster auf den aktuellen Bildschirm des Benutzers passt. Show Address Bar (Optional) – Hiermit kann die Anzeige der Adressleiste erlaubt werden. Der Benutzer kann somit selbst URLs eingeben und navigieren. Show Scrollbars (Optional) – Mit dieser Einstellung wird angegeben, ob Positionsleisten im Fenster dargestellt werden sollen. Wenn diese Einstellung abgewählt wird, sollte man überprüfen, ob der Fensterinhalt auch auf dem Monitor des Benutzers vollständig sichtbar ist. Show Toolbars (Optional) – Hier kann angegeben werden, ob weitere Aktionen des Browsers dargestellt werden. Show Menu Bar (Optional) – Hiermit kann spezifiziert werden, ob die Menüs im Browserfenster sichtbar sind oder nicht. Soll zum Beispiel Aktionen wie Speichern oder Drucken möglich sein, sind solche über das Menü meistens besser erreichbar. Show Status Bar (Optional) – Soll eine Statusleiste am unteren Fensterrand angezeigt werden, muss diese Einstellung angewählt werden. Gerade bei lang laufenden Aktionen innerhalb der Seite ist eine visuelle Rückmeldung zum Benutzer, wie sie oft in der Statusleiste zu sehen ist, sehr hilfreich. Sind alle Einstellungen vorgenommen worden, wird eine abschließende Seite mit allen Informationen angezeigt. Da nicht alle Einstellungen später geändert werden können, empfiehlt sich eine kurze Überprüfung der Angaben.

Abbildung 4.77: Bestätigung der Angaben

Sind alle Angaben korrekt, kann der neue benutzerdefinierte Link mittels „Save“ gespeichert werden. Im Anschluss ist dieser für die Entwicklung von Anwendungen nutzbar.


115



4.2.6 Bilder und Dokumente Eine grafisch ansprechende Anwendung verfügt über zusätzliche Bilder und beschreibende Informationen. Diese Informationen sind in Salesforce.com in der Dokumentenbibliothek enthalten. In diesem Bereich können alle globalen Artefakte aufbewahrt werden. Zu beachten ist jedoch, dass es signifikante Einschränkungen für Größe und Form der internen Dokumente gibt. Die Dokumentbibliothek ist nicht über das „Setup“ erreichbar, stattdessen befindet es sich auf einem eigenen Tab. Sind Bilder und Dokumente in diesen Bereich geladen worden, können diese von anderer Stelle (zum Beispiel von Anwendungen) genutzt werden. Wie man leicht bemerken wird, ist das Dokumentkonzept von Salesforce.com wesentlich mächtiger als das simple Speichern von Informationen. Hier können zum Beispiel Dokumente in einer Abteilung gemeinsam genutzt werden, das Sicherheitskonzept kann dabei die vertrauliche Behandlung derselben zusichern. An dieser Stelle ist jedoch für uns lediglich die Möglichkeit der Aufbewahrung von Artefakten interessant. Um ein Bild in den Dokumentenbereich zu legen, muss zuerst auf die entsprechende Seite gewechselt werden. Sollte die Seite nicht über einen Tab sichtbar sein (das kann zum Beispiel sein, wenn Sie gerade eine eigene Anwendung ausprobieren und die Dokumentseite nicht hinzugefügt haben), kann der Pfeil ganz links in der Tableiste genutzt werden, um eine Seite mit allen verfügbaren Seiten (Tabs) zu öffnen. Von hier aus kann die Dokumentseite leicht angewählt werden.

Abbildung 4.78: Document Tab

Dieser Bereich wird geteilt zwischen allen Anwendungen, welche in dem aktuellen Salesforce.com-Account laufen. Wenn also ein neues Dokument oder Bild hinzugefügt wird, empfiehlt sich unter Umständen das Anlegen eines neuen Verzeichnisses. Beim Anlegen eines neuen Verzeichnisses müssen zwingend der Verzeichnisname und die öffentlichen Zugriffsrechte angegeben werden. Im Weiteren wird festgelegt, wer auf dieses neue Verzeichnis zugreifen darf.

116



Abbildung 4.79: Anlegen eines neuen Verzeichnisses

Ist die Entscheidung für einen Verzeichnis gefallen, kann das Dokument eingefügt werden. Eine Menge von Angaben spezifizieren das Dokument und die spätere Integration in den Gesamtkontext. Die folgenden Angaben können oder müssen vorgenommen werden:

Abbildung 4.80: Neues Dokument einfügen

Document Name (Pflichtfeld, Automatisch) – In diesem Feld kann ein beliebiger Name für das Dokument angegeben werden. Wenn jedoch der Dateiname gewählt wird, kann dieses Feld leer gelassen werden. In diesem Fall wird später der Name aus dem Dateinamen gebildet und ergänzt. Internal Use Only (Optional) – Wenn es sich um ein vertrauliches Dokument handelt, sollte diese Checkbox angeschaltet werden. Die hier gemachte Angabe schränkt nicht die Sichtbarkeit ein, zeigt aber den Anwendern an, dass es sich um ein vertrauliches Dokument handelt. Externally... Image (Optional) – Wenn es sich bei dem Dokument um ein Bild handelt, kann hiermit angezeigt werden, dass das Bild extern verfügbar sein soll. Das bedeutet, dass es ohne vorherige Authentifizierung (als Salesforce.com-Benutzer) in E-Mails genutzt


117



wird. Wenn es sich zum Beispiel um das Logo einer Salesforce.com-Anwendung handelt, sollte es nur nach einer Authentifizierung sichtbar sein. Folder (Pflichtfeld) – Hier wird das Verzeichnis angegeben, in dem das Dokument gespeichert wird. Description (Optional) – Hier kann ein beschreibender Text des Feldes angegeben werden. Die Beschreibung selber unterliegt keiner Beschränkung. Keywords (Optional) – Durch die Angabe von Schlüsselworten wird die spätere Suche und das Auffinden der Dokumente erleichtert. Für den Ort der Speicherung des Dokumentes (Select the File) stehen zwei Möglichkeiten zur Verfügung. In einem ersten Fall ist ein lokaler Pfad zu einer Datei zu spezifizieren. Diese Datei wird im Anschluss in das Dokumentverzeichnis des Salesforce.com-Account geladen. Hierbei ist zu beachten, dass Dateinamen nicht länger als 255 Zeichen sein dürfen und die Gesamtgröße der Datei nicht mehr als 5 MB beträgt. Wird das Dokument in einer benutzerdefinierten Anwendung verwendet, darf die Gesamtgröße der Datei 20 KB nicht übersteigen. In zweiten Fall wird die Lage des Dokumentes durch eine externe URL spezifiziert. Dokumente, welche mit dieser Methode veröffentlicht sind, können nicht in E-Mails verwendet werden, jedoch wird der Speicherplatz der Dokumentbibliothek nicht belastet.

4.2.7

Anwendungen

Eine Anwendung fasst eine Menge von Salesforce.com-Artefakten zusammen. Genauer gesagt eine Menge von Tabs, welche wiederum Objekte, S-Controls, Dokumente und Tabellen enthalten. Die Anwendung bildet eine Kapsel um all diese einzelnen Komponenten. Der Benutzer kann eine Salesforce.com-Anwendung direkt nach dem Login anwählen. Wird Salesforce.com verlassen, befindet sich der Anwender nach dem nächsten Login an der gleichen Stelle wieder.

Abbildung 4.81: Anwendung als Benutzer auswählen

Benutzerdefinierte Anwendungen werden genau, wie auch Interne, in einer Drop-Down Box in der rechten oberen Bildschirmhälfte angezeigt. Eine einfache Selektion bringt die Anwendung in den Vordergrund. Sollen neue Anwendungen hinzugefügt oder vorhandene verändert werden, kann über den Linkt Setup gefolgt von Custom Apps gegangen werden.

118



Abbildung 4.82: Eigene Anwendungen verwalten

In der Übersicht der Anwendungen werden alle vorhandenen angezeigt. Das betrifft sowohl die internen von Salesforce.com („Sales“ und „Service & Support“) als auch die Benutzerdefinierten Anwendungen. Die Unterscheidung ist einfach über den gesetzten Haken im Feld Custom möglich. Interne Anwendungen können zwar verändert, aber nicht gelöscht werden. Interessant ist das Anlegen neuer Anwendungen natürlich, wenn eine Menge zusammenhängender benutzerdefinierter Objekte und Tabs entwickelt worden sind. Jedoch kann eine neue Anwendung auch dann von Interesse sein, wenn vorhandene Tabs sehr benutzerspezifisch zu gruppieren sind. Um eine neue Anwendung zu entwickeln, wird in der Übersichtsanzeige der Anwendungen der Button „New“ angewählt.

Abbildung 4.83: Wichtige Informationen zur Anwendung

In einem ersten Schritt müssen grundlegende Informationen zur Anwendung eingegeben werden. Das beinhaltet Folgendes: Label (Pflichtfeld) – In diesem Feld wird der Name der Anwendung eingetragen. Jede Anwendung muss einen eindeutigen Namen haben. Eine gewisse Sorgfalt bei der Auswahl kann an dieser Stelle nicht schaden, da der Name an den verschiedensten prominenten Stellen in der Benutzeroberfläche verwendet wird. Description (Optional) – Hier kann eine optionale Beschreibung der Anwendung eingetragen werden. Zu jeder Anwendung gehört, wie der Name, ein entsprechendes Bild. Das Bild wird links oben bei einer angewählten Anwendung dargestellt.

Abbildung 4.84: Bild hinzufügen (Entwicklung und später in der Anwendung)


119



In einem nächsten Schritt kann dieses Bild beschrieben werden. Obwohl der Eintrag optional ist, sollte er doch angegeben werden. Benutzer können so leichter einen visuellen Zusammenhang herstellen. Das Bild selber muss sich in der Dokumentenbibliothek befinden (siehe auch Kapitel zur Dokumentenbibliothek für mehr Informationen). Nach der Angabe der grundlegenden Daten zur Anwendung werden die beteiligten Tabs bestimmt.

Abbildung 4.85: Tabs hinzufügen

Bei der Auswahl der beteiligten Seiten (Tabs) kann zwischen den internen und den benutzerdefinierten Tabs frei gewählt werden. Sind zum Beispiel einige Tabs für ein Projekt entwickelt worden, können diese hier gruppiert werden. Der Tab „Home“ sollte auf keinen Fall fehlen, steht er doch bei allen Salesforce.com-Anwendungen immer auf der ganz linken Seite. Welche zusätzlichen Tabs hinzugenommen werden, zum Beispiel „Documents“, entscheidet letztlich die Sinnhaltigkeit für die neue Anwendung. In einem letzten Schritt werden die Profile bestimmt, für welche die Anwendung sichtbar ist. Hier wird auch bestimmt, ob es sich um die Vorgabeanwendung für ein bestimmtes Profil handelt. Solche Anwendungen sind für neue Benutzer als Erstes sichtbar, wenn sie sich zum ersten Mal bei dem Salesforce.com-Account anmelden.

Abbildung 4.86: Profile zuweisen

An dieser Stelle kann die neue Anwendung mittels Betätigung von Speichern verfügbar gemacht werden.

120



4.2.8 Layouts für Suche und Übersichten Für die verschiedensten Übersichten sowie Suchanfragen werden tabellarische Listen der Datensätze angezeigt. Drei verschiedene Szenarien können dabei identifiziert werden. Möchte man die Layouts für die Ergebnisseiten einer Anfrage ändern, kann dies über das benutzerdefinierte Objekt geschehen. Wenn das entsprechende Objekt angewählt worden ist, findet sich auf der Übersichtsseite eine Sektion mit den Layoutangaben für die Suche.

Abbildung 4.87: Layouts für die Suche im Überblick

Die Änderung des Layouts für Anfragen und Übersichten kann sehr positiv auf die Nutzungseigenschaften der Anwendung wirken. Werden mehr Informationen zum Datensatz dargestellt, kann der Anwender besser den Zieldatensatz identifizieren. Jedoch sollte die Anzahl der angezeigten Felder, aus Gründen der Performance und Übersichtlichkeit, nicht zu hoch sein. 쮿

Übersicht im Tab – Wenn eine Seite (Tab) angewählt wird, wird eine Liste von Datensätzen angezeigt. Die angezeigten Datensätze richten sich dabei nach verschiedenen Kriterien. So kann nach kürzlich benutzten, angelegten oder modifizierten selektiert werden. Normalerweise wird nur der Name des Datensatzes in der Liste angezeigt. Siehe dazu auch Abbildung 4.88.

Abbildung 4.88: Übersicht bei Anwahl der Seite 쮿

Suchdialoge – Werden Suchdialoge geöffnet, wird per Default der Name des Datensatzes dargestellt. Auch hier kann die Menge der angezeigten Informationen eingestellt werden.


121


4 – Anwendungen mit dem Apex Builder – Grundlagen 쮿

Lookup-Dialoge – Ähnlich den Suchdialogen wird bei einem Lookup-Feld eine Identifikation des Zieldatensatz vom Benutzer verlangt. Auch hier können mehr Informationen dem Benutzer die Auswahl desselben erleichtern. Die Menge der dargestellten Informationen sollte jedoch angemessen sein. Zu viele Daten können leicht unübersichtlich werden. Siehe dazu auch Abbildung 4.90.

Abbildung 4.89: Lookup-Dialog in der Anwendung

Durch Anwahl des entsprechenden Links können die anzuzeigenden Felder identifiziert werden. Auf der linken Seite befinden sich alle möglichen Felder, auf der rechten Seite werden die darzustellenden Felder angezeigt.

Abbildung 4.90: Anpassen des Layouts

Nach der Anpassung des Layouts kann es mit „Save“ bestätigt werden. Die vorgenommenen Änderungen können jederzeit verändert werden.

4.2.9

S-Controls

S-Controls im Überblick S-Controls stellen die mächtigste Möglichkeit zur Beschreibung der Benutzeroberfläche dar. Im Weiteren können in diesen Komponenten spezielle Aktivitäten zusammengefasst werden. Jedoch sollte das S-Control immer als Bestandteil einer Apex-Anwendung gesehen werden und nicht zu viel Logik der Anwendung enthalten. Die im System enthaltenen benutzerdefinierten S-Controls werden über Setup und anschließendem anwählen des Custom S-Controls-Links angezeigt. Auf dieser Seite können vorhandene Komponenten verändert oder neue angelegt werden.

122



Abbildung 4.91: Überblick über die vorhandenen S-Controls

Eine Besonderheit der S-Controls ist die Möglichkeit weitere Oberflächenelemente aufzunehmen. So können Java-Applets, ActiveX-Elemente oder ein beliebiger anderer Inhalt eingefügt werden. Ein S-Control funktioniert somit wie eine kleine Light-WightWebanwendung. Beispiele für solch einen Inhalt reichen zum Beispiel vom Einfügen eines wieder verwendbaren HTML-Fragments bis hin zu Google-Maps oder auch eines E-Mail-Clients. S-Controls sollten genutzt werden, wenn die Benutzeroberfläche um neue Darstellungselemente erweitert wird, wenn man signifikant die Anzahl von „Clicks“ für eine Aktion reduziert oder wenn ähnliche Veränderungen an einer Menge von Datensätzen durchgeführt werden sollen. S-Controls sollten im Gegenzug nicht verwendet werden, um schwergewichtige Erweiterungen zu entwickeln.

Benutzerdefinierte S-Controls anlegen Ein neues S-Control wird über einen Klick auf den „New Custom S-Control“ Button angelegt.

Abbildung 4.92: Eigenschaften des S-Control festlegen


123



Bei der Definition eines neuen benutzerdefinierten S-Control müssen wichtige Eigenschaften angegeben werden. Name (Pflichtfeld) – In diesem Feld muss der Name der Komponente angegeben werden. Der Name muss eindeutig sein und kann nicht doppelt vergeben werden. Description (Optional) – Hier kann eine Beschreibung der Komponente angegeben werden. Gerade bei einem S-Control, welches ein komplexeres Gebilde darstellen kann, ist eine ausführliche Beschreibung durchaus angebracht. HTML Body (Pflichtfeld) – In diesem Feld wird der HTML-Inhalt angegeben. Der eingefügte HTML-Text kann zudem auf interne Objekte und deren Daten zugreifen. Dazu existiert oben auf der Seite eine Möglichkeit, sich die vorhandenen Feldtypen inklusive der möglichen Felder anzuzeigen. Ein selektiertes Feld kann im Anschluss einfach per Copy und Paste in den HTML-Text aufgenommen werden. Filename (Optional) – Da in einem S-Control weitere Komponenten, wie Applets oder auch ActiveX-Elemente, verwendet werden können ist es notwendig, diese in die ApexAnwendung zu transportieren. Um diese Komponente später anzuzeigen, muss im HTML Body die Feldreferenz {!SControl_URL} eingetragen werden. Handelt es sich um eine Java-Applet, sollte als Feldreferenz {!Scontrol_JavaCodebase} oder {!Scontrol_JavaArchive} verwendet werden. Sind alle benötigten Informationen eingetragen, kann das S-Control mittels Klick auf den „Save“ Button zur Anwendung geladen werden. Um solch eine Komponente zu nutzen, muss zusätzlich eine benutzerdefinierter Link (Custom Link) oder ein Web-Tab erzeugt werden, welcher auf das S-Control zeigt.

Einfaches S-Control als Beispiel Ein einfaches, erstes S-Control soll als Beispiel für die Entwicklung und Anwendung dienen. Es wird eine Komponente entwickelt, die lediglich etwas formatierten Text darstellen kann. Die Komponente wird im Anschluss in einem benutzerdefinierten Tab angezeigt. In einem ersten Schritt wird das S-Control selber entwickelt. Dabei wird als Name MyFirstS-Control und als Beschreibung eine kurze Erläuterung angegeben. Der eigentliche Inhalt der Komponente besteht aus einer Standard HTML-Seitenbeschreibung ohne irgendwelche zusätzlichen Elemente. Der Titel

124



Überblick
Hier steht etwas Text.

Die gesamten Informationen werden, wie in Abbildung 4.93 dargestellt, in die Daten für das S-Control eingegeben. Danach wird mittels Save das S-Control gespeichert. In der Übersichtsliste sollte jetzt eine weitere Komponente mit dem Namen MyFirstS-Control zu sehen sein.

Abbildung 4.93: Das erste S-Control definieren

Nach der Entwicklung des S-Control kann dieses verwendet werden. Dazu kann man am einfachsten einen neuen Web-Tab erzeugen. Im Beispiel bekommt dieser den Namen „S-Control Test“. Mehr zur Entwicklung von Web-Tabs ist in dem Kapitel 4.2.4 zu finden. Als Inhalt für den Tab wird das zuvor entwickelte S-Control angegeben. Nach dem Speichern sollte ein ähnliches Bild wie in Abbildung 4.94 gezeigt zu sehen sein.

Abbildung 4.94: Benutzerdefiniertes S-Control


125



4.3

Entwicklungstipps

4.3.1

Best Practices

Anwendungen lassen sich mit Apex und dem Apex Builder leicht entwickeln. Jedoch ist es hilfreich, einige Basiskonzepte und die Designphilosophie dahinter zu erkennen.

Anwendungen einfach halten Bei der Entwicklung von Anwendungen sollte immer der zukünftige Benutzer im Vordergrund stehen. Ein Anwender, der mit den in Salesforce.com standardmäßig enthaltenen Anwendungen vertraut ist, erwartet die gleiche oder ähnlich einfache Herangehensweise. Dazu gehört auch, Strukturen und Anwendungen nicht übermäßig zu komplizieren.

Fokus auf das Datenmodell legen Wie schon am Anfang dieses Kapitel erläutert worden ist, sind Salesforce.com-Anwendungen sehr datenzentriert. Das bedeutet aber auch, dass im Datenmodel selber der größte Faktor für Erfolg oder Misserfolg einer Anwendung zu suchen ist. So kann ein mögliches Problem im Design der Datenstruktur selber liegen. Einer der größten Fehler ist das Design von zu komplexen Strukturen. Dieses verlangt von dem Anwender eine möglicherweise zu hohe Strukturierung seiner Informationen. Damit sinkt gleichzeitig aber die Benutzbarkeit (zu viele Eingabeebenen, Felder, ...) und damit auch die Akzeptanz des Anwenders (wie schnell können die Daten erfasst werden, ist eine Suche über die Daten leicht möglich, ...). Eine Entscheidung, wann strukturierte Daten notwendig sind, wie zum Beispiel Lookup-Felder oder Master-Detail-Beziehungen, oder wenn einfache Felder, wie Text, ausreichen, ist kritisch für den Erfolg der Anwendung. Auch hier kann wieder von der Regel „Anwendungen einfach halten“ ausgegangen werden.

Vorhandenes Datenmodell nutzen Die grundlegenden Anwendungen jedes Salesforce.com-Accounts bringen eine reichhaltige Menge von Objekten und damit Datenstrukturen mit, wie zum Beispiel für „Leads“, „Contacts“ und „Opportunities“. Diese sind hauptsächlich im CRM-Bereich angesiedelt. Die Kenntnis dieser Strukturen und Objekte ist entscheidend für die Entwicklung eigener Anwendungen. Der Anwender sollte niemals in die Lage versetzt werden, Daten doppelt zu halten oder schlimmer, doppelt eingeben zu müssen. Schwieriger ist natürlich das Zusammenspiel mit Third-Party-Anwendungen und deren Objektstruktur. Hier sollte darauf geachtet werden, so wenig wie möglich neu zu erfinden. Die Apex-Plattform macht es einfach, bestehende Anwendungen aus einem globalen Repository zu installieren und somit Datenmodelle von Fremdanwendungen zu integrieren.

126


Entwicklungstipps

Externe Ressourcen kennen und anwenden Die Apex-Plattform fördert den Austausch von Anwendungen und Artefakten. Bevor man also selbst zu viel Zeit aufwendet, um etwas neu zu schreiben oder auch nachzuvollziehen, kann die Entwicklerseite (http://www.salesforce.com/developers) aufgesucht werden. Auf dieser Seite sind Dokumentation, aktuelle Fragen und Antworten als auch Beispiele zu finden.

4.3.2 Migration von Daten beim Einfügen einer Master-DetailBeziehung Während der Entwicklung oder Erweiterung einer Apex-Anwendung kann es durchaus vorkommen, dass eine Master-Detail-Beziehung zwischen zwei Objekten eingefügt werden muss. Sind jedoch schon Datensätze für das Detailobjekt erfasst worden, wird der Apex Builder das Anlegen der Beziehung verhindern. In einem solchen Fall muss im Detailobjekt zuerst ein Lookup-Feld angelegt werden (siehe dazu auch Kapitel 4.2.2). Anschließend muss für jeden Detaildatensatz der zugehörige Masterdatensatz angegeben werden. Sind alle Beziehungen gesetzt, kann das LookupFeld zu einer Master-Detail-Beziehung umgewandelt werden. Dazu wird in der Übersicht der Felder des Objektes das entsprechende Lookup-Feld ausgewählt und editiert.

Abbildung 4.95: Feldtyp auf Master-Detail ändern

Nach der Änderung des Feldtyps auf Master-Detail-Beziehung kann die veränderte Anwendung weiter genutzt werden.


127



5 5.1

Anwendungen mit dem Apex Builder – das Projekt

Beispielanwendung – Issue Tracking

Im folgenden Kapitel wird eine erste reale Anwendung mit dem Apex Builder entwickelt. Dabei handelt es sich um einen Issue Manager, also ein Ticketsystem im weitesten Sinne. Eine solche Grundform von Anwendung findet sich zum Beispiel als Grundstein jeder modernen Bug- und Feature-Tracking-Anwendung oder im Supportbereich von Firmen. Natürlich werden wir hier eine sehr kleine Ausbaustufe einer solchen Anwendung entwickeln. Diese kann jedoch als Ausgangspunkt für weitere Experimente und eigene Ideen genutzt werden. Die Anwendung wird sich vollständig in einen vorhandenen Salesforce.com-Account integrieren. Die Entwicklung der einzelnen Bestandteile wird Schritt für Schritt erklärt, so dass Sie sofort das Ergebnis sehen und verifizieren können. Manchmal möchte man jedoch mehr Hintergrundwissen zu dem ein oder anderen Schritt und Artefakt oder Vorgehen erfahren. In einem solchen Fall können Sie das Kapitel 4 „Anwendungen mit dem Apex Builder – Grundlagen“ aufschlagen und detailliert Informationen zu einem bestimmten Artefakt nachlesen. Die Anwendung selber besteht aus mehreren Elementen. Bei der Entwicklung macht es Sinn, erst einmal zu überlegen, welche einzelnen Artefakte benötigt werden und welchen Zweck diese haben. Von einem eher architektonischen Standpunkt ausgesehen können die einzelnen Bestandteile wie folgt charakterisiert werden: 쮿

Datenobjekt Issue – In diesem benutzerdefinierten Objekt sind alle wichtigen Daten eines Falls (Issue) abgelegt. Das sind natürlich die Beschreibung, welcher Kunde oder Benutzer es gefunden und eingetragen hat und der aktuelle Status.

쮿

Datenobjekt IssueDetail – Manchmal ist es notwendig, weitere Informationen über einen gewissen Zeitraum zu sammeln und dem eigentlichen Fall zuzuweisen. Das sind zum Beispiel Rückfragen beim Kunden, Diskussionen zur Lösung der Aufgabe und erklärendes Material. Mit Hilfe dieses benutzerdefinierten Objektes können die zusätzlichen Informationen zur Issue erfasst werden. Da es sich später um eine beliebige Menge handeln kann, wird eine Master-Detail-Verbindung zur Issue etabliert werden müssen.


129


5 – Anwendungen mit dem Apex Builder – das Projekt

Abbildung 5.1: Benutzerdefinierte Objekte und Attribute 쮿

Überblicksseite – Der zukünftige Benutzer möchte sicherlich gern wissen, wer die Anwendung entwickelt hat und wo er Hilfe, Updates oder auch neue Versionen bekommt. Dies alles kann am besten auf einer Überblicksseite untergebracht werden.

쮿

Anwendungsseite – Die Anwendungsseite stellt die hauptsächliche Komponente für die Kommunikation mit dem Benutzer dar. Hier können einzelne Issues erfasst und verändert werden. Zusätzlich können Details erfasst und angezeigt werden. Beim ersten Start der Issue-Tracking-Anwendung wird jedoch automatisch die Überblicksseite präsentiert.

쮿

Reportseite – Auf der Übersichtsseite werden Statusinformationen zum aktuellen Stand aller Issues angezeigt. Darunter kann man sich die Anzahl der gelösten, offenen oder in Arbeit befindlichen Fälle vorstellen.

쮿

Anwendung – Alles zusammen wird zu einer Anwendung verpackt, welche sich einfach weitergeben lässt. So können sie, ganz nach dem Gedanken des AppExchange, Ihre Anwendung mit anderen Benutzern teilen.

In einzelnen Schritten wird bewusst das vorhandene Apex-Grundsystem genutzt werden. So kann zum Beispiel bei der Angabe, wer eine Issue gefunden hat, das vorhandenene Objekt (Lead, Account, ...) weiter genutzt werden. Das Issue Tracking wird sich vollständig in den Salesforce.com-Account integrieren. Im weiteren Kapitel werden an den verschiedensten Stellen Namen, zum Beispiel für Objekte und Tabs, benötigt. Sollte in dem aktuellen Salesforce.com-Account ein Name schon vergeben sein, kann er beliebig angepasst werden. Zu beachten ist jedoch, dass mit diesem angepassten Namen im Verlauf des Kapitels gearbeitet werden muss.

5.2


Benutzerdefiniertes Objekt Issue Ein Issue-Objekt enthält alle Felder, um einen möglichen Fall aufzunehmen. Dabei werden bei der Definition des Objektes sowohl Standard- als auch benutzerdefinierte Felder angelegt. Das benutzerdefinierte Objekt wird den Namen „Issue“ bekommen. Die Felder des Objektes sind in Tabelle 5.1 beschrieben. Ein Standardfeld wird hierbei automatisch angelegt, zum Beispiel bei der Definition des Objektes.

130



Feldname (Spaltenname)

Feldtyp (Standard/Userfeld)

Beschreibung

Created By (CreatedBy)

Lookup(User) (Standardfeld)

Benutzer, welcher den Datensatz angelegt hat

Last Modified By (LastModifiedBy)


Benutzer, welcher den Datensatz zuletzt verändert hat

Issue Name (Name)

Text(80) (Userfeld, wird beim Anlegen des Objektes definiert)

Name und Identifikation des Datensatzes

Owner (Owner)


Eigentümer des Datensatzes

Issue Id (Issue_Id)

Auto Number (Userfeld)

Automatisch generierte, eindeutige Fallnummer

Reportet von (ReportedBy)

Lookup(Contact) (Userfeld)

Kontakt, welcher den Fall gemeldet hat

Status (State)

Picklist (Userfeld)

Status des Falls

Beschreibung (Description)

Text Area (long) (Userfeld)

Beschreibung des Falls

Tabelle 5.1: Felder und ihre Bedeutung

In einem ersten Schritt wird das Objekt angelegt. Dazu muss auf die Seite der benutzerdefinierten Objekte navigiert werden. Nach dem Start des Wizard werden die grundlegenden Eigenschaften des Objektes eingetragen (siehe auch Abbildung 5.2). 쮿

Label

: Issue

쮿

Label (Mehrzahl)

: Issues

쮿

Geschlecht

: Neuter

쮿

Object Name

: Issue

Abbildung 5.2: Grundlegende Eigenschaften des Objektes Issue

In einem weiteren Schritt kann jetzt der Datensatzname mit Typ vergeben werden. Im Beispiel wird der Name des Datensatzes auch gleichzeitig für eine kurze Identifikation des Inhaltes genutzt. Wir verwenden deshalb den Namen „Issue Name“ und als Datentyp die kürzeste, verfügbare Textform. Durch die Bestätigung dieser Seite wird mit der Definition von Metainformationen zum Objekt fortgefahren.


131



Abbildung 5.3: Angabe von Datensatzname und Typ

Da das erste Objekt möglichst wenige Querverweise haben soll, muss bei den Metainformationen auf Folgendes geachtet werden: In den optionalen Möglichkeiten werden Reports eingeschaltet, die Aktivitätsverfolgung wird ausgeschaltet. Der Veröffentlichungsstatus sollte auf „In Entwicklung“ gesetzt werden. So kann in Ruhe an dem Objekt weiter gearbeitet werden, ohne andere Benutzer zu stören. In den Optionen zum Objekt selber wird das Anlegen von Notizen ausgeschaltet. Als Letztes wird angeboten, automatisch zum Anlegen einer Seite voranzuschreiten, auch das sollte an dieser Stelle ausgeschalten werden. Mittels Betätigen des Save-Button wird das Objekt gespeichert. Gratulation, Sie haben an dieser Stelle ein erstes benutzerdefiniertes Objekt definiert. Auf der Seite der benutzerdefinierten Objekte sollte jetzt das Objekt zu sehen sein. Mittels Klick auf den Namen Link („Issue“) können die Details erforscht werden. Wie man leicht bemerken wird, sind eine Menge weiterer Dinge im Hintergrund angelegt worden. Aber keine Sorge, es hat alles seine eigene Bedeutung und Richtigkeit. In der Abbildung 5.4 sind die Details des Objektes zu sehen.

Abbildung 5.4: Details des Objektes „Issue“

In weiteren Schritten müssen jetzt die einzelnen Felder angelegt werden. Dabei ist zu beachten, dass lediglich die Benutzerdefinierten Felder von Interesse sind. Alle Standardfelder sind automatisch mit dem Objekt zusammen angelegt worden. Die primäre Identifikation des Datensatzes erfolgt über das Feld mit dem internen Namen „Name“. Auch dieses Feld wurde mit dem Objekt zusammen angelegt. Als Erstes wird das Feld für die Issue Nummer angelegt. Hierbei handelt es sich um eine eindeutige Identifikationsnummer der Issue, welche zum Beispiel bei der Kundenkommunikation genutzt werden kann.

132



1. Wechseln Sie dazu zur Objektansicht mittels der Links Setup → Build → Custom Objects und anschließender Wahl des Objektes Issue. 2. Im Bereich der benutzerdefinierten Felder wählen Sie den Knopf zum Anlegen eines neuen Feldes. 3. Jetzt muss der Feldtyp „Auto Number“ gewählt und zur nächsten Seite fortgeschritten werden. 4. Die grundlegenden Informationen für das Feld sind, wie in Abbildung 5.5 gezeigt, zu erfassen.


5. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden. 6. Im letzten Schritt wird angegeben, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier sollte die Voreinstellung, Ja, gewählt werden. 7. Jetzt können die Angaben bestätigt und zum nächsten Feld vorangegangen werden. Betätigen Sie dazu den Button „Save and New“. Eine Issue wird normalerweise von einem Benutzer gemeldet. Da es in vielen Fällen zu Rückfragen kommen kann, wird ein weiteres Feld eingefügt. Dieses Feld beschreibt, wer die Issue im Original gemeldet hat. Da die Eingabe beim ersten Feld mit dem Wunsch nach einem neuen Feld abgeschlossen worden ist, befindet man sich automatisch an der richtigen Stelle im Wizard. 1. Wählen Sie für dieses Feld den Typ „Lookup Relationship“ und schreiten zur nächsten Seite fort. 2. In diesem Schritt wird ein Lookup-Ziel definiert. In unserem Fall wählen wir das Objekt „Contact“. Dieses Objekt befindet sich im Grundsystem, welches jedem Salesforce.com-Account beiliegt. 3. In einem weiteren Schritt werden die grundlegenden Informationen für das Feld, wie in Abbildung 5.6 gezeigt, erfasst.


4. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden.


133



5. Im diesem Schritt wird angegeben, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier wird die Voreinstellung, Ja, gewählt. 6. Im letzten Schritt wird gefragt, ob Datensätze vom Typ IssueDetail automatisch in Layouts für das Objekt Contact angezeigt werden sollen. Wählen Sie hier am besten nein, um vorhandene Layouts nicht zu beeinflussen. 7. Jetzt können die Angaben bestätigt und zum nächsten Feld vorangegangen werden. Betätigen Sie dazu den Button „Save and New“. Jede Issue befindet sich in einem bestimmten Status. Man muss schließlich zumindest wissen, ob das Teil neu, in Arbeit oder sogar erledigt ist. Gerade wenn es ein Fall eines Benutzers ist, wird man im Support sicherlich häufig mit den Fragen „Wie weit ist die Arbeit an meiner Issue?“ konfrontiert. In der Beispielanwendung werden wir deshalb ein Statusfeld einfügen, was genau diese Information enthält. Im letzen Schritt wurde wiederum angezeigt, dass ein weiteres Feld angelegt werden soll. Wir befinden uns also an der richtigen Position im Wizard. 1. Wählen Sie für dieses Feld den Typ „Picklist“ und schreiten zur nächsten Seite fort. Vergewissern Sie sich, dass nicht Multiselect angewählt worden ist. Wer möchte schon eine Issue gleichzeitig auf neu und geschlossen setzen? 2. In diesem Schritt wird ein Lookup-Ziel definiert. In unserem Fall wählen wir das Objekt „Contact“. Dieses Objekt befindet sich im Grundsystem, welches jedem Salesforce.com-Account beiliegt. 3. In einem weiteren Schritt werden die grundlegenden Informationen für das Feld, wie in Abbildung 5.7 gezeigt, erfasst. Zusätzlich zu den gebräuchlichen Eigenschaften wie dem Namen des Feldes oder dessen Bezeichnung werden in einer Liste sämtliche zur Auswahl stehenden Werte eingetragen. Da beim Status einer Issue eine natürliche Reihenfolge vorliegt (offen, in Arbeit, geschlossen), sollte auf eine alphabetische Sortierung verzichtet werden.


4. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden.

134



5. Im letzten Schritt wird angegeben, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier ist die Voreinstellung, Ja, zu wählen. 6. Jetzt können die Angaben bestätigt und zum nächsten Feld vorangegangen werden. Betätigen Sie dazu den Button „Save and New“. An dieser Stelle haben wir in einem Issue-Datensatz festgehalten, von wem die Information kam, welchen Status diese hat und einen kurzen Titel. Jetzt muss eine Möglichkeit geschaffen werden, einen beschreibenden Text einzufügen. Dazu stehen Textfelder mit verschiedenen Eigenschaften zur Verfügung. Das letzte Feld wurde wiederum mit der Angabe verlassen, dass ein weiteres Feld angelegt werden soll. Somit befinden wir uns automatisch auf der richtigen Position. 1. Wählen Sie für dieses Feld den Typ „Text Area (long)“ und schreiten zur nächsten Seite fort. Durch die zusätzliche Angabe von „long“ stehen bis zu 32000 Zeichen für eine Beschreibung zur Verfügung. Das sollte eigentlich ausreichen. 2. In einem weiteren Schritt sollten die grundlegenden Informationen für das Feld, wie in Abbildung 5.8 gezeigt, erfasst werden. Eventuell ist es günstiger, mehr Zeilen sichtbar zu machen, damit die Eingabe bequemer wird. Sie können die Entscheidung jedoch auch aufschieben, solche Einstellungen lassen sich auch später noch ändern.


3. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden. 4. Im letzten Schritt wird angegeben, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier sollte die Voreinstellung, Ja, gewählt werden. 5. Jetzt können Sie die Angaben mit „Save“ bestätigen. Es wurden jetzt alle benutzerdefinierten Felder des Objektes Issue eingegeben. In der Überblicksansicht kann man die Daten nochmals überprüfen oder gegebenenfalls ändern (siehe auch Abbildung 5.9).

Abbildung 5.9: Benutzerdefinierte Felder


135



Benutzerdefiniertes Objekt IssueDetail Nachdem ein Issue-Datensatz angelegt worden ist, kommt es bei realen Anwendungen sehr häufig vor, dass weitere Informationen im Laufe der Zeit zum Datensatz dazu kommen. Zum Beispiel wird bei einem unklaren Eintrag der Support eine Rückfrage zum Kunden senden, die eingetragen werden muss. Eventuell kommen auch Ideen von anderen Benutzern hinzu. Alles in allem wird also eine Menge von zusätzlichen Einträgen benötigt. Solche Einträge werden im Beispiel durch das Objekt „IssueDetail“ beschrieben. Das benutzerdefinierte Objekt wird den Namen „IssueDetail“ bekommen. Die Felder des Objektes sind in Tabelle 5.2 beschrieben. Ein Standardfeld wird hierbei automatisch angelegt. Feldname (Spaltenname)

Feldtyp (Standard/Userfeld)

Beschreibung

Created By (CreatedBy)


Benutzer, welcher den Datensatz angelegt hat

Last Modified By (LastModifiedBy)


Benutzer, welcher den Datensatz zuletzt verändert hat

IssueDetail Name (Name)

Text(80) (Userfeld, wird beim Anlegen des Objektes definiert)

Name und Identifikation des Datensatzes

Owner (Owner)


Eigentümer des Datensatzes

Reportet von (ReportedBy)

Lookup(Contact) (Userfeld)

Kontakt, welcher das Detail gemeldet hat

Issue (Issue)

Master-Detail (Userfeld)

Issue, zu welcher dieses Detail gehört

Beschreibung (Description)

Text Area (long) (Userfeld)

Beschreibung des Falls

Tabelle 5.2: Felder und ihre Bedeutung

In einem ersten Schritt wird wiederum ein Objekt angelegt. Dazu muss auf die Seite der benutzerdefinierten Objekte navigiert werden. Nach dem Start des Wizard werden die grundlegenden Eigenschaften des Objektes eingetragen. Dazu wird analog zum Objekt „Issue“ verfahren. 쮿

Label

: IssueDetail

쮿

Label (Mehrzahl)

: IssueDetails

쮿

Geschlecht

: Neuter

쮿

Object Name

: IssueDetail

Als Name für die Datensätze wird „IssueDetail Name“ verwendet. Der Typ ist wiederum der kleinstmögliche Text.

136



Abbildung 5.10: IssueDetail-Objekt im Überblick

Nachdem das Objekt angelegt worden ist, sollten die Eigenschaften wie in Abbildung 5.10 zu sehen sein. Im Anschluss kann mit den Felddefinitionen fortgefahren werden. Die Standardfelder wurden, wie in derselben Abbildung ersichtlich ist, automatisch mit angelegt. Kommen wir jetzt zum Anlegen der Felder. Im ersten Feld wollen wir uns merken, wer die Ergänzung zur Issue gemacht hat. Eventuell muss später eine Rückfrage oder eine nähere Erklärung der Ergänzung erfolgen. 1. Wechseln Sie jetzt zur Objektansicht mittels der Links Setup → Build → Custom Objects und anschließender Wahl des Objektes IssueDetail. 2. Im Bereich der benutzerdefinierten Felder wählen Sie den Knopf zum Anlegen eines neuen Feldes. 3. Jetzt muss der Feldtyp „Lookup Relation“ gewählt und zur nächsten Seite fortgeschritten werden. 4. An dieser Stelle muss das Ziel der Relation eingegeben werden. Wir wählen hier das ‚Contact’-Objekt. Dieses Objekt wird vom Salesforce.com-Grundsystem zur Verfügung gestellt. 5. In einem weiteren Schritt werden grundlegenden Informationen für das Feld, wie in Abbildung 5.11 gezeigt, erfasst.


6. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden. 7. Im diesem Schritt wird angegeben, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier sollte die Voreinstellung, Ja, gewählt werden.


137



8. Im letzten Schritt wird gefragt, ob Datensätze vom Typ IssueDetail automatisch in Layouts für das Objekt Contact angezeigt werden sollen. Wählen Sie hier am besten nein, um vorhandene Layouts nicht zu beeinflussen. 9. Jetzt können Sie die Angaben bestätigen und zum nächsten Feld vorangehen. Betätigen Sie dazu den Button „Save and New“. Als nächstes wird die Master-Detail-Beziehung zwischen Issue und IssueDetail definiert. Wie im Überblick zum Beispiel angegeben, kann zu einem einzelnen Issue-Datensatz eine Menge von Anmerkungen (IssueDetail) angegeben werden. Die im Anschluss definierte Beziehung wird dafür sorgen, das die Anmerkungen genau einer Issue zugeordnet sind. 1. Jetzt muss der Feldtyp „Master-Detail Relationship“ gewählt und zur nächsten Seite fortgeschritten werden. 2. An dieser Stelle muss das Ziel der Relation eingegeben werden. Wir wählen hier das ‚Issue’-Objekt. Dieses Objekt wurde vorher in diesem Kapitel angelegt. 3. In einem weiteren Schritt werden grundlegenden Informationen für das Feld, wie in Abbildung 5.12 gezeigt, erfasst.


4. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden. 5. Im nächsten Schritt muss angegeben werden, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier ist die Voreinstellung, Ja, zu verwenden. 6. Im letzten Schritt wird gefragt, ob Datensätze vom Typ IssueDetail automatisch in Layouts für das Objekt Issue angezeigt werden sollen. Wählen Sie hier ja, um das automatisch vorhandene Layout anzupassen. Issues werden mit ihren Details zusammen in einem Layout dargestellt. 7. Jetzt können die Angaben bestätigt und zum nächsten Feld vorangegangen werden. Betätigen Sie dazu den Button „Save and New“. Bisher wurde angegeben, wer die Information zur Verfügung gestellt hat, zu welcher Issue sie gehört bzw. einen kurzen Namen für die Detailinformationen. Im Feld Beschreibung soll jetzt die Möglichkeit geschaffen werden, den Inhalt einzutragen. Es muss somit ein Textfeld definiert werden. Da auch hier sehr viele Informationen erfasst werden können, empfiehlt sich eine ausreichende Dimensionierung des Feldes. 1. Wählen Sie für dieses Feld den Typ „Text Area (long)“ und schreiten zur nächsten Seite fort. Durch die zusätzliche Angabe von „long“ stehen bis zu 32000 Zeichen für eine Beschreibung zur Verfügung. Das sollte eigentlich ausreichen.

138



2. In einem weiteren Schritt sollten die grundlegenden Informationen für das Feld, wie in Abbildung 5.13 gezeigt, erfasst werden. Eventuell ist es günstiger, mehr Zeilen sichtbar zu machen, damit die Eingabe bequemer wird. Sie können die Entscheidung jedoch auch aufschieben, solche Einstellungen lassen sich auch später noch ändern.


3. Wählen Sie im nächsten Schritt die Benutzerprofile, für die das Feld sichtbar sein soll. In dieser Anwendung können aber bedenkenlos die Voreinstellungen genutzt werden. 4. Im letzten Schritt muss angegeben werden, ob das Feld automatisch zum voreingestellten Layout hinzugefügt werden soll. Hier sollte die Voreinstellung, Ja, gewählt werden. 5. Da keine weiteren Felder eingeben werden, können die Angaben mit „Save“ bestätigt werden. Mit Fertigstellung des letzten Schrittes ist auch das zweite Objekt vollständig. Überprüfen Sie auch hier noch einmal alle gemachten Angaben (siehe auch Abbildung 5.14).

Abbildung 5.14: IssueDetail-Felder im Überblick

Unser Objektmodell bzw. die Tabellen sind jetzt vollständig definiert und können genutzt werden. Während der Entwicklung wurden die Objekte jedoch in einen privaten, unveröffentlichten Zustand gesetzt. Der letzte Schritt bei der Entwicklung ist die Veröffentlichung der benutzerdefinierten Objekte. Dazu müssen mittels Edit die Eigenschaften eines Objektes aufgerufen werden. In den Eigenschaften lässt sich der Status der Veröffentlichung umsetzten. Nach dem Editieren sollten sich beide Objekte im Status „Deployed“ befinden.

Abbildung 5.15: Objekte auf Status „Deployed“ setzen


139



5.3

Seiten entwickeln

Über-Issue-Tracking-Seite Nach der ganzen Arbeit mit den Objekten eine einfache Seite am Anfang. In dieser typischen „About“-Seite werden Informationen zur Anwendung gezeigt. Typischerweise könnten hier auch Links zu Updates oder Hilfeseiten angeboten werden. Diese Seite wird durch einen Web-Tab repräsentiert. Um eine solche Seite zu entwickeln, ist zuerst die Definition eines S-Control notwendig. Das S-Control wird den Inhalt der HTML-Seite aufnehmen. Die Seite selbst kann im Folgenden das S-Control beherbergen und somit darstellen. Das klingt zwar am Anfang etwas kompliziert, ist es aber nicht. Bei weiteren oder auch größeren Anwendungen wird man die Flexibilität schätzen lernen. Aber als Erstes gehen wir an die Entwicklung des S-Control. Zur Entwicklung der Komponente sind die folgenden Schritte notwendig: 1. Wechseln Sie jetzt zur Seitenansicht mittels der Links Setup → Build → Custom S-Controls. 2. Wählen Sie den Knopf zum Anlegen eines neuen S-Controls. Durch diesen Klick wird der Wizard gestartet. 3. Das S-Control besteht aus seinem Namen, einer optionalen Beschreibung und der darzustellenden HTML-Seite. Die Daten sollten, wie in Abbildung 5.16 gezeigt, eingegeben werden. Der Quelltext der HTML-Seite befindet sich auf der beiliegenden CD oder kann unter [AR01] bezogen werden (Datei samples/5/about.html).

Abbildung 5.16: S-Control konfigurieren

4. Durch Betätigen des Save-Button wird das S-Control gespeichert und kann im Anschluss verwendet werden.

140


Seiten entwickeln

Nachdem das S-Control fertig gestellt worden ist, kann mit der Seite fortgefahren werden. Um die „Über Issue-Tracking“-Seite zu entwickeln, sind die folgenden Schritte notwendig: 1. Wechseln Sie jetzt zur Seitenansicht mittels der Links Setup → Build → Custom Tabs. 2. Im Bereich der Web-Tabs wählen Sie den Knopf zum Anlegen einer neuen Seite. Durch diesen Klick wird der Wizard zum Anlegen eines neuen Tab gestartet. 3. Auf der ersten Seite wird nach dem Seitenlayout gefragt. Damit die Anwendung einer typischen Salesforce.com-Anwendung gleicht, sollte das zweispaltige Layout gewählt werden. 4. Im nächsten Schritt werden der Inhalt und das Aussehen der Seite angegeben. Wichtig ist auch, dass der Tab Type S-Control verwendet wird.

Abbildung 5.17: Inhalt und Layout der Seite

5. In diesem Schritt muss das zu verwendende S-Control eingetragen werden. Geben Sie hier den Namen des zuvor erzeugten S-Control, „About Issue Manager“, an. 6. Als Nächstes kann angegeben werden, welches Benutzerprofil die Seite sehen darf. Lassen Sie ruhig alle angeschaltet. 7. Auf der letzten Seite kann angegeben werden, zu welcher Apex-Anwendung der Tab zugeordnet werden soll. Da noch keine Issue-Manager-Anwendung existiert, sollte alles ausgeschaltet werden. 8. Jetzt kann mit Save die Eingaben bestätigt und der Tab gespeichert werden. In der Anwendung wird sich der erzeugte Tab später einmal wie in Abbildung 5.18 präsentieren.

Abbildung 5.18: „About Issue Manager“ Seite in der Anwendung


141



Anwendungsseite Die Hauptseite der Anwendung nimmt das Objekt „Issue“ sowie das abhängige Objekt „IssueDetail“ auf. Für unsere Anwendung sind drei getrennte Schritte notwendig. Natürlich kann hier variiert werden, jedoch sollte immer das Wohl des Benutzers bei grafischen Anwendungen im Vordergrund stehen. Im ersten Schritt ist etwas vorbereitende Arbeit notwendig. Beim ersten Start der Anwendungsseite soll in einer Splash-Seite der Inhalt des „About Issue Tracking“ Tab präsentiert werden. Diese Splash-Seite wird nach dem ersten Betrachten durch den Benutzer abwählbar sein. In einem weiteren Schritt wird das Issue-Objekt mit der Seite verbunden. Genauer gesagt, wird also das Layout für die Seite um das Objekt herum gestaltet. Das hat den Vorteil, dass man sich die Seite schon mal anschauen kann. Wenn wie in unserem Fall noch keine Anwendung existiert, kann die Seite auch manuell über den Link „Show all Tabs“ mit anschließender Wahl der Seite in den Vordergrund gebracht werden. Diesen Link findet man ganz rechts, am Ende der Leiste der verfügbaren Tabs. In einem letzten Schritt wird dann das Layout für das Objekt selbst festgelegt. Dazu muss der Objekt-Layouteditor bemüht werden. Als Erstes wird vorbereitend die Splash-Seite angelegt. Hierbei ist die Wiederverwendung, in Form von S-Controls, sehr nützlich. Die Splash-Seite ist eigentlich ein sogenannter Homepage Link und wird wie folgt angelegt: 1. Wechseln Sie jetzt zur Ansicht der Homepage Links mittels der Anwahl von Setup → Customize → Home → Custom Links. 2. Wählen Sie den Knopf zum Anlegen einer neuen Seite. Durch diesen Klick wird der Wizard gestartet. 3. Geben Sie jetzt für den Namen des Link „About Issue Manager Link“ und als Typ Custom S-Control ein. Wählen Sie anschließend die nächste Seite an. 4. Auf dieser Seite geben Sie das im vorherigen Abschnitt definierten S-Controls an („About Issue Manager“). 5. Auf der nächsten Wizardseite muss das Layout angegeben werden. Wählen Sie hier am besten die Option mit zwei Spalten. Der Benutzer wird somit nicht durch neue Fenster behindert und bleibt in seiner vertrauten Salesforce.com-Umgebung. 6. Auf dieser Seite muss die Höhe angegeben werden. Lassen Sie am besten den vorgegebenen Wert stehen und gehen zur nächsten Seite. 7. Nach einer abschließenden Kontrolle der Daten bestätigen Sie die Angaben mittels Save. Es kann sein, das hier die Warnung erfolgt, dass weitere Schritte durchgeführt werden müssen. Ignorieren Sie diese einfach für jetzt, die nächsten Schritte erfolgen gleich.

142


Seiten entwickeln

Aber zurück zur Entwicklung der Seite selbst. Die folgenden Schritte werden benötigt, um die gewünschte Anwendungsseite zu entwickeln: 1. Wechseln Sie jetzt zur Seitenansicht mittels der Links Setup → Build → Custom Tabs. 2. Im Bereich der Custom-Object-Tabs wählen Sie den Knopf zum Anlegen einer neuen Seite. Durch diesen Klick wird der Wizard zum Anlegen eines neuen Tab gestartet. 3. In diesem Wizard-Schritt wird angegeben, welches Objekt darzustellen ist. Zusätzlich kann eine Splash-Seite angegeben werden. Tragen Sie bitte die Daten, wie in Abbildung 5.19. ersichtlich, in den Wizard ein.

Abbildung 5.19: Eigenschaften der Seite

4. Als Nächstes kann angegeben werden, welches Benutzerprofil die Seite sehen darf. Lassen Sie ruhig alle angeschaltet. 5. Auf der letzten Seite wird angegeben, zu welcher Apex-Anwendung der Tab zugeordnet werden soll. Da noch keine Issue-Manager-Anwendung existiert, sollte alles ausgeschaltet werden. 6. Jetzt kann mit Save die Eingaben bestätigt und der Tab gespeichert werden. In der Anwendung wird sich der erzeugte Tab, später einmal, wie in Abbildung 5.20 präsentieren. Zu beachten ist, dass bei der ersten Anwahl des Tabs die Splash-Seite zu sehen sein wird. Auf dieser Seite selbst kann festgelegt werden, ob diese auch weiterhin zu sehen sein soll.

Abbildung 5.20: „Issue“-Seite in der Anwendung

Reportseite Bei der Nutzung der Anwendung Issue Manager werden im Laufe der Zeit mehr und mehr Einträge erfasst werden. Da ist es natürlich, dass wichtige Informationen im Überblick dargestellt werden. Solche Informationen sind am besten wiederum auf einer eigenen Seite zu präsentieren.


143



In der hier entwickelten Anwendung werden die Anzahl der Issues mit ihrem jeweiligen Status gezeigt. Zur Reportseite gehören ein S-Control und die entsprechende Anwendungsseite. Das S-Control enthält dabei die Logik für das Summieren der einzelnen Issues und die Verbindungsdetails zum Salesforce.com-Account. 1. Wechseln Sie jetzt zur Seitenansicht mittels der Links Setup → Build → Custom S-Controls. 2. Wählen Sie den Knopf zum Anlegen eines neuen S-Control. Durch diesen Klick wird der Wizard gestartet. 3. Das S-Control besteht aus seinem Namen (Issue Manager Report), einer optionalen Beschreibung und der darzustellenden HTML/JavaScript-Seite. Die Daten sollten, wie in Abbildung 5.21 gezeigt, eingegeben werden. Der Quelltext der HTML/JavaScript-Seite befindet sich auf der beiliegenden CD oder kann unter [AR01] bezogen werden (Datei samples/5/report.html).

Abbildung 5.21: S-Control konfigurieren

Innerhalb des S-Control wird das AJAX Toolkit verwendet um auf den Salesforce.comAccount zuzugreifen. Weitere Informationen zur Syntax, zum Aufbau und zur Verwendung des AJAX Toolkit sind im Kapitel 7 zu finden. Wenn Sie sich jedoch den folgenden Quelltext anschauen, wird deutlich, wie einfach der Zugriff auf die gespeicherten Daten ist. Nach der Initialisierung wird je eine Abfrage für den gewünschten Status ausgelöst und die so gewonnenen Ergebnisse in die Seite eingefügt.

144


Seiten entwickeln

Issue Manager Report


145



1. Durch Betätigen des Save-Button wird das S-Control gespeichert und kann im Anschluss verwendet werden. Um das S-Control mit dem zuvor entwickelten Report darzustellen, muss wiederum eine Seite für die Anwendung definiert werden. Dies wird mit den folgenden Schritten durchgeführt. 2. Wechseln Sie jetzt zur Seitenansicht mittels der Links Setup → Build → Custom Tabs. 3. Im Bereich der Custom-Web-Tabs wählen Sie den Knopf zum Anlegen einer neuen Seite. Durch diesen Klick wird der Wizard zum Anlegen eines neuen Tabs gestartet. 4. Als Erstes wird nach dem gewünschten Seitenlayout gefragt. Wir benutzen am besten wiederum das Layout mit zwei Spalten, um eine möglichst einheitliche Form der Apex-Anwendungen zu zeigen. 5. In diesem Wizard-Schritt wird angegeben, was dargestellt werden soll. Tragen Sie bitte die Daten, wie in Abbildung 5.22 ersichtlich, in den Wizard ein.

Abbildung 5.22: Eigenschaften der Seite

6. Im nächsten Schritt des Wizard wird das S-Control angegeben, welches auf der Seite angezeigt werden soll. Tragen Sie hier das zuvor entwickelte S-Control „Issue Manager Report“ ein. 7. Als Nächstes kann angegeben werden, welches Benutzerprofil die Seite sehen darf. Lassen Sie ruhig alle angeschaltet. 8. Auf der letzten Seite kann angegeben werden, zu welcher Apex-Anwendung der Tab zugeordnet werden soll. Da noch keine Issue-Manager-Anwendung existiert, sollte alles ausgeschaltet werden. 9. Jetzt wird mit Save die Eingaben bestätigt und der Tab gespeichert. In der Anwendung selber ist die Reportseite wie in Abbildung 5.23 zu sehen.

Abbildung 5.23: Reportseite in Aktion

146



Ausgehend von dem entwickelten S-Control muss hier natürlich noch eine Menge mehr getan werden. Da lediglich die grundlegende Funktionalität implementiert worden ist, kann in einem ersten Schritt an die Verbesserung der Darstellung gedacht werden. In weiteren Schritten können zusätzliche Informationen extrahiert und dargestellt werden.

5.4


Bisher wurde eine Menge von Komponenten und Seiten definiert. Diese bilden zusammen genommen eine Anwendung. Die Zusammenfassung zu einer Anwendung hat für den Anwender viele Vorteile. So wird er in einem ersten Schritt nicht gezwungen, sich alle benötigten Seiten selbst zusammen suchen zu müssen (natürlich können diese bei der weiteren Nutzung verändert oder neu gruppiert werden). Auch die Verteilung und Installation wird unterstützt, aber dazu später mehr in diesem Kapitel. Um eine neue Anwendung zu entwickeln, kann analog zu den folgenden Schritten vorgegangen werden. Auch hier kann es wieder vorkommen, dass einzelne Namen schon verwendet werden. In einem solchen Fall können Sie beliebige, andere Namen wählen. 1. Wählen Sie als Erstes den Link Setup → Build → Custom Apps an. Je nachdem wie der Apex Builder vorher konfiguriert worden ist, wird eventuell eine Informationsseite angezeigt. Auf dieser wird noch einmal erklärt, was eine Anwendung ist und welche Vorteile diese bietet. Wenn diese Seite zu sehen ist, gehen Sie einfach auf die nächste Seite, es werden keine Eingaben erwartet. 2. Nach der Anwahl des Link ist eine Übersicht über alle derzeitig installierten Anwendungen zu sehen. Hierbei wird zwischen benutzerdefinierten und internen Anwendungen (Sales, Service&Support) unterschieden. Auf dieser Seite können Sie mit Hilfe des New Button den Wizard für eine neue Anwendung starten. 3. In einem ersten Wizard-Schritt werden die grundlegenden Daten für die Anwendung erfasst. Geben Sie hier die Informationen, wie in Abbildung 5.24 zu sehen ist, ein. Der gewählte Name der Anwendung wird später einmal in der Auswahlbox der Anwendungen für den Benutzer sichtbar sein.

Abbildung 5.24: Grundlegende Daten der Anwendung

4. Im nächsten Schritt werden Sie aufgefordert ein Bild zu wählen. Für unsere Anwendung kann die Vorgabe genutzt werden. Weiterführende Informationen, zu Bildern und wie diese geändert werden, sind im Kapitel 4 zu finden. 5. Der wohl wichtigste Schritt folgt an dieser Stelle. Wählen Sie alle Seiten aus, welche in der Anwendung zusammengefasst werden sollen. Eine erste Seite „Home“ ist bereits eingetragen und kann nicht geändert werden. Für die neue Anwendung sollten wenigstens die Seiten „About Issue Manager“, „Issue“ und „Issue Manager Report“, am besten auch in dieser Reihenfolge, hinzugefügt werden.


147



6. Im letzten Schritt muss angegeben werden, für welche Benutzer die neue Anwendung sichtbar sein soll. Vergewissern Sie sich, dass die Anwendung wenigstens für Ihr Profil sichtbar ist. 7. Nach der Betätigung von Save werden alle Einstellungen verbindlich festgehalten und die Anwendung kann genutzt werden. Zuerst befindet man sich jedoch wiederum in der Übersicht aller Anwendungen. Die gerade entwickelte Anwendung sollte zu sehen sein. Wenn das Benutzerprofil es erlaubt, ist die Anwendung bereits in der Liste der anwählbaren Anwendungen enthalten (siehe Abbildung 5.25, rechte Seite). Nach der Anwahl von „Issue Manager“ werden die beschriebenen Seiten eingeblendet.

Abbildung 5.25: Installierte Anwendung

Gratulation! Die Anwendung ist damit fertig gestellt und kann jetzt genutzt werden. Legen Sie am besten ein oder mehrere Einträge mit verschiedenen Status an. Auf der Reportseite ist die dabei die Menge der Einträge, sortiert nach dem Status, jederzeit aktuell sichtbar.

5.5


Nachdem eine Anwendung fertig gestellt worden ist, kann diese zur Nutzung frei gegeben werden. Dabei unterscheidet man die private Nutzung, auch als Packaging bezeichnet, und die öffentliche Nutzung, auch als Publishing bezeichnet. Egal für welche Art der Verteilung und späteren Nutzung man sich entscheidet, der Packaging Prozess ist der erste Schritt. Packaging bezeichnet dabei genau genommen das Sammeln aller Artefakte und Komponenten der Anwendung und die Veröffentlichung als ein Packet in einem privaten Bereich. Für die folgenden Aktionen wird ein Salesforce.com-Entwickler-Account benötigt. Dabei ist das Packaging einer Anwendung sicherlich die interessanteste Variante, aber man sollte nicht vergessen, dass sich prinzipiell jegliche Zusammenstellung von Artefakten als Package zusammenfassen lässt. Also auch einzelne Seiten, Teile der Dokumentbibliothek oder auch eine Sammlung von S-Controls.

148



Der Prozess des Packaging mit anschließender privater Nutzung der Anwendung besteht aus den folgenden Schritten: 1. Apex-Entwickler-Account anlegen oder verifizieren 2. Packaging 3. Upload und Registrierung 4. Private Veröffentlichung und Nutzung

Apex-Entwickler-Account anlegen oder verifizieren Als Erstes sollte man verifizieren, ob ein entsprechender Account vorhanden ist oder wenn nicht, diesen einrichten. Dazu kann auf die Seite http://www.salesforce.com/appexchange gegangen werden. Dort befindet sich der Login Link. Zum Einloggen können dieselben Daten wie bei dem Salesforce.com-Account verwendet werden.

Abbildung 5.26: Entwickler-Account

In Abbildung 5.26 ist ein Teil der Informationen nach dem Einloggen zu sehen. Je nachdem, wie viele Anwendungen über den Salesforce.com-Account schon veröffentlicht worden sind oder ob schon Angaben zum Profil gemacht wurden, kann es etwas anders aussehen. Über dieses Login kann später jederzeit die Liste der veröffentlichen Anwendungen betrachtet oder verändert werden. In diesem Bereich von Apex sollten auch Informationen zum Profil und weitere beschreibende Informationen angegeben werden. Je ausführlicher die Beschreibung ist, je leichter haben es Anwender, später die passenden Anwendungen zu finden.

Packaging Wenn die Anwendung fertig gestellt ist, kann diese veröffentlicht werden. Dazu wird in dem Salesforce.com-Account, in welchem die Anwendung und die Komponenten entwickelt worden sind, zu dem Bereich Exchange navigiert (vgl. auch Abbildung 5.27). Hier


149



findet man den Bereich Share Apps. Nach der Anwahl des Links sind sämtliche definierten Packages sichtbar.

Abbildung 5.27: Exchange-Bereich

Durch Auswahl des Button New wird ein neues Package angelegt (siehe Abbildung 5.27).

Abbildung 5.28: Package anlegen

Zwingender Bestandteil der Angaben zum Package ist der Name. Hier sollte ein beschreibender Name angegeben werden. Im Fall unserer Anwendung kann Issue Manager verwendet werden. Im Laufe der Zeit hat es sich als vorteilhaft erwiesen, in diesem Namen auch die Versionsnummer mit einzufügen. So kann der Anwender sofort sehen, welche Version der Anwendung sich in dem Package befindet. Mehrerer Versionen einer Anwendung können nicht unter einem Namen abgelegt werden, so dass hier über den Namen und die Version zusätzlich ein Namenskonflikt vermieden wird. Optional ist eine Beschreibung der Anwendung hinzuzufügen. Diese Beschreibung sollte in jedem Fall angegeben werden, da ein potentieller Nutzer damit leichter Rückschlüsse auf die Anwendung ziehen kann. Sind die grundlegenden Eigenschaften des Package erfasst, ist mittels Save das Package zu speichern. Im ersten Schritt wurde ein leeres Package beschrieben. Damit lässt sich allerdings noch nicht allzu viel anfangen. In einem weiteren Schritt können nun die Bestandteile hinzugefügt werden. Geht man von einer bereits entwickelten Anwendung aus, ist das Hinzufügen der Artefakte relativ einfach möglich. Im Bereich der Items auf der Übersichtsseite des Packages wird der Button zum Hinzufügen von Artefakten angewählt. In der daraufhin sichtbaren Seite muss als Erstes der Typ des Artefaktes gewählt werden (siehe auch Abbildung 5.29).

Abbildung 5.29: Inhalt des Packages hinzufügen

150



Wenn der Typ des Artefaktes gewählt worden ist, werden automatisch alle verfügbaren benutzerdefinierten Artefakte dargestellt. So zum Beispiel auch die Anwendung Issue Manager. Eventuell kann es sein, dass hier mehr Einträge zu sehen sind, je nach dem Salesforce.com-Account. Wird hier eine Anwendung gewählt, werden automatisch auch alle abhängigen Bestandteile mit aufgenommen. Die Abbildung 5.30 zeigt die gefundenen Artefakte, ihren Typ und Namen.

Abbildung 5.30: Inhalt des Packages

Ist man sich nicht sicher, ob auch alle abhängigen Artefakte mit erfasst worden sind, kann über den Button Find Dependencies eine Analyse der Abhängigkeiten erfolgen. Da diese Aktion ungefährlich ist, sollte diese auf jeden Fall vor der Veröffentlichung durchgeführt werden. Mit dem automatischen Erkennungsprozess können möglicherweise nicht alle abhängigen Komponenten gefunden werden. Es hat sich als notwendig erwiesen, die Liste vor der Veröffentlichung zu überprüfen. Komponenten, welche möglicherweise nicht automatisch in der Liste enthalten sind, können zum Beispiel Reports, Dokumente oder auch Dashboards sein. Es hat sich als günstig erwiesen, solche Komponenten in einem gemeinsamen Ordner abzulegen (oder besser, für jeden Artefakttyp einen Ordner). So kann beim Hinzufügen der Artefakte der Typ Ordner gewählt werden und es muss nicht jedes einzelne Element einzeln angewählt werden.

Upload und Registrierung Wenn alle Artefakte hinzugefügt worden sind, kann das Package in den privaten ApexBereich geladen werden. Dieser Bereich ist nur für den Entwickler-Account sichtbar. Jedoch werden Anwendungen, welche in diesem Bereich veröffentlicht wurden, durch eine eindeutige URL beschrieben. Wie später noch zu sehen ist, kann diese URL auch an Dritte zur Installation der Anwendung weitergegeben werden. In der Detail-Ansicht des Package befindet sich der Button zum Upload der Anwendung (Upload to Appexchange) sowie ein Deploy Button. Mit Hilfe des Letzteren können alle Artefakte auf einmal in den Zustand Deployed gesetzt werden.


151



Bevor die Anwendung jedoch in den privaten Bereich von Apex geladen wird, sind einige grundlegende Angaben zu machen.

Abbildung 5.31: Upload Details

Version Number (Pflichtfeld) – Hier muss eine Versionsnummer angegeben werden. Es können beliebige Nummern für ein und dasselbe Package angegeben werden, jedoch sollte die Version in irgendeiner Weise den Inhalt widerspiegeln. Description (Optional) – Eine zusätzliche Beschreibung wird in dieses Feld eingetragen. Da es sich um eine sichtbare Anwendung handelt, sollte die Beschreibung angegeben werden. Security (Pflichtfeld) – Hier kann man entscheiden, ob ein Passwort zum Download der Anwendung erforderlich ist. Password, Confirm – In diesen Feldern wird das Passwort eingegeben. Hierbei ist besondere Aufmerksamkeit angebracht, da das Passwort nicht gelöscht oder zurückgesetzt werden kann. Geht das Passwort verloren, kann die Anwendung nur noch gelöscht und erneut veröffentlicht werden. Zu beachten ist außerdem, dass ein nach Apex geladenes Package nicht mehr veränderbar ist. Es kann nur noch gelöscht und erneut nach Apex geladen werden. Der Upload selbst geschieht asynchron, das heißt, nach einer Weile erfolgt die Benachrichtigung per E-Mail, dass der Upload beendet wurde. In der Übersicht des Package kann man sich den aktuellen Status des Upload anschauen (siehe Abbildung 5.32). Eine per Upload verfügbar gemachte Anwendung wird innerhalb von 180 Tagen automatisch gelöscht, wenn diese nicht von irgendeinem anderen Benutzer installiert worden ist. Nach 150 Tagen wird in einem solchen Fall eine E-Mail mit der entsprechenden Warnung an den Besitzer der Anwendung gesendet.

Abbildung 5.32: Upload ist vollständig

152



Nach dem Upload werden weitere Aktionen frei geschaltet. Im oberen Teil der Abbildung 5.32 sind die Aktionen sichtbar und haben die folgende Bedeutung: 쮿

Register – Das Package wird für die private Nutzung vorbereitet und veröffentlicht. Es wird eine URL erzeugt, mit der andere Benutzer die Anwendung installieren und nutzen können.

쮿

Create Test Drive – Hiermit kann ein Nur-Lese-Account für Demonstrationszwecke erzeugt werden. Es wird eine URL für einen Testbereich erzeugt, mit der andere Benutzer die Anwendung testen können. Es können jedoch keine Daten verändert werden.

쮿

Edit Security – Die Sicherheitseinstellungen können hiermit geändert werden.

쮿

View Contents – Der Inhalt des Packages wird angezeigt.

쮿

Delete – Die Anwendung wird gelöscht.

Private Veröffentlichung und Nutzung An dieser Stelle kann man davon ausgehen, dass sich die Anwendung im privaten Bereich von AppExchange befindet. In einem nächsten Schritt kann diese registriert werden. Das bedeutet, das Package kann von anderen Benutzern installiert und genutzt werden. Durch Betätigung des Buttons Register (siehe Abbildung 5.32) wird eine eindeutige Referenz-URL für die Anwendung erzeugt. Diese URL kann an weitere Benutzer gegeben werden.

Abbildung 5.33: URL der Anwendung

Es besteht grundsätzlich keine Pflicht, eine Anwendung öffentlich verfügbar zu machen. Ist zum Beispiel die Anwendung nur intern für die Firma interessant, kann sie in diesem privaten Status gelassen werden. Über die URL besteht jederzeit die Möglichkeit, die Anwendung zu installieren. Zu beachten ist jedoch, dass eine solche private Anwendung nicht öffentlich sichtbar ist. Das bedeutet, sie ist nicht durch eine Apex-Schlüsselwortsuche auffindbar oder in irgendeiner Form öffentlich aufgelistet. Die einzige Möglichkeit, eine solche Anwendung zu finden, ist über die entsprechende URL. Wurde die Anwendung privat veröffentlicht, kann jederzeit über die URL die Installation begonnen werden (vgl. Abbildung 5.33). Die URL selbst kann mit den üblichen Mitteln wie E-Mail oder als Link auf einer Webseite vertrieben werden. Die Informationen, welche auf der Webseite präsentiert werden, hängen von den Angaben ab, welche im EntwicklerAccount gemacht wurden. An dieser Stelle ist es also ratsam, noch mal den Account zu


153



öffnen (http://www.salesforce.com/appexchange), zu der entsprechenden Anwendung zu gehen und die Daten zu vervollständigen. Sie werden bemerken, dass eine Vielzahl von Informationen zusätzlich eingegeben werden können. Diese Informationen können nicht über einen der im vergangenen Kapitel vorgestellten Wizards und Seiten eingegeben werden.

Abbildung 5.34: Anwendung finden und Installation beginnen

5.6


Bisher wurde die Anwendung lediglich einem privaten Benutzerkreis zur Verfügung gestellt. Das hat zum einen den Vorteil, dass ein ausgiebiger Test möglich ist und zum anderen, dass die Anwendung sehr selektiv an bestimmte Benutzer gegeben werden kann. Dieser enge Kreis von Benutzern hat dabei normalerweise auch Verständnis für die eine oder andere Limitierung des Systems. Was aber noch wichtiger ist, der private Kreis der Nutzer kennt normalerweise den Entwickler der Anwendung oder hat diese sogar bei ihm in Auftrag gegeben. Ist man jedoch selbst Entwickler von Software, möchte man unter Umständen die Anwendung einem größeren Kreis von potentiellen Benutzern präsentieren. Das beste Beispiel dafür sind natürlich die mit Salesforce.com mitgelieferten Standardanwendungen wie Sales oder auch Service&Support. Da die Anwendung einem hohen potentiellen Benutzerkreis zugänglich gemacht werden soll, müssen einige wichtige Dinge eingehalten werden. So werden viel mehr Informationen über den Hersteller selbst benötigt. Natürlich muss auch die Anwendung sehr viel genauer beschrieben werden. Schlüsselworte und erklärende Informationen sind genauso wichtig wie eine vorhandene Test Drive Organisation (siehe Kapitel 5.1.7) oder auch eine Dokumentation. Zusammengefasst sollte man an dieser Stelle nicht vergessen, dass die Anwendung öffentlich wird. Sie ist demnach auch ein Aushängeschild für Ihre Firma. Wenn Sie vorher noch nicht Anwendungen für eine On-Demand-Plattform entwickelt haben, stellen Sie sich einfach vor, dass jetzt der Zeitpunkt gekommen ist, die Packung in einem Supermarkt in das Regal zu stellen und potentiellen Käufern zu präsentieren.

154



Für die Veröffentlichung (auch oft als Publishing bezeichnet) sind die folgenden Schritte notwendig: 쮿

Publisher-Profil erzeugen

쮿

Anwendung mit Publisher-Profil verbinden und Metainformationen zur Verfügung stellen

쮿

Anwendung für das Application Review Board (ARB) vorbereiten und absenden

Bei der Veröffentlichung von Anwendungen wird zwischen zwei Rollen unterschieden. Eine natürliche Person kann entweder eine von beiden Rollen oder auch beide annehmen. 쮿

Developer – In der Rolle des Entwicklers kontrolliert man die Bestandteile der Anwendung und registriert diese im Entwickler-Account von Apex. Das ist vorstellbar mit der privaten Veröffentlichung, siehe Kapitel 5.1.5. Als einen wichtigen Part in diesem Prozess hat der Entwickler weiterhin die Aufgabe, der Anwendung einen Publisher zuzuordnen.

쮿

Publisher – In dieser Rolle kann eine beliebige Anzahl von Anwendungen veröffentlicht werden. Jede Anwendung muss genau einen Publisher besitzen. Typischerweise repräsentiert eine Person mit dieser Rolle die Firma. Verschiedene Anwendungen können von verschiedenen Teams entwickelt und über eine Stelle (den Publisher) bekannt gemacht werden.

Publisher-Profil erzeugen Der erste Schritt für die Veröffentlichung ist die Erzeugung eines Profils für den Publisher. Es kann jedoch sein, dass im gewählten Account bereits ein Profil vorhanden ist. In einem solchen Fall sollte im Rahmen der Firma überprüft werden, welches Profil zu nutzen ist. Um ein Profil zu erzeugen, muss man sich in den Apex-Entwicklerbereich einwählen. Gehen Sie hierzu zu der Adresse (http://www.salesforce.com/appexchange) und verwenden Sie für das Login die Informationen des Salesforce.com-Accounts. Auf der angezeigten Webseite muss jetzt nur noch der Bereich Manage My Publishing Profile angewählt werden.

Abbildung 5.35: Profil erzeugen

Nach der Anwahl des Links, um ein neues Profil zu erzeugen, wird eine Eingabemaske präsentiert, in der die verschiedensten Informationen angegeben werden können. Auch hier ist von Vorteil, so viel wie möglich anzugeben. Die folgende Tabelle zeigt einen Überblick über die gewünschten Angaben und ihre Bedeutung. Die Sichtbarkeit steuert hierbei, inwieweit die Daten an Dritte gegeben werden.


155



Feld

Beschreibung

Sichtbarkeit

Username

Benutzername des Publishers

Privat

Phone

Telefonnummer des Publishers

Privat

Publisher Name

Name der Person oder Organisation, welche für die Anwendung verantwortlich ist

Öffentlich

Publisher Description

Beschreibung der Person oder der Organisation, welche für die Anwendung verantwortlich ist

Öffentlich

Web Site URL

Webseite, welche der Benutzer für eventuellen Support oder Fragen besuchen kann

Öffentlich

Contact Phone

Telefonnummer, welche der Benutzer für eventuellen Support oder Fragen anrufen kann

Öffentlich

Tabelle 5.3: Eigenschaften des Profils

Nach der Eingabe der Informationen kann das Profil bestätigt und genutzt werden. Alle Angaben lassen sich zu einem späteren Zeitpunkt verändern.

Metainformationen für die Anwendung bereitstellen In der Rolle des Entwicklers müssen für die Anwendung eine Reihe von Metainformationen zur Verfügung gestellt werden. Das beinhaltet in einem ersten Schritt auch den Publisher, also diejenige Person, welche den Prozess der Veröffentlichung begleitet und auch später der erste Ansprechpartner für die Anwendung ist. Im Hauptfenster, nach dem Apex-Entwickler-Login, muss dazu die Anwendung angewählt werden (vgl. dazu Abbildung 5.36). Unter der Rubrik Publisher kann zuvor definiertes Profil ausgewählt und der Anwendung zugewiesen werden.

Abbildung 5.36: Publisher zur Anwendung hinzufügen

Wenn ein Namen für den Publisher eingegeben wird, wird die Person, welche mit dem Profil verbunden ist, die Anwendung unter dem Tab Manage My Apps sehen. Diese Person kann dann die weiteren Schritte durchführen. Ist der Name jedoch nicht mit einem gültigen Profil verbunden, ist es nicht möglich, die Anwendung zu veröffentlichen. Wenn Sie nicht selbst der Publisher der Anwendung sind, sollte diejenige Person informiert werden. Es existiert kein Automatismus für diesen Vorgang. Auf derselben Seite müssen auch die beschreibenden Informationen zur Anwendung erfasst werden. Neben dem Namen der Anwendung befindet sich dazu der Link Edit, welcher wiederum ein Formular öffnet. Hier sollten wiederum so viele Angaben wie mög-

156



lich gemacht werden. Die folgende Tabelle zeigt einen Überblick über die gewünschten Angaben und ihre Bedeutung. Feld

Beschreibung

Public Application Title

Der Name der Anwendung, wie dieser im öffentlichen Directory zu sehen sein soll

Application Abstract

Hier kann eine kurze Beschreibung der Anwendung sowie die Möglichkeiten für den Benutzer angegeben werden

Application Description

An dieser Stelle wird eine ausführliche Beschreibung der Anwendung und ihrer Möglichkeiten erwartet. Normalerweise sollten ein oder zwei kurze Absätze ausreichen.

Feature Bullets

Ein bis drei kurze Aussagen über die Eigenschaften der Anwendung können hier beschrieben werden. Dabei sollten möglichst einmalige Features gewählt werden.

Compatible Editions

Hier muss angegeben werden, in welchen Salesforce.com Editions die Anwendung betrieben werden kann

Additional System Requirements Alle zusätzlichen benötigten Eigenschaften der Laufzeitumgebung sollten hier erfasst werden. Das sind zum Beispiel Informationen zum gewünschten Betriebssystem, Browser oder einer bestimmten Office Edition. Screenshot, Thumbnail

Anwendungen im öffentlichen Verzeichnis enthalten normalerweise ein Bildschirmfoto und ein kleines Vorschaubild. Beide können hier eingetragen werden. Zu beachten ist jedoch, dass das Bildschirmfoto nicht größer als 850x600 Pixel und das Vorschaubild nicht größer als 165x115 Pixel sein darf. Als Bildformate können JPG oder GIF genutzt werden.

Presentation

Wenn eine automatische Demonstration der Anwendung zur Verfügung steht, (zum Beispiel als Flash) kann der zugehörige Link hier eingetragen werden

Datasheet and Customization Guide

Hier kein eine kurze Beschreibung (zum Beispiel als PDF Datei) oder auch Installationsanleitung angegeben werden. Ein Vorlage für solch eine Datei ist unter salesforce.com/appexchange/how_to_publish.jsp zu finden.

Test Drive Demo

Wenn für die Anwendung eine Test-Drive-Organisation erzeugt worden ist, kann der Link hier angegeben werden. Es ist grundsätzlich immer von Vorteil, ein Test-Drive-Demo zu erzeugen.

Licensing, Pricing and Sales

Anwendungen, welche zum Verkauf angeboten werden, sollten Preise und Kontaktinformationen enthalten. Anwendungen, welche kostenlos zur Verfügung gestellt werden, sollten dies mit einer kurzen Aussage in eben diesem Feld öffentlich machen. Kommerzielle müssen zusätzlich eine entsprechende Lizenz mitbringen. Der Lizenztext kann mittels Copy&Paste in ein Feld eingetragen werden. Wird kein Lizenztext bereitgestellt, wird automatisch der Vorgabetext von Salesforce.com genutzt.

Tabelle 5.4: Eigenschaften der Anwendung

Nach der Eingabe aller Informationen wird die Eingabe bestätigt. In einem nächsten Schritt müssen Sie jetzt noch das Verzeichnis (auch Exchange genannt) wählen. Jede Anwendung kann genau in einem öffentlichen Verzeichnis installiert werden. Als Regel


157



gilt hierbei, dass das Verzeichnis gewählt wird, welches die Sprache der Anwendung unterstützt (oder zumindest den Sprachraum).

Abbildung 5.37: Exchange zur Anwendung hinzufügen

Nachdem die Anwendung einem Verzeichnis hinzugefügt worden ist, kann die Kategorie gewählt werden. Dazu kann man nach dem Klick auf den entsprechenden Link ein oder zwei Kategorien auswählen. Hat man alle Informationen eingegeben, kann die Veröffentlichung erfolgen. Eventuell ist dazu eine andere Person zu benachrichtigen.

Anwendung für das Application Review Board (ARB) vorbereiten und absenden Im Feld Status (vgl. Abbildung 5.36) ist der Link Submit to Publication sichtbar. Es kann sein, dass der Link erst nach der Eingabe von bestimmten Informationen zur Anwendung sichtbar wird (Exchange, Publisher, ...), geben Sie deshalb immer zuerst alle Eigenschaften der Anwendung an. An dieser Stelle empfiehlt es sich, noch einmal tief Luft zu holen und die angegebenen Informationen zu überprüfen. Nach der Absendung besteht keine Möglichkeit mehr, die Angaben zu verändern (genauer gesagt, die Angaben können nur noch sehr begrenzt im Rahmen des ARB auf Anforderung geändert werden). Wurde die Anwendung zur Überprüfung an das Application Review Board gesendet, wird der Status auf Submittet geändert. Die möglichen Status während des Review-Prozesses sind aus der folgenden Tabelle ersichtlich. Status

Beschreibung

New

Die Anwendung wurde nicht an das Application Review Board (ARB) gesendet. Das bedeutet, es handelt sich um eine private Anwendung (siehe auch Kapitel 5.1.5).

Submitted

Die Anwendung wurde zur Überprüfung an das ARB gesendet. Zeitgleich wird die Anwendung gesperrt und kann nicht mehr verändert werden.

In Review

Die Anwendung wird vom ARB getestet

In Edit

Die Anwendung wurde für einen definierten Zeitraum entsperrt. In diesem Zeitraum kann der Publisher geforderte Änderungen vornehmen.

Approved

Die Anwendung wurde getestet und akzeptiert für die öffentliche Nutzung über Apex. Ab diesem Zeitpunkt kann die Anwendung im globalen Apex Verzeichnis gelistet werden.

Tabelle 5.5: Status der Veröffentlichung

158



Das ARB wird die Anwendung anschauen und eine entsprechende Statusmitteilung per E-Mail zusenden. Sobald die Anwendung den Status Approved erreicht hat, wird auf die Seite der Anwendung eine Checkbox mit dem Text Listet eingeblendet. Hiermit kann bestimmt werden, ob die Anwendung im öffentlichen Verzeichnis sichtbar ist oder nicht. Die Sichtbarkeit beeinflusst nicht den Status der Anwendung.

Anwendung nach der Veröffentlichung verändern Wie jeder Entwickler schon sehr frühzeitig lernt, müssen Anwendungen hin und wieder verbessert werden. Nach der Veröffentlichung ist die eingestellte Anwendung jedoch gesperrt, das bedeutet, Änderungen können nicht mehr durch den Entwickler direkt durchgeführt werden. Nach der Veröffentlichung befindet sich jedoch neben dem Namen der Anwendung der neue Link Change Listing Info. Durch Anwahl dieses Links wird ein Formular angezeigt, in welchem die gewünschten Änderungen beschrieben werden müssen. Sind es eher leichte Änderungen, werden diese von einem Apex-Teammitglied durchgeführt. Handelt es sich um weitreichende Änderungen, wird der Status der Anwendung auf Public – In Edit gesetzt und die Anwendung kann erneut an das ARB gesendet werden.

5.7


Nachdem die Anwendung fertig gestellt und veröffentlicht ist, kann diese zukünftigen Benutzern vorgestellt werden. Jedoch wäre es sehr mühsam, und oft auch gar nicht erwünscht oder möglich, wenn jeder potentielle Benutzer die Anwendung erst selbst installieren und Daten eingeben muss. Dieses Verfahren ist zwar von der herkömmlichen Entwicklung und Vertrieb von Anwendungen durchaus bekannt, spielt aber bei OnDemand-Anwendungen keine Rolle mehr. Zusätzlich zur entwickelten Anwendung kann deshalb eine als Test Drive Organization bezeichnete Beispielinstallation angelegt werden. Diese Installation verhält sich wie eine normaler Salesforce.com-Account mit dem Unterschied, dass die gewünschte Apex-Anwendung bereits vorinstalliert ist. Der potentielle Anwender kann hier in Ruhe alle Möglichkeiten ausprobieren, ohne in die Gefahr zu kommen, etwas irreparabel zu zerstören. Jede Test Drive Organisation kennt zwei Benutzer. Zum einen ist das der Administrator und zum anderen ein Read-Only-Benutzer. Mit Hilfe des Administrator-Zugangs kann die Beispielanwendung angepasst werden. Hier sind die Eingabe von Beispieldaten sowie die Anpassung des Demo-Account möglich. Nach der Installation der Test Drive Organisation sollten auf jeden Fall Beispieldaten eingegeben werden, um den potentiellen Anwendern einen möglichst guten Einblick in die neue Anwendung zu verschaffen. Um eine Test Drive Organisation zu erstellen, ist der normale Salesforce.com-Zugang notwendig. Am besten nutzt man natürlich den Account, mit dessen Hilfe auch die Entwicklung durchgeführt worden ist. Unter Setup → Exchange → Share Apps kann die gewünschte Anwendung ausgewählt werden. Im Bereich der Uploads muss die für den Test Drive anzuwendende Version ausgewählt werden. Mit Hilfe des Button Create Test Drive wird jetzt eine neue Test Drive Organisation erstellt.


159



Abbildung 5.38: Testanwendung

Als Pflichtfeld muss der Upload-Name angegeben werden. Hierbei wird automatisch ein entsprechender Vorschlag von Apex eingetragen. Normalerweise kann der Name auch so genutzt werden, enthält er doch schon alle wichtigen Daten. Nach der Bestätigung der Eingabe beginnt der Prozess des Erzeugens des Test Drive. Je nach Größe der Anwendung kann dies einige Zeit in Anspruch nehmen. Man muss aber hier nicht warten, sondern kann, wenn gewünscht, mit der Arbeit an anderer Stelle fortfahren. Nach einiger Zeit erfolgt die Benachrichtigung über die Fertigstellung des Test Drive per E-Mail. In der E-Mail sind nochmals alle wichtigen Daten, wie Passwort, Nutzernamen und Zugangsdetails der Anwendung enthalten. Auf der Seite der Anwendung kann man sich jederzeit über den Erfolg informieren (siehe Abbildung 5.39).

Abbildung 5.39: Testanwendung wurde erzeugt

Der Zugang zu der Testanwendung erfolgt über den Administrator mit dem Benutzernamen admin@[upload name].demo. Ein potentieller Benutzer der Anwendung kann den Benutzernamen eval@[upload name].demo nutzen, um den Read-Only Account anzuschauen.

160


6 6.1

Apex Toolkit für Eclipse

Überblick

In den vergangenen Kapiteln wurden Apex-Anwendungen direkt mit Hilfe des Apex Builder realisiert. Diese direkt in dem Salesforce.com-Account integrierte Entwicklungsumgebung kann für den vollständigen Entwicklungsprozess genutzt werden und stellt eine hohe Funktionalität bereit. Bei der täglichen Nutzung der integrierten Web-Entwicklungsumgebung werden jedoch einige Nachteile sichtbar. So fehlt am Anfang sicherlich die Möglichkeit, schnell das ein oder andere S-Control zu entwickeln und bei Fehlern zu erneuern. Die Entwicklung von S-Controls ist zwar prinzipiell möglich, der Entwicklungsprozess mit ständigem Aufruf derselben Deploy-Edit-Kette ist jedoch recht mühsam. Während der weiteren Entwicklung, speziell dem Aufbau von Reports und komplexeren Abfragen, fehlt einem früher oder später ein Object Browser. Mit dem Apex Toolkit für Eclipse wurde eine Möglichkeit geschaffen, einige Limitierungen einer reinen webzentrierten Entwicklung zu umgehen. So stehen nach der Installation ein Schema-Explorer (oder auch Object Browser) und eine Editiermöglichkeit für die S-Controls zur Verfügung.

6.2

Installation und Apex-Projekt

Das hier genutzte Apex Toolkit für Eclipse trägt die Versionsnummer 8.0.1008 und die Installation setzt eine Eclipse-Entwicklungsumgebung 3.2.1 oder höher voraus. Eclipse selber ist unter der Adresse http://eclipse.org zu finden. Hier stehen auch neuere Versionen der Entwicklungsumgebung und Updates bereit. Das Apex Toolkit für Eclipse wird am besten über den Update-Mechanismus in die Eclipse-Installation eingefügt. Dazu wird die folgende Adresse verwendet. Der Name kann natürlich frei gewählt werden, aber „Apex Toolkit“ bietet sich zur Übersichtlichkeit an. Name: Apex Toolkit URL: http://adnsandbox.com/appexchange/e3.2s

Nach dem die Apex-Toolkit-Seite bekannt ist, kann mit der Installation fortgefahren werden. Hierbei ist wichtig, dass zusätzlich die Callisto-Discovery-Seite einbezogen wird (siehe Abbildung 6.1). Auf der Callisto-Seite befinden sich die benötigten WebToolkits, zum Beispiel für die Arbeit mit HTML oder JavaScript-Seiten.


161


6 – Apex Toolkit für Eclipse

Abbildung 6.1: Update-Seiten für die Installation wählen

Nach dem Aufruf der Update-Seite werden die in Abbildung 6.2 gezeigten Plugins für die Installation angeboten. Je nachdem, was in der Eclipse-Version bereits installiert ist, müssen noch zusätzliche Plugins mitinstalliert werden. Wählen Sie zuerst das Apex Eclipse Toolkit. Wenn im Anschluss die Fehlermeldung zu sehen ist, dass weitere Plugins fehlen, betätigen Sie den Button BENÖTIGTE PLUGINS hinzufügen. Sollte nach der Installation die Apex-Umgebung nicht wie gewünscht funktionieren, sollte man es mit einem „frischen“ Eclipse und einer anschließenden Installation aller von den Update-Seiten benötigten Plugins versuchen. So lassen sich eventuelle Inkompatibilitäten am besten umgehen.

Abbildung 6.2: Installation des Toolkit

War die Installation erfolgreich, kann unter dem Menüpunkt FILE → NEW PROJECT ein Apex-Projekt erzeugt werden. Dazu müssen einige Daten, wie zum Beispiel Benutzername und Passwort des Salesforce.com-Account, sowie ein Projektname angegeben werden. Diese Daten können jedoch später beliebig verändert werden. In einem ersten Schritt werden die benutzerdefinierten S-Controls von dem Salesforce.com-Account zu dem lokalen Rechner übertragen.

162


Abfragen

6.3

Abfragen

Nachdem das Projekt erzeugt und mit dem Salesforce.com-Account verbunden worden ist, steht als eine erste Funktionalität der Schema-Explorer zur Verfügung (siehe Abbildung 6.2). Dazu genügt ein Doppelklick auf den Projekteintrag appexchange.schema. Sehr gut zu sehen ist die Unterscheidung in Standardobjekte und benutzerdefinierte Objekte. Wenn Sie dem Buch bis hier chronologisch gefolgt sind oder zuvor das ApexProjekt ausprobiert haben, finden Sie zum Beispiel unsere Objekte Issue und IssueDetail wieder. Beide haben den Postfix __c für ein benutzerdefiniertes Objekt. Durch Anwahl der einzelnen Felder wird automatisch in der Abfrage Sektion auf der linken Seite eine Abfrage erzeugt, welche auch auf Wunsch ausgeführt werden kann. Mit Hilfe des Schema-Explorer ist es leicht möglich, sich die gewünschten Abfragen zusammenzubauen und zum Beispiel in einem S-Control zu verwenden.

Abbildung 6.3: Schema-Browser

6.4

S-Controls

Die interessanteste Funktionalität des Toolkit ist sicherlich die Entwicklung von S-Controls. Im Gegensatz zur Webseite stehen hier Funktionen wie Syntaxkontrolle des Quelltextes sowie eine automatische Synchronisation mit dem Salesforce.com-Account bereit. Jedes Mal, wenn das S-Control gespeichert wird, wird es übertragen. Man hat somit die Möglichkeit, die Apex-Anwendung in einem Browser offen zu halten, parallel das S-Control zu entwickeln und mittels Refresh im Browser auch gleich anzeigen zu lassen. Die Abbildung 6.4 zeigt die Entwicklung eines Controls.


163


6 – Apex Toolkit für Eclipse

Abbildung 6.4: Entwicklung von S-Controls

Zusätzlich zum Quelltext des Controls können Metadaten eingegeben werden. Auch eine Vorschau ist möglich. Hierbei sollte jedoch beachtet werden, dass es möglicherweise Unterschiede in der Darstellung und Nutzung zum Salesforce.com-Account gibt. Eine abschließende Überprüfung in der realen Anwendung ist notwendig. Neue S-Controls werden über das Kontextmenü des Ordners S-Controls angelegt. Ein kleiner Hinweis noch am Ende: Wenn Sie mittels Sync Folder eine Synchronisation mit dem Salesforce.com-Account durchführen, werden zuerst alle lokal gespeicherten S-Controls gelöscht. Das geschieht sehr effektvoll, indem jedes einzelne S-Control aus der Liste entfernt wird. Aber keine Sorge, die auf dem Salesforce.com-Account gespeicherten Controls werden nicht gelöscht – nach der Synchronisation sind alle wieder vorhanden.

164


7 7.1

S-Controls und das Ajax Toolkit

Überblick

Wenn die Anwendungen komplexer werden, oder auch eine spezielle Funktionalität gewünscht wird, kommt man mit dem Ajax Toolkit für Apex in Berührung. Im Prinzip versteckt sich dahinter der Zugriff per JavaScript auf das Apex API. Somit stehen sämtliche Objekte und Tabellen zur Verfügung, welche auch aus dem Salesforce.com-Account her bekannt sind.

7.2

JavaScript

Obwohl JavaScript so schön mit dem Wort Java beginnt, ist hiermit nicht die Sprache Java gemeint. Es handelt sich vielmehr um eine eigenständige Sprache. JavaScript wurde ursprünglich von Netscape entwickelt und ist heute der Standard unter den clientseitigen Sprachen. Der Webbrowser interpretiert den Quelltext und führt diesen in einer Sandbox, auf der Seite des Benutzers, auch aus. Das bedeutet, dass die Ausführung überwacht werden kann. Jedoch gab es immer wieder die ein oder andere Schwachstelle in der Sicherheit, so dass die Ausführung von Seiten des Benutzers abgeschaltet werden kann. Da wir hier jedoch von Apex-Anwendungen sprechen, also Anwendungen, die der Benutzer bewusst testet und in seinem Salesforce.com-Account installiert, kann davon ausgegangen werden, dass JavaScript eingeschaltet wird oder eingeschaltet werden kann. Es handelt sich ja hierbei nicht um unbekannte Seiten im Internet. JavaScript liegt in verschiedenen Versionen vor und es kann zu Inkompatibilitäten zwischen verschiedenen Browsern kommen. Deshalb sollte man in einem ersten Schritt die Anwendung oder das S-Control für einen genau bekannten Interessenkreis entwickeln. In diesem Kapitel erfolgt keine Beschreibung der Syntax von JavaScript noch soll eine Einführung in die Programmierung gegeben werden. Dazu gibt es sehr viele Bücher, welche sich ausschließlich mit dem Thema beschäftigen.


165


7 – S-Controls und das Ajax Toolkit

7.3

Struktur einer JavaScript-Anwendung

JavaScript-Quelltext kann an fast beliebiger Stelle in eine HTML-Seite eingefügt werden, jedoch hat sich die folgende Struktur bewährt: Titel Inhalt der Seite

Dabei wird das Script in den Header der HTML-Seite nach dem Titel aufgenommen. Das hat wiederum Vorteile beim Laden der Seite. Der JavaScript-Quelltext wird mittels dem SCRIPT Tag eingeschlossen. Da ältere Browser oft Probleme haben, den Quelltext des Scripts zu verstehen, behilft man sich mit einem simplen Trick. Das Script selber wird in einen HTML-Kommentar eingeschlossen. Dabei ist der öffnende HTML-Kommentar gleichzeitig eine JavaScript-Kommentarzeile, während der schließende HTML-Kommentar mit einem JavaScript-Kommentarbeginn versehen wird. Da es mühsam wäre, immer wieder die gleichen JavaScript-Funktionen in die HTML-Seite aufzunehmen, existiert die Möglichkeit, eine Scriptdatei zu importieren. In späteren Abschnitten wird man sehen, dass das Ajax Toolkit davon reichlich Gebrauch macht. ...

Die einzufügenden Quelltexte können hier auch relativ zur aufgerufenen Seite stehen. Ein weiteres Problem ist die Möglichkeit, von Seiten des Anwenders, JavaScript auszuschalten. In einem solchen Fall wird unser S-Control nicht ausgeführt, was zu erheblichen Beeinträchtigungen der Funktionsweise der Anwendung führen kann. Abhilfe schafft hier die Angabe eines zusätzlichen Blocks in der HTML-Seite, welcher im Fall, dass Scripts abgeschaltet sind, ausgeführt wird. Dieser Block wird mit dem NOSCRIPTTag eingeschlossen und kann beliebigen HTML-Text aufnehmen.

166



JavaScript ist im Browser nicht aktiviert. Bitte aktivieren Sie es für eine korrekte Anzeige der Seite.

Zusätzlich zum vollständigen Abschalten von JavaScript bieten moderne Browser auch die Möglichkeit, bestimmte Teile der Funktionalität zu deaktivieren. Es macht sich deshalb notwendig, bestimmte Richtlinien für die Nutzung des S-Controls vorzugeben.

7.4


Nach den Grundlagen kann man die Apex-spezifischen Ergänzungen vornehmen. Dabei bleibt das Grundgerüst einer JavaScript-Anwendung erhalten. Wie das S-Control in eine Apex-Anwendung eingebaut und verwendet wird, kann dem Kapitel 4 oder 5 entnommen werden. S-Controls sollten zudem mit dem Eclipse Plugin entwickelt werden, da sich so am besten zwischen Entwicklung und Erprobung wechseln lässt. Der folgende Quelltext zeigt die Apex-typischen Ergänzungen: Der Titel

1. Apex Ajax Toolkit An dieser Stelle wird das Apex Ajax Toolkit eingebunden. Mit der Bibliothek sforceclient.js bekommt man alle zur Verfügung stehenden Objekte. 2. Initialisierung In einem weiteren Schritt muss das Toolkit initialisiert werden. Wenn die HTML-Seite als S-Control verwendet wird, braucht keine weitere Authentifizierung zu erfolgen. Wichtig ist die Anweisung unter dem Punkt 2.2, hierbei werden das zu verwendende API und die aktuelle Session bekannt gemacht. Beide Variablen sind während der Ausführung bereits initialisiert. Bevor man selbst mit dem Toolkit arbeiten kann, muss dieses vollständig initialisiert worden sein. Dazu kann eine Methode registriert werden (2.1), welche nach der vollständigen Initialisierung des Toolkit aufgerufen wird. Wenn Sie zum Beispiel Werte auf einer Seite der Apex-Anwendung darstellen werden, können Sie den Quelltext dazu, beginnend in dieser Methode, ablegen. 3. Initialisierung aufrufen Methoden in einem JavaScript-Block werden nicht automatisch beim Aufbau der Seite ausgeführt. Deshalb kann man sich mit der ONLOAD-Funktionalität einen definierten Eintrittspunkt schaffen. Wurde die HTML-Seite geladen, kann mit der Abarbeitung der JavaScript-Anweisungen gestartet werden. Wird die HTML-Seite in einer alleinstehenden Webanwendung eingesetzt, das bedeutet nicht als S-Control innerhalb einer Apex-Anwendung, muss noch ein explizites Login hinzugefügt werden. Siehe dazu auch die Methode login in der Dokumentation.

168



7.5


Ist die Initialisierung geschafft, steht einem das vollständige Apex API zur Nutzung zur Verfügung. Der folgende Quelltext zeigt eine Abfrage Issues mit dem Status Neu in der Issue-Tabelle.

Die Anzahl der Elemente, welche gefunden worden sind, wird auf der HTML-Seite angezeigt. Dazu wird direkt mit dem Document Object Model der Seite gearbeitet und der Wert an der gewünschten Stelle eingefügt (siehe folgender Quelltext).

Natürlich sind über das Apex API beliebige Abfragen, das Einfügen, Löschen oder Ändern von Datensätzen sowie viele weitere Operationen möglich. Das API stellt den Apex Web Service über JavaScript zur Verfügung. Es eignet sich daher sehr gut für die Entwicklung von S-Controls in integrierten Apex-Anwendungen. Weitere Möglichkeiten des API, sowie genauere Hintergründe zu den Abfragen, werden im Kapitel 8 näher beleuchtet.


169



8

Anwendungen entwickeln mit dem Apex Web Service API

8.1

Web Services

8.1.1

Überblick

In den vorherigen Kapiteln wurde die Entwicklung von integrierten Apex-Anwendungen beschrieben. Solche Anwendungen laufen vollständig innerhalb des Salesforce.comAccount. Der Zugriff auf die gespeicherten Daten ist jedoch auch direkt möglich. Somit erhält man die größte mögliche Freiheit bei dem Design und der Funktionalität von Anwendungen. Im Gegenzug muss natürlich speziell darauf geachtet werden, wie genau mit diesen Daten umgegangen wird. Man sollte hier mit einem Testaccount arbeiten oder zumindest eine Sicherung des Datenbestandes vornehmen. In diesem ersten Unterkapitel (8.1) wird eine Einführung in die Welt der Web Services gegeben. Wenn Sie sich schon damit befasst haben oder gleich etwas praktischer werden wollen, können Sie mit dem Kapitel 8.2 direkt fortfahren. In der Literatur existiert eine Menge von Definitionen für Web Services. Wir wollen an dieser Stelle von Anwendungen und Modulen ausgehen, welche ihre Funktionalität über eine standardisierte Serviceschnittstelle nach außen geben. Die Anwendung mit der Schnittstelle zusammen bildet den Web Service. Eine große Bedeutung hat die Web-Service-Schnittstelle durch die Unabhängigkeit von jeglicher Programmiersprache oder jeglichen Betriebssystems erlangt. Die Schnittstelle wird in der Web Service Description Language (WSDL) beschrieben. Betrachtet man sich die Datei genauer, fällt als Erstes das XML-Format und als Zweites die Beschreibung von Operationen, Datentypen, Nachrichten und Services auf. Die Kommunikation mit einem Web Service geschieht über Nachrichten im XML-Format. Da sowohl die Service-Schnittstelle an sich als auch die Nachrichten und Datentypen in einer Textform (XML) definiert sind, fällt es nicht schwer, den universellen Charakter dahinter zu erkennen. Diese Technologie ermöglicht es uns mit beliebigen Sprachen, wie zum Beispiel Java, C# oder auch JavaScript, auf einen Salesforce.com-Account zuzugreifen. Web Services existieren heute für die verschiedensten Business-Anforderungen. Sie können öffentlich (Suchdienste, Übersetzungen oder auch Pakettracking) oder auch firmenintern vorhanden sein. Services selbst können in einem Repository aufbewahrt oder zu Prozessen assembliert werden. Nicht zuletzt bilden sie die technische Grundlage einer Service-orientierten Architektur. Gerade im B2B-Bereich lassen sich somit externe Anwendungen und Daten in interne Prozesse integrieren.


171


8 – Anwendungen entwickeln mit dem Apex Web Service API

8.1.2

Web Service Description Language (WSDL)

Grundlage eines Service bildet dessen Definition mit Hilfe der Web Service Description Language (WSDL). Günstigerweise tragen die Dateien auch die Endung wsdl. An dieser Stelle wird, der Übersichtlichkeit halber, ein Beispielservice verwendet (die Salesforce WSDL ist wesentlich mächtiger). Die einzelnen Bestandteile lassen sich jedoch analog auf den Salesforce.com Web Service übertragen und können dort wieder gefunden werden. Unser Beispielservice (EchoService) soll lediglich eine Operation definieren (echo), welche eine Zeichenkette als Parameter übernimmt und auch eine Zeichenkette zurück gibt. Die vollständige Definition des Service kann dem folgenden Quelltext entnommen werden. Auf die einzelnen Bestandteile und ihre Bedeutung wird dann im Anschluss eingegangen.

172


Web Services

Definition (1) Hier werden alle verwendeten Namensräume definiert. Solche Namensräume werden für vordefinierte Datentypen (http://www.w3.org/2001/XMLSchema), die Strukturinformation des WSDL selbst (http://schemas.xmlsoap.org/wsdl/), aber auch den konkreten benutzerdefinierten Service (http://www.arlanis.com/echo/) benötigt. Zusätzlich werden der Name des Service sowie mögliche optionale Metadaten angegeben. Datentypen (2) Zwischen einem Service und einem Client werden die verschiedensten Nachrichten ausgetauscht. Diese Nachrichten beinhalten wiederum Nutzdaten, welche durch Datentypen in dieser Sektion definiert werden. Einige Typen sind im XML-SchemaStandard bereits definiert (wie zum Beispiel string). Die Definition der Datentypen muss an dieser Stelle jedoch nicht erfolgen. Es hat sich auch bewährt, diese in eine eigene Schema-Datei auszulagern und in der Servicebeschreibung zu importieren. Welche Technik verwendet wird, entscheidet der Serviceanbieter. Für den Benutzer spielt die Lage eine


173



untergeordnete Rolle, da die WSDL zu Language Compiler solche Lageangaben automatisch auflösen können. Nachrichten (3) In dieser Sektion werden die Nachrichten definiert, welche zwischen Service und Client ausgetauscht werden. Die Nachrichten verwenden dazu die vorher definierten Datentypen. Zu beachten ist jedoch, dass die Servicebeschreibung im WSDL sehr komplexe Nachrichtenformen zulässt. Die spätere Abbildung in eine konkrete Programmiersprache kann deshalb zu Hilfskonstrukten (zum Beispiel Containerklassen) führen. Das genaue Aussehen einer Nachricht während des Transports kann dem Kapitel 8.1.3 entnommen werden. Service Interface (4) Die Schnittstelle des Service wird in dieser Sektion definiert. Die Definition besteht aus einer Menge von Operationen, die wiederum zuvor definierte Nachrichten für Eingabe und Ausgabe enthalten. Die Servicedefinition wird in modernen Sprachen, wie Java oder C#, meistens in ein Interface oder eine Klasse übersetzt. Diese enthält dann die durch die Operationen definierten Methoden. Mit der Angabe der Sektionen eins bis vier ist der Service im eigentlichen Sinne definiert. Damit ein potentieller Client aber auf einen konkreten Service zugreifen kann, müssen weitere Angaben zur verwendeten Art der Datenübertragung und -kodierung sowie zur tatsächlichen Lage des Service angegeben werden. Binding (5) In der Binding-Sektion wird das konkrete Protokoll und Format für die Nachrichten und den Transport definiert. Service (6) Die Implementierung eines konkreten Service wird hier beschrieben. Durch die Angabe der Serviceadresse kann ein Client später den Service im Netzwerk finden. Im Salesforce.com-Partner-WSDL findet sich dazu zum Beispiel die Angabe: Sforce SOAP API

Die Web-Service-Beschreibung (WSDL) kann noch eine Menge weiterer, zusätzlicher Angaben zu einem Service enthalten. Ein Beispiel hierfür sind Informationen zu möglichen Fehlern, die während der Ausführung einer Operation auftreten können. Weitere Information können der WSDL-Spezifikation auf den Seiten des World Wide Web Consortium (W3C) entnommen werden [W3C01].

174


Web Services

8.1.3

Nachrichten

Zwischen einem Service und den Clients werden die im WSDL definierten Nachrichten ausgetauscht. Dabei ist jedoch zu beachten, dass im WSDL lediglich die Nutzdaten definiert sind – also der eigentliche Inhalt. Wenn Probleme mit der Nachrichtenübermittlung entstehen oder doch eine Inkompatibilität zwischen den Systemen vermutet wird, kann man sich die übermittelten Nachrichten meist direkt zur Ursachenforschung anschauen. Als der gängige Standard für die Kommunikation hat sich das Simple Object Access Protocol (SOAP) etabliert. Da es sich bei der On-Demand-Programmierung des Salesforce.com-Account um einen webzentrierten Ansatz handelt, wird man auch hauptsächlich mit diesem Protokoll konfrontiert. Wie bereits geschrieben, ist der genaue Aufbau der Nachricht hier lediglich von allgemeinem Interesse. Normalerweise werden alle Details durch die Bindung an eine konkrete Sprache versteckt. Die Nachrichten selber können mit beliebigen TCP-Monitoren sichtbar gemacht werden. Die Abbildung 8.1 zeigt einen solchen Monitor von Apache Axis [AXIS01] sowie die Nachrichten, die zwischen Service und Client ausgetauscht werden.

Abbildung 8.1: TCP-Monitor von Apache Axis

Der folgende Quelltext zeigt etwas detaillierter eine Anfrage an den EchoService.


175



World

Envelope (1) Der Umschlag fasst die in der Nachricht definierten Hauptelemente Header und Body zusammen. Im Weiteren werden hier die benötigten Namensräume definiert. Header (2) Im Kopfbereich werden alle Daten übertragen, welche nicht zur eigentlichen Nachricht gehören. Das können zum Beispiel Informationen zur Sicherheit, zur Transaktion oder auch die Adressinformationen sein. Weiterführende Informationen findet man in der generellen Literatur zu Web Services. Body (3) Im Body werden die von uns definierten Nachrichten übertragen. Dabei lassen sich die Datentypen leicht in der WSDL wieder finden. Im Falle eines Fehlers werden im Body Informationen zum Fehler übertragen. Natürlich kann solch eine Nachricht noch mehr Informationen enthalten. Genaueres dazu kann in der Spezifikation des World Wide Web Consortium gefunden werden [W3C02].

8.1.4

WSDL zu Language-Generatoren

Die Struktur des Service, seine Operationen und die Zugriffsmodalitäten sind in der WSDL abgelegt. Damit könnte man eigentlich schon arbeiten. Es ist nicht verboten, sich die Nachricht (das XML) selbst zusammenzubauen und an den Service zu senden. Jedoch wird dies in der heutigen Zeit keiner mehr ohne einen wirklichen Grund machen. Mit der zunehmenden Popularität der Web-Service-Technologien entstanden auch die WSDL zu Language (Java, C#, ...) -generatoren. Mit Hilfe dieser Generatoren ist es möglich, aus einer WSDL-Datei eine Bibliothek für den Zugriff in einer konkreten Sprache zu erzeugen. Mit Hilfe dieser Bibliothek arbeitet man dann so, als würde lokal auf den Service zugegriffen werden. Ausgangspunkt ist das WSDL. Danach muss ein Generator gefunden und genutzt werden. Jedes der modernen heutigen Sprachsysteme bringt normalerweise einen solchen Generator im Standardumfang mit. Wenn zum Beispiel Apache Axis2 eingesetzt wird, trägt dieser den Namen wsdl2java und befindet sich im bin Verzeichnis der Installation. Jetzt kann die WSDL-Datei genutzt werden, um die entsprechenden Java-Klassen zu erzeugen (der –u Parameter gibt an, dass die XML zu Java-Bindingklassen als extra Java-

176


Web Services

Dateien erzeugt werden). Im Kapitel 8.1.5 wird erläutert, wie Salesforce.com die WSDL in welcher Form zur Verfügung stellt. > WSDL2Java –u –uri partner.wsdl

Betrachtet man sich die erzeugten Dateien, sind wiederum die einzelnen WSDL-Sektionen erkennbar. Datentypen, Nachrichten und Schnittstellen werden in den entsprechenden Java-Quelltext umgesetzt. Dieser enthält dann auch gleich die Funktionalität, um die Nachrichten in eine XML-Datei umzusetzen oder daraus zu lesen.

Abbildung 8.2: Salesforce.com Partner API in Java

Zusätzlich erzeugen moderne Generatoren noch Klassen für den Zugriff auf den Service selbst. Damit entfällt für den Benutzer die fehleranfällige Konfiguration einer http-Verbindung oder die Angabe der speziellen Verbindungsparameter für den Service.

Abbildung 8.3: Hilfsklassen für den Zugriff auf den Service

Was hier am Beispiel von Java demonstriert worden ist, funktioniert im Praktischen mit fast jeder anderen Sprache auch. Auf den Apache-Axis-Seiten ist zum Beispiel auch noch ein Generator zu Microsoft C# vorhanden. Für weitere Generatoren kann man einfach einen Websuche bemühen oder direkt die verwendete Entwicklungsumgebung befragen.

8.1.5

Salesforce WSDL

Die Salesforce WSDL kann leicht über Setup → Integrate → Apex API gefunden werden. Nach der Anwahl des Links hat man die Auswahl zwischen der Partner WSDL und der Enterprise WSDL. Durch Anwahl der entsprechenden Links wird automatisch die entsprechende WSDL-Datei angezeigt. Partner WSDL Die Partner WSDL ist die generische Version für ISVs und Salesforce.com Partner. Dieser Service erlaubt den Zugriff auf jeden beliebigen Salesforce.com-Account (natürlich muss immer noch ein Passwort angegeben werden, dazu aber ab dem Kapitel 8.2 mehr). Wenn man also eine Anwendung entwickeln möchte, die mit jedem Salesforce.com-Account genutzt werden kann, ist das die richtige Datei. Die Partner WSDL ist fest vorgegeben und unveränderlich.


177



Enterprise WSDL Im Gegensatz zur generischen Partner WSDL ist die Enterprise WSDL lediglich für einen Salesforce.com-Account zu einem Zeitpunkt gültig. Das bedeutet, anhand der aktuellen Tabellen und Objekte wird eine spezielle Servicebeschreibung erzeugt. Schaut man sich die Beschreibung etwas genauer an, fällt auf, dass auch die Tabellen und benutzerdefinierten Objekte enthalten sind. Haben Sie zum Beispiel den Issue Manager aus den vorherigen Kapiteln entwickelt, werden Sie den komplexen Datentyp Issue__c wieder finden. Die Enterprise WSDL wird bei jeder Anfrage neu erzeugt. Welche WSDL für Sie günstig ist, entscheidet nicht zuletzt die Anwendung. Mit der Partner WSDL hat man zwar generischen Zugriff auf die Informationen, jedoch auch einen erhöhten Aufwand bei der Benutzung. Die Flexibilität ist hierbei sehr hoch. Die Enterprise WSDL enthält die definierten Datentypen, macht sie dadurch aber unflexibler bei möglichen Änderungen oder Wechseln des Salesforce.com-Account. Die Typsicherheit ist hierbei natürlich am höchsten.

8.2

Eine erste Verbindung

Im vorausgehenden Unterkapitel wurde definiert, was unter einem Web Service zu verstehen ist. Wie dort dargelegt wurde, stellt auch Salesforce.com einen Teil seiner Funktionalität als Web Service zur Verfügung; in diesem Teil des Kapitels soll zunächst unabhängig vom konkreten Beispiel erläutert werden, wie eine Verbindung mit Salesforce.com unter Verwendung des entsprechenden API hergestellt werden kann. In diesem Zusammenhang sind auch Aspekte des Umgangs mit den Verbindungsdaten zu diskutieren. Eine konkrete Fallstudie, die auf diesem Abschnitt aufbaut und in der das Web Service API zur Anwendung kommen wird, findet sich in Abschnitt 8.3, Fallstudie: Verwendung des Web Service API für einen Angebotsrechner. Die in diesem Abschnitt enthaltenen Codebeispiele sind stets in Java formuliert und lassen sich daher plattformübergreifend anwenden. Als Entwicklungsumgebung für Javaprogramme wird Eclipse eingesetzt, wenngleich natürlich auch andere Umgebungen wie etwa NetBeans uneingeschränkt verwendbar sind.

8.2.1

Vorbereitungen

Bei der Verwendung des Web Service API von Salesforce.com gelten die gleichen Zugriffsrechte und -beschränkungen wie bei der gewöhnlichen Nutzung von Salesforce.com in einem Internetbrowser. Folglich werden zur Ausführung der gewünschten Operationen zunächst ein Benutzer mit entsprechender Berechtigung und das zugehörige Kennwort benötigt. In vielen Fällen sind die reinen Salesforce.com-Zugangsdaten jedoch nicht ausreichend, um das Web Service API verwenden zu können. In vielen Firmennetzwerken wird heute ein Proxy eingesetzt, um den Internetverkehr besser regulieren zu können. Wird ein Proxy im Netzwerk verwendet, so muss zum Aufbau einer Internetverbindung zusätzlich der Proxy-Host und der Proxy-Port angegeben werden; ist der Proxy zudem kennwortgeschützt, sind außerdem der Proxy-Benutzername und das Proxy-Kennwort erforderlich. Genauere Informationen zum Thema Proxy können beim zuständigen Netzwerkadministrator erfragt werden.

178



Mit der Beschaffung der korrekten Werte für die zuvor genannten sechs Verbindungsparameter ist die erste Hürde genommen. Als Nächstes gilt es, das richtige Salesforce API zu verwenden. In Abschnitt 8.1.5, Salesforce WSDL, wurde bereits darauf verwiesen, dass es zwei Varianten des APIs gibt. Da in der Fallstudie (siehe Abschnitt 8.3 Fallstudie: Verwendung des Web Service API für einen Angebotsrechner) ein generischer Ansatz verfolgt werden wird, der in der Lage sein muss, auf beliebige Salesforce.com-Daten zuzugreifen, ist das Partner API die richtige Wahl. Um die Beschreibung der Integration des Web Service API in das eigene Softwareprojekt möglichst einfach zu halten, wird im Folgenden Bezug genommen auf ein bereits zusammengestelltes Beispielpaket PartnerSamples7.0.zip, das von der Salesforce.com-Webseite heruntergeladen werden1 kann; neben den gebrauchsfertig erzeugten Stubs, allen zur Verwendung der Stubs erforderlichen Bibliotheken und einem kleinen Beispielprogramm enthält dieses zip-Archiv natürlich auch die Datei partner.wsdl, welche die vollständige Beschreibung der Web-Service-Schnittstelle enthält. Neben dem hier beschriebenen Paket sind unter [SF05] auch für andere Programmiersprachen solche Pakete verfügbar. Vor Beginn der eigentlichen Arbeit muss zunächst ein Java-Projekt in Eclipse für den Zugriff auf das Salesforce API konfiguriert werden: Nach dem Start von Eclipse legt man ein neues Projekt an, indem man im Menü FILE → NEW → PROJECT... auswählt; im folgenden Dialog wählt man zuerst JAVA PROJECT als Typ aus der Liste und klickt anschließend in NEXT >.

Abbildung 8.4: Erster Schritt zum Anlegen eines neuen Eclipse-Projekts

Im nächsten Schritt benennt man das Projekt, etwa mit „MySalesforceProject“, und selektiert die Optionen CREATE NEW PROJECT IN WORKSPACE, USE DEFAULT JRE und CREATE SEPARATE SOURCE AND OUTPUT FOLDERS; dabei muss man darauf achten, dass ein aktueller JDK2 auf dem eigenen Rechner installiert ist und dieser von Eclipse auch standardmäßig verwendet wird. Diesen Dialog beendet man durch einen Klick auf FINISH. 1 2

Die zur Zeit der Entstehung dieses Buches aktuelle Version 7.0 ist zu finden unter http://www.salesforce.com/us/developer/downloads/PartnerSamples7.0.zip. Ein aktuelles JDK kann geladen werden unter http://java.sun.com/javase/downloads/index.jsp; Für die Arbeit mit dem Salesforce API ist der Einsatz von Version 5 des JDK (oder neuer) ratsam.


179



Abbildung 8.5: Zweiter Schritt zum Anlegen eines neuen Eclipse-Projekts

Nun müssen die einzelnen Elemente des Salesforce API zum Projekt hinzugefügt werden. Der Einfachheit halber werden die Bibliotheken und Stubs verwendet, die in PartnerSamples7.0.zip enthalten sind; aus diesem zip-Archiv werden die beiden Verzeichnisse lib und src extrahiert; Eclipse wird nun so konfiguriert, dass die Inhalte von lib dem Java Build Path hinzugefügt werden; dazu wählt man das Projekt im PACKAGE EXPLORER aus und drückt (Alt)+(¢), um die Projekteigenschaften zu öffnen. Im linken Teil des sich öffnenden Fensters wählt man dann JAVA BUILD PATH aus und anschließend im rechten Teil des Fensters den mit LIBRARIES beschrifteten Tab. Dann klickt man auf ADD EXTERNAL JARS...

Abbildung 8.6: Hinzufügen externer Bibliotheken zum Build Path

180



Im erscheinenden Dateidialog navigiert man in das Verzeichnis, welches die aus dem zip-Archiv entpackten Dateien enthält und öffnet dort das Unterverzeichnis lib; dann wählt man alle enthaltenen jar-Dateien aus und klickt auf ÖFFNEN.

Abbildung 8.7: Auswahl der Bibliotheken im Dateidialog

Im Anschluss daran kann das Fenster mit den Projekteigenschaften durch Klick auf OK geschlossen werden. Es verbleibt der Import der Stubs in das Eclipse-Projekt; da diese Klassen bereits als Quelltext vorliegen, wählt man im Menü FILE → IMPORT... und in dem sich öffnenden Dialog aus der Rubrik GENERAL den Punkt FILE SYSTEM. Um zum nächsten Schritt zu gelangen, klickt man auf NEXT >.

Abbildung 8.8: Erster Schritt zum Import von Java-Quelltexten in ein Eclipse-Projekt


181



Unter FROM DIRECTORY gibt man den Pfad zu dem src Verzeichnis an, das aus der Datei PartnerSamples7.0.zip entpackt wurde. Anschließend kann in dem darunter erscheinenden Dateibaum das Verzeichnis src/com markiert werden, das alle benötigten Quelltexte enthält. Unter INTO FOLDER sollte MySalesforceProject/src eingetragen sein (wobei „MySalesforceProject“ natürlich durch den tatsächlich gewählten Projektnamen zu ersetzen ist). Nach Auswahl der Option CREATE SELECTED FOLDERS ONLY beendet man den Import durch Klick auf FINISH.

Abbildung 8.9: Zweiter Schritt zum Import von Java-Quelltexten in ein Eclipse-Projekt

Um die vorbereitende Arbeit abzuschließen, fügt man dem Eclipse-Projekt schließlich noch eine neue Klasse hinzu, die später den Code für die Salesforce.com-Interaktion enthalten soll. Dazu wählt man im Menü FILE → NEW → CLASS aus; die Einträge für den folgenden Dialog sind in der folgenden Abbildung festgehalten. Anstelle des beispielhaft gewählten Namens „MySalesforceBridge“ kann natürlich auch eine sinnvollere Bezeichnung für die neue Klasse gewählt werden. Durch Klick auf FINISH beendet man das Anlegen der neuen Klasse.

182



Abbildung 8.10: Anlegen einer neuen Klasse

Wenn alles richtig gemacht wurde, sollte das Eclipse-Fenster nun etwa wie folgt aussehen:

Abbildung 8.11: Fertiges Eclipse-Projekt

Das Web Service API von Salesforce.com steht nun zur Nutzung zur Verfügung.


183



8.2.2 Verbindung mit Salesforce.com aufbauen In diesem Abschnitt wird die zuvor angelegte Klasse „MySalesforceBridge“ mit Inhalt gefüllt. Ziel ist es, eine universell verwendbare Klasse zu erhalten, mit der man sich am Salesforce.com-System anmelden kann; in dem später betrachteten Fallbeispiel kann diese Klasse dann verwendet werden. Um die Lesbarkeit des Quelltextes zu erhöhen und um Schreibarbeit zu sparen, werden zunächst die für den Verbindungsaufbau zu Salesforce.com erforderlichen Bestandteile des Partner-API importiert, etwa so wie im folgenden Quelltextsegment dargestellt. import import import import import import

com.sforce.soap.partner.LoginResult; com.sforce.soap.partner.SessionHeader; com.sforce.soap.partner.SforceServiceLocator; com.sforce.soap.partner.SoapBindingStub; com.sforce.soap.partner.fault.ExceptionCode; com.sforce.soap.partner.fault.LoginFault;

Bei Verbindungen über das Internet gibt man ein Timeout an, um so zu definieren, wie lange auf die Antwort des kontaktierten Servers gewartet werden soll. Da die Verbindungsqualität Schwankungen unterworfen ist, sollte dieser Wert nicht zu knapp bemessen sein, aber auch nicht zu großzügig, um im Fall eines Netzwerkausfalls eine geeignete Fehlermeldung ausgeben zu können. In der Praxis hat sich ein Wert von 300 Sekunden als sinnvoll erwiesen; im Quelltext muss dieser Wert jedoch in Millisekunden angegeben werden: public final static int SF_TIMEOUT = 300000;

In der Java-Klasse werden auch einige globale Attribute benötigt, die innerhalb des Konstruktors initialisiert werden, um sicher zu stellen, dass diese Attribute gültige Werte enthalten: private String logonUserName, password; private String proxyHost, proxyPort, proxyUser, proxyPassword; private SoapBindingStub binding; public MySalesforceBridge() { logonUserName = "[email protected]"; password = "myPassword"; proxyHost = "ourProxy.myCompany.com"; proxyPort = "3128"; proxyUser = "myProxyLogin"; proxyPassword = "myProxyPassword"; binding = null; }

184



Der aufmerksame Leser wird bemerkt haben, dass dem Attribut binding noch kein konkreter Wert zugewiesen wurde. Der Wert null soll nämlich immer dann genutzt werden, wenn die Verbindung zu Salesforce.com noch nicht erfolgreich aufgebaut ist. Um die Login-Klasse universell verwendbar zu machen, erscheint es sinnvoll, noch einen Getter für das binding zu definieren, damit andere Java-Klassen auf die aufgebaute Verbindung zugreifen können. public SoapBindingStub getBinding() throws Exception { if (binding == null) { // binding is not available ... we have to login first throw new Exception("Not connected to Salesforce."); } return binding; }

Für den eigentlichen Verbindungsaufbau mit dem Salesforce.com-Server wird eine eigene Methode login() implementiert. Ist der Login-Versuch erfolgreich, so erhält das Attribut binding in dieser Methode einen Wert, der als eindeutige Verbindungskennung bei späteren Zugriffen auf Salesforce.com verwendet wird. Durch dieses Vorgehen erspart man sich ein neuerliches Login für jede Einzelanfrage. public void login() { // set the proxy if necessary if (proxyHost.length() > 0 && proxyPort.length() > 0) { sysProps = System.getProperties(); sysProps.put("proxySet", "true"); sysProps.put("http.proxyHost", proxyHost); sysProps.put("http.proxyPort", proxyPort); if (proxyUser.length() > 0) { sysProps.put("http.proxyUser", proxyUser); sysProps.put("http.proxyPassword", proxyPassword); } } // establish a connection to Salesforce try { binding = (SoapBindingStub)new SforceServiceLocator().getSoap(); binding.setTimeout(SF_TIMEOUT); LoginResult loginResult =


185



binding.login(logonUserName, password); binding._setProperty(SoapBindingStub. ENDPOINT_ADDRESS_PROPERTY, loginResult.getServerUrl()); SessionHeader sh = new SessionHeader(); sh.setSessionId(loginResult.getSessionId()); binding.setHeader( new SforceServiceLocator().getServiceName(). getNamespaceURI(), "SessionHeader", sh); return; } catch (LoginFault ex) { ExceptionCode exCode = ex.getExceptionCode(); // we can provide different error messages depending // on the exception code returned ... // a list of available exception codes is contained in // com.sforce.soap.partner.fault.ExceptionCode System.err.println("Salesforce Login Fault: " + exCode.getValue()); } catch (Exception ex) { System.err.println("An unknown Exception occurred"); ex.printStackTrace(); } // we only get here if an exception occurred binding = null; }

Wie bereits bemerkt, werden alle folgenden Interaktionen mit Salesforce.com stets auf das Attribut binding zurückgreifen und so die gerade aufgebaute Verbindung nutzen; deswegen muss im Falle einer Exception auch darauf geachtet werden, dass binding wieder auf null zurückgesetzt wird. Der Vollständigkeit halber implementiert man ergänzend noch eine Methode logout(), mit der das binding wieder ungültig gemacht werden kann. public void logout() { binding = null; }

186



8.2.3 Umgang mit Verbindungsdaten In der Praxis ist es sicherlich nicht dienlich, die Login-Daten zu Salesforce.com fest in einem Java-Quelltext zu verankern, wie das der Einfachheit halber in obigem Beispiel geschehen ist; einerseits verlangen Sicherheitsaspekte nach einer besseren Lösung und andererseits wünscht man sich natürlich etwas mehr Flexibilität, möchte also mit mehr als nur dem einen festen Benutzer auf Salesforce.com zugreifen können. Es hat sich als gute Praxis herausgestellt, die Verbindungsdaten für Salesforce.com in einer XML-Datei zu hinterlegen, die dann für den Verbindungsaufbau eingelesen wird; auf diese Weise ist eine Umparametrierung und Wiederverwendung sehr einfach möglich. Wie genau eine solche XML-Datei strukturiert ist, hat man im Einzelfall zu entscheiden; das im folgenden Beispiel verwendete Format wird in Abschnitt 8.3.2, Verwendung des Salesforce API, noch näher erläutert werden. encryption_class_name password bXlQYXNzd29yZA== proxy_host ourProxy.myCompany.com proxy_password bXlQcm94eVBhc3N3b3Jk proxy_port 3128 proxy_user myProxyLogin user_name [email protected]

Auch Sicherheitsaspekte können bei Verwendung einer XML-Datei zur Parametrierung umfassend behandelt werden. In obigem Beispiel etwa ist bereits ein Eintrag encryption_ class_name vorgesehen, mit dem man auf eine Java-Klasse verweisen kann, mit deren Hilfe die Passworteinträge der XML-Datei ver- und entschlüsselt werden; der genaue Algorithmus hierzu ist frei wählbar. Damit eine derartige Referenzierung der Verschlüsselungsmethode durch den Namen einer Java-Klasse auch funktioniert, ist noch die Einführung eines Interfaces erforderlich, das dann von der konkreten Verschlüsselungsklasse implementiert werden muss:


187



public interface SalesforceEncryption { /** * Decrypts the given String and returns the decrypted value * @param eText the encrypted value as String * @return the decrypted value as Stirng */ public String deCrypt(String eText); /** * Encrypts the given String and returns the encrypted value * @param pText the clear-text value as String * @return the encrypted value as Stirng */ public String enCrypt(String pText); }

Bestehen grundsätzliche Vorbehalte gegen die Speicherung von Kennwörtern – auch in verschlüsselter Form – so muss das Java-Programm die entsprechenden Kennwörter zur Laufzeit erfragen; für Arbeitsabläufe, die ohnehin Benutzerinteraktion erfordern, stellt dies kein großes Hindernis dar. Für automatisierte Abläufe hingegen gibt es keine Alternative zur Speicherung der Kennwörter.

8.3

Fallstudie: Verwendung des Web Service API für einen Angebotsrechner

Nachdem im letzen Abschnitt erfolgreich eine Verbindung zu Salesforce.com aufgebaut wurde, soll diese nun an einem konkreten Beispiel genutzt werden, wie es im Businessalltag recht häufig vorkommt. Da das im Folgenden spezifizierte Projekt jedoch sehr umfangreich ist, werden im Rahmen dieses Buches nur die mit dem Web Service API in Zusammenhang stehenden Teilaspekte ausführlich behandelt werden können.

8.3.1

Spezifikation der Aufgabenstellung

Salesforce.com als CRM-System ist für die Mitarbeiter eines Unternehmens mit Sicherheit ein nützliches Werkzeug zur Erfassung und Verwaltung von Kundenbeziehungen. Da Salesforce.com internetbasiert ist, entstehen auch bei weltweit tätigen Unternehmen keine Probleme beim Zugriff auf die unternehmensrelevanten Daten. Die Aufgabe, mit der sich dieses Kapitel befasst, geht über die reine Erfassung und Verwaltung der Daten weit hinaus: Aus den in Salesforce.com hinterlegten Daten soll ein Angebot in der Form erstellt werden, wie es auch an einen Kunden versandt wird. Wie

188



die folgenden Absätze zeigen werden, reichen die Bordmittel von Salesforce.com zu diesem Zweck nicht mehr aus, so dass die Erstellung eines externen Angebotsrechners erforderlich wird.

Allgemeine Einführung Im direkten Kontakt mit dem Kunden, wie etwa bei der Abgabe eines Angebotes, müssen die vorhandenen Daten zunächst in eine Form gebracht werden, die konform mit der Corporate Identity ist; ferner sind Aspekte des Qualitätsmanagements zu berücksichtigen. Neben den genannten offensichtlichen Anforderungen an ein solches Programm sind auch noch die konkreten Bedürfnisse der Abteilungen zu beachten, in denen dieses Werkzeug zum Einsatz kommt. Ein Softwarehaus mit einer festen Produktpalette hat andere Anforderungen an ein Angebot als zum Beispiel ein chemischer Betrieb, der nach Wünschen seiner Kunden produziert, und diese Anforderungen unterscheiden sich wiederum von denen eines Dienstleisters. Die folgenden Ausführungen orientieren sich an einem tatsächlich durchgeführten Projekt; Auftraggeber war ein international tätiges Unternehmen mit Standorten in Deutschland, der Schweiz und den USA, das dem produzierenden Gewerbe zugeordnet werden kann. Innerhalb dieses Unternehmens gibt es mehrere Geschäftsbereiche mit ähnlichen, jedoch nicht identischen Anforderungen an Salesforce; vor allem im Detail seien die Unterschiede teils gravierend. Aus Entwicklersicht erscheinen folgende Anforderungen sinnvoll: 1. Die zu erstellenden Angebote haben immer eine gewisse Grundform, die durch den Angebotsrechner mit Daten aus Salesforce.com gefüllt werden soll. 2. Das Werkzeug soll für viele unterschiedliche Szenarien wieder verwendbar sein, also unabhängig von einer bestimmten Struktur in der Salesforce.com-Datenbank. 3. Der Kern des Angebotsrechners soll unabhängig sein von den konkreten Vorgaben und Formaten, die von einem Nutzer gewünscht werden. 4. Im Sinne der Wiederverwertbarkeit sollte das Werkzeug plattformunabhängig realisiert werden. 5. Schließlich soll der Angebotsrechner über eine zeitgemäße grafische Benutzerführung verfügen, um dem Benutzer die Arbeit zu erleichtern.

Besondere Anforderungen Im Fall dieses konkreten Beispiels stellt der Salesforce.com-Nutzer folgende weitere Anforderungen, welche bei der Realisierung des Projekts ebenfalls zu berücksichtigen sind, an seinen Angebotsrechner: 1. Im Beispielunternehmen gibt es prinzipiell zwei unterschiedliche Formen des Angebots: Die erste Form ist die tabellarische Form, in der die einzelnen Positionen nebst zugehörigem Preis aufgelistet sind; in der zweiten Form ist das Angebot als fortlaufender Text formuliert und wird genutzt zur Beschreibung umfangreicher Kundenprojekte. 2. Abgesehen von den üblichen Merkmalen der Corporate Identity soll das Angebot an den jeweiligen Kunden individuell angepasst werden können, insbesondere müssen auch üblicherweise feste Textbausteine anpassbar sein.


189



3. Ergänzungen des Angebotstextes sollen in einem Standard-Textverarbeitungssystem möglich sein, um den Schulungsaufwand für Mitarbeiter zu minimieren. 4. Da Angebote an Kunden im deutschsprachigen und im französischsprachigen Raum sowie in den USA versendet werden, müssen erstellte Angebote automatisch für den jeweiligen Kunden lokalisiert werden; neben der reinen Übersetzungsarbeit bei Textelementen sind insbesondere auch Felder mit numerischen Werten oder einem Datum zu berücksichtigen. 5. Für einige Artikel gibt es Staffelpreise, die auch im Angebot aufgeführt werden sollen; hierbei ist insbesondere auf die korrekte aufsteigende Sortierung der Staffelungen zu achten. 6. Aus Gründen des Qualitätsmanagements darf die Änderung eines Angebots nach dem Versand an den Kunden nicht mehr möglich sein; auch der mehrfache Versand eines Angebots muss ausgeschlossen sein. 7. Die Rechner, auf denen das Programm betrieben werden soll, werden von einer zentralen IT-Abteilung verwaltet; diese Abteilung muss die volle Kontrolle über die Installation des Angebotsrechners haben; insbesondere existieren aus früheren Projekten bereits spezielle unternehmensweit einheitliche Verzeichnisstrukturen, in die sich das Programm einfügen muss.

Umsetzung der Anforderungen in einen generischen Algorithmus Designüberlegungen Aus Entwicklersicht ergibt die Analyse der Anforderungen folgendes Bild: Um die komplexen Formatierungsanforderungen möglichst schnell und anpassungsfreundlich umzusetzen, erscheint es günstig, Vorlagen zur Angebotserstellung zu verwenden, die bereits alle wesentlichen Teile der Formatierung eines Angebots enthalten (wie etwa Schriftart, Tabellen, Abstände, ...). Für diese Vorlagen wird eine Seitenbeschreibungssprache (wie zum Beispiel HTML oder LaTeX) verwendet, und jene Stellen im Text, an denen später Daten aus Salesforce.com einzusetzen sind, werden durch entsprechende Platzhalter markiert. Genauere Überlegungen zum Umfang der Platzhalter-Syntax in einer solchen Vorlage werden an späterer Stelle in diesem Abschnitt noch angestellt. Eine Unabhängigkeit von der konkreten Salesforce.com-Datenstruktur erreicht man, indem man eine Konfigurationsdatei verwendet, die unter anderem alle Datenbankabfragen enthält. Das Design und die Interpretation dieser Konfigurationsdatei wird einer der wesentlichen Bestandteile des Angebotsrechners werden. Eine genaue Beschreibung ihrer Struktur folgt in Abschnitt 8.3.2, Verwendung des Salesforce API, im Rahmen der konkreten Anwendung. Der grundlegende Ablauf des Programms (Lesen – Verarbeiten – Schreiben) ist zwar stets gleich, unabhängig von einem konkreten Angebot, aber im Detail ergeben sich Unterschiede im Ablauf. Der Applikationskern muss daher frei von spezialisierter Funktionalität bleiben; spezielle Funktionen werden stets in einer eigenen Klasse implementiert. Um die Arbeit mit diesen Klassen zu erleichtern, wird ein Interface-Paar definiert, ein Interface auf Seite des Applikationskerns, über das der speziellen Klasse Daten und Callbacks zur Verfügung gestellt werden, und ein anderes auf Seite der spezialisierten Klasse, mit dessen Hilfe der Applikationskern auf die Klasse zugreifen kann. Abgerun-

190



det wird dieser Ansatz, indem die Namen der Klassen mit speziellen Funktionen in die Konfigurationsdatei aufgenommen werden; so kann der Applikationskern unter Verwendung von Java Reflections automatisch die richtige Klasse an der richtigen Stelle instanziieren. Die Plattformunabhängigkeit der Lösung ist durch die Verwendung von Java bereits weitestgehend erfüllt. In Kombination mit der Forderung nach einer grafischen Benutzeroberfläche sind allerdings noch einige Überlegungen erforderlich. Klar ist, dass die grafische Oberfläche wiederum getrennt von Applikationskern und Klassen mit spezialisierter Funktionalität implementiert werden muss; zur Kommunikation zwischen GUI und Applikationskern wird wieder ein entsprechendes Interface-Paar definiert. Für einen Entwickler ist es mit vertretbarem Aufwand kaum möglich eine komplexe Java Oberfläche von Hand zu programmieren, weswegen an dieser Stelle ein GUI-Builder zum Einsatz kommt; viele GUI-Builder setzen jedoch auch unter Java native Komponenten ein, wodurch die Plattformunabhängigkeit leiden würde. Ein gutes Werkzeug, das zudem nur Java-Elemente bei der Erstellung der Benutzeroberfläche verwendet, ist in die Entwicklungsumgebung NetBeans3 integriert; der von NetBeans genutzte LayoutManager ist als Erweiterung zum JDK 1.5 verfügbar und gehört ab dem JDK 1.6 standardmäßig zum Lieferumfang (siehe hierzu auch [IX01]). Für die weitere Arbeit wird daher das Eclipse-Projekt auf NetBeans migriert. Für einige Teilprozesse erscheint die Verwendung externer Werkzeuge sinnvoll; durch Aufruf eines geeigneten externen Prozesses (etwa ein PDF Viewer oder eine Textverarbeitung) lässt sich ein großer Teil der Arbeit an existierende Software delegieren; die entsprechenden Aufrufe werden wieder in der Konfigurationsdatei eingetragen. Zur Realisierung von spezieller Funktionalität auf dem System des Benutzers kann auch die Nutzung von (nativen) Skripten sich als Vorteil erweisen, da dies die Performanz zum Teil wesentlich erhöhen und den Entwicklungsaufwand minimieren kann. In den so gesteckten Rahmen werden nun die speziellen Anforderungen des Salesforce.com-Benutzers eingearbeitet. Um die Editierbarkeit von Angeboten in einer gängigen Textverarbeitung zu gewährleisten, nutzt man für die Vorlagen HTML-Dokumente, die von Microsoft Word erstellt wurden, da solche Dokumente sowohl gut formatierbar sind als auch wieder in Microsoft Word editiert werden können. In der Vorlage findet eine relativ umfangreiche Platzhalter-Syntax Verwendung, da neben der einfachen Ersetzung von Textpassagen auch Wiederholungsanweisungen und weitere Optionen (etwa zur Formatierung eines numerischen Wertes oder zur Sortierung von Staffelpreisen) benötigt werden. Ferner soll zur vollständigen Flexibilisierung auch den Aufruf spezieller Java-Klassen aus der Vorlage heraus erlaubt sein, ähnlich einer Makro-Funktionalität. Im Fall von HTML als zugrunde liegender Seitenbeschreibungssprache könnte die Syntax der Vorlage folgendermaßen gestaltet sein:

3

NetBeans (derzeit aktuell ist Version 5.5) kann kostenfrei herunter geladen werden unter http://www.netbeans.info/downloads/index.php.


191



Platzhalter

Bedeutung

[[varname]]

Wird ersetzt durch den intern mit „varname“ bezeichneten Wert

[[numwert~#,##0.00##]]

Wird ersetzt durch den intern mit „numwert“ bezeichneten numerischen Wert, der gemäß dem angegebenen Formatstring ausgegeben wird

((~etwas Text~[[varname]]~noch mehr Text~))

Für den Fall, dass der Wert „varname“ leer ist, wird die gesamte von ((...)) umschlossene Textpassage aus dem Dokument entfernt, anderenfalls werden die Texte ausgegeben (die „~“ dienen hierbei nur als Trennzeichen und werden in jedem Fall entfernt)

{{0~tr}} ... {{0}}

Markiert die aktuelle Tabellenzeile („tr“ steht für das HTML-Tag „ ... “, das eine Tabellenzeile umschließt) als zu wiederholenden Abschnitt; die Schachtelungstiefe dieser Wiederholung ist „0“, d.h., die Wiederholung ist nicht innerhalb einer übergeordneten Wiederholung geschachtelt

{{#[[mengen]]~staffel~num~asc#}} {{[[preise]]~staffel~num~asc}}

Füge alle Werte mit der internen Bezeichnung „mengen“ ein und sortiere diese aufsteigend („asc“) als numerische Werte („num“); „staffel“ wird als Kennung der Sortiergruppe genutzt und „#“ markiert das Feld als Sortierschlüssel; demnach wird für „preise“ dann die für „mengen“ ermittelte Sortierreihenfolge übernommen

$$macros.Macro~par$$

Ruft die Java-Klasse „macros.Macro“ auf; dabei wird „par“ als Parameter an die Klasse übergeben

Tabelle 8.1: Beispiele für die Syntax in einer HTML-Vorlage des Angebotsrechners

Zur Lokalisierung von Datums- und Zahlformaten wird die in Java verfügbare Funktionalität verwendet, wobei über eine spezielle Klasse auch Abweichungen von den festen Vorgaben der Java Locales eingerichtet werden können. Da Angebote nach dem Versand nicht mehr geändert werden dürfen, wird das Angebot unmittelbar vor dem Versenden in ein PDF-Dokument umgewandelt. Der prinzipielle Ablauf einer Angebotserstellung Im Wesentlichen gliedert sich die Erstellung eines Angebots in folgende Schritte: 쮿

Lesen der Konfigurationsdatei

쮿

Durchführung der einzelnen Salesforce.com-Abfragen

쮿

Erstellen des Angebots als editierbare Version

쮿

Konvertierung des Angebots in die finale PDF-Version

쮿

Versenden des Angebots

쮿

Zurückschreiben der geänderten Informationen in die Salesforce.com-Datenbank

In etwas feinerer Granularität ist dieser Ablauf in der folgenden Grafik dargestellt; auch Interaktionen mit externen Medien sind in dieser Grafik dargestellt.

192



Abbildung 8.12: Schematischer Ablauf der Angebotserstellung; dunkel unterlegte Schritte nutzen das WebService API von Salesforce


193



Implementierung in Java Wie bereits während der Vorbereitungen dargelegt, erfolgt die Implementierung des Angebotsrechners in Java. Ein Bedenkenträger mag nun einwerfen, Java sei für ein Projekt dieser Größenordnung viel zu langsam und zu speicherintensiv; mit den neueren Java-Versionen (etwa ab Version 1.5) hat sich jedoch die Geschwindigkeit, insbesondere bei rechenintensiven Anwendungen, drastisch gesteigert und auch der Speicherverbrauch weicht nicht mehr signifikant vom Verbrauch nativer Programme mit grafischer Oberfläche ab. Import eines Eclipse-Projekts nach NetBeans Da zum Design der grafischen Benutzeroberfläche auf die in NetBeans verfügbaren Funktionen zurückgegriffen werden soll, wird das im vorigen Unterkapitel erstellte Eclipse-Projekt nun nach NetBeans übertragen. Glücklicherweise sieht NetBeans eine entsprechende Funktion bereits vor, so dass lediglich im Menü von NetBeans FILE → IMPORT PROJECT → ECLIPSE PROJECT... ausgewählt werden muss. Im folgenden Dialog ist die Option IMPORT PROJECTS FROM WORKSPACE auszuwählen und der Pfad zum Eclipse Workspace unter WORKSPACE LOCATION einzutragen. Mit dem Button NEXT > gelangt man zur nächsten Seite.

Abbildung 8.13: Erster Schritt beim Import eines Eclipse-Projekts in NetBeans

Dort wählt man das Projekt mit Namen „MySalesforceProject“ durch Markieren des entsprechenden Auswahlfeldes aus; durch Klick auf FINISH startet der Import (bei Bedarf kann natürlich zuvor noch die LOCATION OF NETBEANSPROJECTS nach den eigenen Bedürfnissen angepasst werden).

194



Abbildung 8.14: Auswahl des Eclipse-Projekts

Abhängig von der Eclipse-Konfiguration zeigt NetBeans möglicherweise Warnungen beim Import des Projektes an. Diese Warnungen können jedoch einfach ignoriert werden; der Import sollte auch trotz der Warnungen reibungslos ablaufen. Es sei an dieser Stelle nochmals daran erinnert, dass (genau wie bei Eclipse) auch für NetBeans ein aktueller JDK verwendet werden muss; NetBeans erfragt das standardmäßig zu verwendende JDK üblicherweise bereits bei der Installation.

Abbildung 8.15: Mögliche Warnungen beim Import des Eclipse-Projekts

Mit der Umstellung auf NetBeans ergibt sich noch eine weitere Annehmlichkeit: NetBeans erstellt während des Build-Vorgangs automatisch eine Java-Archiv-Datei, die sich per Doppelklick starten lässt, da Classpath- und Main-Class-Attribut im Manifest korrekt gesetzt wird.

8.3.2 Verwendung des Salesforce API Starten des Angebotsrechners aus Salesforce.com heraus Da Salesforce.com Internet-basiert ist, reduziert sich der Start des Angebotsrechners für den Endanwender auf das Anklicken eines Links. Intern muss dieser Klick jedoch die Java Virtual Machine dazu veranlassen, die richtige Klasse zu laden und anschließend auszuführen.


195



Diese Aufgabe lässt sich mit zwei unterschiedlichen Ansätzen bewältigen: Einerseits bietet sich die Nutzung des Java Web Start API an, das in jeder aktuellen Java Distribution enthalten ist, andererseits besteht natürlich auch die Möglichkeit, das Deployment von Hand durchzuführen. Im Folgenden soll das Deployment von Hand ausführlicher beschrieben werden. Hierfür gibt es mehrere Gründe: Erstens ist das Deployment von Hand etwas schwieriger umzusetzen als die Verwendung des Web Start API, so dass ein Studium aus diesem Grunde bereits lohnenswert erscheint; zweitens erlauben die Vorgaben der IT-Abteilung des Salesforce.com-Anwenders in diesem Beispielprojekt praktisch keinen Einsatz automatisierter Softwareinstallationen, was bei der Umsetzung von Web Start sehr hinderlich wäre. Ein weiterer Grund ist, dass sich das Deployment von Hand problemlos auf andere Programmierumgebungen übertragen lässt, somit also den universell verwendbaren Ansatz darstellt. Auch wenn hier aus den genannten Gründen nicht genauer darauf eingegangen wird, stellt das Java Web Start API eine sehr nützliche Technologie dar; daher sei diesbezüglich auf die ausführliche Dokumentation [J2SE01] verwiesen.

S-Controls als Schnittstelle zu externer Software Mit S-Controls (siehe vorausgehende Kapitel) lassen sich auch externe Anwendungen aufrufen. In konkreten Fall muss auf dem Rechner, der die Anwendung ausführen soll, ein entsprechendes URL-Protokoll registriert sein, um den Aufruf weiterzuleiten; vor der Implementierung eines S-Control wird also zunächst ein URL-Protokoll mit Namen „salesforce“ registriert.

Achtung In der Vergangenheit wurde die Registrierung von URL-Protokollen zum Teil missbräuchlich verwendet, um Schadcode von einer Internetseite aus aufrufen zu können. Daher müssen unter modernen Betriebssystemen zur Registrierung gewisse Hürden umgangen werden. Auf Microsoft-Windows-Systemen werden URL-Protokolle über die Windows Registry zur Verfügung gestellt; insbesondere sind hierzu Administratorrechte auf dem System erforderlich, so dass gegebenenfalls die Hilfe eines Systemadministrators erforderlich sein kann. Unter der Annahme, dass eine aktuelle Java-Version auf dem System installiert ist und sich die jar-Datei der aufzurufenden Anwendung auf der obersten Ebene des Startlaufwerks befindet, sähe ein entsprechender Registry-Eintrag wie folgt aus: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\salesforce] @="URL:salesforce Protocol" "URL Protocol"=""

196



[HKEY_CLASSES_ROOT\salesforce\shell] @="" [HKEY_CLASSES_ROOT\salesforce\shell\open] @="" [HKEY_CLASSES_ROOT\salesforce\shell\open\command] @="javaw -jar \"C:\\MySalesforceProject.jar\" \"%1\""

Unter Linux hängt es von der Distribution und von der verwendeten Desktop-Umgebung ab, wie der Prozess der URL-Registrierung genau abläuft; teils lässt sich die Konfiguration über den Internetbrowser unter Angabe von „about:config“ als Adresse erledigen, teils müssen Konfigurationsdateien von Hand erstellt werden (der Suchpfad nach solchen Dateien variiert je nach Distribution). Von der genutzten Methode hängt es auch ab, ob root Berechtigung für die Einstellung erforderlich ist oder nicht. Unter einer GnomeDesktop-Umgebung beispielsweise gibt es ein einheitliches Kommando für die Registrierung eines URL-Protokolls: $ gconftool-2 –s –t string /desktop/gnome/url-handlers/salesforce/command 'java –jar /MySalesforceProject.jar "%s"' $ gconftool-2 –s –t bool /desktop/gnome/url-handlers/salesforce/enabled true

Unter Mac OS X ist das Modul „LaunchServices“ für die Registrierung von URL-Protokollen zuständig. Dieser Dienst bezieht die Informationen über die verfügbaren Protokolle direkt aus dem Dictionary der Info.plist der Anwendung. Die LaunchServices werden aus Sicherheitsgründen jedoch beim ersten Gebrauch der URL zurückfragen, ob die durchgeführte Registrierung gewünscht ist. Unter Mac OS X wird man den Angebotsrechner also als Application Bundle ausliefern, dessen Info.plist unter anderem folgenden Eintrag enthält: CFBundleURLTypes CFBundleTypeRole Shell CFBundleURLName com.mycompany.url-protocols.salesforce CFBundleURLSchemes salesforce


197



Nachdem die Frage der Registrierung des URL-Protokolls geklärt ist, kann das eigentliche S-Control implementiert werden. Bei Aufruf eines externen Programms über eine URL wird die vollständige URL als Argument übergeben. Daher sollte die Übergabe aller notwendigen Parameter über die URL erfolgen, mit der der Aufruf des Programms ausgelöst wird; für den Einsatz mit dem Angebotsrechner muss die URL also insbesondere die Angebotsnummer enthalten. In der Praxis realisiert man dies am besten durch Einbettung eines Formulars in das S-Control. Damit keine Benutzerinteraktion erforderlich wird, verwendet man ein kleines Javascript innerhalb des S-Controls zum Auslösen der Versendung, wobei das Formular hierzu die GET-Methode nutzen muss. Das verwendete Codefragment könnte etwa folgendermaßen aussehen: document.externCallForm.submit();

Nimmt man einmal an, dass die Angebots-Id „00630000001sQ31“ lautet, so wird auf Seite des externen Programms das folgende Argument ankommen: salesforce://localhost/?--salesforce-id=00630000001sQ31

Der Angebotsrechner kann dieses Argument einfach analysieren, indem er den Teil hinter dem „?“ betrachtet und etwa vorhandene URL-kodierte Sonderzeichen durch Verwendung der Java-Klasse java.net.URLDecoder wieder in Klartext verwandelt. Das folgende Codefragment zeigt diesen Vorgang beispielhaft, wobei dort auch die Übergabe mehrerer Parameter (etwa noch der Name einer bestimmten Konfigurationsdatei) per URL unterstützt wird: import java.io.UnsupportedEncodingException; import java.net.URLDecoder; import java.util.TreeMap; public class OfferTool { private TreeMap myArgs; public OfferTool(String[] urlArgs) { myArgs = new TreeMap();

198



for (int i = 0; i < urlArgs.length; i++) { String[] argParts = urlArgs[i].split("="); try { argParts[0] = URLDecoder.decode(argParts[0], "ISO-8859-1"); argParts[1] = URLDecoder.decode(argParts[1], "ISO-8859-1"); } catch (UnsupportedEncodingException ex) { ex.printStackTrace(); } myArgs.put(argParts[0], argParts[1]); } } public static void main(String[] args) { String urldata = args[0].split("?")[1]; String[] urlArgs = urldata.split("&"); new OfferTool(urlArgs); } }

Verwendung von SOQL zum Lesen von Daten Für den Zugriff auf die Datenbank verwendet Salesforce.com im WebService API, wie auch in den übrigen APIs, die Salesforce Object Query Language (SOQL).

Achtung Obwohl die mit SOQL an Salesforce.com gesendeten Anfragen nicht zwischen Großund Kleinschreibung unterscheiden, enthält das von Salesforce.com gelieferte Ergebnis die Feldnamen in genau der Schreibweise, die in Salesforce.com definiert ist. Um Missverständnissen vorzubeugen, empfiehlt es sich daher stets, mit den Feldnamen in korrekter Groß-/Kleinschreibung zu arbeiten. Syntaktisch orientiert sich SOQL an den diversen SQL-Dialekten, implementiert jedoch nur grundlegende Funktionalität; eine Datenbankabfrage ist stets von der folgenden Form: SELECT FROM WHERE


199



Diese Syntax ist zwar sehr einfach, jedoch gibt es auch wesentliche Beschränkungen, die beim direkten Zugriff auf eine SQL-Datenbank nicht vorhanden wären. In der Praxis als besonders hinderlich erweist sich die Tatsache, dass man mit SOQL keinen Einfluss auf die Sortierung der abgefragten Daten hat. Was ebenfalls sehr häufig vorkommt, sind Datenbankabfragen, die das Ergebnis einer vorausgehenden Abfrage verwenden. Ein solches Verschachteln von Abfragen ist mit SOQL ebenfalls nicht möglich. Weniger häufig, aber nicht minder nützlich, wäre eine Funktionalität, die das Nachbearbeiten von gelesenen Daten erlaubt; ein Beispiel hierfür ist eine Funktion zum Suchen und Ersetzen von Werten, die man zum Beispiel zum Umschlüsseln von Werten einsetzen kann. Zunächst soll nun die Implementierung von SOQL in Java genauer studiert werden; danach folgt eine etwas ausführlichere Diskussion der oben angeregten Erweiterungsgedanken. Durchführen einer Salesforce Query aus einem Java-Programm Das entscheidende Java-Objekt für eine Salesforce Query innerhalb des Web Service API ist QueryResult; es wird als Ergebnis der Methoden query und queryMore des Salesforce Bindings (siehe Abschnitt 8.2.2, Verbindung mit Salesforce.com aufbauen) zurück geliefert. Der Grund für die Existenz von zwei verschiedenen Methoden bei einer Abfrage liegt darin, dass Salesforce.com bei einer Query nicht alle Ergebnisse auf einmal zurückgibt, sondern immer nur eine gewisse Anzahl (maximal 2000 Datensätze pro Anfrage). Um weitere verfügbare Datensätze zu erhalten, ist man auf die Nutzung von queryMore angewiesen, da hier genau die Ergebnisliste der laufenden Abfrage erweitert wird. Je nach Umfang der Datenmenge muss queryMore sogar mehrfach aufgerufen werden, bis alle Daten gelesen sind. Zur Realisierung in Java erzeugt man zunächst eine eigene Klasse (dies wird vor allen Dingen im Rahmen der geplanten Erweiterungen sinnvoll sein) mit dem Namen „MySalesforceQuery“. Diese Klasse enthält ein Attribut binding, das jenem aus der Login-Klasse aus dem Abschnitt 8.2.2, Verbindung mit Salesforce.com aufbauen entspricht. Die entscheidende Methode der Klasse ist runQuery, deren Java-Quelltext könnte etwa wie folgt aussehen: import java.util.TreeMap; import org.apache.axis.AxisFault; import org.apache.axis.message.MessageElement; import import import import import import

200

com.sforce.soap.partner.QueryOptions; com.sforce.soap.partner.QueryResult; com.sforce.soap.partner.SforceServiceLocator; com.sforce.soap.partner.SoapBindingStub; com.sforce.soap.partner.fault.ApiFault; com.sforce.soap.partner.sobject.SObject;



public class MySalesforceQuery { private private private private private

static final int QUERY_BATCH_SIZE = 250; SoapBindingStub binding; String queryString; TreeMap queryResult; boolean runTerminated;

public MySalesforceQuery(MySalesforceBridge mySfBridge, String myQuery) throws Exception { binding = mySfBridge.getBinding(); queryString = myQuery; queryResult = new TreeMap(); runTerminated = false; } public TreeMap getResult() throws Exception { if (!runTerminated) { throw new Exception("Result not available; " + "query must run first"); } return queryResult; } public void runQuery() { boolean done = false; QueryResult qr = null; QueryOptions qo = new QueryOptions(); qo.setBatchSize(new Integer(250)); binding.setHeader(new SforceServiceLocator(). getServiceName().getNamespaceURI(), "QueryOptions", qo); // execute the query try { qr = binding.query(queryString); SObject[] results = qr.getRecords();


201



if (results == null) { // query returned no result at all done = true; // we may add processing of empty results here } else { done = false; } while (!done) { // process the query results for (int i = 0; i < results.length; i++) { // process all records returned by the query SObject record = results[i]; // the Salesforce Id must be queried // separately (if needed) String theId = record.getId(); // all other fields are returned by get_any() MessageElement[] elements = record.get_any(); if (elements != null) { // elements may be null ... we have to check for (int k = 0; k < elements.length; k++) { // process the data for one record String name = new String(elements[k].getName()); String value = elements[k].getValue(); if (value == null) { value = new String(); } // do something with the data, e.g. // save it into a TreeMap structure queryResult.put(name, value); } } } if (qr.isDone()) { // no more results are available done = true; } else { // there are more results available qr = binding.queryMore(qr.getQueryLocator()); results = qr.getRecords(); }

202



} // we are done; prevent this query from running again runTerminated = true; } catch (ApiFault ex) { // errors related to the usage of the API ex.printStackTrace(); } catch (AxisFault ex) { // errors occured during the WebService communication ex.printStackTrace(); } catch (Exception ex) { // other exceptions during data processing ex.printStackTrace(); } } }

So weit zur reinen Abfrage der Daten aus der Datenbank. Für den Angebotsrechner besteht die eigentliche Kunst jedoch in der geeigneten Aufbereitung und Speicherung der Daten zur weiteren Verarbeitung. Darauf soll an späterer Stelle noch etwas genauer eingegangen werden. Ansatz zur Aufhebung von Beschränkungen in der SOQL Wie eingangs bereits erwähnt, wünscht man sich weitere Funktionalität von SOQL, um den Angebotsrechner effizienter implementieren zu können. Dabei ist das Problem der geschachtelten Datenbankabfragen noch ohne allzu großen Aufwand lösbar, indem man solche Abfragen in der Konfigurationsdatei des Angebotsrechners zulässt. Das Programm wird diese Schachtelung dann in mehrere Einzelabfragen auflösen, die dann der Reihe nach per SOQL an Salesforce.com gesendet werden; durch Verwendung geeigneter Caching-Techniken lässt sich die mehrfache Anfrage nach identischen Daten verhindern und somit auch die Netzwerkbelastung auf ein Minimum reduzieren. Eine hierfür geeignete Struktur der Konfigurationsdatei wird im nächsten Abschnitt entwickelt werden. Innerhalb der Konfigurationsdatei soll außerdem die Syntax der SOQL um folgende Elemente erweitert werden: 쮿

ORDER BY (ACS|DESC) [, ...]

쮿

LIMIT OFFSET

쮿

PROCEDURE 왘 REPLACE (, "search", "replace" [, ...]) 왘 SUM () 왘 AVERAGE ()


203



Diese Elemente sollen in beliebiger Reihenfolge und beliebig oft ans Ende der gewöhnlichen SOQL-Abfrage angehängt werden können. Wie bereits erwähnt, kann man diesen Schluss des Abfrage-Strings nicht direkt per SOQL an Salesforce.com senden, sondern muss diese Funktionalität selbst implementieren, nachdem man von Salesforce.com die ungefilterte Antwort auf die Abfrage (ohne Erweiterungen) erhalten hat. Insbesondere für die Implementierung von „ORDER BY“ benötigt man eine geeignete Datenstruktur, womit sich der übernächste Absatz noch beschäftigen wird. Ferner muss man hier zwischen numerischen Werten und Werten mit Textinhalten unterscheiden, weil dies Änderungen in der Sortierfolge impliziert. Einen entsprechenden Sortieralgorithmus zu implementieren ist im Falle eines Angebotsrechners nicht sonderlich schwierig, da die Datenmengen ohne Probleme im Speicher gehalten werden können. Wären die Datenmengen wesentlich größer, wäre insbesondere die Implementierung von „ORDER BY“ entsprechend komplizierter, da auf geeignete Hilfsmittel zurückgegriffen werden müsste; denkbar wäre hier die Nutzung von MySQL auf dem lokalen Rechner über den JDBC. Nicht wirklich effizient lösbar ist die Implementierung des LIMIT-OFFSET-Befehls; wäre dieser Befehl bereits auf Seite der Abfragesprache implementiert, so würden beim Zugriff auf die Datenbank nur die Daten in den gefragten Schranken ausgelesen werden, während Salesforce.com zunächst einmal alle Daten zurückliefern wird, für welche die Rumpfabfrage zutrifft. Erst innerhalb der eigenen Implementierung werden diese Daten dann gefiltert und überflüssige Daten ausgelassen, was natürlich negative Auswirkungen sowohl auf das Zeitverhalten als auch auf den Speicherbedarf hat. Die Implementierung der diversen PROCEDUREs verlangt wiederum eine geeignete Datenstruktur, die insbesondere auch zwischen numerischen und Textinhalten unterscheiden kann. Zumindest teilweise werden die hier beschriebenen Erweiterungen der SOQL im aktuellen Release 8.0 des Web Service API4 enthalten sein. Salesforce.com sieht dort insbesondere den LIMIT-Befehl vor (allerdings ohne OFFSET) und auch ORDER BY ist dann zulässig (wobei hier nur ein Sortierschlüssel angegeben werden kann). Da die API Version 8.0 abwärtskompatibel zu Version 7.0 ist, lassen sich die zuvor eingeführten Erweiterungen auch weiter verwenden; bei LIMIT ohne OFFSET empfiehlt sich aus Performanzgründen zukünftig jedoch die Verwendung der im API enthaltenen Version.

Verwalten der SOQL-Abfragen über eine Konfigurationsdatei Die bisherigen Ausführungen zum Angebotsrechner haben deutlich gemacht, dass die Konfigurationsdatei als Herzstück des Programms zu sehen ist. In dieser Datei müssen einerseits komplexe Datenstrukturen – wie zum Beispiel geschachtelte Datenbankabfragen – abgebildet werden und andererseits benötigt man ein erhebliches Maß an Flexibilität, um mit den Anforderungen wachsen zu können. Unter den XML-basierten Formaten bietet sich hier die Verwendung des PropertyList-Formates an. Selbiges wird definiert durch den folgenden DTD:

4

204

Für Detailinformationen siehe http://www.salesforce.com/developer/tech-notes.jsp?tn=TN-19.



Gemäß dieser Formatspezifikation kann eine PropertyList Zeichenketten (string), binäre Daten (data), Datumswerte (date), ganze Zahlen (integer), Fließkommazahlen (real) und die beiden booleschen Konstanten (true und false) erfassen. Ferner sind Felder (array) mit Einträgen beliebigen Typs zulässig sowie Schlüssel-Werte-Paare (dict), bei denen der Schlüssel (key) aus einer Zeichenkette besteht und der Wert von beliebigem Typ sein darf. Mithin liegt ein sehr mächtiges Format vor, denn es lassen sich beliebige Kombinationen und Schachtelungen der einzelnen Grunddatentypen erstellen und dennoch bleibt der Inhalt der PropertyList auch für einen menschlichen Leser nachvollziehbar. Ein weiterer Vorteil des Formats ist die einfache Erweiterbarkeit der Datenstruktur durch Einführung neuer Schlüssel-Werte-Paare. Insbesondere bei der Verwendung des Formats zusammen mit Salesforce.com fällt noch auf, dass das Format des Datumsfeldes in der PropertyList mit dem von Salesforce.com intern genutzten Format übereinstimmt, was bei geeigneter Nutzung der Daten aus der PropertyList etliche Umrechnungsarbeit erspart. Das bis jetzt nur allgemeinen definierte PropertyList-Format soll nun im konkreten Beispiel genutzt werden, um Datenbankabfragen darzustellen; eine einzelne geschachtelte Abfrage ließe sich etwa wie folgt kodieren (die Bedeutung der einzelnen Einträge wird im Anschluss diskutiert).


205



db_queries append_query_results_to_existing_ones empty_fields_are_compressible field_name_mapping usr_fax Fax usr_fst FirstName usr_lst LastName usr_mal Email usr_mob MobilePhone usr_tel Phone usr_tit Title further_attributes max_results 1 min_results 1 nested_result_is_compressible table_name User where_clause Id PQ==

206



append_query_results_to_existing_ones empty_fields_are_compressible field_name_mapping owner_id OwnerId further_attributes max_results 1 min_results 1 nested_result_is_compressible table_name Opportunity where_clause Offer_No__c PQ== Iw==

Betrachtet man die einzelnen Einträge der PropertyList genauer, so ist auf der obersten Ebene der Konfigurationsdatei ein dict-Eintrag platziert; neben den Datenbankabfragen (key = db_queries) ist man also in der Lage, noch weitere Parameter in derselben Konfigurationsdatei unterzubringen, etwa die im Abschnitt 8.2, Eine erste Verbindung, erwähnten Salesforce.com-Login-Daten. Der zum Schlüssel db_queries gehörende Wert ist ein array, das heißt, es können beliebig viele Datenbankabfragen in einer Konfigurationsdatei untergebracht werden. Jede einzelne dieser Abfragen ist wieder in Form eines dictEintrags in die Konfigurationsdatei eingetragen worden. Dahinter versteckt sich zunächst einmal eine einfache SOQL-Abfrage, nämlich SELECT FROM WHERE


207



(in spitzen Klammern stehen hier die entsprechenden key-Werte aus der Konfigurationsdatei). Während table_name nur eine einfache Zeichenkette mit dem Namen des abzufragenden Salesforce.com-Objekts ist, enthält das field_name_mapping bereits zusätzliche Informationen, denn hier wird jedem Namen eines abgefragten Datenbankfeldes ein eindeutiger interner Name (als Schlüssel) zugeordnet; über diesen internen Namen wird der Zugriff auf die Daten aus dem Angebotsrechner heraus erfolgen, insbesondere wird er auch für die Platzhalter in der Angebotsvorlage verwendet. Die Einführung des internen Namens ist darin begründet, dass im Laufe einer Angebotserstellung unter Umständen mehrere Felder mit gleichem Namen abgefragt werden; ohne eindeutige interne Kennzeichnung würde dies zu Überschneidungen führen. Die where_clause wird in der Konfigurationsdatei durch einen array dargestellt. Eine sinnvolle where_clause ist entweder leer oder setzt sich aus 4·n-1 Einträgen zusammen (n ist eine beliebige ganze Zahl ≥1). Die Bedeutung der Einträge ist wie folgt: Zunächst wird das Feld genannt, an das eine Bedingung gestellt werden soll, dann folgt ein SOQL-Operator wie etwa „“, „=“, „!=“ oder „LIKE“ (um Konflikte mit der XML-Syntax zu vermeiden, wird der Operator in binär kodierter Form gespeichert) und anschließend steht der zugehörige Wert; optional kann die where_clause um je vier Elemente erweitert werden, wobei das erste der vier Elemente eine logische Verknüpfung („AND“, „OR“) darstellt und die folgenden drei Einträge wieder Feld, Operator und Wert entsprechen. Für den Wert in der where_clause sind verschiedene Datentypen zulässig: Bei string wird der Wert als Text behandelt, real wird für numerische Werte genutzt, date für Datumsfelder und true bzw. false für Wahrheitswerte. Zusätzlich erlaubt ist für den Wert auch noch der Datentyp dict, um so Datenbankabfragen schachteln zu können. Ein Wert vom Typ data wird verwendet, um interne Daten aus dem Angebotsrechner (wie etwa die beim Start übergebene Angebotsnummer) in eine Abfrage zu substituieren. Neben dieser reinen Abbildung der SOQL enthält die Konfigurationsdatei noch weitere Informationen zur gestellten Anfrage. Unter further_attributes können die im vorausgehenden Abschnitt geschilderten Erweiterungen der SOQL verwendet werden, und mit min_results und max_results kann festgelegt werden, wie viele Ergebnisse der Angebotsrechner als Antwort erwartet; das Mitführen dieser Werte erlaubt eine entsprechende Fehlerbehandlung im Angebotsrechner. Die drei verbleibenden Attribute sind erst bei komplexeren Anfragen von Bedeutung: 쮿

append_query_results_to_existing_ones beeinflusst das Verhalten, wenn mehrere Anfragen für dieselbe interne Feldbezeichnung erfolgen; ist diese Option true, so wird das neue Ergebnis einfach an das bereits bestehende angehängt, anderenfalls wird die Schachtelungstiefe erhöht, so dass das Ergebnis in einer Hierarchie (etwa für geschachtelte Wiederholungsanweisungen in der Vorlage) zur Verfügung steht.

쮿

empty_fields_are_compressible ist von Bedeutung, wenn mehrere Felder eines Salesforce.com-Objekts gleichzeitig abgefragt werden, denn es kann vorkommen, dass eines der abgefragten Felder keinen Wert enthält. Ist diese Option true, so werden leere Felder ignoriert; dies ist zugleich das Standardverhalten von Salesforce.com. Dies kann allerdings dazu führen, dass die Ergebnisse der Abfrage für die einzelnen Felder eine ungleiche Länge haben, was für die Erstellung von Tabellen in einem Angebot jedoch nicht sinnvoll ist.

208


Fallstudie: Verwendung des Web Service API für einen Angebotsrechner 쮿

nested_result_is_compressible bezieht sich ebenfalls auf einen Fall, der speziell bei

der Angebotserstellung auftreten kann; unter Umständen ist es erwünscht, dass zu ein und demselben Artikel mehrere Positionen im Angebot erscheinen, wobei die genauen Konditionen variieren. Die Artikelstammdaten sind in Salesforce.com in Preisbüchern hinterlegt, auf die nur über eine ProductId zugegriffen wird; Standardverhalten von Salesforce.com (Option ist true) ist es jedoch, derartige Doppelgänger in einer einzigen Anfrage zu ignorieren, was im konkreten Fall nicht zum gewünschten Ergebnis führen würde. Setzt man stattdessen die Option auf false, so wird der Angebotsrechner die einzelne Abfrage in mehrere Einzelabfragen aufspalten, um so auch doppelte Produkteinträge im Angebot erzeugen zu können.

Abbildung des QueryResult auf eine Java-Datenstruktur Wie bereits bei der Analyse der Konfigurationsdatei erwähnt wurde, gibt es für jedes angefragte Feld eine eindeutige interne Kennung. Die Java-Datenstruktur einer TreeMap erscheint daher geeignet, die Ergebnisse der einzelnen Salesforce.com-Anfragen aufzunehmen. Genauer typisiert wird eine TreeMap zur Speicherung der Ergebnisse verwendet, wobei der Schlüssel den internen Bezeichnungen entspricht. Die Wahl des umfassenden Datentyps Object auf Werteseite ist erforderlich, um geschachtelte Ergebnisse ebenso erfassen zu können wie einzelne Texteinträge; mit anderen Worten: Für Object steht entweder ein String oder ein Vector oder – je nach Schachtelungstiefe – ein Vector. Bei Verwendung von Object als Datentyp besteht allerdings die Gefahr, dass ClassCastExceptions auftreten, weil das Objekt irrtümlich als vom falschen Typ angesehen wird. Deswegen muss bei der Implementierung des Angebotsrechners in jedem Einzelfall sorgfältig geprüft werden, welche Datenstruktur sich gerade hinter dem jeweiligen Objekt verbirgt. Dazu lässt sich zum Beispiel der für alle Objekte verfügbare Aufruf getClass().getCanonicalName() verwenden. Bei der gegebenen Datenstruktur muss man sich auch Gedanken machen über den Zugriff auf die Daten, da für den Zugriff auf einen bestimmten Eintrag unter Umständen ein Multiindex angegeben werden muss. Dennoch sind derart geschachtelte Daten eher ein Sonderfall, so dass man auch daran denken sollte, eine Zugriffsmethode für den am häufigsten genutzten Datentyp Vector zu implementieren.

Ändern von Daten Die Anforderungen des hier behandelten Beispiels verlangen, dass nach der Erstellung und Versendung des Angebots ein Link auf das fertige Dokument in Salesforce.com eingetragen werden muss. Dazu existiert ein benutzerdefiniertes Feld „Document_Path__c“ innerhalb des Salesforce.com-Objekts „Opportunity“. Ferner muss auch das Flag „Opportunity_sent__c“ gesetzt werden. Unter der Annahme, dass der Pfad zu dem archivierten Angebot neben weiteren Einstellungen in einer TreeMap mit Namen settings abgelegt wurde, tut die folgende Methode genau dies:


209



public void writeToSalesforce() throws Exception { String tableToUpdate = "Opportunity"; String theId = myArgs.get("--salesforce-id"); String archOppPath = settings.get("archived_opportunity_path"); String[] namesOfFieldsToUpdate = { "Document_Path__c", "Opportunity_sent__c" }; String[] fieldContentsToUpdate = { archOppPath, "true" }; SObject[] objs = new SObject[1]; objs[0] = new SObject(); objs[0].setType(tableToUpdate); objs[0].setId(theId); MessageElement[] fieldsToUpdate = new MessageElement[fieldContentsToUpdate.length]; for (int i = 0; i < fieldContentsToUpdate.length; i++) { fieldsToUpdate[i] = new MessageElement( new QName(namesOfFieldsToUpdate[i]), fieldContentsToUpdate[i] ); } objs[0].set_any(fieldsToUpdate); SaveResult[] saveResults = mySfBridge.getBinding(). update(objs); if (saveResults == null) { throw new Exception("Save operation did not complete; no diagnostics are available."); } for (int i = 0; i < saveResults.length; i++) { if (!saveResults[i].isSuccess()) { com.sforce.soap.partner.Error[] err = saveResults[i].getErrors(); String msg = "Error during database update:\n";

210



for (int k = 0; k < err.length; k++) { msg = msg + err[i].getMessage(); if (k != err.length-1) { msg = msg + "\n"; } } System.err.println(msg); } } }

8.3.3 Nutzen der Generizität des Ansatzes Zum Abschluss dieses Kapitels bleibt noch die Frage zu klären, welchen Nutzen ein solch allgemeingültiger Angebotsrechner bringt. Viel schneller wäre es doch, unter Verzicht auf die Konfigurationsmöglichkeiten eine einzige Werkzeugklasse zu entwickeln, die speziell auf den Einzelfall zugeschnitten ist.

Flexibilität bei Anpassungen und Erweiterungen Der eingangs genannte Einwand ist jedoch nur dann berechtigt, wenn in Zukunft keine Anpassungen an dem Werkzeug vorgenommen werden sollen und auch kein weiteres Programm von derselben Art geplant ist. Während nämlich bei der spezialisierten Werkzeugklasse auch kleine Änderungen am Werkzeug auf Quelltextseite sehr aufwändig werden können und man bei der Implementierung eines weiteren Angebotsrechners praktisch wieder bei Null anfangen müsste, da die alten Programmbestandteile kaum wieder verwendbar wären, liegen hier die Vorteile der generischen Lösung auf der Hand: Durch das implementierte Makro-Konzept lässt sich die Funktionalität des Programms bei Bedarf beliebig erweitern, ohne bestehende Komponenten antasten zu müssen; die Kapselung in einzelne Klassen erhält auch eine gewisse Übersichtlichkeit der Quelltexte. In vielen Fällen ist es allerdings nicht einmal erforderlich, neue Funktionalität zu implementieren. Zur Aufnahme eines neuen Geschäftsbereichs zum Beispiel wird nur eine weitere Konfigurationsdatei nebst entsprechender Vorlage benötigt; bei der Vorlage können sogar viele Passagen von bereits existierenden Geschäftsbereichen übernommen werden, so dass der Gesamtaufwand relativ gering ist. Auch auf Änderungswünsche des Salesforce.com-Benutzers kann man mit dem vorgestellten Konzept relativ schnell reagieren, da die meisten Wünsche sich bereits auf Ebene der Konfigurationsdatei (Anpassung der Abfragen) und der Vorlage (Änderungen am Layout) verwirklichen lassen.


211



Verwendung für weitere Geschäftsschreiben Aufgrund der oben geschilderten Flexibilität des Ansatzes lässt sich das Konzept des Angebotsrechners auf andere Bereiche übertragen; jedes andere Dokument, das Daten aus Salesforce.com verwendet, ist hierbei denkbar: 쮿

Zum Beispiel wäre es möglich, aus in Salesforce.com hinterlegten Notizen – etwa über ein Meeting – einen entsprechenden Report zu erstellen. Reizvoll an diesem Thema ist vor allem das Vorkommen geschachtelter Wiederholungen in dem zu erzeugenden Dokument, etwa weil der Bericht aus mehreren Abschnitten besteht, von denen jeder wiederum Unterabschnitte enthält.

쮿

Rechnungen sind Angeboten auf den ersten Blick sehr ähnlich; möglicherweise sind für diese Aufgabe einige Änderungen im Makrobereich erforderlich, je nachdem welche Kalkulationen noch außerhalb von Salesforce.com vorzunehmen sind.

쮿

Denkbar ist auch die Verwendung des gleichen Konzepts zur Erstellung von Serienbriefen, etwa zu Marketingzwecken; hierbei wird Salesforce.com dann nur als Adressdatenbank verwendet und die von dort bezogenen Daten in ein vorgefertigtes Schreiben eingefügt.

Mögliche Erweiterungen des Funktionsumfangs Löst man sich von den Details des Fallbeispiels und kehrt zur Kernfunktionalität des Werkzeugs zurück (Lesen – Verarbeiten – Schreiben), so lassen sich auf dieser Basis auch andere Anwendungen konstruieren. Beispielsweise kann so die Offline Edition von Salesforce.com ergänzt werden. Mit Hilfe der Offline Edition erhält der Salesforce.com-Benutzer auch dann Zugriff auf seine in Salesforce.com gespeicherten Daten, wenn er nicht mit einem Netzwerk verbunden ist. Salesforce.com stellt dazu die erforderlichen Daten auf dem lokalen Rechner des Benutzers zur Verfügung. Sind allerdings Dokumente auf Servern des Firmennetzwerks gespeichert und die Salesforce.com-Datenbank enthält nur einen Link auf diese Dokumente, so wird die Offline Edition diese Dateien nicht bereitstellen. Genau hier kann das vorgestellte Werkzeug ansetzen: Mit geeigneten SOQL-Abfragen werden alle für den Benutzer relevanten Links aus Salesforce.com ausgelesen. Die verlinkten Dateien werden dann auf die lokale Festplatte des Benutzers kopiert und der neue Speicherplatz wird schließlich in einem geeigneten Feld in Salesforce.com hinterlegt. Auf diese Weise lässt sich der Zugriff auf Dokumente des Firmennetzwerks im Offline-Modus realisieren.

212


9 9.1

Batchprozesse und Salesforce.com DataExchange

Hinter den Kulissen

Unter „Batchprozess“ wird im Folgenden der maschinelle Austausch von Daten mit einem Salesforce.com-Account verstanden. Der Austausch findet also nicht über den Internet-Browser, sondern mittels eines Programms, dem Apex Web Service API, statt. Die folgenden Erörterungen befassen sich zunächst ausschließlich damit, welche Daten als Extrakt benötigt oder zum Upload bereitgestellt werden, nicht aber, wie der Datenaustausch mit Salesforce.com tatsächlich bewerkstelligt wird. Dieses Problem wird unter 9.3 gesondert und ausführlich abgehandelt.

9.1.1

Daten up-to-date halten

Wenn ein Salesforce.com-System einmal im Betrieb ist, wird der Benutzer vornehmlich mit der Browser-Oberfläche zu tun haben. Dort wird er seine Daten beauskunften, Berichte erstellen, Angebote ausdrucken lassen und auch kleine Änderungen in den Daten vornehmen. Zu Recht wird er aber verlangen können, dass zu Beginn der Arbeit mit Salesforce.com alle nötigen Daten zur Verfügung stehen und diese Daten auch kontinuierlich auf dem neuesten Stand gehalten werden. Der Benutzer selbst wird das nur in äußerst geringem Umfang leisten können, wenn er zum Beispiel einen neuen Kundenkontakt eingibt, eine Kundenadresse korrigiert oder dergleichen. Aber darüber hinaus werden Anwender Daten in Salesforce.com kaum verändern oder selbst auf dem neuesten Stand halten können: 쮿

Es sind meist einfach zu viele Daten.

쮿

Die Daten liegen in anderen Systemen, auf die der Salesforce.com-Benutzer keinen Zugriff hat.

쮿

Es ist bei bestimmten Daten schlicht nicht erwünscht, dass sie vom Benutzer manipuliert werden können. Das betrifft zum Beispiel Umsatzdaten, aus denen eine Verkäuferprovision berechnet wird.

9.1.2

Auswertungen

Nicht nur die Datenänderung, sondern die bloße Beauskunftung der Daten aus Salesforce.com kann oft nur maschinell erfolgen. Beispiel – Einer unserer Kunden wollte seine Auftrags- und Rechnungs-Daten periodisch verdichten lassen zu einer Graphik, die über Internet von befugten Leuten aufge-


213


9 – Batchprozesse und Salesforce.com DataExchange

rufen werden kann. Zwar gibt es innerhalb von Salesforce.com mit dem Report-Modul und dem Dashboard eine Möglichkeit, Grafiken zu erzeugen. In diesem Fall mussten die Daten jedoch statistisch aufbereitet werden (gleitende Durchschnitte etc.) und dann als XML-Datei einem spezialisierten Tool zugeführt werden. Sie mussten daher zwingend maschinell aus Salesforce.com gewonnen werden. Ein anderer Fall – Ein Salesforce.com-Report über alle Aufträge und Rechnungen eines bestimmten Monats liefert Summen, die von denen im Buchhaltungs-System abweichen, obwohl alle Aufträge und Rechnungen in Salesforce.com aus eben diesem System stammen. Daher wird beschlossen, die fraglichen Aufträge und Rechnungen, mit allen Feldern, aus Salesforce.com zu entladen und dabei bestimmte Prüfungen durchzuführen, die dabei helfen, den Abweichungen auf die Spur zu kommen. Es könnte zum Beispiel entdeckt werden, dass Aufträge versehentlich manuell von einem Benutzer über den Browser geändert wurden, was am Feld „LastModifiedById“ eines Auftrags-Objekts abzulesen wäre. Zusammengefasst ergibt sich die Notwendigkeit maschineller Auswertungen, oder anders gesagt Exporte, aus verschiedenen Gründen: 쮿

Daten können anders nicht gewonnen werden (z.B., wenn Salesforce-IDs analysiert werden müssen),

쮿

die Daten sind zu umfangreich und

쮿

die Daten müssen maschinell weiterverarbeitbar sein.

9.1.3

Maschinelle Batch-Verarbeitung ist unverzichtbar

Uns sind nur wenige produktiv genutzte Salesforce.com-Accounts bekannt, in denen nicht maschinell Daten geändert, ergänzt oder ausgewertet werden müssen. Beispiele aus der Praxis sind: 쮿

Abgleich von in anderen System entstehenden und gepflegten Flussdaten aus einem ERP-System: 왘 Aufträge 왘 Rechnungen 왘 Lieferdaten

쮿

Abgleich von in anderen System entstehenden und gepflegten Stammdaten aus einem ERP-System: 왘 Kunden 왘 Artikel 왘 Parameterdateien (Zahlungsbedingungen, Lieferbedingungen ...) 왘 externe Parameterdateien (die sich manchmal in sehr kurzen Perioden ändern) 왘 Wechselkurse 왘 Edelmetallpreise 왘 Wertpapierkurse

Mit dem maschinellen Initial Load hat sich das 3. Kapitel dieses Buches bereits ausführlich befasst. Im diesem Kapitel soll es um den maschinellen Abgleich (täglich, wöchentlich, monatlich, ad hoc ...) gehen.

214


Design des Abgleichs

9.2


Der Abgleich von externen Massendaten mit denen im Salesforce.com-Account muss gut überlegt sein. Im Resultat ist zu gewährleisten, dass er zuverlässige Ergebnisse liefert, d.h. dass Salesforce.com die externen Daten präzise widerspiegelt und dass er performant läuft. All dies bedarf konzeptioneller Vorüberlegungen, die im Folgenden ausführlicher erläutert werden.

9.2.1

Was – Wie – Wo abgleichen?

Es gilt zunächst zu bestimmen, 쮿

für welche Salesforce.com-Objekte der Abgleich stattfinden soll,

쮿

wo die externen Daten herkommen,

쮿

in welcher Beziehung identifizierte Objekte zu anderen stehen,

쮿

welche Felder Gegenstand des Abgleichs sein sollen,

쮿

auf welchen Zeitraum der Abgleich sich bezieht.

Salesforce.com-Objekte – Die Auswahl hängt im wesentlichen von fachlichen Erwägungen ab. Fast immer dabei sind: 쮿

Aufträge,

쮿

Rechnungen,

쮿

Lieferscheine,

쮿

Kunden und

쮿

Artikel.

Hier ist es oft auch so, dass diese Daten genau einer externen Quelle entspringen (dem ERP-System) und damit die Chance groß ist, dass sie in sich konsistent sind. Darauf kann man sich allerdings nicht immer verlassen, denn große, weltweit tätige Unternehmen haben oft einen ganzen „Zoo“ von verschiedenen ERP-Systemen, bei denen Salesforce.com gerade die Aufgabe zufällt, eine einheitliche Sicht über alle diese Systeme zu bieten. Aber auch für andere geschäftskritische Daten, z.B. Warenterminkurse, sind mitunter, teilweise stündliche, Abgleiche erforderlich. Externe Daten – Natürlich muss klar sein: 쮿

woher die externen Daten kommen, möglicherweise aus verschiedenen Quellen,

쮿

welche Felder aus ihnen jeweils benötigt werden,

쮿

in welcher Form sie angeliefert werden, also z.B. als Datei (CSV, XML, IDOC, EDIFACT,...) oder über einen Aufruf eines API einer anderen Applikation,

쮿

wann sie angeliefert werden,

쮿

dass sie in sich konsistent sind,

쮿

auf welchen Zeitraum sie bezogen sind.


215



Beziehungen – In vielen Fällen sind Daten mit anderen Daten verknüpft, zum Beispiel Aufträge mit Kunden. In Salesforce.com wird diese Verknüpfung sehr elegant als Link realisiert, ein Mechanismus, der es ermöglicht, dass (um beim Beispiel zu bleiben) im Browser schon im Auftrag der Kundenname zu sehen ist und man durch einen Klick auf diesen Link direkt zum Kunden navigieren kann. Aber ohne Fleiß kein Preis: Das Abgleichprogramm muss Salesforce.com instruieren, einen solchen Link einzurichten. Folglich ist bei der Bestimmung des Umfangs der nötigen Auftrags-Daten darauf zu achten, dass die Kundennummer in der externen Anlieferung immer mit enthalten ist. Eine zweite Art von Beziehungen, die in Salesforce.com gepflegt werden müssen, hängt mit den Zugriffsrechten bzw. den Sichtbarkeitsregeln zusammen. Ein beliebter Fehler beim Laden neuer Accounts nach Salesforce.com z.B. ist es, das Account-Feld „OwnerId“ nicht explizit zu füllen. In diesem Falle setzt das Salesforce-API automatisch dort den Benutzer ein, mit dem sich das Ladeprogramm am Account angemeldet hat. Das kann dazu führen, dass der eigentliche Anwender auf einen solchen Kunden nicht mehr zugreifen kann, obwohl dieser als Objekt in Salesforce.com gespeichert ist. Richtig ist es in diesem Fall, in „OwnerId“ die Salesforce-ID eines Benutzers mitzugeben, der im Berechtigungssystem für die definierte Zielgruppe die Sichtbarkeit garantiert. Hierher gehört auch die Tatsache, dass neue Produkte („Product2“) immer mindestens mit dem Standard-Preisbuch verknüpft werden müssen, pro Währung eine Verknüpfung. Für weitere Preisbücher sind entsprechende Einträge nötig. Versäumt man das, ist das Produkt gleichfalls nicht sichtbar (siehe auch Kapitel 3). Felder – selbstverständlich muss geklärt sein, welche Felder aus den externen Daten nach Salesforce.com übernommen werden. Manchmal muss man aber auch festlegen, dass manche Felder in Salesforce.com beim Abgleich nicht geändert werden, obwohl sie in den externen Daten auch gepflegt werden. Ein Beispiel sind die Adressangaben in den Kontakten; hier sollte eine manuell in Salesforce.com eingepflegte Änderung, die ja mit Bedacht, vielleicht aufgrund eines Telefongesprächs, vorgenommen wurde, nicht blind überschrieben werden. Eine Kompromisslösung in diesem Fall wäre, dass der Abgleich seine Daten stets in einen zusätzlichen Satz von (Custom-)Adress-Feldern („Adresse aus Buchhaltung“) schreibt, die dann von Anwender bei Bedarf übernommen oder verworfen werden können. Es kommt manchmal auch auf die Art des Abgleichs an: Wird z.B. ein Account neu erzeugt, wird man auch die normalen Adress-Felder automatisch füllen. In einem unserer Projekte gibt es sogar in jedem einzelnen Account-Objekt ein Kennzeichen, das festlegt, ob die Daten des betr. Accounts gegen externe Daten abgeglichen werden sollen oder nicht. Erfahrungsgemäß ist es wichtig, identifizieren zu können, welche Salesforce.com-Objekte bei einem Datenabgleich „angefasst“ wurden. Daher wird man, aus Gründen der Administration, (für den Endbenutzer unsichtbare) Custom-Felder in wichtigen Objekten anlegen, in denen jedes Abgleichprogramm gewissermaßen seinen „Fingerabdruck“ hinterlegt (vgl. auch Kapitel 3). Dort kann man vermerken, welches Abgleich-Programm zu welchem Datum und welcher Uhrzeit das fragliche Objekt angelegt oder modifiziert hat.

216



Zeitraum – Eine wichtige Frage: Auf welchen Zeitraum sollen sich die gelieferten Daten beziehen oder wird immer der gesamte Bestand geladen? Diese Frage ist brisant, weil der gesamte Bestand (meist bei Flussdaten wie z.B. bei Aufträgen und Positionen) oft einfach zu groß ist. Kommt man zum Ergebnis, dass man die anzuliefernden Daten auf einen Zeitraum begrenzt, ist sicherzustellen, dass sie konsistent sind über alle Datenbestände hinweg, die aufeinander verweisen (siehe vorangegangene Erläuterungen zu „Beziehungen“). Zudem muss man sicherstellen, dass alle Daten eines Zeitraums nach Salesforce.com gelangen und dass überlappende oder redundante Anlieferungen erkannt und gegebenenfalls ignoriert werden. Dieses spezielle Problem wird in den folgenden Abschnitten unter „Das Delete-Problem“ und „Fehlertoleranz“ behandelt.

9.2.2

CRUD in Salesforce

CRUD ist die Abkürzung von Create/Read/Update/Delete und bezeichnet in einem Akronym, welche vier verschiedenen Arten von Manipulationen auf Datensätzen vorgenommen werden können. Mit eben diesen haben wir es auch beim Abgleich mit Salesforce.com zu tun. Ein Beispiel: Aus einem ERP-System wird ein Auszug aus den Kunden-Daten erstellt, der dazu benutzt werden soll, die Accounts in Salesforce.com auf den neuesten Stand zu bringen. Dem API, über das man Salesforce.com diese Änderungen mitteilt, muss man auch jeweils mitgeben, ob es sich um einen 쮿

neuen (C),

쮿

bereits bestehenden (U) oder

쮿

zu löschenden Account (D)

handelt, und (im Falle U und D) die interne Salesforce-ID des fraglichen Accounts. D.h., bevor der eigentliche Abgleich durchgeführt werden kann, muss für jeden Kunden ermittelt worden sein, ob sein Pendant in Salesforce.com schon als Account bekannt ist oder nicht. Und zu diesem Zweck muss der oben genannte Kundendaten-Auszug einen eindeutigen Schlüsselbegriff, die Kundennummer, zur Verfügung stellen, der ebenso eindeutig in allen Account-Objekten als Feld zu finden sein muss. Wenn diese Voraussetzung gegeben ist (die im Übrigen schon in der Designphase des Salesforce.com-Systems vorgesehen werden muss), kann man über einen Query an Salesforce.com ermitteln, ob ein Account mit einer bestimmten Kunden-Nummer schon vorhanden ist oder nicht. Daher gehen jedem Abgleich Lese-Operationen („R“) über verschiedene Salesforce.comObjekte voraus. Die unter 9.2.5 folgende Fallstudie zeigt all dies anhand der Problemstellung, wie von einem externen System angelieferte Auftragsdaten mit den entsprechenden Daten im Salesforce.com-Account abgeglichen werden.


217



9.2.3

Eindeutigkeit

Manchmal ist es nicht einfach, einen eindeutigen Schlüssel zu finden. Beispiel – In ein Salesforce.com-System fließen Artikel-Daten aus unterschiedlichen ERP-Systemen, wobei nicht garantiert ist, dass die Artikelnummern über alles ERP-Systeme hinweg eindeutig sind. Zunächst ist das nicht schädlich, weil Salesforce.com keine Eindeutigkeit von Artikelnummern erzwingt (obwohl es intern gleichwohl eine eindeutige Id für jeden geladenen Artikel erzeugt). Die Schwierigkeit entsteht – wie oben erläutert – dann, wenn entschieden werden muss, ob ein angelieferter Artikel aus der Sicht von Salesforce.com ein neuer oder ein bereits bekannter Artikel ist. Die Lösung besteht darin, zusätzlich in einem Custom-Feld zu vermerken, aus welchem ERP-System der betreffende Artikel stammt. Die Kombination aus Artikelnummer und Inhalt dieses Feldes sorgt dann wieder für Eindeutigkeit. Man muss also im Design des Abgleichs dafür sorgen, dass alle Objekte, die man eindeutig identifizieren können muss, die nötigen Daten als Felder enthalten, damit das gewährleistet ist.

9.2.4

Das Delete-Problem

Ein spezielles Problem ergibt sich, wenn Objekte in Salesforce.com gelöscht werden sollen, zum Beispiel Artikel, die dort nicht mehr erwünscht sind. Leider sind externe Abgleichdaten dafür oft nicht geeignet, weil sie die gelöschten Daten einfach nicht enthalten. In diesem Fall könnte man zunächst sämtliche in Salesforce.com bekannten Artikel ermitteln und dann diejenigen löschen, die in der externen Datenlieferung nicht mehr auftauchen. Schwieriger wird es, wenn externe Abgleichdaten bewusst so schlank gehalten werden, dass nur Informationen über Objekte enthalten sind, die neu erzeugt oder geändert wurden. Daraus ergibt sich ein Dilemma: Wenn ein bestimmter Artikel in den externen Daten nicht mehr auftaucht, ist damit gemeint, 쮿

dass der Artikel sich seit dem letzten Abgleich nicht geändert hat,

oder 쮿

dass er gelöscht worden ist?.

Hier gibt es verschiedene Lösungen. Die eine wäre, dass die fraglichen Datenbestände stets vollständig angeliefert werden und dass das Fehlen des externen Pendants eines in Salesforce.com bekannten Objekts folglich signalisiert, dass das Objekt in Salesforce.com gelöscht werden soll. Diese Lösung kann gegebenenfalls nicht gangbar sein, wenn die Datenbestände zu groß sind. Eine andere Lösung: Die externen Anwendungen müssen dezidierte Dateien mit zu löschenden Objekten anliefern. Das bedeutet zwar mehr Programmieraufwand, klärt aber die Verhältnisse. Manchmal können die Verhältnisse aber auch noch komplizierter sein, was an einem Beispiel erläutert werden soll.

218



Zwecks Abgleich von Auftrags-Positionen-Daten kommt vom ERP-System periodisch eine Liste der derzeit aktiven Auftragspositionen. Aus der Liste geht nicht hervor, ob Auftragspositionen gelöscht wurden. Die Auftragspositionsnummern lassen keine zuverlässige Identifizierung einer Position zu; es kann vorkommen, dass eine Position gelöscht worden ist und mit völlig anderen Daten neu erfasst wurde. Eine zuverlässige Lösung ist (bzw. war im konkreten Fall) Folgende: Wenn in den angelieferten externen Daten ein Auftrag mit seiner ersten Position auftaucht, werden zuvor alle Auftragspositionen-Objekte dieses Auftrags in Salesforce.com gelöscht und anschließend alle Positionen (den externen Daten entsprechend) neu erzeugt. Beim Löschen von Objekten muss man auch immer überprüfen, ob irgendwelche in Salesforce.com etablierte Links gebrochen werden. Löscht man z.B. ein Account-Objekt, für das es Aufträge gibt, zeigen die Verweise in diesen Aufträgen anschließend ins Leere. Zwar überprüft Salesforce.com für bestimmte Links, z.B. zwischen dem Objekt „Opportunity“ und „Account“, ob sie durch einen Löschbefehl gebrochen werden und weist dann – via API – den Delete-Request zurück. Allerdings gilt das nicht durchgehend und keinesfalls für Custom-Links, so dass man gut daran tut, beim Design des Abgleichs diese Fälle im Auge zu behalten.

9.2.5

Eine Fallstudie

Vorbemerkung – In den folgenden Abschnitten werden wir uns immer wieder auf diese Fallstudie beziehen. Daher empfiehlt es sich, sie sorgfältig zu studieren. Problemstellung – Externe Auftragsdaten sollen mit denen in Salesforce.com abgeglichen werden. Was wird extern angeliefert – Ein ERP-System erzeugt täglich eine Datei mit den neuesten Auftragsdaten. Diese Datei enthält sowohl neue als auch ggf. geänderte Aufträge. Gelöschte Aufträge sind in dieser Datei nicht enthalten und werden in dieser Fall-Studie ignoriert. Die Datei enthält lediglich Records mit Auftragspositionen, allerdings sind in jedem der Records (redundant) auch alle Auftragskopfdaten enthalten, soweit sie für Salesforce.com relevant sind, insbesondere die Kundennummer des Auftragskunden. Die Datei ist aufsteigend sortiert nach Auftragsnummern und Positionsnummern. In Salesforce.com – sind folgende Objekte betroffen: 쮿

Account ein neu erzeugter Auftrag (Order__c) soll auf den zugehörigen Account verweisen

쮿

Product2 eine Position (OrderItem__c) soll auf das zugehörige Produkt verweisen

쮿

Order__c (Auftrag) dieses (Custom-)Objekt enthält alle Auftragskopfdaten; es verweist auf einen Account (=Link)

쮿

OrderItem__c (Position) dieses (Custom-)Objekt enthält alle Positionsdaten wie Menge, Preis, Artikel-Nummer etc.; es verweist auf seinen zugehörigen Auftrags-Kopf (Order__c) und einen Artikel (Product2) (=Links)


219



Abbildung 9.1: Zielstruktur

Mit der Fachabteilung ist vereinbart, dass Aufträge immer neu erzeugt werden, d.h., wenn ein Auftrag extern angeliefert wird, der auf Salesforce.com schon bekannt ist, wird er dort inklusive aller seiner Positionen gelöscht und die geänderte Version wird wie ein neuer Auftrag in Salesforce.com eingetragen. Im Schema sieht der Ablauf wie in Abbildung 9.2 gezeigt aus:

Abbildung 9.2: Ablauf des Abgleichs

220



Im Detail: Download von ID-Listen von 4 Salesforce.com-Objekten – Zunächst werden 4 Listen der Objekte „Account“, „Product2“, „Order__c“ und „OrderItem__c“ aus Salesforce.com als CSV-Dateien heruntergeladen, die jeweils zwei Spalten mit der Salesforce-ID und einem eindeutigen Schlüsselbegriff beinhalten. Für „Account“ könnte eine Datei wie folgt aussehen: "ID","CUSTNO" "00T20000005UAsJEAW","4711" "00T20000005UAsKEAW","4712" ...

für „OrderItem__c“ wie folgt: "ID","ITEMNO" "00T20000005UAtJEAW","ORD0001-ITM001" "00T20000005UAuJEAW","ORD0001-ITM002" "00T20000005UAvJEAW","ORD0001-ITM003" "00T20000005UAwJEAW","ORD0002-ITM001" ...

und für die anderen Objekte entsprechend. Diese Listen dienen im Einzelnen dazu: 쮿

anhand der Listen für „Account“ und „Product2“ sicherzustellen, dass alle Aufträge bzw. Auftragspositionen ihren Kunden bzw. ihren Artikeln in Salesforce.com zugeordnet werden können,

쮿

mit der Liste für „Order__c“ zu entscheiden, ob ein Auftrag schon bekannt ist und

쮿

unter Benutzung der Liste für „OrderItem__c“ ggf. die Auftragspositionen in Salesforce.com zu identifizieren, die gelöscht werden müssen.

Externe Daten analysieren und präparieren – Ein erstes Programm absolviert folgende Aufgaben für jede Zeile, die es in der externen Auftragspositionendatei findet: 쮿

Prüfen, ob der im Auftragskopf mit seiner Nummer vermerkte Kunde als Salesforce.com-Account bekannt ist; wenn nein, Eintrag in Fehlerliste; (diese Prüfung ist natürlich nur einmal pro Auftrag nötig, nicht für jede Auftragsposition)

쮿

Prüfen, ob zu jeder bei einer Position vermerkten Artikelnummer im Salesforce.com ein „Product2“-Objekt existiert; wenn nein, Eintrag in Fehlerliste;

쮿

Prüfen, ob der Auftrag im Salesforce.com schon bekannt ist oder nicht; wenn ja, alle Einträge, die zu dem fraglichen Auftrag gehören, in der zuvor runtergeladenen Liste der „OrderItem__c“ in eine „Delete“-Datei übernehmen sowie den betr. „Order__c“ in eine andere „Delete“-Datei; (auch dies muss natürlich nur einmal pro Auftrag geschehen, nicht für jede Auftragsposition)


221


9 – Batchprozesse und Salesforce.com DataExchange 쮿

pro Auftrag aus der Eingabe eine Zeile in einer „Create“-Datei anfügen, in der alle notwendigen Daten zum Erzeugen eines „Order__c“-Objekts enthalten sind, unter anderem die Id des Accounts, zu der der Auftrag gehört; hier sollte dieses Programm auch seinen „Fingerabdruck“ hinterlassen (siehe oben); eine solche Datei könnte wie folgt aussehen:

"NUM__C","CUSTNUM__C","DATE__C","ACCOUNTID__C","FINGERPRINT__C" "0001","4711","2007_01_10","0T2000005UAsJEAW","LOD20061201112233" "0002","4712","2007_01_08","0T2000005UAtJEAW","LOD20061201112233"

Im Resultat entstehen also bis zu vier Dateien: 쮿

Fehlerdatei (nicht gefundene „Account“/“Product2“)

쮿

„Delete“-Datei mit den IDs der in Salesforce.com zu löschenden „Order__c“-Objekte

쮿

„Delete“-Datei mit den IDs der in Salesforce.com zu löschenden „OrderItem__c“Objekte

쮿

„Create“- (oder „Insert“-)Datei der neu zu erzeugenden „Order__c“ -Objekte

Löschen OrderItem__c / Order__c, Erzeugen neuer Order__c – Die Informationen für diese Aufgabe sind im vorigen Schritt in Form von Dateien bereitgestellt worden; mittels einer geeigneten Software wie Sforce Data Loader oder Salesforce.com DataExchange (siehe Abschnitt 9.3) kann man diese Daten nun an das Salesforce-API übergeben und damit die entsprechenden Deletes in Salesforce.com veranlassen. Download der neuesten ID-Liste „Order__c“ – weil 쮿

die Auftragspositionen an ihre zugehörigen „Order__c“-Objekte angehängt werden sollen,

쮿

die neuen „Order__c“ in Salesforce.com mit ihren IDs aber gerade erst erzeugt worden sind und beim letzten Download noch gar nicht bekannt waren,

wird die Id-Liste der „Order__c“ noch einmal angefordert und ist dann auf dem neuesten Stand. Damit sind die Voraussetzungen geschaffen, dass die „OrderItem__c“ korrekt zu ihren „Order__c“ verlinkt werden können. Lade-Datei für OrderItem__c-Objekte erzeugen – Ein zweites Programm geht nun noch einmal die Datei der externen Auftragspositionsdaten durch und erzeugt für jeden Satz einen Satz in einer „Create“-Datei für „OrderItem__c“, in der sich nicht nur die relevanten Positionsdaten, sondern auch die Links auf die zugehörigen „Order__c“ bzw. „Product2“ befinden. Ein solcher Verweis besteht in einer Salesforce-ID, die das Programm aus den entsprechenden ID-Listen für den betreffenden Auftrag bzw. Artikel gewinnen kann. Eine solche Datei könnte wie folgt aussehen: "ORD__C","NUM__C","ORDID__C","PRODID__C","ISACTIVE",.. "0001","001","00T20000005UAsJEAX","00T20000005UAsJEAY","TRUE",.. "0001","002","00T20000005UAsJEAX","00T20000005UAsJEAZ","TRUE",.. "0002","001","00T20000005XXsJEAX","00T20000005UAsJEAZ","TRUE",.. ...

222



Erzeugen der „OrderItem__c“-Objekte in Salesforce.com – Die im vorigen Schritt bereitgestellte Datei kann mit einem Utility-Programm nach Salesforce.com geladen werden und veranlasst, dass die Auftragspositionen in Form von „OrderItem__c“-Objekten erzeugt werden.

9.2.6

Architektur-Empfehlungen für den Abgleich

Salesforce.com ist ein System, das auf hohe Verfügbarkeit der Daten zugeschnitten ist. Daher muss in der Architektur des Datenabgleichs auch mit berücksichtigt werden, welche Auswirkungen Fehler im Abgleichprozess (und ihre Korrektur) haben sollen und dürfen. Im Lauf der Zeit kommt es beim Abgleichprozess immer zu Fehlern. Man kann deren Auswirkungen stark einschränken, wenn man folgende ArchitekturEmpfehlungen beachtet, die ihren Nutzen dann besonders entfalten, wenn sie alle eingehalten werden: 쮿

Wiederholbarkeit: Ein Abgleich muss mit denselben Daten wiederholbar sein, ohne dass er zu anderen Ergebnissen führt; das gewährleistet, dass man einen abgebrochenen Abgleich ohne große Vorkehrungen wiederholen kann.

쮿

gleitende Zeiträume bei zeitabhängigen externen Daten: Wenn man z.B. Auftragsdaten abgleichen will, sollte man niemals festlegen, dass Daten eines Zeitraums nur ein einziges Mal angeliefert werden, sondern eher so etwas wie „immer alle Daten der letzten 14 Tage“. Nehmen wir an, bei einem Abgleich wurde ein Auftrag ausgesteuert, weil der zugehörige Kunde in Salesforce.com-Account nicht bekannt war. Die Fachabteilung muss den fehlenden Kunden erst einpflegen, bevor der Auftrag ohne Probleme durch den Abgleich läuft. Wird ein Auftrag aber immer nur einmal angeliefert, ist er für immer verloren, es sei denn, man implementiert eine Fehlerbehandlung, die sich abgewiesene Aufträge merkt und zu gegebener Zeit wieder dem Abgleich zuführt. All dies kann man sich sparen, wenn man mit gleitenden Zeiträumen arbeitet und als Zeitraumdauer die maximale Zeitspanne wählt, die man benötigt, um einen Fehler zu korrigieren. 14 Tage ist hierbei ein erprobter Wert.

쮿

den direkten Datenaustausch mit Salesforce.com aus den Abgleichprogrammen heraushalten: Das heißt, alle Abgleichprogramme sollen nur Dateien lesen oder erzeugen, niemals aber direkt mit Salesforce.com kommunizieren. Wenn man sich daran hält, reduziert sich die Anzahl kritischer Stellen, an denen im Fehlerfall gegebenenfalls Handarbeit nötig ist. Zudem stehen die Dateien des Up- und Downloads immer noch zur Fehleranalyse zur Verfügung und haben sich nicht (da im Memory) beim Absturz eines Programms verflüchtigt. Diese Dateien enthalten ja wichtige Informationen darüber, welche Kommandos man an Salesforce.com geschickt hat bzw. was von Salesforce.com als Antwort geliefert worden ist.


223



niemals die externen Daten ändern aufgrund des Abgleichs: Wenn man versucht, irgendwo in den externen Daten genau Buch darüber zu führen, wie weit ein Abgleich gekommen ist, ist das bei Systemfehlern ggf. nicht zuverlässig und verkompliziert die Fehlerbehebung. Auch hier kommt es wie immer natürlich darauf an, wie man das macht; unsere Empfehlung ist jedoch, es gar nicht zu tun. Allerdings kann es sinnvoll sein, sich auf einer (gesonderten) Datei zu merken, welche Abgleiche mit welchen „Fingerabdrücken“ erfolgreich durchgelaufen sind, d.h. ihre Updates in Salesforce.com vollständig haben durchführen können.

쮿

„Fingerabdruck“ hinterlassen In jedem wichtigen Salesforce.com-Objekt, das Gegenstand des Batch-Abgleichs ist, sollte sich ein Feld befinden, aus dem ersichtlich ist, welches Programm zu welcher Zeit Creates bzw. Updates in Salesforce.com vorgenommen hat. Muss man zwecks Fehlerkorrektur bereits nach Salesforce.com geladene Daten wieder entfernen kann man mit einem einfachen Query feststellen, welche Objekte betroffen waren und sie gegebenenfalls löschen. In konkreten Projekten hat sich das folgende Vorgehen bewährt: Jedes relevante Salesforce.com-Objekt bekommt ein Custom-Feld „FINGERPRINT__C“ (Text: 20 Stellen), welches das Ladeprogramm mit einem fünfstelligen Kürzel und einem Zeitstempel füllt, z.B. „ORD01_20061231121500“. Das bedeutet, dass das Abgleichprogramm „ORD01“, das am 31.12.2006 12:15:00 gestartet wurde, diesen Datensatz erzeugt hat, der dann in Salesforce.com zum Create oder Update eines Objekts führt.

9.2.7

Fehlerbehandlung

Mit diesem Rüstzeug sollen nun die verschiedenen Fehlerarten betrachtet werden und insbesondere, wie man ihre Auswirkungen – insbesondere eine Blockade der Verarbeitung – gering hält. Die obersten Maximen sind: 쮿

den laufenden Vertrieb möglichst wenig beeinträchtigen,

쮿

inkonsistente oder falsche Daten gar nicht erst nach Salesforce.com gelangen zu lassen.

Systemfehler – Darunter sollen Fehler verstanden werden, die zum unvorhergesehenen Abbruch eines Abgleichprozesses führen, der an sich logisch korrekt arbeitet. Gründe dafür können sein: 쮿

Programmabsturz,

쮿

Rechnerabsturz,

쮿

Zusammenbruch der Internet-Verbindung beim Upload/Download.

Zunächst muss natürlich die Fehlerursache ermittelt und ggf. behoben werden. Für die Wiederholung des Abgleichs bleibt (wenn die oben dargelegten Empfehlungen eingehalten werden) aber nur ein einziger kritischer Punkt: der Upload einer Datei, die Salesforce.com anweist, neue Objekte zu erzeugen, sie zu ändern oder sie zu löschen. Denn andernfalls ist in Salesforce.com schlichtweg nichts geändert worden.

224



Bei näherem Hinsehen ergibt sich eine weitere Eingrenzung der Fehlermöglichkeiten: 쮿

Das Löschen von Objekten ist tatsächlich nicht kritisch: Die bereits gelöschten Objekte sind ja zu Recht gelöscht worden und die noch nicht gelöschten werden bei der Wiederholung gelöscht.

쮿

Das Update von Objekten ist nicht kritisch: Hier gilt dieselbe Überlegung wie beim Löschen.

쮿

Das Create von Objekten kann kritisch sein, weil man nicht sicher weiß, inwieweit die über SOAP an Salesforce.com übermittelten Anweisungen tatsächlich ausgeführt worden und somit Objekte erzeugt worden sind. Es hängt vom Design des Abgleichs ab, ob ein Abgleich in einer solchen Fehlersituation einfach wiederholt werden kann (das oben in der Fallstudie vorgestellte Design „verkraftet“ einen solchen Abbruch). Andernfalls kommt das „Fingerabdruck“-Feld zum Zuge: Man kann mittels eines Query alle solchen Objekte identifizieren und vor dem Wiederhollauf löschen.

Logische Fehler (I) – Es gibt eine Sorte logischer Fehler, die von den Abgleichprogrammen und der Upload-Utility unmittelbar erkannt werden können. Die folgenden Beispiele sind so gewählt, dass sie jeweils eine andere Fehlerbehandlung nahelegen: 쮿

(a) für in Auftragsdaten referenzierte Kunden bzw. Artikel fehlen die entsprechenden Salesforce.com-Objekte „Account“ bzw. „Product2“;

쮿

(b) eine aus Salesforce.com geladene Liste mit Kundennummer und Salesforce-ID enthält doppelte Kundennummern;

쮿

(c) ein PriceBookEntry für eine Kombination Artikel/Währung/Preisbuch, die erzeugt werden soll, existiert schon.

Im Fall (a) wird man das Problem in einer Fehlerliste dokumentieren und die entsprechenden Aufträge bzw. Auftragspositionen nicht nach Salesforce.com laden, aber den gesamten Abgleich deswegen nicht abbrechen. Befolgt man die oben propagierte Empfehlung der „gleitenden Zeiträume“, müssen lediglich die fehlenden „Account“- bzw. „Product2“-Objekte in Salesforce.com angelegt werden: Einer der nächsten Abgleiche wird dann die fraglichen Daten korrekt nach Salesforce.com einspielen. Im Fall (b) muss wahrscheinlich der Abgleich abgebrochen werden, da ggf. nicht mehr eindeutig ist, zu welchem Kunden ein Auftrag in Salesforce.com gelinkt werden soll. Solche Probleme entstehen oft dann, wenn Objekte in Salesforce.com manuell gepflegt werden. Fall (c) kann einfach ignoriert werden, weil man ja nur irrtümlich ein bloßes Link-Objekt („PriceBookEntry“ ist ein solcher Objekt-Typ) noch einmal erzeugen wollte, das es aber schon gibt. Logische Fehler (II) – Eine Sorte weitaus unangenehmerer logischer Fehler besteht darin, dass sich erst nach längerer Zeit herausstellt, dass Abgleichprogramme falsche Algorithmen für Berechnungen oder die Erzeugung von Links benutzt haben oder dergleichen. Hier ist es schwierig, allgemeine Ratschläge zu geben, weil die Art des Fehlers maßgeblich ist für die Maßnahmen, die ergriffen werden müssen. Oft muss in solchen


225



Fällen die Gesamtheit bestimmter Objekte gelöscht und neu geladen oder zumindest ein Update über sie gefahren werden. Fehler melden: wann, wie, an wen – Damit der Abgleichprozess möglichst automatisch ablaufen kann, wird man ihn periodisch mit einem Scheduler starten lassen. Im Sinne eines „Management By Exception“ lohnt es sich, frühzeitig zu bedenken, wer im Fehlerfall wie informiert wird, und die OS-Scripte, die den Batch-Abgleich steuern, entsprechend zu gestalten. Voraussetzung ist, dass die beteiligten Programme die verschiedenen Abbruchbedingungen – so weit und so detailliert wie möglich – an das Script zurückgeben. In der Praxis hat sich folgendes Vorgehen bewährt: 쮿

Abbruch-Ursachen werden kategorisiert danach, wer für eine Fehlerbehebung verantwortlich ist;

쮿

Verantwortliche werden per E-Mail benachrichtigt.

Hier mag das folgende Beispiel helfen, das die obige Fallstudie aufgreift:

Abbildung 9.3: Benachrichtigung mittels E-Mail

226



Im Detail: 쮿

Download I: 4 ID-Listen wenn Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs

쮿

Programm I wenn schwerer Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs wenn Fehler-Bericht erzeugt wurde 왘 E-Mail an Fachabteilung mit Fehlerbericht 왘 (kein Abbruch)

쮿

Upload I: Löschen Aufträge/Positionen, Erzeugen Aufträge wenn Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs

쮿

Download II: ID-Liste für „Order__c“ wenn Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs

쮿

Programm II wenn schwerer Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs

쮿

Upload II: Erzeugen Positionen wenn Fehler 왘 E-Mail an IT mit Log-Datei 왘 Abbruch des Jobs

쮿

Success: 왘 ggf. E-Mail an Fachabteilung mit OK-Meldung

9.2.8

Performanz

Wenn abzusehen ist, dass ein täglicher Abgleichprozess sehr lange oder gar zu lange dauern wird, sind weitere Überlegungen nötig. Da beim Abgleich regelmäßig der Austausch von Daten mit Salesforce.com (insbesondere der Upload) der Flaschenhals ist, lohnt es sich, hier genauer hinzuschauen.


227



Datenmengen minimieren – Je weniger Daten über die Apex-Web-Service-Schnittstelle nach Salesforce.com geschickt werden, desto günstiger. Man sollte daher nicht stets alle Daten abgleichen, sondern versuchen, mit Deltas zu arbeiten, also bereits in Salesforce.com korrekt befindliche Daten unangetastet zu lassen. Zeitfenster suchen – Die Geschwindigkeit, mit der Salesforce.com das Apex Web Service API bedient, schwankt stark im Tagesverlauf. Mit der Auswahl eines richtigen Zeitfensters (z.B. ab 22:00 MEZ) kann man leicht die doppelte und dreifache Geschwindigkeit erreichen, gemessen an normaler Belastung. Batches bilden – Die Programme, die den direkten Austausch der Daten mit dem Apex API steuern, sollten immer mit Batches arbeiten, d.h. Verarbeitungs-Requests zu Paketen zusammenfassen, da pro Paket jeweils nur eine Interaktion mit Salesforce.com stattfindet. In den oben bereits erwähnten Utilities Sforce Data Loader und Salesforce.com Data Exchange ist das gewährleistet.

9.2.9

Helferlein

Die oben erwähnten Abgleichprogramme, die je nach Anforderung individuell erstellt oder geändert werden müssen, weisen trotz aller Unterschiede doch ähnliche Muster auf: 쮿

verschiedene Datenformate müssen gelesen oder erzeugt werden,

쮿

Dateninhalte werden gegeneinander abgeglichen,

쮿

Fehlerberichte sind zu schreiben.

Man muss das Rad nicht ständig neu erfinden: Es gibt entsprechende Frameworks, die bei der Entwicklung und dem Test solcher Programme Hilfestellung leisten.

9.3

Salesforce.com DataExchange

In diesem Abschnitt geht es um das Programm Salesforce.com DataExchange (SDE), welches den Datenaustausch mit Salesforce.com über SOAP regelt (genau genommen das Apex Web Service API). Die Software wurde aufgrund der Anforderung in mehreren Projekten entwickelt. Denkanstöße kamen vom Sforce Data Loader [SDL], den wir auch zunächst in einigen Projekten eingesetzt hatten. Da die uns damals vorliegende Version 6 zu begrenzt und umständlich erschien, und es zudem fast unmöglich war, in OS-Scripten Fehler abzufangen, reifte der Entschluss, eigene Software für diesen Zweck zu entwickeln.

9.3.1

Anforderungen

Funktionsumfang bzw. Charakteristiken der Utility sollten sein: 쮿

Herunterladen beliebiger Objekte mit ihren Daten aus Salesforce.com: Übergabe eines Query an Salesforce.com, Entgegennahme des Query-Resultats und Abspeicherung in einer CSV-Datei.

228


Salesforce.com DataExchange 쮿

Herunterladen einzelner Felder in jeweils eine Datei: Salesforce.com kann einzelne sehr große Felder haben, in denen man z.B. Dokumente oder HTML-Daten speichern kann; solche Feld-Inhalte, die auch Steuerzeichen aller Art enthalten können, sollen direkt in eine Datei heruntergeladen werden können.

쮿

Löschen von Salesforce.com-Objekten: Übergabe multipler, als CSV-Datei vorliegender Salesforce-IDs an Salesforce.com, deren zugehörige Objekte zu löschen sind.

쮿

Update von Salesforce.com-Objekten: Übergabe von Salesforce-IDs und zu ändernden Daten als CSV-Datei, aufgrund deren die betr. Salesforce.com-Objekte modifiziert werden.

쮿

Update einzelner Felder von Datei: Salesforce.com kann einzelne sehr große Felder haben, in denen man z.B. Dokumente speichern kann; solche Feld-Inhalte, die auch Steuerzeichen aller Art enthalten können, sollen direkt von einer Datei nach Salesforce.com hochgeladen werden können.

쮿

Erzeugen von Salesforce.com-Objekten und Ermittlung der IDs: Übergabe von zu erzeugenden Daten als CSV-Datei, aufgrund deren die betreffenden Salesforce.com-Objekte erzeugt werden; dazu optionale Rückübermittlung der vergebenen Salesforce-IDs.

쮿

Selektives Löschen: Übergabe einer Query-Bedingung an Salesforce.com, die formuliert, welche Objekte eines Objekt-Typs zu löschen sind, ohne dass man sie als Liste zur Verfügung stellen muss.

쮿

Löschen einzelner Felder: Normalerweise werden Felder, denen man im Update einen leeren Inhalt geben will, von Salesforce.com in ihrem ursprünglichen Wert belassen; es soll eine Möglichkeit zur Verfügung stehen, den alten Inhalt tatsächlich zu entfernen.

쮿

Zusammenfassung mehrerer „Tasks“: Mehrere verschiedene Verarbeitungsanforderungen an Salesforce.com sollten mit einem einzigen Aufruf angestartet werden können.

쮿

zuverlässiges und parametrierbares Fehler-Handling: Da die Software im Produktivbetrieb in OS-Scripten Verwendung findet, sollen möglichst alle Fehler-Situationen gut unterscheidbar und zuverlässig in Form eines Return-Codes zurückgegeben werden.

쮿

möglichst hohe Performanz: Das Batching von Requests an Salesforce.com ist zu unterstützen.


229



Zugriff auch über Proxy-Host: Die Einwahl ins Internet über einen Proxy-Server (bis zu vier zusätzliche Parameter: IP-Adresse, Port, User, Password) muss unterstützt werden.

쮿

Test-Modus: Unterstützung eines Modus, der verschiedene syntaktische und logische Prüfungen durchführt, ohne dass der Austausch über das Apex Web Service API tatsächlich angestartet wird.

쮿

Abarbeitung von Mixed-Mode-Scripten: Unterstützung einer Verarbeitungsart, in der die API-Aufrufe nicht per Batch verarbeitet werden, sondern aufgrund einzelner Anweisungen durch das API.

쮿

automatische Zeit-Korrektur: Die Möglichkeit, mit einfachen Mitteln festzulegen, dass alle angelieferten Daten um eine festgelegte Zeitdifferenz korrigiert werden.

쮿

implizite Mapping-Definitionen Die erste Zeile einer Lade-Datei enthält immer die Namen der Felder in Salesforce.com, auf die sich die Daten in den Spalten beziehen, sodass keine gesonderten Mapping-Informationen erforderlich sind.

쮿

Meta-Daten: Einfacher Zugriff auf Salesforce.com bei Fragestellungen wie: 왘 Welche Felder hat ein bestimmter Objekt-Typ? 왘 Wie viele Objekte eines bestimmten Typs sind in Salesforce.com vorhanden?

쮿

Kommando-Datei XML: Die Datei, mittels derer die Software parametriert wird, ist eine XML-Datei.

9.3.2

Beispiel: Kommando-Datei und Trace

Im Folgenden wird, bevor die einzelnen Funktionen im Detail erläutert werden, eine typische XML-Datei gezeigt, die den Salesforce.com DataExchange steuert. [email protected] 4711pwd4712

230



yes c:/arlanis/sde_log_file.log 24 500000 extract Account ID,name Name like 'A%' c:/arlanis/result1.csv insert Lead c:/arlanis/leads_to_be_created.csv update Product2 c:/arlanis/products_to_be_updated.csv selective_delete Contact flag__c = 'LOD01_20061231111523'


231



Die, hier etwas komprimiert dargestellte, Log-Datei könnte wie folgt aussehen: [00:00:00:016] [00:00:00:016] [00:00:00:016] [00:00:00:032] [00:00:00:032] [00:00:00:032] [00:00:00:032] [00:00:00:032] [00:00:00:032] [00:00:00:032] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:047] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:00:063] [00:00:06:187]

232

Arlanis Salesforce.com DataExchange (c) arlanis Software AG (2005-2007) *** Parameters *** ======================================= user_name : [email protected] con_file_name : c:/arlanis/sde_commands.xml trace : true log_file_name : c:/arlanis/sde_log_file.log deltaHours : 24 time-out (ms) : 500000 --------------------------------------task : #1 - command : extract - object : Account - namelist : ID,NAME - where : Name like 'A%' - csv file : c:/arlanis/result1.csv - force title : true --------------------------------------task : #2 - command : insert - object : Lead - csv file : c:/arlanis/leads_to_be_created.csv --------------------------------------task : #3 - command : update - object : Product2 - csv file : c:/arlanis/products_to_be_updated.csv --------------------------------------task : #4 - command : selective_delete - object : Contact - namelist : ID - where : flag__c = 'LOD01_20061231111523' - csv file : c:/arlanis/products_to_be_updated.csv ======================================= ... start of login ... login successful



[00:00:06:187] [00:00:06:187] [00:00:09:281] [00:00:09:281] [00:00:09:281] [00:00:09:281] ... [00:00:15:399] [00:00:15:399]

... start of processing ...... start of task #1: 'extract' --> Account ......... extracting last batch (ok:176/err:0) ......... 176 action(s) successful ......... 0 action(s) failed ......... task status code: 00 ... end of processing End of Trace: 2006-12-22, 07:46:02:687

Die folgenden Beschreibungen geben ausgewählte Bereiche der Funktionalitätsvielfalt wieder. Die vollständige Dokumentation liegt dem Werkzeug in Form einer HTMLHilfe-Datei bei.

9.3.3

{userName} {password} {proxyHostName|proxyHostIpAdress} {proxyHostPortNumber} {proxyUsername} {proxyPassword}

Der -Tag und seine beiden ersten Einträge sind mandatorisch. Ob tatsächlich die -Tags erforderlich sind, hängt von der Umgebung ab, in der der SDE betrieben wird.

9.3.4

{logFileName} {yes|no} ±{hours} {generalStatusFileToBeWritten} {num} 쮿

log_file_name (mandatorisch) Name der Datei, auf die das Log ausgegeben werden soll


233



trace (optional; Leerwert: ‚no’) ‚yes’ erzeugt einen detaillierten Trace.

쮿

correct_date_by_hours (optional; Leerwert: ‘+0’) Sorgt für eine Korrektur des Inhalts aller Felder, die bei einem „insert“ oder „update“ angeliefert werden und die in Salesforce.com vom Typ „date“ oder „datetime“ sind; kann auch eine negative Zahl sein

쮿

status_file_name (optional; Leerwert: keine Datei) Enthält als Ergebnis (lediglich) eine zweistellige Nummer, die angibt, mit welchem Status die Verarbeitung beendet wurde; folgende Statuswerte sind möglich: 50: severe error; 33: was aborted, b/c an alarm status was reached 05: some objects could not be processed 01: no errors, but no object was processed 00: no errors; at least one object was processed successfully

쮿

abort_if_status_greater_equal (optional; Leerwert: 2147483647) Die gesamte Verarbeitung wird abgebrochen, sobald eine einzelne Task (siehe unten) mit einem Status abbricht, der gleich oder größer als der hier angegebene Wert ist.

9.3.5

und

extract|extract_numbers|delete|selective_delete| insert|update|mixed_mode|metainfo {SalesForce-Object-Name} {whereClause} {@all|listOfNames} {csvFile(ReadOrWrite)} {errorFile(Write)} {statusFile(Write)} {fileWithNewIDs(Write)} {num} ...

234



In kann ein einzelnes Attribut („check_only“) mitgegeben werden, das bestimmt, ob nur syntaktische und logische Prüfungen durchzuführen sind oder ob danach die Verarbeitung auch angestartet wird. Ansonsten ist hier das allgemeine Format des -Tags vorgestellt. Je nach Kommando (siehe unten) haben die einzelnen Tags ggf. unterschiedliche Bedeutungen. Alle Angaben (mit Ausnahme der XML-Tag- und XML-Attribute-Namen) können in Groß- oder Kleinschrift erfolgen.

9.3.6

Kommando: Extract

Ein einleitendes Beispiel: EXTRACT Lead where company = 'Arlanis' Id,lastname c:/arlanis/sde/leads.down

Mit „EXTRACT“ wird SDE angewiesen, einen Query auszuführen und das Resultat als CSV-Datei zur Verfügung zu stellen. Im Beispiel oben sollen alle Objekte vom Typ „Lead“ selektiert werden, in denen das Feld „company“ den Inhalt „Arlanis“ hat; deren Felder „Id“ und „lastname“ sollen auf die CSV-Datei „c:/arlanis/sde/leads.down“ geschrieben werden. Ein Resultat könnte wie folgt aussehen: "ID","LASTNAME" "00Q30000009zxCrEAI","name1" "00Q30000009zxCsEAI","name2" "00Q30000009zxCtEAI","name3" "00Q30000009zxCuEAI","name4" ...

Die Angabe „force_extract_title=’yes’“ im -Tag bewirkt, dass die erste Zeile mit den Feldnamen auch dann geschrieben wird, wenn kein Objekt gefunden wurde. Fehlt diese Angabe, wird eine Ausgabedatei überhaupt nur dann geschrieben, wenn der Query mindestens ein Objekt gefunden hat.


235



9.3.7

Kommando: Insert

Ein einleitendes Beispiel: INSERT Lead c:/sde/leads.insert c:/sde/leads.insert.errors.csv c:/sde/leads.IDs.csv

Mit „INSERT“ wird SDE angewiesen, eine CSV-Datei einzulesen und daraus neue Salesforce.com-Objekte zu erzeugen. Eine solche Datei könnte so aussehen: "LASTNAME","COMPANY","STATUS","LEADSOURCE","FINGERPRINT__C" "name1X","TMG","Open","RGR","lod01_20061227155513" "name2X","TMG","Open","RGR","lod01_20061227155513" "name3X","TMG","Open","RGR","lod01_20061227155513" ...

Die Namen in der ersten Zeile müssen in Salesforce.com bekannte Namen des betreffenden Objekt-Typs sein; der Name „id“ darf dort aber nicht erscheinen. Im Beispiel oben sollen die in Datei „c:/sde/leads.insert“ befindlichen Angaben zur Erzeugung von neuen „Lead“-Objekten benutzt werden. Eventuell auftauchende Fehler sind in die Datei „c:/sde/leads.insert.errors.csv“ zu schreiben. In der Datei „c:/sde/ leads.IDs.csv“ werden in der Reihenfolge der Eingabe die von Salesforce.com erzeugten IDs gespeichert.

9.3.8

Kommando: Update

Einleitendes Beispiel: UPDATE Lead c:/sde/leads.update c:/sde/leads.update.errors.csv

Mit „UPDATE“ wird SDE angewiesen, eine CSV-Datei einzulesen und daraus bestehende Salesforce.com-Objekte zu modifizieren. Eine solche Datei könnte so aussehen:

236



"ID","LASTNAME","TITLE","FINGERPRINT__C" "00Q30000009zxCrEAI","Smith","","lod01_20061227155513" "00Q30000009zxCsEAI","Jones","","lod01_20061227155513" "00Q30000009zxCtEAI","Brown","","lod01_20061227155513" "00Q30000009zxCuEAI","Black","","lod01_20061227155513" ...

Die Namen in der ersten Zeile müssen in Salesforce.com bekannte Namen des betreffenden Objekt-Typs sein; der Name „id“ muss dort erscheinen. Im Beispiel oben sollen die in der Datei „c:/sde/leads.update“ befindlichen Angaben zur Modifikation von bestehenden „Lead“-Objekten benutzt werden. Eventuell auftauchende Fehler sind in der Datei „c:/sde/leads.update.errors.csv“ abzulegen. Die Angabe „blank_to_null='yes'“ bewirkt, dass die „TITLE“-Felder der betr. Objekte, die ja im Beispiel auf '''' gesetzt werden sollen, tatsächlich auch in Salesforce.com geleert werden. Andernfalls werden mit leerem Inhalt angelieferte Felder ignoriert und demnach in Salesforce.com auch nicht modifiziert.

9.3.9

Kommando: Delete

Ein einleitendes Beispiel: DELETE Lead c:/sde/leads.delete

Mit „DELETE“ wird SDE angewiesen, eine CSV-Datei einzulesen und unter Zuhilfenahme der dort befindlichen Feld-Inhalte der Spalte „Id“ bestehende Salesforce.comObjekte zu löschen. Eine solche Datei könnte wie folgt aussehen: "ID" "00Q30000009zxCrEAI" "00Q30000009zxCsEAI" "00Q30000009zxCtEAI" "00Q30000009zxCuEAI" ...

Die Namen in der ersten Zeile müssen in Salesforce.com bekannte Namen des betreffenden Objekt-Typs sein; der Name „id“ muss dort erscheinen. Letztlich werden aber nur die Werte aus der „Id“-Spalte benutzt. Im Beispiel oben sollen die in der Datei „c:/sde/leads.delete“ befindlichen Angaben zum Löschen von bestehenden „Lead“-Objekten benutzt werden.


237



9.3.10 Kommando: Selective_Delete Ein einleitendes Beispiel: SELECTIVE_DELETE Account Name like 'S%'

„SELECTIVE_DELETE“ ist ein kombinierter Befehl: Er vereinigt die Funktionalität von „EXTRACT“ und „DELETE“ und erlaubt es, direkt anzugeben, welche Objekte eines Typs zu löschen sind, ohne dass man entsprechende Dateien zur Verfügung stellen muss, die diese Objekte auflisten. Im vorherigen Beispiel wird verlangt, dass alle „Account“-Objekte gelöscht werden sollen, deren „Name“ mit „S“ beginnt.

9.3.11

Kommando: Mixed_Mode

Der Mixed_Mode stellt eine Syntax zur Verfügung, die es erlaubt, Befehl für Befehl mit dem Apex API zu arbeiten. Beispiel: In einer Text-Datei werden folgende Zeilen bereitgestellt: ; Start-Message zeigen display,"... start ..." ; neues "Account"-Objekt erzeugen mit dem Namen "Smith Ltd." insert,"Account:Name","Smith Ltd." ; Salesforce-ID des gerade erzeugten Objekts holen get_id,"Account","name = 'Smith Ltd.'" ; Salesforce-ID anzeigen display,"ID=%ID%" ; BILLINGSTREET-Feld in diesem Account ändern update,"Account:ID,BILLINGSTREET","%ID%","Peace Avenue 3" ; DESCRIPTION-Feld von Datei holen und nach Account laden update_field_from_file,"Account:%ID%:Description", "c:/sde/descr.data" ; DESCRIPTION-Feld aus Account holen und auf ; andere Datei schreiben get_field_into_file,"Account:%ID%:Description", "c:/sde/descr_get.data" ; Account wieder löschen delete_by_id,"%ID%"

238



In diesem Beispiel kommen alle zulässigen Mixed-Mode-Kommandos vor (sie sind fett geschrieben); in den mit „;“ beginnenden Kommentarzeilen wird erläutert, was das jeweils folgende Kommando tut. Die in Doppelhochkomma eingeschlossenen Angaben können auch ohne das Doppelhochkomma angegeben werden, sofern sie kein Komma enthalten. Ist diese Anweisungsfolge als Datei „c:/sde/mixed_mode_commands.csv“ hinterlegt, kann man sie mit folgender -Angabe zur Ausführung bringen: MIXED_MODE c:/sde/mixed_mode_commands.csv

Bei einem Fehler wird die Abarbeitung der Mixed-Mode-Kommandos abgebrochen. Dieser Modus sollte nicht für größere Datenmengen benutzt werden, da für jede Zeile eine Interaktion mit dem Apex Web Service API stattfindet und daher die Verarbeitung langsam sein kann.

9.3.12 Kommandos: MetaInfo/Extract_Numbers Die beiden Kommandos „METAINFO“ und „EXTRACT_NUMBERS“ werden hier nur gestreift. Weitere Details können in der HTML-Online-Hilfe nachgelesen werden. „METAINFO“ dient dazu, von allen oder ausgewählten Salesforce.com-Objekt-Typen zu ermitteln, welche Felder sie haben, welchen Typs sie sind und wie sie bearbeitet werden können. „EXTRACT_NUMBERS“ ermittelt die Anzahl aller oder ausgewählter Salesforce.com-Objekt-Typen.

9.3.13 Download von Salesforce.com DataExchange SDE ist ein freies Werkzeug und steht auf den Webseiten der arlanis Software AG zum Download bereit. Der Salesforce.com DataExchange kann sowohl in freien als auch in kommerziellen Projekten eingesetzt werden, Feedback ist natürlich jederzeit willkommen. Weitere Informationen sind unter der Webseite zum Buch zu finden [AR01].


239



10 10.1

Apex Code – On-DemandProgrammiersprache

Überblick

Apex Code ist eine prozedurale Programmiersprache. Programme in dieser Sprache werden vollständig innerhalb des Apex OS, also auf dem Server, ausgeführt. Im Gegensatz zum Ansatz mit JavaScript bestehen keine Einschränkungen der Performance, wie sie durch die Übertragung und clientseitige Ausführung von Skripten entstehen. Apex Code-Programme werden geschrieben, zum Apex OS übertragen, übersetzt und können im Anschluss aus den verschiedensten Umgebungen heraus genutzt werden.

Abbildung 10.1: Apex Code in der Entwicklung und zur Laufzeit

Wenn ein Entwickler Apex-Code-Skripte zur Apex-Plattform überträgt, werden diese in einem ersten Schritt überprüft und anschließend in einen abstrakten Satz von Instruktionen übersetzt. Diese Instruktionen werden im Metadata-System gespeichert und können vom Apex-Code-Laufzeitinterpreter ausgeführt werden. Wenn der Salesforce.comAnwender den Apex Code ausführen möchte, werden die übersetzten Instruktionen aus dem Metadata-System geholt und mittels des Laufzeitinterpreter abgearbeitet. Das Ergebnis dieses Vorgangs wird im Anschluss zum Anwender gesendet. Dieser erkennt keinen Unterschied zu Standardanfragen an die Plattform. Die Apex-Code-Sprache ist sehr stark an Java angelehnt, enthält aber integrierte Abfrageund Manipulationsmöglichkeiten für die im Salesforce.com-Account gespeicherten


241


10 – Apex Code – On-Demand-Programmiersprache

Datensätze. Die in die Sprache integrierte Unterstützung umfasst dabei die meisten aus der Apex-Plattform her bekannten Idiome: 쮿

Die Datenmanipulation mittels INSERT, UPDATE, DELETE inklusive der dazugehörigen Ausnahmebehandlung ist über entsprechende Schlüsselworte möglich.

쮿

Eine integrierte Abfragesprache auf Basis der Sforce Object Query Language (SOQL) ermöglicht den Zugriff auf einzelne Objekte oder Objektmengen.

쮿

Steuer- und Flussanweisungen (zum Beispiel for-Schleifen), welche eine Batchverarbeitung ermöglichen, wurden integriert.

쮿

Es besteht die Möglichkeit, Objekte zu sperren, um Konflikte zu vermindern.

쮿

Methoden in Apex Code können als öffentliches API anderen Systemen (wie AJAX basierten Clients) zur Verfügung gestellt werden.

Obwohl vieles möglich ist, sollte man sich jedoch einiger Einschränkungen1 und Limitierungen bewusst sein: 쮿

Es können keine Oberflächenelemente, mit Ausnahme von Fehlernachrichten, dargestellt werden.

쮿

Die Standardfunktionalität von Salesforce.com kann nicht verändert werden.

쮿

Es können keine Sforce Object Search Language (SOSL)-Abfragen genutzt werden.

쮿

Der Versand von E-Mail ist nicht möglich.

쮿

Der Aufruf von Third-Party Web Services ist nicht möglich.

쮿

Das Erzeugen von temporären Dateien ist untersagt.

쮿

Es können keine neuen Threads erzeugt werden.

쮿

Die Nutzung von Netzwerkressourcen ist nicht möglich.

Mittels Apex Code ist es möglich, Business-Funktionalität direkt in eine Apex-Anwendung einzufügen oder zu benutzten. Im Weiteren ist es möglich, Events, Buttons, Datensatz-Updates oder auch S-Controls mit mehr Logik zu versehen. Viele Informationen zu Apex Code sind in der Language Reference [ACLR] zu finden.

10.2 Apex Code schreiben und veröffentlichen Als Voraussetzung für das weitere Vorgehen ist ein Entwickler-Edition-Account zu Salesforce.com notwendig. Apex-Code-Skripte können mit jedem handelsüblichen Editor geschrieben werden. Unserer Meinung nach empfiehlt sich jedoch der Einsatz des Apex Eclipse Plugin.

1

242

Diese Einschränkungen existieren in der dem Buch zugrunde liegenden Apex-Code-Version vom Januar 2007. Es ist nicht ausgeschlossen, dass die späteren Versionen diese Einschränkungen nicht mehr haben.


Apex Code schreiben und veröffentlichen

10.2.1 Apex Code – Webschnittstelle Um ein Apex Package mittels der Apex-Webschnittstelle anzulegen, muss zur Seite Setup → Build → Code navigiert werden.

Abbildung 10.2: Apex-Code-Seite im Apex Builder

Auf der Apex-Code-Seite werden alle derzeitig im Salesforce.com-Account zur Verfügung stehenden Packages angezeigt. Um ein neues Package anzulegen, wird einfach der New-Button betätigt (siehe Abbildung 10.2). Daraufhin bekommt man das Eingabefeld für den Apex Code zu sehen. Wie man leicht bemerkt, fehlen viele nützliche Dinge für die Entwicklung. Man denke zum Beispiel an Syntaxhervorhebungen, automatische Vervollständigung von Quelltext und anderes. Das ist aber kein Problem, wie schon geschrieben ist der Weg über das Eclipse Plugin nicht nur unsere favorisierte Lösung.

Abbildung 10.3: Neues Package anlegen

Mittels Save kann man das Package überprüfen und die Seite verlassen. Quick Save hingegen führt eine Überprüfung des Quelltextes durch, die Seite wird jedoch nicht verlassen und man kann weiter am Quelltext arbeiten.

10.2.2 Apex Code – Eclipse-Integration Kommen wir jetzt zur schönen Seite der Apex-Code-Entwicklung. Mit Hilfe des Eclipse Plugin (siehe auch das Eclipse Kapitel für Installationshinweise) ist eine bequeme Entwicklung von Skripten möglich. Dazu kann der Wizard für ein neues Apex Package benutzt werden (siehe Abbildung 10.4). Das neue, angelegte Package wird mit Hilfe der Apex-Synchronisation in den Salesforce.com-Account übertragen.


243



Abbildung 10.4: Neues Apex Code Package anlagen

Zum Anlegen eines neuen Packages ist lediglich ein Name notwendig, der sich noch nicht in Benutzung befindet. Auch hier ist eine zuvor durchgeführte Synchronisation hilfreich. Ist das Package angelegt, kann mit der eigentlichen Arbeit am Apex Code begonnen werden. Mittels eines Click auf den entsprechenden Namen ist der Inhalt ersichtlich. Dabei wird in der Outline die Struktur und um Editor der Quelltext angezeigt (siehe Abbildung 10.5).

Abbildung 10.5: Apex Code Package bearbeiten

Die Synchronisation mit dem Salesforce.com-Account wird bei jedem Speichern oder auf ausdrücklichen Wunsch über das Kontextmenü durchgeführt. So kann man im Editor bequem den Apex-Code-Quelltext entwickeln, während man im Browser (mit geöffnetem Account) die korrekte Arbeitsweise verifizieren kann.

10.3 Ein einleitendes Beispiel 10.3.1 Das Beispiel Ein erstes Beispiel soll Ihnen ein Gefühl für Apex Code vermitteln. Wenn Sie das Beispiel noch nicht bis ins Detail verstehen, macht dies aber nichts. Die einzelnen Bestandteile einer Anwendung, welche Apex Code enthält, werden im folgenden Kapitel näher erläutert. Das Beispiel wird den folgenden Handlungsablauf unterstützen: 쮿

244

Auf einem Web-Tab wird ein Formular bereitgestellt, in welchem ein gültiger AccountName eingetragen werden kann.


Ein einleitendes Beispiel 쮿

Nach dem Betätigen des Send Button wird das dazugehörige Account-Objekt mittels eines Apex Code Skript gesucht.

쮿

Im Anschluss wird mittels eines weiteren Apex Code Skript ein neuer Kontakt in dem zuvor gefundenen Account angelegt.

쮿

Zum Schluss wird die Id des neuen Account auf dem Web-Tab angezeigt.

Der vollständige Quelltext kann von der Seite zum Buch geladen werden [AR01]. Auch wird in den folgenden Abschnitten lediglich skizziert, wie S-Control und Web-Tab zu definieren sind. Genaue Informationen sind in den Kapiteln zum Apex Builder in diesem Buch zu finden.

10.3.2 Apex Code Package anlegen (Apex Code) Wir beginnen mit der Definition des Apex Code für das Package. Jede Funktionalität muss in genau ein Package eingeschlossen werden. Später wird man feststellen, dass der verwendete Name auch gleichzeitig die Definition des Namensraums darstellt. Vorerst erzeugen wir aber ein leeres Package mit der Bezeichnung Buch. package Buch { }

10.3.3 Account-Objekt suchen (Apex Code) Die erste Apex-Code-Funktion dient zum Suchen eines Account-Objektes. Dieses muss zuvor, zum Beispiel über die Weboberfläche, angelegt worden sein. Die Methode übernimmt lediglich den Namen des Accounts und gibt ein Account-Objekt zurück. An dieser Stelle wird schon einmal die integrierte Abfragesprache von Apex Code verwendet. Die Abfrage des Account-Objektes kann direkt in der Methode verankert werden. webService Account findAccount(String aName) { Account a = [select id, name from account where name = :(aName)]; return a; }

10.3.4 Neuen Kontakt anlegen (Apex Code) In einer weiteren Apex-Code-Funktion wird ein neuer Kontakt in einem Account angelegt. Dazu wird sowohl der Name des Kontaktes als auch ein Account-Objekt übergeben. Die in Apex Code integrierte Transaktionssteuerung wird benutzt, um den neuen Kontakt dauerhaft zu speichern. Aus der Funktion wird die Id des Kontaktes zurückgegeben.


245



webService Id createContact(String a, Account acc) { Contact c = new Contact(LastName = a, AccountId = acc.Id); insert c; commit; return c.id; }

10.3.5 S-Control anlegen (Apex Builder) Um die zuvor definierten Apex-Code-Funktionen zu verwenden, wird ein S-Control angelegt. Im ersten Teil des Quelltextes ist die JavaScript-Funktion zu sehen, welche die beiden Apex-Code-Stücke logisch miteinander verbindet. Der gefundene Account wird sogleich an die Funktion zum Erzeugen des Kontaktes weiter gegeben. Der Name des Account wird aus dem Formular genommen, im Anschluss wird die Kontakt-Id in die Webseite zurückgeschrieben. Der hier gezeigte Quelltext stellt ein HTML-S-Control dar.

246


Ein einleitendes Beispiel

Im zweiten Teil des S-Control ist das HTML-Formular definiert. Es wird lediglich der Account-Name für die spätere Verwendung erfasst.
Account:

Salesforce.com Entwicklerhandbuch. On-Demand-Anwendungen mit Apex

Apex Predator

Apex Predator

Apex Hides The Hurt

Oracle APEX 4.0 Cookbook

Apex Hides the Hurt

Apex Hides the Hurt

Oracle APEX 4.0 Cookbook

Ramez Naam - 03 Apex

Oracle APEX Best Practices

Oracle APEX Best Practices

Shoot Apex and Leaf Growth

The Apex Book of World SF

Descended from Darkness, Apex Magazine Vol 2

Descended from Darkness, Apex Magazine Vol 1

Descended from Darkness, Apex Magazine Vol 2

The Apex Book of World SF

Descended from Darkness, Apex Magazine Vol 1

Apex Science Fiction and Horror Digest 11

The Apex Book of World SF

The Apex Book of World SF

Apex Science Fiction and Horror Digest 10

Mit Familienanschluß

MIT Conference

Konstruieren mit SolidWorks. Mit CD-ROM

Interview mit

Mit Familienanschluс

Interview mit

Mit Familienanschluс

Mit Teufelsg'walt

Interview mit

Salesforce.com Entwicklerhandbuch. On-Demand-Anwendungen mit Apex

Apex Predator

Apex Predator

Apex Hides The Hurt

Oracle APEX 4.0 Cookbook

Apex Hides the Hurt

Apex Hides the Hurt

Oracle APEX 4.0 Cookbook

Ramez Naam - 03 Apex

Oracle APEX Best Practices

Oracle APEX Best Practices

Shoot Apex and Leaf Growth

The Apex Book of World SF

Descended from Darkness, Apex Magazine Vol 2

Descended from Darkness, Apex Magazine Vol 1

Descended from Darkness, Apex Magazine Vol 2

The Apex Book of World SF

Descended from Darkness, Apex Magazine Vol 1

Apex Science Fiction and Horror Digest 11

The Apex Book of World SF

The Apex Book of World SF

Apex Science Fiction and Horror Digest 10

Mit Familienanschluß

MIT Conference

Konstruieren mit SolidWorks. Mit CD-ROM

Interview mit

Mit Familienanschluс

Interview mit

Mit Familienanschluс

Mit Teufelsg'walt

Interview mit

Recommend Documents