Er ist ein Power Platform Entwickler mit über 5 Jahren Erfahrung. Außerhalb der Bürozeiten ist Amadeusz ein Amateur-Fußballanalyst und ein begeisterter PC-Bauer.
Teilen
Inhaltsverzeichnis
- Was brauchen Sie?
- Lösungen
- Main Entity
- Service Principal, Azure Key Vault und Umgebungsvariablen
- Target Entity - Zieleinheit
Dieser Artikel ist der zweite Teil meiner Serie über das Erstellen benutzerdefinierter Überwachungsprotokolle in Power Apps. Im vorherigen Teil „Einführung in benutzerdefinierte Dataverse-Audits für Power Apps-Lösungen“, haben wir die Out-of-the-Box-Erfahrung sowie das Design einer benutzerdefinierten Lösung besprochen, die mehr Möglichkeiten bietet. Dieses Mal werde ich alle notwendigen Vorbereitungsarbeiten durchgehen, die Sie vor dem Codieren erledigen müssen.
Was brauchen Sie?
Hier ist die Liste der Dinge, die Sie benötigen, damit es funktioniert:
- Lösungen – optional, aber es erleichtert Ihnen das Leben, wenn es um Wartung und Bereitstellung in verschiedenen Umgebungen geht
- Main Entity – Eine Tabelle, in der Sie Änderungen verfolgen werden
- Azure Subscription – für den Key Vault, den Ressourcenanbieter und den Dienstprinzipal
- Azure Key Vault – zur sicheren Speicherung der App-ID
- Dienstprinzipal – zum Autorisieren von HTTP-Aufrufen in Power Automate
- Umgebungsvariablen – um Ihre Lösung mit Key Vault zu verknüpfen
- Target Entity – benutzerdefinierte Entity zum Speichern Ihrer Protokolle
- Automatisieren Sie den automatisierten Ablauf – für die Magie
Jetzt ist es an der Zeit, sich eingehender mit all diesen Elementen zu befassen und zu lernen, wie man sie einrichtet.
Lösungen
Was ich für diesen Zweck verwende, ist eine nicht verwaltete Lösung, bei der ich als Herausgeber festgelegt bin.
Der Grund, warum ich es erstellt habe, ist die einfache Wartung. Alles, was ich von nun an erstellen werde, wird in dieser Lösung enthalten sein.
Main Entity
Um mit Audit-Protokollen überhaupt anfangen zu können, benötigen Sie die Entity, an der Sie Änderungen verfolgen werden. Um den Rest dieses Artikels besser zu verstehen, lassen Sie uns meine benutzerdefinierte Tabelle durchgehen.
Für den Zweck dieses Leitfadens habe ich in meiner Lösung eine benutzerdefinierte Entity namens „Cast“ erstellt. Es hat die folgenden benutzerdefinierten Spalten:
- Name – Primäre Spalte; Einzelne Textzeile;
- Organisation – Wahl („Avalanche“, „Shinra“)
- Leader – Suche (Cast – Selbstreferenz)
- Joined – Datum und Uhrzeit; nur Datum
Ich werde die vollständige Besetzung von Final Fantasy VII in dieser Tabelle speichern und ich möchte alle Änderungen verfolgen, die an diesen Aufzeichnungen vorgenommen wurden.
Bevor Sie fortfahren, müssen Sie die Option „Audit changes to this data (Änderungen an diesen Daten prüfen)“ aktivieren. Gehen Sie dazu zu den Eigenschaften und aktivieren Sie das entsprechende Kontrollkästchen unter „Erweiterte Optionen“.
Service Principal, Azure Key Vault und Umgebungsvariablen
Im Geiste eines alten Sprichworts „Wenn es nicht kaputt ist, reparieren Sie es nicht“, lasse ich die Microsoft-Dokumentation diese Voraussetzungen erklären:
Erstellen Sie eine neue Umgebungsvariable für das Key Vault-Geheimnis
Hoffentlich haben Ihnen diese Richtlinien geholfen, alles richtig einzurichten. Wenn das der Fall ist, ist es jetzt an der Zeit, Variablen für Ihr Projekt zu erstellen.
Sie benötigen zwei Umgebungsvariablen, um eine Verbindung zwischen Key Vault und unserer Lösung herzustellen:
- ClientID
- ClientSecret
Sie werden diese Variablen später verwenden, um HTTP-Anfragen zu authentifizieren.
Sehen wir uns an, wie Sie diese in der Lösung erstellen.
Ein Bild, das Text enthält.
Automatisch generierte Beschreibung Dabei handelt es sich um Variablen vom Typ „Secret“, wobei „Azure Key Vault“ als Secret Source festgelegt ist.
In Bezug auf die geheime Referenz unter Berufung auf die Microsoft-Dokumentation:
- Azure Subscription ID: Die dem Key Vault zugeordnete Azure-Abonnement-ID
- Ressourcengruppenname: Die Azure-Ressourcengruppe, in der sich der Key Vault befindet, der das Secret enthält
- Azure Key Vault-Name: Der Name des Key Vault, der das Secret enthält
- Secret Name: In Azure Key Vault zu finden
Jetzt werden wir zwei weitere Variablen erstellen und dieses Mal „Text“ als Typ auswählen.
- EnvironmentURL – zum Speichern der Umgebungs-ID. Zu finden im Admin Center.
- TenantID – zum Speichern der TenantID. Diese finden Sie in der Übersicht im AAD.
Wenn alle vier vorhanden sind, können Sie fortfahren.
Target Entity - Zieleinheit
Mit anderen Worten ist es eine benutzerdefinierte Tabelle, in der Ihr benutzerdefiniertes Überwachungsprotokoll gespeichert wird. Für diesen Leitfaden habe ich einen sehr einfachen erstellt, aber nichts hindert Sie daran, ein komplexeres Überwachungsprotokoll zu erstellen - mit Ausnahme der Dataverse-Kapazität.
In meinem Fall sind das die Spalten, die im Audit-Log verwendet werden.
- Protokoll – Automatische Nummerierung; Präfix – „Protokoll“; Mindestanzahl Ziffern = 4; Samen = 0;
- Änderungen – Mehrere Textzeilen; Text
- Kontext – Auswahl („Neuer Datensatz“, „Aktualisieren“, „Löschen“)
- Geändert von – Lookup (Benutzer)
- Geändert am – Datum und Uhrzeit
- Record – Lookup (Cast – meine benutzerdefinierte Entität, an der ich Änderungen verfolgen möchte)
Und damit beende ich den zweiten Teil dieses Leitfadens. An diesem Punkt sollten Sie bereit sein mit der Entwicklung zu beginnen. Im dritten Teil beginnen wir mit der Arbeit am Power Automate-Flow. Wir werden das Einrichten von Triggern, das Herstellen einer Verbindung mit Azure Key Vault und das Abrufen des Überwachungsprotokolls von Dataverse durchgehen.
Er ist ein Power Platform Entwickler mit über 5 Jahren Erfahrung. Außerhalb der Bürozeiten ist Amadeusz ein Amateur-Fußballanalyst und ein begeisterter PC-Bauer.
