Salesforce CRM mit Testdaten befüllen
Datensauger
Wer sich in Salesforce einarbeiten will, muss nicht auf seine Kundendaten zurückgreifen. Die Datenanalysten von Dunnhumby haben zu Lern- und Testzwecken einen kompletten Testdatensatz ins Netz gestellt.
Ist das Datenmodell von Salesforce CRM an die Organisation angepasst und erweitert, wie es der letzte Artikel in dieser Serie beschrieb [2], geht es an das initiale Beladen. Typischerweise hat jede Organisation eine Kundenliste und andere für das CRM relevante Daten, die den Anwendern bei der Einführung von Salesforce zur Verfügung stehen müssen.
Da es sich bei den Dunnhumby-Daten um Einzelhandelsdaten handelt, bestehen diese insbesondere aus dem erworbenen Inhalt des Warenkorbs. Wie bereits erwähnt, ist die von Salesforce empfohlene Vorgehensweise für die Abbildung der Warenkörbe die Verwendung von Opportunities. Eine abgeschlossene Opportunity entspricht dabei einem gekauften Warenkorb. Der ist einem spezifischen Haushalt zugeordnet und kann ein oder mehrere Produkte mit einem bestimmten Preis und der jeweiligen Menge enthalten.
Für das weitere Nachvollziehen dieser Artikelserie wurde aber eine einfachere Variante gewählt, die sich auch mit den Speicherplatzbegrenzungen des kostenlosen Salesforce-Entwickler-Accounts verträgt: Es werden nur die Zusammenhänge zwischen Haushalten und Coupons betrachtet.
Diese Daten werden im CSV-Format mithilfe des Apex Data Loader in die Salesforce-Cloud geladen (die Download-Adressen finden Sie unter „Alle Links“). Allerdings müssen die Daten zuvor vom Dunnhumby-Quell- ins Salesforce-Zielformat gewandelt werden. Das geht notfalls mit einem Werkzeug wie dem awk, wenn diese Transformation im „richtigen Leben“ besonders komplex sind, sollte man über die Nutzung eines ETL-Tools nachdenken (Extract/Transform/Load). Hierzu lohnt ein Blick in die AppExchange. Dort lassen sich eine Reihe von Werkzeugen für die Initialbefüllung finden. Zusätzlich kann auch die Nutzung von Microsofts SQL Server Integration Services (SSIS) hilfreich sein, daneben gibt es Open-Source-Tools wie Pentaho Data Integration oder Talend Data Integration. Im Rahmen dieses Artikels kamen Microsoft SQL Server Integration Services zum Einsatz. Diese werden mithilfe des Business Intelligence Studio installiert, das wiederum Teil der SQL Server Data Tools ist. Wie die Zieldateien aussehen müssen, ist beispielhaft in den Daten auf dem iX-FTP-Server zu sehen. Die beschriebene Vorgehensweise ist sowohl mit der Test- als auch mit der Entwicklerversion des SQL Server nachvollziehbar. Apropos Entwicklerversion: Wer die Artikelserie über mehrere Ausgaben verfolgen will, sollte sich mindestens die – kostenlose – Developer Edition von Salesforce besorgen.
Die jeweiligen URLs sind unter der im blauen Kästchen „Alle Links“ am Artikelende vermerkten Webadresse zusammengestellt.
Mit ETL-Tools im Batch-Betrieb
Das Laden durch ETL-Werkzeuge erfolgt im Batch-Betrieb, alle zu einem bestimmten Zeitpunkt verfügbaren Datensätze werden in einem Rutsch in die Zielumgebung importiert. Im SSIS sind dazu Jobs und Data Flows konfiguriert. Der Job stellt den Gesamtablauf der Initialbeladung sicher, während der Data Flow die Daten selbst bewegt. Angelegt wird die Konvertierung im Business Intelligence Studio als neues SSIS-Projekt.
Nach dem Start der Entwicklungsumgebung muss ein neues SSIS-Projekt (SQL Server Integration Services) erstellt werden. Dies geht am besten über den Menüpunkt „Datei/Neues Projekt“. Unter „Installierte Vorlagen“ findet sich der Knoten „Business Intelligence“. Dort die Vorlage für „Integration Services Project“ auswählen. Nachdem ein Name vergeben wurde, öffnet sich das neue Projekt in Visual Studio (oder besser gesagt in den SQL Server Data Tools, am Ende ist es aber die gleiche Basis).
Zu empfehlen ist, sich dabei an den Zieltabellen zu orientieren und je Zieltabelle einen Data Flow zu erzeugen. Dies reduziert die Komplexität der Datenflüsse. Dabei werden die Daten nicht direkt in das Salesforce CRM geschrieben, sondern in CSV-Dateien, die der Data Loader lädt. Jeder Datenfluss hat also genau ein CSV-Ziel und eine oder mehrere CSV-Quellen. Dieses zielorientierte Vorgehen vereinfacht den Beladungsprozess, insbesondere bei großen Migrationsprojekten.
Objekte mit Tabellen mappen
Wichtig ist, auf die entsprechenden Datentypen des Ziels zu achten: Zwar erlaubt der Einsatz von CSV-Dateien viel Spielraum, jedoch hat die CSV-Datei nur temporäre Bedeutung. Nach dem Import der Daten durch den Apex Data Loader müssen die verwendeten Datentypen schon stimmen.
Das im weiteren Verlauf dieses Artikels beschriebene Verfahren ist nur eine von mehreren Möglichkeiten der Initialbeladung. Man kann die Daten auch direkt über SSIS in das Salesforce CRM laden. Dazu benötigt man von Komponentenherstellern angebotene SSIS-Transformationen, die allerdings kostenpflichtig sind. Diese Investition erspart einem der hier beschriebene Weg, denn für diesen ist ein Zuwachs an Komplexität zu berücksichtigen: Man benötigt externe IDs. Beim Einsatz von SSIS-Komponenten sind Lookups in den Salesforce-Daten möglich, um die intern verwendeten IDs zu ermittelt und beim initialen Beladen zu verwenden.
In den meisten Fällen besteht die Transformation der Quelldaten aus einem einfachen Mapping der Quell- auf die Zielspalten. Das sollte durch Mappingtabellen vorbereitet werden, wie sie beispielhaft die Tabelle „Objekt-Mapping“ zeigt. Das Mapping lässt sich dann im Flat File Destination Editor des SSIS abbilden. Dieser Editor wird über die Flat File Destination Transformation bereitgestellt (Doppelklick auf die Transformation). Doch dazu gleich mehr – zuerst geht es um den vollständigen Data Flow, für den noch einiges benötigt wird.
Daten an das Zielformat anpassen
Für diesen gilt eine einfache Grundregel: Je Salesforce-Ziel (und meist auch je Quelle) muss ein Data Flow dem Job hinzugefügt werden. Dabei handelt es sich um eine jahrelang geübte „Best Practice“. Der Data Flow benötigt dann auf jeden Fall erst mal eine Flat File Source Transformation und eine Flat File Destination. Dazwischen können beliebige weitere Transformationen hinzugefügt werden, um die sogenannte Datentransformation durchzuführen.
Die Daten für den Data Flow liefert die Dunnhumby-CSV-Quelldatei. Diese werden dem Data Flow über die erste Komponente, die Flat File Source, bereitgestellt. Eine zweite Transformation setzt die OwnerID auf die SalesforceID des Nutzers, der den Besitzer des Datensatzes darstellen soll (dies kann ein spezieller Migrationsnutzer sein oder ein ausgewählter Nutzer). Die letzte Transformation (zur Flat File Destination) produziert das Ziel: die CSV-Datei, die mit dem Apex Data Loader in die Cloud geladen werden soll. Um die Konfiguration der Zielspalten zu erleichtern, bietet es sich an, eine Beispieldatei des Ziels zu exportieren, um die Spaltendefinitionen schneller aufbauen zu können.