Arbeitslast-Manifest

Übersicht

Die WorkloadManifest.xml- und Item.xml-Dateien für die Workloaddefinition in Fabric sind erforderlich. Sie enthalten die grundlegenden Konfigurationseinstellungen für Workloads und Workload-Elemente und dienen als Anleitung für die Workload-Einrichtung und -Verwaltung. Außerdem helfen sie bei der Definition, Weitergabe und Aufzeichnung wichtiger Workload-Details für eine reibungslose Integration in Fabric.

In unserem Beispiel-Repository wird eine .nupkg-Datei aus den XML-Dateien generiert, die sich während des Buildvorgangs im Ordner src/Packages/manifest befinden. Diese verpackte Datei enthält alle erforderlichen Informationen zu Ihrem Workload. In der Datei workload-dev-mode.json gibt es ein Feld namens ManifestPackageFilePath, das auf diese neu erstellte Datei .nupkg verweisen sollte.

Upload- und Registrierungsprozess

1. Benutzerauthentifizierung: Während der Entwicklung, sobald das Beispiel ausgeführt wird, leitet Ihre Authentifizierung den Upload- und Registrierungsprozess ein. Dadurch wird die richtige Zuordnung des Workload mit Ihrer Identität sichergestellt.
2. Manifestanalyse: Das hochgeladene Manifest wird analysiert, um die Struktur und den Inhalt zu überprüfen. In diesem Schritt wird sichergestellt, dass das Manifest korrekt formatiert und zur weiteren Verarbeitung bereit ist.
3. Workload-Registrierung: Wenn die Analyse erfolgreich ist, wird der Workload in Fabric registriert. Wichtige Konfigurationsdetails, wie z. B. die Workload-ID, werden in der Fabric-Datenbank gespeichert und ermöglichen eine effektive Workload-Verwaltung.

Workload-Manifest – Wichtige Manifestkomponenten

Das Manifest, dessen Struktur durch WorkloadDefinition.xsd definiert ist, skizziert Kern-Attribute eines Workload, z. B. Name, Anwendung und Endpunkte.

SchemaVersion-Attribut

Stellt die veröffentlichte Version WorkloadDefinition.xsd von Fabric dar.

WorkloadName-Attribut

Der eindeutige Bezeichner Ihrer Arbeitslast. Beachten Sie, dass es erforderlich ist, eine 'Org.' zu besitzen. Präfix für WorkloadName, so dass der Name aus zwei Wörtern mit dem Trennzeichen '.' besteht, z.B. 'Org.MyWorkload'. Andere Präfixe sind ungültig und führen zu einem Uploadfehler. Dies wird in den folgenden Szenarien erzwungen - dev-Verbindung, Testupload.

Version-Element

Die Version des Manifests sollte mit SemVer kompatibel sein.

CloudServiceConfiguration-Element

Die Dienstkonfiguration Ihres Workload. Derzeit wird nur eine Konfiguration unterstützt.

Microsoft Entra ID [Azure Active Directory (AAD)] Anwendungskonfiguration

Im Abschnitt <AADApp> wird die Anwendung Microsoft Entra ID [Azure Active Directory (AAD)] für Authentifizierungs- und Autorisierungsprozesse eingerichtet. AppId steht für den eindeutigen Bezeichner für Ihre Anwendung, RedirectUri gibt den URI an, an den Microsoft Entra ID die Authentifizierungsantwort sendet, und ResourceId verweist auf den eindeutigen Bezeichner für die Ressource, auf die die Anwendung zugreift. Weitere Informationen zu dem, was ResourceId, AppId und RedirectUri darstellen, finden Sie in der Authentifizierungsdokumentation.

<AADApp>
    <AppId>YourApplicationId</AppId>
    <RedirectUri>YourRedirectUri</RedirectUri>
    <ResourceId>YourResourceId</ResourceId>
</AADApp>

In der Authentifizierungsdokumentation werden AppId, ResourceId und RedirectUri sowie deren Bedeutung im Kontext von Authentifizierungsprozessen eingehender erläutert.

ServiceEndpoint-Elemente

Stellen Sie die Konfiguration eines bestimmten logischen Endpunkts dar, z. B. den Back-End-Endpunkt, der die Implementierung für Element-CRUD- und Auftrags-APIs enthält.

• Die Konfiguration für den Back-End-Endpunkt der Workload gibt die Back-End-URL Ihrer Workload an.

<ServiceEndpoint>
    <Name>Workload</Name>
    <Url>YourWorkloadBackendUrl</Url>
    <IsEndpointResolutionService>...
    <EndpointResolutionContext>...
</ServiceEndpoint>

• <IsEndpointResolutionService> und <EndpointResolutionContext> werden basierend darauf festgelegt, ob Ihr Endpunkt die Workload-API oder nur die Endpunktauflösung implementiert.
• Der aufgelöste Endpunkt, der vom Dienst zurückgegeben wird, muss die folgenden Anforderungen erfüllen:
  • Die Domäne des aufgelösten Endpunkts muss mit der Domäne der Ressourcen-ID übereinstimmen, die im WorkloadManifest.xmlgefunden wurde.
  • Die aufgelöste Endpunkt-URL kann bis zu sechs zusätzliche Unterdomänen vor der Hauptdomäne aufweisen.
  • Jede Unterdomäne nach dem ersten Segment muss zur Liste der überprüften Domänen des Herausgebermandanten gehören.

Beispiel

RESSOURCEN-ID-URL:https://contoso.com/fe/be/Org.WorkloadSample (wo Domäne ist contoso.com)

Überprüfte Domänen im Mandant:contoso.com, be.contoso.com, eastus.be.contoso.com

Gültige aufgelöste Endpunkte:

• api.eastus.be.contoso.com
• be.contoso.com
• api.be.contoso.com

Ungültige aufgelöste Endpunkte:

• api.eastus.fe.contoso.com (ungültig, da eastus.fe.contoso.com es sich nicht um eine überprüfte Domäne handelt)
• contoso-dev.com (ungültig, da contoso-dev.com es sich nicht um eine überprüfte Domäne handelt und auch nicht mit der Hauptdomäne der Ressourcen-ID übereinstimmt)

• Weitere Informationen zur Verwendung der Workload-Client-API für die Endpunktauflösung finden Sie unter Endpunktauflösung.

Artikel-Manifest - Wichtige Manifestkomponenten

Das Manifest, dessen Struktur durch ItemDefinition.xsd definiert ist, skizziert Kern-Attribute des Workload-Artikels, z. B. Name und Auftragsdefinitionen.

SchemaVersion-Attribut

Stellt die veröffentlichte Version von ItemDefinition.xsd von Fabric dar.

TypeName-Attribut

Eindeutiger Bezeichner Ihres Objekts.

Konfiguration des Auftragsplaners

Der Abschnitt <JobScheduler> umfasst verschiedene Elemente, die das Verhalten und die Einstellungen der Auftragsplanung, Überwachung und Verwaltung definieren.

• <OnDemandJobDeduplicateOptions> und <ScheduledJobDeduplicateOptions>: Definition der Deduplizierungs-Optionen für On-Demand- bzw. geplante Elementaufträge. Zu den Optionen gehören None (keine Deduplizierung), PerItem (eine Job-Ausführung wird für den selben Artikel und den gleichen Einzelvorgangstyp ausgeführt) und PerUser (eine Job-Ausführung wird für denselben Benutzer und den selben Artikel ausgeführt).
• <ItemJobTypes>: Enthält Konfigurationen für verschiedene Artikel-Einzelvorgangstypen.
• <ItemJobType>: Beschreibt einen bestimmten Jobtyp.
• <Name>: Der Name des Jobtyps. Muss den Namen des Artikels als Präfix verwenden.

Betrachten wir beispielsweise unseren Beispiel-Workload, der drei bestimmte Jobs enthält, die im Abschnitt <ItemJobTypes> definiert sind:

<JobScheduler>
    <OnDemandJobDeduplicateOptions>PerItem</OnDemandJobDeduplicateOptions>
    <ScheduledJobDeduplicateOptions>PerItem</ScheduledJobDeduplicateOptions>
    <ItemJobTypes>
    <ItemJobType Name="Org.WorkloadSample.SampleWorkloadItem.ScheduledJob" />
    <ItemJobType Name="Org.WorkloadSample.SampleWorkloadItem.CalculateAsText" />
    <ItemJobType Name="Org.WorkloadSample.SampleWorkloadItem.CalculateAsParquet" />
    </ItemJobTypes>
</JobScheduler>

• CalculateAsText-Job : Dieser Jobtyp verarbeitet textbasierte Berechnungen, nimmt Operand1 und Operand2, führt die ausgewählte Operation aus und speichert das Ergebnis im Lakehouse.
• CalculateAsParquet Job : Dieses Job-Typ ist speziell auf die Arbeit mit Parquet-Daten zugeschnitten. Es umfasst Operand1 und Operand2, führt den ausgewählten Vorgang aus und speichert das Ergebnis im Lakehouse im Parquet-Format. Weitere Informationen zu Aufträgen und zugehöriger Konfiguration finden Sie im Handbuch zum Überwachungshub.

Zusammenfassend dienen die Workload- und Artikelmanifeste als grundlegende Dokumente, um benutzerdefinierte Workloads in Fabric hinzuzufügen. Der Authentifizierungsprozess löst eine einfache Abfolge von Aktionen aus: Upload, Parsing und Registrierung, Gewährleistung der richtigen Konfiguration und effiziente Workload-Verwaltung innerhalb des Azure-Ökosystems.