Unsere vier “Hidden Highlights” des Sitecore Symposiums 2018 in Orlando, Florida

Sitecore Community

comspace hat auch dieses Jahr wieder zwei Kollegen auf die weite Reise zum Sitecore Symposium geschickt. Nachdem die Folgen des Jetlags überwunden sind, möchten wir – das sind Friederike und Tim – mit diesem Beitrag unsere Eindrücke aus Orlando mit euch teilen. „Unsere vier “Hidden Highlights” des Sitecore Symposiums 2018 in Orlando, Florida“ weiterlesen

Team comspace auf der SUGCON 2018 in Berlin

Letzte Woche waren wir auf der SUGCON in Berlin. SUGCON steht für Sitecore Usergroup Conference. Gegründet in den Niederlanden ist die SUGCON nach 5 Jahren ein europäisches Event mit rund 600 Teilnehmern. Für mich war es nach Amsterdam und Kopenhagen die dritte Teilnahme und die SUGCON ist definitiv ein Highlight im Sitecore-Jahr! Man spürt einfach, dass es von der Community für die Community organisiert wurde und es sind Vortragende und Teilnehmer aus aller Welt da 🙂

„Team comspace auf der SUGCON 2018 in Berlin“ weiterlesen

JSON Service Provider for Data Exchange Framework

Endpoint JSON Service

Vor kurzem habe ich den JSON Service Provider for Data Exchange Framework auf GitHub veröffentlicht. Aber warum? Vielleicht hilft er euch beim Einstieg in die Entwicklung eines eigenen Providers oder dient sogar als Basis für euren eigenen Provider…
Und was kann der JSON Service Provider? Mittels dieses Providers können Daten aus einem beliebigen JSON REST Service ausgelesen werden, um dann beispielsweise mittels des Sitecore Provider for Data Exchange Framework an Contacts oder Items persistiert zu werden.
Zum leichteren Verständnis habe ich in dem GitHub-Repository einen vorkonfigurierten Demo Tenant zur Synchronisation der Jokes von https://api.chucknorris.io/ mitgeliefert. Zusammengefasst habe ich dort folgende Schritte durchgeführt:

1. Konfiguration Endpoint

Am Endpoint werden die Zugangsdaten zum JSON Service und die konkreten URLs zum Auslesen aller JSON-Objekte oder eines einzelnen Objekts (Token “{id}” wird im jeweiligen Pipeline Step durch definierten Identifier ersetzt) hinterlegt.
Endpoint JSON Service

2. Konfiguration Value Accessor mit JSONPath

Der lesende Zugriff auf die JSON-Attribute wird mittels JSONPath definiert, was maximale Flexibilität, auch für verschachtelte JSON-Objekte, bietet.
ValueAccessor mit JSONPath

JSON Path Beispiele

Auf das folgende JSON-Objekt 

{
 	"firstname":"Max",
     "lastname":"Mustermann",
	"addresses":
	[
		{
			"id": 7,
			"type": "Shipping",
			"street": "Bahnhofsstrasse 7",
			"city": "Bielefeld"
			"postalcode": "33333"
		},
        {
			"id": 13,
			"type": "Invoice",
			"street": "Hauptstrasse 7",
			"city": "Hamburg"
			"postalcode": "22222"
		}
	]
}
JSON-Beispiel

kann beispielsweise mit folgenden JSONPath Ausdrücken zugegriffen werden:
$.firstname ==> "Max"
$.addresses[?(@.type=='Invoice')].city ==> "Hamburg"
$.addresses[(@.length-1)].type ==> "Invoice"
JSON-Objekt

3. Sitecore Provider konfigurieren

  • Sitecore Endpoint anlegen
  • Ziel-Template “Joke” definieren
  • Value Accessor für die Felder des Joke-Templates konfigurieren

4. Value Mapping konfigurieren

Das Übliche halt… Id => ExternalId, Value => Text

5. Pipelines konfigurieren

Im Grunde handelt es sich hier um eine Basis-Konfiguration zum Import von externen Daten nach Sitecore.
ReadJsonObjectsStepProcessor
Die Pipeline “Sync Jokes” liest die Daten aus der externen Datenquelle und iteriert darüber.
Die Pipeline “Sync Joke” ermittelt das ggf. zum externen Identifier schon existierende Item in Sitecore, führt das oben konfigurierte Mapping aus und speichert das Sitecore Item.
Der im obigen Screen geöffnete Pipeline Step “Read Jokes” basiert auf dem mit dem Json Service Provider implementierten PipelineStep “ReadJsonObjectsStepProcessor”. Dieser erwartet den zu verwendenden Endpoint und optional einen JSONPath zur Ermittlung des Root-Knotens im JSON-Response.

6. Pipeline Batch starten

Jetzt müsst ihr nur noch den Pipeline Batch einrichten und ausführen. Idealerweise erhaltet ihr folgendes Ergebnis:
25.11.2017 18:22:50 INFO 8 json objects were read from endpoint. (pipeline step: 1 Read Jokes, endpoint: Chuck Norris Jokes API)
25.11.2017 18:22:51 INFO 8 elements were iterated. (pipeline: Sync Jokes – Pipeline, pipeline step: 2 Iterate Jokes)
Und ihr findet unterhalb von content/home die importierten Jokes, wie z.B.
“Wie viele Liegestütze schafft Chuck Norris? Alle.”

Zusammenfassung

Für das Setup dieses Demo Tenants habe ich ca. 1 Stunde benötigt. Zugegeben, es ist nicht die erste Anwendung des Providers meinerseits, aber in der Zeit hätte ich den Import nicht von Hand neu schreiben können.
Habt ihr Fragen dazu oder selber schon Erfahrung mit dem JSON Service Provider gemacht? Dann freue ich mich auf euer Feedback in einem Kommentar!

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 ThemaMit 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.

Wozu braucht ein Unternehmen ein DAM, wenn es schon ein CMS hat?

DAM vs. CMS Headerbild

Ein Content Management System (CMS) wird mittlerweile in nahezu jedem Unternehmen eingesetzt, um den digitalen Content auf einer Plattform zu managen und von dort aus in die Marketingkanäle zu verteilen. Ein Digital Asset Management System (DAM) ist allerdings in vielen Unternehmen noch keine Selbstverständlichkeit. Schließlich verfügt auch jedes Content Management System über eine Mediendatenbank. Dort werden die verwendeten digitalen Mediendateien wie Bilder, Videos oder PDFs hochgeladen, abgelegt und in die verschiedenen Kanäle wie Corporate Website, E-Commerce-Seiten, Blogs, Social Media etc. ausgespielt. So weit, so gut.

„Wozu braucht ein Unternehmen ein DAM, wenn es schon ein CMS hat?“ weiterlesen

How to: Sitecore Content Search – Globale LINQ Filter anwenden

Sitecore Global Linq Filter

Seit der Sitecore Version 7.2. ist es möglich, für die Content Search LINQ Filter zu implementieren, die automatisch bei jedem LINQ Query angewendet werden. Dadurch können “statische” Filter wie z.B. die Einschränkung nach Kontextsprache einmalig angegeben werden und brauchen somit nicht bei jeder Abfrage berücksichtigt zu werden.

Um globale LINQ Filter einzubinden, muss die Pipeline <contentSearch.getGlobalLinqFilters> erweitert werden:

Achtung: Das folgende Beispiel ist bis einschließlich der Sitecore Version 8.1 möglich.

[xml]
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">;
<sitecore>
<pipelines>
<contentSearch.getGlobalLinqFilters>
<processor type="Comspace.Demo.GlobalLinqFilter.ContextLanguageLinqFilter, Comspace.Demo.GlobalLinqFilter"/>
</contentSearch.getGlobalLinqFilters>
</pipelines>
</sitecore>
</configuration>
[/xml]

Die Klasse ContentLanguageLinqFilter erbt von der bereitgestellten Basisklasse ApplyGlobalLinqFilters, welche zwei überschreibbare Funktionen bereitstellt:

  • Process(QueryGlobalFiltersArgs args)
  • GetQuery(QueryGlobalFiltersArgs args)

Um nun nach der aktuellen Sprache zu filtern, muss die Query angepasst werden. Hierfür wird die Funktion GetQuery überschrieben:

[csharp]
namespace Comspace.Demo.GlobalLinqFilter
{
public class ContextLanguageLinqFilter : ApplyGlobalLinqFilters
{
protected override object GetQuery(QueryGlobalFiltersArgs args)
{
var query = (IQueryable<SearchResultItem>)args.Query;
return query.Where(i => i["_language"].Equals(Sitecore.Context.Language.Name));
}
}
}
[/csharp]

In diesem Beispiel wird das Objekt args.Query in den Typen IQueryable<SearchResultItem> umgewandelt.

GlobalLinqFilter ab Sitecore Version 8.2

Mit der Sitecore Version 8.2 ändert sich die Verwendung von Queries im Sitecore, sodass ein allgemeines Casting in den Typen IQueryable<SearchResultItem> nicht mehr möglich ist. Wird ein GlobalLinqFilter wie oben beschrieben eingesetzt, wirft Sitecore bereits bei der Initialisierung bzw. beim Öffnen des Sitecore Content Editors eine Exception:

[text]
Das Objekt des Typs "Sitecore.ContentSearch.Linq.Parsing.GenericQueryable`2[Sitecore.ContentSearch.SearchTypes.SearchResultItem,Sitecore.ContentSearch.Linq.Solr.SolrCompositeQuery]" kann nicht in Typ "System.Linq.IQueryable`1[Sitecore.Social.Search.SearchItem]" umgewandelt werden.

[/text]

Und jetzt?

Zu der Verwendung von GlobalLinqFilter existiert keine nennenswerte Dokumentation. Auch Google liefert nur ein mageres Beispiel von Coveo, das aber nicht für Sitecore ab Version 8.2 geeignet ist.

Der daher konsultierte Sitecore Support stellt folgende Lösung zur Verfügung:

[csharp]
public override void Process(QueryGlobalFiltersArgs args)
{
if ((args != null) && (args.Query != null))
{
Type queryElementType = args.QueryElementType;
if (queryElementType == typeof(SearchResultItem))
{
args.Query = this.GetQuery&lt;SearchResultItem&gt;(args);
}
}
}

protected object GetQuery<T>(QueryGlobalFiltersArgs args) where T : IObjectIndexers
{
var query = (IQueryable<T>)args.Query;

return query.Where(i => i["_language"].Equals(Sitecore.Context.Language.Name));
}
[/csharp]

In diesem Beispiel wird nicht mehr die überschreibbare Funktion GetQuery verwendet, sondern eine eigene, generische Funktion implementiert. Ziel ist es, die Query, die im GlobalLinqFilter als Typ object übergeben wird, in den Zieltypen umzuwandeln. Hierfür liefern die QueryGlobalFiltersArgs auch die QueryElementType-Eigenschaft mit.

Problem: Ein Objekt lässt sich nicht mithilfe einer Variablen typisieren.

Lösung: Um GlobalLinqFilter trotzdem anwenden zu können, muss nun also die Process Methode überschrieben werden. Darin wird der übergebene Typ geprüft und anschließend mit einer expliziten Typisierung die GetQuery<T> Funktion aufgerufen.

Vorteil:

  • Es werden nur solche Queries eingeschränkt, die auch erwünscht sind, da die Abfrage explizit in der Process Methode angegeben muss.

Nachteil:

  • Werden mehrere spezielle Typen von SearchResultItem implementiert, z.B. ExtendedSearchResultItem, DateSearchResultItem, etc. muss für jeden dieser Typen eine Abfrage im GlobalLinqFilter eingerichtet werden.

Der Nachteil äußert sich in der Implementierung dann folgendermaßen:

[csharp]
public override void Process(QueryGlobalFiltersArgs args)
{
if ((args != null) && (args.Query != null))
{
Type queryElementType = args.QueryElementType;
if (queryElementType == typeof(SearchResultItem))
{
args.Query = this.GetQuery<SearchResultItem>(args);
}
if (queryElementType == typeof(ExtendedSearchResultItem))
{
args.Query = this.GetQuery<ExtendedSearchResultItem>(args);
}
}
}
[/csharp]

Zusammenfassung

GlobalLinqFilter sind ein probates Mittel, um Queries standardmäßig nach bestimmten Kriterien zu filtern. Kriterien können neben der hier gezeigten Sprache auch Sicherheitskriterien, Templates oder Sites sein. Wenn nicht exzessiv spezielle SearchResultItem Typen implementiert wurden und somit der oben beschriebene Nachteil eher überwiegt, ist die Nutzung von GlobalLinqFilter zu empfehlen.

Übrigens: Wen das Thema Sitecore Content Search interessiert, findet hier einen Einstieg in das Thema Sitecore Solr Content Search – Facettensuche richtig anwenden.