Wie werden Tabellen, Felder und Views gespeichert?

Der größte Block in fast jeder customizations.xml eines D365 Lösungsexports ist "Entities". Wer versteht wie er aufgebaut ist kann die Kernfragen zu einem Datenmodell direkt aus dem Export beantworten und meistert die Erstellung von Queries in Tool wie der XRM Toolbox im Handumdrehen. Dieser Artikel geht eine Ebene tiefer als der allgemeine Überblick und schaut sich die Struktur im Detail an.

Die Tabelle selbst

Jede Tabelle beginnt mit einem "Entity"-Element. Darin steht ein "EntityInfo"-Block mit den Grunddaten: der technische Name einer Tabelle, der Anzeigename in allen installierten Sprachen (als "LocalizedNames" mit Sprachcodes), die Beschreibung und das Eigentumsmodell. Dazu kommen Dutzende Verhaltensschalter, von der Aktivierung des Audits bis zur Frage ob die Tabelle im Schnellsuchindex auftaucht.

Schon hier lohnt sich Genauigkeit. Die Beschreibung einer Tabelle steht als "Descriptions"-Element direkt neben den Namen. Ist sie leer, dann wurde sie nie gepflegt und das lässt sich für alle Tabellen einer Lösung in einer Minute auszählen. Dokumentation der Geschäftslogik wird nicht immer von jedem Berater gemacht, dennoch ist sie (mal weitergedacht) für KI Workflows fürs Verständnis relevant.

Die Felder

Unter "attributes" folgt pro Feld ein "attribute"-Element. Die wichtigsten Angaben:

• Name und PhysicalName: der technische Name inklusive Präfix aus dem sich ablesen lässt welcher Publisher das Feld angelegt hat.
• Type: der Datentyp, von "nvarchar" über "picklist" bis "lookup". Bei Auswahlfeldern hängen die Optionen mit Wert und Beschriftung direkt darunter sofern es keine globale Auswahlliste ist.
• RequiredLevel: die Pflichtstufe. Ein Bestand voller Pflichtfelder erzählt etwas über die Datenqualität die man erwarten darf.
• Beschreibung und Anzeigenamen: wieder lokalisiert, wieder auszählbar.

Ein einzelnes Feld sieht im Export schematisch so aus:

<attribute PhysicalName="fab_budget">
  <Type>money</Type>
  <Name>fab_budget</Name>
  <LogicalName>fab_budget</LogicalName>
  <RequiredLevel>none</RequiredLevel>
  <displaynames>
    <displayname description="Budget" languagecode="1031" />
  </displaynames>
  <Descriptions>
    <Description description="Freigegebenes Projektbudget (netto)" languagecode="1031" />
  </Descriptions>
</attribute>

Was hier nicht steht: ob das Feld befüllt ist. Der Export kennt die Struktur nicht aber die Daten.

Die Ansichten

Ansichten heißen im Export "savedqueries" und liegen ebenfalls unter der Tabelle. Jede besteht im Kern aus zwei eingebetteten Definitionen. Das "fetchxml" ist die Abfrage mit Spalten, Filtern, Verknüpfungen und Sortierung. Das "layoutxml" legt fest welche Spalten in welcher Breite angezeigt werden.

Beide liegen als XML im XML, müssen also separat gelesen werden. Dafür sind sie erstaunlich auskunftsfreudig. Aus dem fetchxml lässt sich ablesen welche Felder eine Ansicht wirklich nutzt und ob zwei Ansichten bis auf den Namen identisch sind. Solche Duplikate entstehen beim Kopieren und bleiben dann Jahre liegen.

Formulare und Beziehungen als Nachbarn

Im selben Tabellenblock liegen auch die Formulare ("FormXml", wieder eingebettetes XML, getrennt nach Formulartyp). Außerhalb des Entities-Blocks liegen die Beziehungen mit ihrem Kaskadierungsverhalten. Beides verdient eigene Betrachtung gehört aber zum selben Muster: Der Export beschreibt die vollständige Struktur, verteilt auf ineinander verschachtelte Definitionen.

Wer das einmal von Hand durchgegangen ist versteht auch warum Werkzeuge dafür existieren. Nicht weil die Information versteckt wäre sondern weil sie auf Tausende Elemente verteilt ist welche einzeln trivial und in Summe unüberschaubar sind.