Aufbau einer Dynamics 365 Solution

Eine Solution ist zunächst nur eine Ordner: eine benannte Sammlung von Verweisen auf Komponenten die in der Umgebung leben. Trotzdem entscheidet ihr Aufbau darüber wie gut sich ein System später ausliefern und warten lässt. Ein Gang durch die Bausteine auf die es dabei ankommt.

Der Publisher

Jede Solution gehört zu einem Publisher und der bringt das Namenspräfix mit welches vor jedem technischen Namen landet. Diese Verbindung ist dauerhaft. Wer den Publisher wechseln will kann das für die Solution tun. Die bereits angelegten Komponenten behalten ihr altes Präfix aber für immer.

Der Publisher trägt außerdem den Optionswert-Präfix. Er gilt für alle Auswahllisten die unter ihm angelegt werden (globale wie auch lokale). Auch der ist später kaum zu korrigieren weil die Zahlenwerte in den Daten stehen. Wie man beides von Anfang an richtig wählt steht im Artikel zum Publisher der oben verlinkt ist.

Die Komponenten und ihre Teilmengen

Eine Solution kann Komponenten vollständig oder in Teilen enthalten. Nimmt man eine Tabelle mit allen Objekten auf wandert bei jedem Export alles mit auch fremde Felder die zufällig an der Tabelle hängen. Man kann sie auch segmentiert aufnehmen (also nur mit ausgewählten Feldern, Formularen, Ansichten und Diagrammen). Dann bleibt der Export schlank und die Abhängigkeiten überschaubar.

Segmentierung ist heute der empfohlene Weg. Sie hat aber eine Eigenheit: Was nicht in der Solution ist wird auch nicht ausgeliefert. Ein Feld welches jemand in der Entwicklung angelegt aber nie zur Solution hinzugefügt hat fehlt in der Zielumgebung. Der Fehler fällt wenn überhaupt erst beim Testen auf.

Auch die Navigation einer App ist eine eigene Komponente und wandert nur mit wenn sie in der Solution steht - siehe SiteMap-XML erklärt.

Die Abhängigkeiten

Komponenten verweisen aufeinander: ein Formular auf Felder ode ein Flow auf eine Tabelle. Zeigt ein Verweis auf etwas außerhalb der eigenen Solution entsteht eine Abhängigkeit zu der Lösung aus der die Zielkomponente stammt.

Diese Abhängigkeiten stehen im Export in der "solution.xml" und werden beim Import geprüft. Fehlt eine benötigte Solution in der Zielumgebung bricht der Import ab. In gewachsenen Umgebungen überblickt oft niemand mehr das Abhängigkeitsgeflecht vollständig. Gleichzeitig ist es der Teil welcher über die Importreihenfolge entscheidet.

Die Version

Solutions tragen eine vierteilige Versionsnummer. Bei verwalteten Lösungen achtet die Plattform darauf: Eine Fassung mit niedrigerer Nummer als der installierten lässt sich nicht importieren. Bei nicht verwalteten Lösungen wird sie nicht erzwungen, dort ist ein Import mit niedrigerer Nummer möglich und sorgt zuverlässig für Verwirrung. Eine neue Fassung wird dann per Upgrade oder Update eingespielt. Welche Importart man wählt entscheidet darüber ob in der Zielumgebung etwas gelöscht wird. Der Nutzen der Versionsnummer entsteht erst durch Disziplin. Also durch das Hochzählen bei jedem Export und eine kurze Notiz was sich geändert hat.

Bewährt hat sich ein einfaches Schema: Hauptversion bei größeren Umbauten, Nebenversion pro Auslieferung, Build für Zwischenstände und Revision für Hotfixes. Dies wird auch von Microsoft als Best Practice empfohlenm Wichtiger als das Schema ist, dass es eines gibt und sich alle daran halten.

Woran man einen guten Zuschnitt erkennt

Ob eine Solution gut geschnitten ist zeigt sich an drei Stellen. Sie lässt sich unabhängig von anderen ausliefern ohne, dass vorher eine bestimmte Reihenfolge eingehalten werden muss. Ihr Inhalt lässt sich in einem Satz beschreiben. Etwa als das Vertriebsmodul oder die Integration zum ERP. Und ihr Export bleibt in einer Größenordnung bei der ein Import in Minuten statt in Stunden durchläuft.

Wer diese drei Fragen für eine bestehende Solution nicht beantworten kann hat vermutlich keine Solution vor sich sondern einen Container in den über Jahre alles gewandert ist. Auch das lässt sich reparieren nur eben nicht nebenbei.