Was man nicht machen soll: Power Platform und die eingebaute Konnektoren von Microsoft (1. Teil)

Anforderungen des Projekts

• Du oder HR hätten gerne eine schöne, einfache Power App, um neue Benutzer in Azure AD zu erstellen
• Anforderungen des Power Apps:
  • Man kann vorhandene Benutzer als Vorlage kopieren und die erforderlichen Details (UPN, Mail usw.) bearbeiten, um neue Benutzer mit ähnlichen Attributen zu erstellen (z. B. erhält der neue Sales-Typ die gleichen grundlegenden AAD-Attribute wie die aktuelle Sales-Typin).
  • Man kann auch mit einem leeren Formular beginnen und die Details selbst eingeben, einschließlich aller relevanten Benutzerattribute, die in Azure AD verfügbar sind, wie z. B. companyName, city, state, employeeID, groupMembership usw..
  • Die App sollte sehr benutzerfreundlich sein und nur ein Minimum an RBAC-Rollenrechten haben, damit auch Nicht-IT-Benutzer (z. B. Mitglieder des HR-Teams) bei der Erstellung neuer Kollegen mitmachen können
  • Wir erstellen und hosten sie in Teams, um einen gewohnten, einfachen Einstieg zu ermöglichen.

Problemstellung

• Die verdammten „freien“ Microsoft Konnektoren aus dem Bordmittel tun nicht das, was wir als ITler brauchen!
• Nur wenige der üblichen Azure AD-Benutzerattribute können mit dem verdammten Befehl AzureAD.CreateUser() aufgerufen, gelesen, bearbeitet oder erstellt werden!
• Office365Users.UpdateUserProfile() ist ebenso nutzlos, da dieser Connector keinen Create()-Befehl anbietet!
• Der Befehl Office365Groups.ListGroups() gibt nicht einmal zurück, um welche Art von verdammter Gruppe es sich handelt!?!? Ist es eine MS365-Gruppe? Dynamisch oder Assigned? Sicherheitsgruppen? Mail-Verteiler? Vergiss es! Oh, aber der AzureAD.AddToGroup()-Befehl funktioniert nur für MS365-Gruppen und nicht für Verteiler- oder Mail-aktivierte Sicherheitsgruppen. Aber wie kann ich den Unterschied erkennen, wenn ich den Unterschied „get-en“ kann!

Lösung

• Die schlechte Nachricht: man muss seinen eigenen benutzerdefinierten Konnektor zu Microsoft Graph erstellen, um alle oder sogar die meisten der benötigten Attribute beim Erstellen neuer Benutzer und Gruppen auslesen zu können. It is, what it is oder schon auf Deutsch übersetzt: Tja…
• Noch eine schlechte Nachricht: benutzerdefinierte Konnektoren sind „Premium“-Funktionen, so dass man jetzt mit dem Hut in der Hand zu seinem Chef gehen und um eine Power Apps pro Benutzer- oder Power Apps pro App-Lizenz bitten muss.

Weitere Details

Wenn man mit einem Hintergrund des Schreibens von Automatisierungsskripten in PowerShell und PowerShell DSC kommt, kann Power Platform (Power Apps, Power Automate, Power BI, Dataverse und Co.) verdammt frustrierend sein. Variablen und Typ-Casting funktionieren nicht so, wie man es sich wünscht, die Benutzeroberfläche für Entwickler ist fehlerhaft und langsam (ich schaue dich an, STRG+Z), und die Dokumentation von Microsoft ist im Vergleich zu PowerShell äußerst dürftig. Wenn man dann noch die verrückte Lizenzierung dazu nimmt, was Premium und was nicht Premium ist und welche Variante der Lizenz am günstigen ist, und den Unterschied zwischen der „kostenlosen“ Teams-Version von Power Apps (keine Advanced Tools oder Monitor) und der normalen Power Platform-Umgebung, dann wird das Schreiben von Power Apps für echte „Geschäfts-Zwecke“ zu einem Alptraum.

Wenn sie jedoch funktionieren, sehen Power Apps großartig aus und fühlen sich gut an. Außerdem gibt es jede Menge Begeisterung für die Automatisierung grundlegender Geschäfts- oder IT-Aufgaben in einem netten Web-Portal in unserer Branche. Die Chefs lieben es und die IT-Mitarbeiter im Microsoft-Umfeld sollten es lernen.

Wo die Schwierigkeiten liegen

Ich könnte einen Roman über diese Erfahrung schreiben, aber nach dem Prinzip „lange Rede, kurzer Sinn,“ fasse ich das Thema so zusammen: Die von Microsoft für die Power Platform angebotenen integrierten oder kostenlosen Konnektoren sind im Grunde genommen Schrott. Sie sind Demoprodukte, die man in die Power Platform-Umgebung locken und ihm vorgaukeln soll, dass man mit Power Apps und Power Automate voll funktionsfähige Anwendungen oder automatisierte Abläufe erstellen kann, was aber nicht der Fall ist.

Nehmen wir ein einfaches Beispiel, um einen neuen Benutzer in Azure AD oder MS365 zu erstellen. Hier sind einige der Referenzseiten der verschiedenen integrierten Konnektoren (nur in der englischen Sprache leider), die erklären, was ihre Versionen des PowerShell-Befehls „New-AzureADUser“ als Eingabeparameter bieten:

Wir haben also viele verschiedene Möglichkeiten und alle Straßen führen nach Rom. Aber vielleicht ist dir aufgefallen, dass bei den standard Verbidnungen der Power Platform etwas fehlt? Vergleichen wir diese Attribute mit denen, die in Azure AD oder mit dem PowerShell-Befehl New-AzureADUser verfügbar sind, den wir alle kennen und lieben:

Wenn man anfängt, mit diesen Befehlen zu arbeiten, um neue Benutzer in Power Apps aufzurufen und zu erstellen, wird man denken, dass er Crazy-Pills genommen hatte. Ich kann das CITY-Attribut eines neuen Benutzers nicht mit AzureAD.CreateUser() setzen?!?! City?!?! companyName?!?! Department!?!? obwohl es in der AAD Users Dataverse Tabelle verfügbar ist!?!?

Bitte mache nicht den gleichen Fehler wie ich und erstelle eine Power App in dem Glauben, dass diese Konnektoren deiner Zeit wert sind. Sie werden in der Produktion nicht funktionieren und sind wirklich nur gut für niedliche, kleine Youtube-Videos für übermäßig enthusiastische Entwickler auf der Jagd nach Klicks. Das ist Mickey Mouse’s Power App und wir leben nur drin.

Man sollte sich darüber im Klaren sein, dass man einen benutzerdefinierten Konnektor zu Microsoft Graph erstellen muss, bevor man dieses Projekt in Angriff nimmt. Öffne also dein Portemonnaie, besorge dich eine echte Power-Apps-Lizenz und lese meinen nächsten Beitrag, in dem ich den besagten Konnektoren erstelle und eine echte Integration mit Power Apps vornehme und nicht die abgespeckte Teams-Version.