I like to move it – ALM für Trigger in Customer Insights

Dieses Mal schauen wir uns Trigger an und wie du sie mithilfe von Lösungen zwischen Customer Insights Journeys-Umgebungen verschieben kannst. Auf diese Weise kannst du einen Application Lifecycle Management- (ALM-)Prozess für Trigger etablieren. Im ersten Teil des Artikels tauchen wir kurz in die Theorie von ALM und Lösungen ein. Im zweiten Teil bekommst du eine Schritt-für-Schritt-Anleitung, wie du Trigger zu Lösungen hinzufügst, um sie einfach zu übertragen. Für Journeys, E-Mails oder Templates gibt es aktuell noch keine ALM-Unterstützung, aber zumindest stehen sie auf der Roadmap. Also: etwas Geduld!

Übrigens: Sorry, falls du jetzt den Ohrwurm „I like to move it“ im Kopf hast. Wie du vielleicht schon von „Trigger me softly“ gemerkt hast, mag ich Musik und habe oft für jede Situation einen passenden Song im Kopf. Mal sehen, wie lange ich das in meinen Artikeln noch durchhalte.

Was ist ALM?

Lass uns kurz einen theoretischen Blick auf Application Lifecycle Management (ALM) werfen und warum es auch für Customer Insights wichtig ist. ALM ist ein Prozess, der den gesamten Lebenszyklus einer Anwendung begleitet – von der Entstehung bis zur Stilllegung. Dieser Lebenszyklus umfasst mehrere klar definierte Phasen. Er beginnt mit einer sorgfältigen Planung, in der Ziele und Meilensteine festgelegt werden, geht über in die eigentliche Entwicklung und anschließend in Build-, Test- und Deployment-Phasen. Nach dem Deployment läuft die Anwendung in einer Produktionsumgebung und benötigt Monitoring, Wartung und Support. Während des gesamten Zyklus liefern kontinuierliches Monitoring und Nutzerfeedback wertvolle Erkenntnisse und Lernmöglichkeiten. All das kannst du natürlich auch mit der Power Platform umsetzen. Um den vollen Funktionsumfang der ALM-Features und -Tools der Power Platform nutzen zu können, müssen alle beteiligten Umgebungen eine Dataverse-Datenbank enthalten.

Zentrale Konzepte für ALM mit der Power Platform sind:

1. Lösungen: Sie sind das zentrale Mittel zur Umsetzung von ALM und ermöglichen es, Komponenten per Export und Import zwischen Umgebungen zu verteilen. Dazu zählen unter anderem Tabellen, Spalten, Apps, Power-Automate-Flows, Chatbots, Diagramme und Plug-ins.
2. Dataverse: Dient als Speicher für alle Artefakte, einschließlich Lösungen und integrierter Deployment-Pipelines.
3. Source Control: Sollte die maßgebliche Quelle für das Speichern und die Zusammenarbeit an Komponenten sein.
4. CI/CD-Plattformen: Tools wie Azure DevOps ermöglichen die Automatisierung von Build-, Test- und Deployment-Pipelines und lassen sich mit integrierten Pipelines kombinieren.

Im Kontext von Dynamics 365 nutzt du wahrscheinlich (oder hoffentlich) mehrere Umgebungen, um die verschiedenen Phasen deines ALM-Prozesses abzubilden. Typischerweise gibt es eine Entwicklungsumgebung für neue Features, eine Staging- oder Testumgebung für Vorabtests und eine Produktionsumgebung für den finalen Einsatz. Mehrere Umgebungen helfen dir dabei, Konfigurationen zu trennen, Änderungen zu isolieren und potenzielle Konflikte zu vermeiden, die die Stabilität des Systems beeinträchtigen könnten.

Lösungsstruktur in Customer Insights Journeys

Eine Lösung in der Power Platform ist ein Container für eine Sammlung von Komponenten wie Entitäten, Felder, Dashboards, Flows und mehr. Man kann sie sich wie ein Paket vorstellen, mit dem du deine Anpassungen verwalten und transportieren kannst. Der Zweck von Lösungen besteht darin, Customizations kontrolliert zu verwalten – und nur mit Lösungen ist es möglich, Anpassungen von einer Umgebung in eine andere zu verschieben. Außerdem kannst du mit Lösungen Änderungen nachverfolgen und unterschiedliche Versionen deiner Anpassungen pflegen. Lösungen sind essenziell für Konsistenz. Bei der Wahl einer Lösungsstrategie gibt es viele Dinge zu berücksichtigen:

• Modularität: Teile deine Anpassungen in kleinere Lösungen auf. Dabei gibt es horizontales Splitting, bei dem Lösungen nur Komponenten eines Typs enthalten, z. B. eine Lösung nur für Prozesse und eine nur für Sicherheitsrollen. Die andere Variante ist vertikales Solution Layering. Dabei werden Komponenten nach funktionalen Bereichen gruppiert. Häufig gibt es eine gemeinsame Basis- oder Core-Lösung sowie separate Lösungen für einzelne Geschäftsbereiche. Zusätzlich können Lösungen für gemeinsam genutzte Funktionen und für bereichsspezifische Anforderungen erstellt werden.
• Managed vs. Unmanaged: Entscheide, ob deine Lösung managed (gesperrt) oder unmanaged (editierbar) ist. In der Regel arbeitest du in der Entwicklungsumgebung mit unmanaged Lösungen und verteilst diese anschließend als managed Lösungen in die nachfolgenden Umgebungen.
• Abhängigkeiten: Verstehe die Abhängigkeiten zwischen Komponenten (z. B. dass eine App von Entitäten und Flows abhängt).
• Solution Layers: Lösungen können geschichtet sein (Basis, abhängig, Patch), um Abhängigkeiten zu steuern.

Das ist natürlich nur ein sehr, sehr grober Überblick über Lösungen. Ein gut durchdachtes Lösungskonzept ist meiner Meinung nach entscheidend für den Projekterfolg. Deshalb plant eine Solution Architect dieses Thema meist ganz am Anfang, noch bevor die eigentliche Entwicklung startet. Eine Lösung später neu zu strukturieren, ist ziemlich aufwendig und ehrlich gesagt keine besonders schöne Aufgabe.

Trigger in Customer Insights Journeys verschieben

Kommen wir nun zum praktischen Teil: Wie verschiebst du Trigger? Für eine saubere ALM-Unterstützung müssen Dynamics-365-Funktionen „solution-aware“ sein. Das bedeutet, dass Entitäten als Lösungskomponenten modelliert werden und ihre Abhängigkeiten von Dataverse erkannt werden. So können Abhängigkeiten beim Import korrekt aufgelöst werden, was einen reibungslosen Übergang ermöglicht und Fehler reduziert. Um Trigger von einer Umgebung in eine andere zu verschieben, gehst du folgendermaßen vor:

Zugriff auf Power-Platform-Lösungen: Öffne das Maker Portal (make.powerapps.com) in deiner Quellumgebung.

Neue Lösung erstellen: Navigiere links zu Solutions und wähle + New Solution. Vergib einen eindeutigen Namen, der die enthaltenen Trigger beschreibt, und wähle einen Publisher aus. Es empfiehlt sich, innerhalb einer Umgebung immer denselben Publisher zu verwenden. Ich bevorzuge hier horizontales Splitting – also eine eigene Lösung nur für Trigger.

Trigger zur Lösung hinzufügen:

• Klicke oben auf Add existing.
• Wähle More > Other > Triggers.
• Suche die relevanten Trigger und füge sie deiner Lösung hinzu. Welche Komponenten hinzugefügt werden, hängt vom Status des Triggers ab:
  • Draft: Trigger-Datensatz, CustomerAPI-Datensatz und CatalogAssignment-Datensatz.
  • Published: Trigger-Datensatz, CustomAPI-Datensatz, CatalogAssignment-Datensatz und customAPIrequestparameter-Datensätze.

Lösung exportieren:

• Wähle Export Solution.
• Stelle sicher, dass die Lösung als Managed exportiert wird.
• Lade die managed Lösung herunter, sobald sie bereit ist.

Lösung in die Zielumgebung importieren:

• Wechsle in die Zielumgebung und öffne dort den Bereich Solutions.
• Wähle Import Solution und lade die managed Lösung aus der Quellumgebung hoch.
• Prüfe, ob die Trigger korrekt importiert wurden und ihren ursprünglichen Status (Draft, Published oder Stopped) beibehalten haben.

Umgang mit Solution Upgrades

Beim Aktualisieren von Lösungen mit managed Triggern unterscheidet sich der Ablauf etwas von der initialen Migration. Upgrades ändern den Status von Triggern nur dann, wenn sie sich in der Zielumgebung im Draft-Status befinden. Die Statusänderungen verhalten sich dabei wie folgt:

• Published: Der Status bleibt veröffentlicht, unabhängig vom Status des Quell-Triggers.
• Draft: Der Status wird an den Trigger-Status aus der aktualisierten Lösung angepasst.
• Stopped: Der Status bleibt gestoppt, unabhängig vom Status des Quell-Triggers.

Werden Trigger im veröffentlichten Zustand in die Zielumgebung importiert, durchlaufen sie einen Publishing-Prozess. Dieser erfolgt sequenziell, wobei immer nur einige Trigger gleichzeitig verarbeitet werden. In dieser Phase können Trigger zunächst als „Draft“ angezeigt werden. Anschließend wechseln sie in den Status „Publishing“ und schließlich in „Published/Ready to Use“. Bleiben Trigger ungewöhnlich lange im Draft-Status, kann das auf ein Problem hindeuten. In diesem Fall hast du zwei mögliche Optionen:

1. Self-Service-Lösung: Wenn importierte „Published“-Trigger zu lange im Draft-Status verbleiben, führe ein Solution Upgrade durch und importiere die Trigger erneut.
2. Support kontaktieren: Wenn das Problem weiterhin besteht oder komplex erscheint, wende dich an den Microsoft Support.

Noch eine Sache: Trigger neuen Besitzern zuweisen

Es ist möglich, Trigger neuen Besitzern zuzuweisen. Das kann notwendig sein, wenn der ursprüngliche Ersteller des Triggers das Unternehmen verlässt. Ich konnte den Besitzer über die „alte“ Advanced Search ändern – sowohl bei ungenutzten Triggern als auch bei solchen, die in einer Live-Journey verwendet werden. Wichtig ist, dass der neue Benutzer die passende Sicherheitsrolle hat. Ansonsten bin ich ehrlich gesagt nicht zu 100 % sicher, ob es weitere Auswirkungen geben könnte. Falls du dazu mehr weißt, sag mir gern Bescheid 🙂

Fazit

ALM ist ein kontinuierlicher Prozess der stetigen Verbesserung. Mehrere Umgebungen in Dynamics 365 Customer Insights zu verwalten, ist anspruchsvoll, aber essenziell, um Stabilität und Zuverlässigkeit des Systems sicherzustellen. Durch den Einsatz von Power-Platform-Lösungen für die Migration von Triggern kannst du einen robusten und fehlerarmen ALM-Prozess etablieren. Nutze diese Ansätze, um mehr Kontrolle zu gewinnen, potenzielle Konflikte zu reduzieren und über alle Phasen deiner Dynamics-365-Umgebung hinweg eine nahtlose User Experience sicherzustellen. Wenn zukünftig auch weitere Komponenten von Customer Insights über Lösungen verwaltet und migriert werden können, wird das Ganze noch deutlich einfacher.

Hast du Fragen, Ideen oder Anmerkungen? Meld dich gern.