Schlagwort: Data Exchange Framework

Veröffentlicht am

Sitecore Data Exchange Framework aus der Praxis

Sitecore Layer für Data Exchange Framework

Lesson Learned im Integration Bootcamp auf dem Symposium in Vegas: Das Data Exchange Framework wird DEF abgekürzt und nicht DXF, es heißt ja schließlich nicht Data Experience Framework 😉
Das hier wird kein DEF Tutorial, davon gibt es ausreichend. Eine erste Einordnung und hilfreiche Links zum Einstieg findet ihr in meinem letzten Post zu diesem Thema. Mit dem aktuellen Beitrag möchte ich einfach meine Erfahrung aus der Arbeit mit dem DEF in den vergangenen Monaten mit euch teilen.
Die erste Implementierung eines Custom DEF Providers zum Im- und/oder Exportieren von Daten dauert mit Sicherheit länger als wenn ihr wie gewohnt einen Importer bzw. Exporter ohne das DEF schreiben würdet. Aber später führen kleinste Anpassungen dann fast immer zu einem zusätzlichen Implementierungsaufwand. Mit dem DEF können Attribut-Umbenennungen, Mapping-Anpassungen und Datenkonvertierungen einfach konfigurativ vorgenommen werden. Und mal ehrlich, die lästigen Quellcode-seitigen Attribut-Mappings ersparen wir uns ja auch sehr gerne…
Hinzu kommt: Ihr könnt euch eigene wiederverwendbare Provider schreiben, wie in meinem Fall ein generischer JSON Service Provider. Damit können wir JSON-Daten aus unterschiedlichen Quellen lesen und dann mittels des Standard Sitecore Providers in Contacts oder Items schreiben. Im Projekt ist dann nur noch der Endpoint, die zu lesenden Attribute und das Mapping zu konfigurieren und – falls für die Persistierung der Daten nötig – Template-Erweiterungen oder Contact-Facet-Erweiterungen zu implementieren.
Eine abgespeckte Version des JSON Service Providers könnt ihr euch auf Github anschauen, vielleicht hilft es ja beim ersten Einstieg.
Sitecore Layer für Data Exchange Framework

Und sonst?

Es ist ein Framework, es macht nicht unsere Arbeit, aber es ist ein tolles Werkzeug. Was uns noch an Funktionalität fehlt, können wir erweitern.
So haben wir z.B. den Sitecore Provider um eigene Pipeline Steps ergänzt:

  • UpdateWorkflow: Aktualisiert den Workflow Status eines Sitecore Items
  • CreateMediaItem: Erzeugt ein Sitecore MediaItem basierend auf einem Bildpfad
  • EnrollEngagementPlan: Schickt einen Sitecore Contact in einen Engagement Plan
  • AddItemVersion: Erstellt eine neue Item-Version

Und auch einen erweiterten ValueAccessor zum Lesen und Schreiben von beliebig verschachtelten Facet-Properties haben wir uns geschrieben. Wie ihr seht, nichts geht nicht 🙂

Wenn ich mir was wünschen dürfte (@Sitecore):

  • ReadSitecoreItemsStepProcessor: Der Dynamics CRM Connector liefert schon umfangreiche Möglichkeiten zur Filterung von Contacts im CRM, die Konfiguration ist auch schon teilweise global unter Framework eingeordnet, aber das DEF selbst und der Sitecore Provider bieten hier noch kaum Funktionalität um Sitecore Contacts oder Sitecore Items zu filtern.
    Wir haben das jetzt in unseren Projekten mittels eigens implementierter Erweiterung des Pipeline Steps möglich gemacht, das sollte aber m.E. OOTB kommen.
  • Das DEF stellt kein Konzept zum Löschen von Entitäten wie z.B. Contacts oder Items. Das wünsch ich mir für die Zukunft.

Mein Tipp an euch: Lasst euch vom ersten Eindruck nicht abschrecken, es ist anfangs etwas unübersichtlich und macht viel Konfigurationsarbeit. Aber wenn die ersten Schritte gemacht wurden, dann ist es gut zu wissen, wie einfach das DEF erweiterbar und wie flexibel es in der Konfiguration ist. Für die einfache Synchronisation von Daten würde ich immer das DEF in Betracht ziehen.

Veröffentlicht am

Sitecore Data Exchange Framework?

Sitecore Data Exchange Framework

In den letzten Wochen habe ich intensiv an der Implementierung eines Sitecore Celum Connectors gearbeitet. Celum ist ein Digital Asset Management System, als solches verwaltet es alle Assets zentral und liefert diese an diverse Kanäle aus – online oder auch für den Druck.
Da wir uns entschlossen haben, Bilder welche auf der Webseite zum Einsatz kommen, auch in Sitecore vorzuhalten, ist ein großer Part der Integration die Synchronisation der Bilder zwischen beiden Systemen. Beim Stichwort “Synchronisation” kam mir sofort  das im August von Sitecore veröffentlichte Data Exchange Framework in den Sinn. Da ich damit bisher noch gar nicht gearbeitet habe, musste ich mich zunächst mal in den Umfang und die zugrunde liegende Philosophie dieses Frameworks einarbeiten. Die ersten theoretischen Ergebnisse möchte ich hier und jetzt mit euch teilen. In einem späteren Beitrag werde ich dann über meine ersten Erfahrungen aus der Praxis berichten.

Kurzdefinition

Das Data Exchange Framework dient der Verknüpfung zweier System welche Daten miteinander austauschen, es ist ein sog.  ETL-Tool.  In der Regel ist Sitecore eines der Systeme welches sich mit einem Drittsystem verbindet, das muss aber nicht so sein.

Einsatzmöglichkeiten

Zahlreiche Einsatzmöglichkeiten für das Data Exchange Framework sind denkbar. So kann das neue Framework etwa

  • Produkte > Sitecore Items
  • Externe Bilder > Sitecore Items
  • Kontakte > xDB Contacts
  • u.v.m.

verbinden. Der Einsatz kommt einfach immer dann in Frage, wenn Daten aus einem Drittsystem auch in Sitecore vorgehalten werden müssen.

Warum so ein Framework?

Noch ein Framework? Es gibt doch schon so viele Integrationen… Aber jeder Partner und jedes Modul findet seine eigene Lösungen.

Sitecore geht es mit dem Framework um eine einheitliche Anbindung, um Einfachheit, Stabilität und Wartbarkeit zu erreichen. Außerdem werden die Einstellungen, die sonst meist durch Entwickler in den entsprechenden Konfigurationsdateien vorgenommen werden (Tasks, Pipelines, Pipeline Steps), dann zukünftig als Sitecore Items konfiguriert.

Und das Beste, wie ich finde: auch das Attributmapping kann mit dem neuen Framework vollständig über die Oberfläche konfiguriert werden.

Sitecore Data Exchange Framework

Sitecore hat sich mit dem Framework folgende Ziele gesetzt:

  1. Einheitliches Modell zum lesen, schreiben und verknüpfen von Daten
  2. Flexibilität derzeitiger Ansätze beibehalten (aber nicht nur für Entwickler)
  3. Entwicklung eines Providers nicht nur für langjährige Sitecore-Experten ermöglichen.

Sitecore selbst hat auch schon erste Provider für Data Exchange Framework implementiert: Dynamics CRM Connect (Contacts, Entities), Dynamics AX (Product Catalog).

Genau solche Provider werden wir als Sitecore Partner dann zukünftig gegen die APIs der Drittsysteme unserer Kunden entwickeln. Das Mapping der Daten übernimmt dann das Sitecore Data Exchange Framework für uns.

Und was ist eigentlich das xConnect?

Sitecore hat auf dem Symposium 2016 in New Orleans das xConnect Framework für Anfang nächsten Jahres angekündigt. Beim xConnect Framework geht es um die Integration von Daten aus Drittsystemen in die Sitecore xDB. xConnect beinhaltet nicht das Attributmapping selbst, dafür ist wiederum das Data Exchange Framework zuständig.

Neugierig geworden?

Dann möchte ich euch folgende Links ans Herz legen:

  • Webinar mit Adam Conn (Director of Technical Product Management): Intro to Data Exchange Framework
  • Dokumentation Data Exchange Framework inkl. Schritt für Schritt Anleitung für die Implementierung eines eigenen Data Providers.
  • Und eine Beispielimplementierung eines File System Providers (CSV) bei GitHub .

So das war’s erstmal von mir. Jetzt tauche ich in die Umsetzung eines eigenen Data Providers ab. Ich bin gespannt…