Dieses Mal werfen wir einen Blick auf Trigger und wie man sie zwischen den Umgebungen von Customer Insights Journeys mithilfe von Lösungen verschiebt. Auf diese Weise können wir einen Application Lifecycle Management (ALM)-Prozess für Trigger haben. Im ersten Teil des Artikels werden wir etwas tiefer in die Theorie von ALM und Lösungen eintauchen. Und im zweiten Teil habe ich eine Schritt-für-Schritt-Anleitung für dich, wie du Trigger zu Lösungen hinzufügst, um sie leicht zu übertragen. Für Journeys, E-Mails oder Vorlagen gibt es noch keine ALM-Unterstützung, aber zumindest ist es auf der Roadmap. Bleib geduldig!
Übrigens: Ich hoffe, du hast jetzt keinen Ohrwurm. Aber ja, wie du vielleicht nach meinem „Trigger me softly“ Artikel gemerkt hast, ich mag Musik und habe oft einen passenden Song für jede Situation im Kopf. Mal sehen, wie lange ich das für meine Artikel beibehalten kann 🙂
Was ist ALM?
Lass uns kurz einen theoretischen Blick auf das 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 von ihrer Erstellung bis zu ihrer endgültigen Beendigung überwacht. Der Lebenszyklus umfasst mehrere verschiedene Phasen. Angefangen bei sorgfältiger Planung zur Definition von Zielen und Meilensteinen schreitet der Prozess zur eigentlichen Entwicklung voran, gefolgt von Erstellung, Test und Bereitstellung. Sobald die Anwendung bereitgestellt ist, läuft sie in einer Produktionsumgebung und erfordert Überwachung, Wartung und Support. Während dieses Zyklus bieten kontinuierliche Überwachung Einblicke und Möglichkeiten zum Lernen aus Benutzerfeedback und Verhalten. Natürlich kannst du all dies mit der Power Platform tun.
Schlüsselkonzepte für ALM mit der Power Platform
- Lösungen: Diese sind die Hauptmethode zur Implementierung von ALM und ermöglichen die Verteilung von Komponenten zwischen Umgebungen über Export und Import. Komponenten umfassen Tabellen, Spalten, Apps, Power Automate-Flows, Chatbots, Diagramme und Plug-ins.
- Dataverse: Dies dient als Speicherort für alle Artefakte, einschließlich Lösungen und Bereitstellungspipelines im Produkt.
- Quellcodeverwaltung: Hier sollten deine Komponenten gespeichert und kollaboriert werden.
- CI/CD-Plattformen: Tools wie Azure DevOps ermöglichen die Automatisierung deiner Build-, Test- und Bereitstellungspipelines und können mit den im Produkt integrierten Pipelines verbunden werden.
Im Kontext von Dynamics 365 verwendest du wahrscheinlich (oder hoffentlich) mehrere Umgebungen, um verschiedene Phasen deines ALM-Prozesses zu unterstützen. Zum Beispiel hast du eine Entwicklungs-Umgebung für die Erstellung und Prüfung neuer Funktionen, eine Staging-Umgebung für Tests vor der Produktion und eine Produktionsumgebung für die endgültige Anwendungsbereitstellung. Die Verwendung mehrerer Umgebungen ermöglicht es dir, diese getrennt zu halten, Änderungen zu isolieren und potenzielle Konflikte zu vermeiden, die sich auf die Stabilität deines Systems auswirken könnten.
Lösungskonzept in Customer Insights Journeys
Eine Lösung in der Power Platform ist ein Container, der eine Reihe von Komponenten enthält, wie z. B. Tabellen, Spalten, Dashboards, Flows und mehr. Es ist wie ein Bündel, das es dir ermöglicht, deine Anpassungen zu verwalten und zu transportieren. Der Zweck von Lösungen besteht darin, die Anpassungen effektiv zu verwalten, und nur mit Lösungen kannst du deine Anpassungen von einer Umgebung in eine andere verschieben. Außerdem ermöglichen Lösungen dir, Änderungen nachzuverfolgen und verschiedene Versionen deiner Anpassungen zu pflegen. Lösungen sind ganz wesentlich für die Konsistenz. Es gibt viele Dinge zu berücksichtigen, wenn du dich für eine Lösungsstrategie entscheidest.
- Modularität: Teile deine Anpassungen in kleinere Lösungen auf. Es gibt die horizontale Aufteilung, bei der Lösungen nur Komponenten desselben Typs enthalten, z. B. eine Lösung nur für Prozesse und eine nur für Sicherheitsrollen. Die andere Option ist die vertikale Lösungsschichtung. Hier werden Komponenten nach funktionalen Bereichen gruppiert. Oft hast du eine gemeinsame Basis-/Standardlösung mit separaten Lösungen für jeden wichtigen Geschäftsbereich. Anschließend erstellst du eine Lösung für Funktionen, die von verschiedenen Abteilungen gemeinsam genutzt werden, sowie separate Lösungen für abteilungsspezifische Anforderungen.
- Verwaltet vs. Nicht verwaltet: Entscheide, ob deine Lösung verwaltet (gesperrt) oder nicht verwaltet (bearbeitbar) sein soll. Verwende in der Regel eine nicht verwaltete Lösung in der Entwicklungsumgebung und verteile sie von dort aus als verwaltete Lösung in anderen Umgebungen.
- Abhängigkeiten: Verstehe die Abhängigkeiten zwischen Komponenten (z. B. eine App hängt von Entitäten und Flows ab).
- Solution Layer: Lösungen können in Schichten (Basis, abhängig, Patch) aufgeteilt werden, um Abhängigkeiten zu verwalten
Das ist natürlich nur ein sehr grober Überblick über Lösungen und ALM. Meiner Meinung nach ist ein gut durchdachtes Lösungskonzept entscheidend für den Erfolg von Projekten. Deshalb sollte es immer eine der ersten Dinge sein, die vor dem eigentlichen Start der Entwicklung geplant werden müssen. Eine spätere Neugestaltung der Lösung kann ziemlich knifflig und keine wirklich angenehme Aufgabe werden.
Trigger in Customer Insights Journeys bewegen
Nun kommen wir zum praktischen Teil, wie man Trigger verschiebt. Für eine effektive ALM-Unterstützung müssen die Funktionen von Dynamics 365 „lösungsbewusst“ sein, das bedeutet, dass Entitäten als Lösungskomponenten modelliert werden und Abhängigkeiten von Dataverse erkannt werden. Diese Konfiguration hilft, Abhängigkeiten während des Importprozesses aufzulösen, um einen reibungslosen Übergang der Konfigurationen zu gewährleisten und die Wahrscheinlichkeit von Fehlern zu reduzieren. Um meine Trigger von einer Umgebung in eine andere zu verschieben, müssen wir die folgenden Schritte durchführen:
Öffe die Power Platform: Öffne das Maker-Portal (make.powerapps.com) für die aktuelle Entwicklungsumgebung.
Erstelle eine neue Lösung: Navigiere zum Abschnitt “Lösungen” im linken Bereich und wähle + Neue Lösung aus. Gib deiner Lösung einen eindeutigen Namen, der die Trigger darin widerspiegelt, und wähle einen Herausgeber aus. Es wird empfohlen, immer denselben Herausgeber innerhalb der Umgebung zu verwenden. Ich bevorzuge außerdem die horizontale Aufteilung für Lösungen. Das bedeutet, eine eigene Lösung nur für Trigger zu haben.
Füge Trigger zur Lösung hinzu:
- Klicke auf das Dropdown-Menü „Vorhandene hinzufügen“ im oberen Bereich.
- Wähle Mehr > Andere > Trigger aus.
- Suche nach den relevanten Triggern und füge sie deiner Lösung hinzu. Die hinzugefügten Komponenten hängen vom Status des Triggers ab:
- Entwurf: Trigger-Datensatz, CustomerAPI-Datensatz und CatalogAssignment-Datensatz.
- Veröffentlicht: Trigger-Datensatz, CustomAPI-Datensatz, CatalogAssignment-Datensatz und customAPIrequestparameter-Datensätze.
Exportiere die Lösung:
- Wähle „Lösung exportieren“ aus.
- Stelle sicher, dass die Lösung als „Verwaltet“ exportiert wird.
- Lade die verwaltete Lösung herunter, sobald sie bereit ist. (Natürlich kannst du auch eine Pipeline erstellen, die die Lösung automatisch überträgt, aber das wäre für diesen Artikel zu viel des Guten.)
Importiere die Lösung in die Zielumgebung:
- Navigiere zur Zielumgebung und öffne die Seite „Lösungen“.
- Wähle „Lösung importieren“ aus und lade die verwaltete Lösung aus der Quellumgebung hoch.
- Überprüfe, ob die Trigger importiert wurden und ihren ursprünglichen Zustand beibehalten (Entwurf, veröffentlicht oder gestoppt).
Mit Lösungsupgrades umgehen
Wenn du Lösungen aktualisierst, die verwaltete Trigger enthalten, unterscheidet sich der Prozess geringfügig von der ursprünglichen Migration. Upgrades ändern den Zustand der Trigger nur, wenn sie sich in einem Entwurfszustand in der Zielumgebung befinden. Hier ist, wie Zustandsübergänge während der Lösungs-Upgrades auftreten:
- Veröffentlicht: Der Zustand bleibt veröffentlicht, unabhängig vom Zustand des Quelltriggers.
- Entwurf: Der Zustand ändert sich entsprechend dem Trigger-Zustand aus der aktualisierten Lösung.
- Gestoppt: Der Zustand bleibt gestoppt, unabhängig vom Zustand des Quelltriggers.
Wenn Trigger in der Zielumgebung im veröffentlichten Zustand importiert werden, durchlaufen sie einen Veröffentlichungsprozess. Dieser Prozess erfolgt sequenziell, wobei einige Trigger gleichzeitig verarbeitet werden. Während dieser Zeit können Trigger, die auf Veröffentlichung warten, anfangs als „Entwurf“ angezeigt werden. Sie ändern sich jedoch schließlich in einen „Veröffentlichungs“-Zustand und schließlich in einen „Veröffentlicht/Bereit zur Verwendung“-Zustand. Wenn Trigger über einen längeren Zeitraum im „Entwurf“-Zustand verbleiben, könnte dies auf ein potenzielles Problem hinweisen. Hier sind zwei mögliche Vorgehensweisen:
- Selbsthilfe: Wenn du feststellst, dass importierte „veröffentlichte“ Trigger zu lange im „Entwurf“-Zustand bleiben, erwäge eine Lösungsaktualisierung und erneutes Importieren der Trigger. Dies kann mögliche Probleme während des Migrationsprozesses umgehen.
- Erhalte Unterstützung: Wenn das Problem weiterhin besteht oder komplex erscheint, wende dich am besten an den Support.
Eine Sache noch: Trigger-Besitzer ändern
Es ist möglich, Trigger neuen Besitzern zuzuweisen. Dies kann erforderlich sein, wenn der ursprüngliche Ersteller des Triggers das Unternehmen verlässt. Ich konnte den Besitzer ändern, indem ich die ‘alte’ Erweiterte Suche verwendet habe, egal ob es sich um einen ungenutzten Trigger handelt oder einen, der in einer Live-Journey verwendet wird. Wichtig ist, dass der neue Benutzer die richtige Sicherheitsrolle hat. Ansonsten muss ich zugeben, dass ich nicht zu 100 % sicher bin, ob es noch andere Auswirkungen geben könnte. Wenn du es weißt, lass es mich bitte wissen!
Zusammenfassung
ALM ist eine fortlaufender Prozess der kontinuierlichen Verbesserung. Das Verwalten mehrerer Umgebungen in Dynamics 365 Customer Insights ist eine anspruchsvolle, aber unverzichtbare Aufgabe, um die Zuverlässigkeit und Stabilität des Systems sicherzustellen. Durch die Nutzung von Power Platform-Lösungen für die Migration von Triggern kannst du einen robusten und fehlerfreien ALM-Prozess aufrechterhalten. Nutze diese Vorgehen, um bessere Kontrolle zu erlangen, potenzielle Konflikte zu reduzieren und eine nahtlose Benutzererfahrung in allen Phasen deiner Dynamics 365-Umgebung zu gewährleisten. Wenn jetzt noch weitere Komptonenten von Customer Insighs in Lösungen verwaltet und migriert werden können, wirdes in Zukunft auch noch einfacher.
Referenzen: Solutions – Training | Microsoft Learn, Move triggers between environments – ALM process for triggers – Dynamics 365 Customer Insights | Microsoft Learn
***Hinweis: Der Inhalt ist zum Zeitpunkt der Erstellung korrekt. Microsoft mag in der Zwischenzeit Änderungen vorgenommen haben.***
Schau dir auch die FAQs in meinem Blog an: Kurze Fragen - schnelle Antworten! Zu den FAQs
