Manifest obciążenia

Omówienie

Pliki WorkloadManifest.xml i Item.xml są wymagane do definicji obciążenia w sieci szkieletowej. Przechowują podstawowe ustawienia konfiguracji elementów obciążenia i obciążeń na potrzeby konfiguracji i pełnią rolę przewodnika dotyczącego konfigurowania i zarządzania obciążeniami, pomagając definiować, udostępniać i rejestrować podstawowe szczegóły obciążenia w celu zapewnienia bezproblemowej integracji z usługą Fabric.

W naszym przykładowym repozytorium .nupkg plik jest generowany na podstawie plików XML znajdujących się w src/Packages/manifest folderze podczas procesu kompilacji. Ten spakowany plik zawiera wszystkie niezbędne informacje o obciążeniu. workload-dev-mode.json W pliku znajduje się pole o nazwie ManifestPackageFilePath , które powinno wskazywać ten nowo utworzony .nupkg plik.

Proces przekazywania i rejestracji

1. Uwierzytelnianie użytkownika: w trakcie tworzenia, po uruchomieniu przykładu, uwierzytelnianie inicjuje proces przesyłania i rejestracji. Zapewnia to prawidłowe skojarzenie obciążenia z twoją tożsamością.
2. Analizowanie manifestu: przekazany manifest jest analizowany w celu zweryfikowania jego struktury i zawartości. Ten krok gwarantuje, że manifest jest poprawnie sformatowany i gotowy do dalszego przetwarzania.
3. Rejestracja obciążenia: jeśli analizowanie zakończy się pomyślnie, obciążenie jest rejestrowane w Fabric. Podstawowe szczegóły konfiguracji, takie jak identyfikator obciążenia, są przechowywane w bazie danych sieci Szkieletowej, co umożliwia efektywne zarządzanie obciążeniami.

Manifest obciążenia — kluczowe składniki manifestu

Manifest, którego struktura jest definiowana przez element WorkloadDefinition.xsd, przedstawia podstawowe atrybuty obciążenia, takie jak nazwa, aplikacja i punkty końcowe.

Atrybut SchemaVersion

Reprezentuje opublikowaną wersję WorkloadDefinition.xsd sieci szkieletowej.

Atrybut WorkloadName

Unikatowy identyfikator obciążenia. Należy pamiętać, że wymagane jest posiadanie "Organizacji". prefiks nazwa_obciążenia, taki jak nazwa składa się z dwóch wyrazów z separatorem '.', np. 'Org.MyWorkload'. Inne prefiksy są nieprawidłowe i spowodują niepowodzenie przekazywania. Zostanie to wymuszone w następujących scenariuszach — połączenie dewelopera, ładowanie testowe.

Version, element

Wersja manifestu powinna być zgodna ze standardem SemVer .

CloudServiceConfiguration, element

Konfiguracja usługi obciążenia, obecnie obsługiwana jest tylko jedna konfiguracja.

Microsoft Entra ID [Azure Active Directory (AAD)] Konfiguracja aplikacji

Sekcja <AADApp> konfiguruje aplikację Microsoft Entra ID [Azure Active Directory (AAD)] na potrzeby procesów uwierzytelniania i autoryzacji. Reprezentuje AppId unikatowy identyfikator aplikacji, określa identyfikator URI, RedirectUri do którego identyfikator Entra firmy Microsoft wyśle odpowiedź uwierzytelniania, a ResourceId wskazuje unikatowy identyfikator zasobu, do którego uzyskuje dostęp aplikacja. Aby uzyskać więcej informacji na temat tego, co ResourceIdAppId, i RedirectUri reprezentuje, możesz zapoznać się z dokumentacją uwierzytelniania.

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

Zapoznaj się z dokumentacją uwierzytelniania, aby lepiej zrozumieć AppId, ResourceIdi RedirectUri ich znaczenie w kontekście procesów uwierzytelniania.

Elementy punktu końcowego usługi

Reprezentują konfigurację określonego logicznego punktu końcowego, na przykład punkt końcowy zaplecza, który obejmuje implementację dla interfejsów API CRUD elementów i zadań.

• Konfiguracja punktu końcowego zaplecza obciążenia określa adres URL zaplecza obciążenia.

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

• <IsEndpointResolutionService> i <EndpointResolutionContext> są ustawiane na podstawie tego, czy punkt końcowy implementuje interfejs API obciążenia, czy tylko rozwiązanie punktu końcowego.
• Rozwiązany punkt końcowy zwrócony z usługi musi spełniać następujące wymagania:
  • Domena rozpoznanego punktu końcowego musi być zgodna z domeną identyfikatora zasobu znalezionego w WorkloadManifest.xml.
  • Rozpoznany adres URL punktu końcowego może mieć maksymalnie sześć dodatkowych domen podrzędnych przed domeną główną.
  • Każda poddomena po pierwszym segmencie musi należeć do listy zweryfikowanych domen dzierżawcy wydawcy.

Przykład

Adres URL identyfikatora zasobu:https://contoso.com/fe/be/Org.WorkloadSample (gdzie domena to contoso.com)

Zweryfikowane domeny w dzierżawie:contoso.com, be.contoso.com, eastus.be.contoso.com

Prawidłowe ustalone punkty końcowe:

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

Nieprawidłowe ustalone punkty końcowe:

• api.eastus.fe.contoso.com (nieprawidłowa, ponieważ eastus.fe.contoso.com nie jest zweryfikowaną domeną)
• contoso-dev.com (nieprawidłowa, ponieważ contoso-dev.com nie jest zweryfikowaną domeną, a także nie jest zgodna z główną domeną identyfikatora zasobu)

• Aby uzyskać więcej informacji na temat używania interfejsu API klienta obciążenia roboczego do rozpoznawania punktów końcowych, zobacz Rozpoznawanie punktów końcowych.

Manifest elementu — kluczowe składniki manifestu

Manifest, którego struktura jest definiowana przez element ItemDefinition.xsd, przedstawia podstawowe atrybuty elementu obciążenia, takie jak nazwy i definicje zadań.

Atrybut SchemaVersion

Reprezentuje opublikowaną wersję ItemDefinition.xsd sieci szkieletowej.

Atrybut TypeName

Unikatowy identyfikator elementu.

Konfiguracja harmonogramu zadań

Sekcja <JobScheduler> obejmuje różne elementy, które definiują zachowanie i ustawienia planowania, śledzenia i zarządzania zadaniami.

• <OnDemandJobDeduplicateOptions> i <ScheduledJobDeduplicateOptions>: Zdefiniuj opcje deduplikacji odpowiednio dla zadań elementów na żądanie i zaplanowanych elementów. Opcje obejmują None (bez deduplikacji), PerItem (jedno zadanie jest uruchamiane dla tego samego elementu i typu zadania) oraz PerUser (jedno zadanie jest uruchamiane dla tego samego użytkownika i elementu).
• <ItemJobTypes>: zawiera konfiguracje dla różnych typów zadań elementów.
• <ItemJobType>: Opisuje określony typ zadania.
• <Name>: nazwa typu zadania. Musi używać nazwy elementu jako prefiksu.

Rozważmy na przykład nasze przykładowe obciążenie, które obejmuje trzy konkretne zadania zdefiniowane w <ItemJobTypes> sekcji:

<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 : Ten typ zadania zajmuje się obliczeniami tekstowymi, przyjmując Operand1 i Operand2, wykonując wybraną operację i zapisując wynik w lakehouse.
• CalculateAsParquet Job : Ten typ zadania jest specjalnie przystosowany do pracy z danymi Parquet. Ponadto przyjmuje Operand1 i Operand2, wykonuje wybraną operację, a następnie zapisuje wynik w lakehouse zgodnie z formatem danych Parquet. Aby uzyskać więcej informacji na temat zadań i powiązanej konfiguracji, zobacz Przewodnik centrum monitorowania .

Podsumowując, manifesty obciążeń i elementów służą jako podstawowe dokumenty służące do dodawania niestandardowych obciążeń do sieci szkieletowej. Proces uwierzytelniania wyzwala prostą sekwencję akcji: przekazywanie, analizowanie i rejestrację, gwarantując właściwą konfigurację i efektywne zarządzanie obciążeniami w ekosystemie platformy Azure.