SiteMap-XML in Dynamics 365 erklärt

Die SiteMap ist die Navigationsstruktur einer modellgesteuerten App: die Bereiche links, die Gruppen darin, die einzelnen Einträge. Wir verstehen sie als die grundlegendensten Navigationelemente im CRM. Dort wählen wir aus, welche Art von Datensätzen wir als nächstes anlegen möchten. Im Lösungs-Export liegt sie als eigene XML-Definition, und die ist erfreulich simpel aufgebaut.

Drei Ebenen, mehr nicht

Die Struktur besteht aus genau drei verschachtelten Elementen. "Area" ist die oberste Ebene, also ein Arbeitsbereich wie Vertrieb oder Service. Darunter fassen "Group"-Elemente Einträge zu benannten Blöcken zusammen. Die unterste Ebene, "SubArea", ist der einzelne Navigationseintrag.

Ein Ausschnitt macht das greifbar:

<SiteMap>
  <Area Id="Vertrieb" ResourceId="Area_Sales">
    <Group Id="Kunden">
      <SubArea Id="nav_accounts" Entity="account" />
      <SubArea Id="nav_kontakte" Entity="contact" />
    </Group>
    <Group Id="Auswertungen">
      <SubArea Id="nav_report" Url="$webresource:fab_/seiten/report.html" />
    </Group>
  </Area>
</SiteMap>

Eine SubArea zeigt entweder auf eine Tabelle (Attribut "Entity", die Plattform rendert dann automatisch die Standardansicht) oder auf eine URL, etwa eine Web-Ressource oder ein Dashboard. Dazu kommen Icons, lokalisierte Titel und Sichtbarkeitsschalter für verschiedene Clients. Auch eine Berechtigungssteuerung ist möglich: Eine SubArea kann an Tabellenrechte gekoppelt werden, sodass Nutzer ohne Leserecht den Eintrag gar nicht erst sehen.

Zum Bearbeiten muss heute übrigens niemand mehr ins XML: Der moderne App-Designer deckt die Navigation vollständig ab. Das XML zu lesen lohnt trotzdem, denn der Designer zeigt immer nur eine App, während der Export alle SiteMaps nebeneinanderlegt und damit erst die Frage beantwortet, wie viele Navigationsstände überhaupt existieren.

Eine SiteMap pro App

Früher gab es eine einzige SiteMap für die ganze Organisation. Heute bringt jede modellgesteuerte App ihre eigene mit, verknüpft über die App-Definition. Im Export einer gewachsenen Lösung liegen deshalb oft mehrere SiteMaps nebeneinander, darunter manchmal noch die alte organisationsweite, die niemand mehr pflegt, die aber weiterhin mit exportiert wird.

Wo sich Altlasten sammeln

Die Navigation ist einer der Orte, an denen sich Geschichte ablagert, weil Einträge selten entfernt werden. Drei Muster tauchen immer wieder auf.

Einträge auf Tabellen, die es nicht mehr gibt oder die leer sind: Der Eintrag funktioniert scheinbar, führt aber ins Nichts. URL-Einträge auf alte Web-Ressourcen, oft HTML-Seiten aus einer früheren Projektphase, die längst durch etwas anderes ersetzt wurden. Und Sichtbarkeitsregeln für Clients, die es nicht mehr gibt, Reste aus der Zeit des alten Web-Clients und von Dynamics for Outlook.

Eine vierte Beobachtung aus der Praxis: SubAreas, die per URL auf Web-Ressourcen zeigen, sind eine der Stellen, an denen scheinbar verwaiste Web-Ressourcen doch noch in Verwendung sind. Wer den Bestand an Skripten und HTML-Seiten aufräumt, sollte die SiteMaps deshalb in die Referenzsuche einbeziehen, sonst fliegt eine Seite raus, die im Menü noch verlinkt ist.

Nichts davon ist gefährlich. Aber die Navigation ist das Erste, was jeder Nutzer sieht, und ein aufgeräumtes Menü ist die billigste Verbesserung der Nutzererfahrung, die es in diesem System gibt. Die Prüfung dafür ist schnell: jede SubArea gegen die Liste der vorhandenen Tabellen und Web-Ressourcen halten. Was ins Leere zeigt, kann raus.