Манифест рабочей нагрузки

Обзор

Для определения рабочей нагрузки в среде Fabric требуются файлы WorkloadManifest.xml и Item.xml. Они содержат базовые параметры конфигурации рабочих нагрузок и элементов рабочей нагрузки для настройки и управления ими, помогая определять, делиться и записывать важные сведения о рабочей нагрузке для плавной интеграции с Fabric.

В нашем примере репозитория .nupkg файл создается из XML-файлов, расположенных в папке src/Packages/manifest во время процесса сборки. Этот упакованный файл содержит все необходимые сведения о рабочей нагрузке. В файле workload-dev-mode.json есть поле ManifestPackageFilePath, которое должно указывать на этот недавно созданный файл .nupkg.

Процесс отправки и регистрации

1. Проверка подлинности пользователей: во время разработки после выполнения примера проверка подлинности инициирует процесс отправки и регистрации. Это гарантирует правильную связь рабочей нагрузки с вашей идентичностью.
2. Синтаксический анализ манифеста: загруженный манифест проходит синтаксический анализ для проверки его структуры и содержимого. Этот шаг гарантирует правильность форматирования манифеста и готовности к дальнейшей обработке.
3. Регистрация рабочей нагрузки. Если синтаксический анализ выполнен успешно, рабочая нагрузка зарегистрирована в Fabric. Основные сведения о конфигурации, такие как идентификатор рабочей нагрузки, хранятся в базе данных Fabric, обеспечивая эффективное управление рабочими нагрузками.

Манифест рабочей нагрузки — ключевые компоненты манифеста

Манифест, структура которого определена в WorkloadDefinition.xsd, описывает основные атрибуты рабочей нагрузки, такие как имя, приложение и конечные точки.

Атрибут SchemaVersion

Представляет опубликованную версию Fabric WorkloadDefinition.xsd.

Атрибут WorkloadName

Уникальный идентификатор рабочей нагрузки. Обратите внимание, что необходимо иметь "Org". префикс для имени рабочей нагрузки, так чтобы имя состояло из двух слов с разделителем '.', например 'Org.MyWorkload'. Другие префиксы недопустимы и вызывают сбой отправки. Это будет применяться в следующих сценариях: подключение для разработчиков, загрузка тестового файла.

Элемент версии

Версия манифеста должна быть совместимой с SemVer.

Элемент CloudServiceConfiguration

Для конфигурации службы вашей рабочей нагрузки в настоящее время поддерживается только одна конфигурация.

Идентификатор Microsoft Entra ID [Azure Active Directory (AAD)] Конфигурация приложения

В <AADApp> этом разделе описано, как настроить приложение Microsoft Entra ID [Azure Active Directory (AAD)] для процессов проверки подлинности и авторизации. Представляет AppId, который является уникальным идентификатором для вашего приложения; RedirectUri указывает URI, на который Microsoft Entra ID отправит ответ аутентификации; и ResourceId указывает на уникальный идентификатор ресурса, к которому обращается приложение. Дополнительные сведения о том, что ResourceId, AppId, и RedirectUri означают, см. в документации по аутентификации.

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

Ознакомьтесь с документацией по проверке подлинности для более глубокого понимания AppId, ResourceId, и RedirectUri и их важности в контексте процессов проверки подлинности.

Элементы ServiceEndpoint

Представляет конфигурацию определенной логической конечной точки, например серверную конечную точку, которая включает реализацию для API-интерфейсов cruD и заданий элементов.

• Конфигурация серверной конечной точки рабочей нагрузки указывает внутренний URL-адрес рабочей нагрузки.

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

• <IsEndpointResolutionService> и <EndpointResolutionContext> задаются в зависимости от того, реализует ли конечная точка API рабочей нагрузки или только разрешение конечной точки.
• Разрешенная конечная точка, возвращаемая службой, должна соответствовать следующим требованиям:
  • Домен разрешенной конечной точки должен соответствовать домену идентификатора ресурса , найденного в WorkloadManifest.xml.
  • URL-адрес разрешенной конечной точки может иметь до шести дополнительных поддоменов до основного домена.
  • Любой поддомен после первого сегмента должен принадлежать списку проверенных доменов клиента издателя.

Пример

URL-адрес идентификатора ресурса:https://contoso.com/fe/be/Org.WorkloadSample (где домен )contoso.com

Проверенные домены в клиенте:contoso.com, be.contoso.comeastus.be.contoso.com

Допустимые разрешенные конечные точки:

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

Недопустимые разрешенные конечные точки:

• api.eastus.fe.contoso.com (недопустимо, так как eastus.fe.contoso.com не является проверенным доменом)
• contoso-dev.com (недопустимо, так как contoso-dev.com не является проверенным доменом, а также не соответствует основному домену идентификатора ресурса)

• Дополнительные сведения об использовании API клиента рабочей нагрузки для разрешения конечных точек см. в разделе "Разрешение конечных точек".

Примечание.

Разрешение конечных точек для фронтенда не поддерживается.

Манифест элемента — ключевые компоненты манифеста

Манифест, структура которого определяется itemDefinition.xsd, описывает основные атрибуты элемента рабочей нагрузки, такие как определения имен и заданий.

Атрибут SchemaVersion

Представляет опубликованную версию файла ItemDefinition.xsd от Fabric.

Атрибут TypeName

Уникальный идентификатор элемента.

Настройка планировщика заданий

В <JobScheduler> разделе рассматриваются различные элементы, определяющие поведение и параметры планирования заданий, отслеживания и управления.

• <OnDemandJobDeduplicateOptions> и <ScheduledJobDeduplicateOptions>: определение параметров дедупликации для заданий по запросу и запланированных элементов соответственно. Параметры включают None (без дедупликации), PerItem (одно задание выполняется для одного и того же элемента и типа задания) и PerUser (одно задание выполняется для одного пользователя и элемента).
• <ItemJobTypes>: содержит конфигурации для различных типов заданий, связанных с элементами.
• <ItemJobType>: описывает определенный тип задания.
• <Name>: имя типа задания. Необходимо использовать имя элемента в качестве префикса.

Например, рассмотрим пример рабочей нагрузки, которая включает три конкретных задания, определенные в <ItemJobTypes> разделе:

<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 : этот тип задания выполняет текстовые расчеты, принимает Operand1 и Operand2, выполняет выбранную операцию и сохраняет результат в lakehouse.
• CalculateAsParquet Job : специально адаптировано для работы с данными Parquet, этот тип задания также принимает Operand1 и Operand2выполняет выбранную операцию и сохраняет результат в lakehouse, следуя формату данных Parquet. Дополнительные сведения о заданиях и связанной конфигурации см. в руководстве по центру мониторинга .

В итоге манифесты рабочей нагрузки и элементов служат основными документами для добавления пользовательских рабочих нагрузок в Fabric. Процесс проверки подлинности запускает простую последовательность действий: отправку, синтаксический анализ и регистрацию, гарантируя правильную настройку и эффективное управление рабочими нагрузками в экосистеме Azure.