Partager via

Présentation des charges de travail

  • Article

Ce chapitre présente les composants clés de notre système et fournit une vue d’ensemble de l’architecture. Ces composants fonctionnent ensemble pour créer une plateforme robuste et flexible pour vos besoins de développement. Examinons ces composants et leurs rôles dans notre architecture.

Architecture de la charge de travail Fabric

Voici quelques-uns des aspects clés de l’architecture de la charge de travail Fabric :

  • Il gère le traitement, le stockage et la gestion des données. Il valide les jetons Microsoft Entra ID avant de les traiter et interagit avec les services Azure externes, tels que Lakehouse.

  • Le serveur front-end (FE) de charge de travail offre une interface utilisateur pour la creation, la réalisation, la gestion et l’exécution des tâches.

  • Les interactions utilisateur via la FE initient des demandes à l’instance BE, directement ou indirectement via le backend Fabric (Fabric BE).

Pour obtenir des diagrammes plus détaillés illustrant la communication et l'authentification des différents composants, consultez la vue d'ensemble de l'authentification et de l’autorisation back-end et les diagrammes de vue d'ensemble de l’authentification.

Front-end (FE)

Le serveur front-end sert de base de l’expérience utilisateur (UX) et du comportement, fonctionnant dans un iframe dans le portail Fabric. Il fournit au partenaire Fabric une expérience d’interface utilisateur spécifique, y compris un éditeur d’élément. Le kit de développement logiciel (SDK) client d'extension fournit les interfaces, les API et les fonctions d'amorçage nécessaires pour transformer une application web ordinaire en une application web Micro Front-end qui fonctionne de manière transparente au sein du portail Fabric.

Back-end (BE)

Le serveur principal est le serveur principal pour le traitement de données et le stockage des métadonnées. Il utilise des opérations CRUD pour créer et gérer des éléments de charge de travail avec des métadonnées, et exécute des tâches pour remplir les données dans le stockage. Le pont de communication entre le front-end et le back-end est établie par le biais d’API publiques.

Les charges de travail peuvent s’exécuter dans deux environnements : local et cloud. En local (devmode), la charge de travail s’exécute sur l’ordinateur du développeur, avec des appels d’API gérés par l’utilitaire DevGateway. Cet utilitaire gère également l’inscription des charges de travail avec Fabric. En mode cloud, la charge de travail s’exécute sur les services partenaires, avec des appels d’API effectués directement vers un point de terminaison HTTPS.

Environnement de développement

  • Package de charge de travail en mode développement : lors de la génération de la solution back-end dans Visual Studio, utilisez la configuration de build Debug pour créer un package NuGet BE, qui peut être chargé dans le tenant Fabric en utilisant l’application DevGateway.

Diagramme de l’architecture du mode développeur.

  • Package de charge de travail en mode cloud : lors de la génération de la solution BE dans Visual Studio, utilisez la configuration de build Release pour créer un package de charge de travail autonome (BE et FE). Ce package peut être chargé directement sur le locataire.

Diagramme de l'architecture du mode cloud.

Structure des paquets NuGet pour la charge de travail

La charge de travail est présentée sous la forme d'un paquet NuGet, combinant des composants frontaux et dorsaux. La structure adhère à des conventions d’affectation de noms spécifiques et est appliquée par Fabric pour assurer la cohérence des scénarios de téléchargement. Le paquet NuGet conçu pour représenter les charges de travail est structuré de manière à inclure à la fois des composants backend et frontend.

Structure du backend

Le segment backend comprend des fichiers .xml qui définissent la charge de travail et ses éléments associés, qui sont essentiels pour l'enregistrement auprès de Fabric.

Composants clés
  • WorkloadManifest.xml - Le fichier de configuration de la charge de travail, qui doit avoir ce nom exact pour la vérification de Fabric.
  • Item1.xml, Item2.xml, - ... Manifestes pour les articles individuels avec une dénomination flexible, suivant le format XML.

Structure du frontend

La section frontend contient des fichiers .json détaillant le produit et les éléments pour le frontend, ainsi qu'un répertoire "assets" pour les icônes.

Composants clés
  • Product.json - Le manifeste principal pour le frontend de votre produit, qui doit être nommé précisément pour la vérification de Fabric.
  • Item1.json, Item2.json, ... : manifestes pour les articles individuels avec une dénomination flexible, suivant le format JSON. Chaque JSON correspond à un manifeste back-end (par exemple, Item1.json à Item1.xml).
  • Dossier assets : stocke toutes les icônes icon1.jpg, icon2.png, ... utilisées par le front-end.

Conformité obligatoire des structures

La structure, y compris les noms de sous-dossiers spécifiques ("BE", "FE", "assets"), est obligatoire et appliquée par Fabric pour tous les scénarios de téléchargement, y compris les paquets de test et de développement. La structure est spécifiée dans les fichiers .nuspec qui se trouvent dans le référentiel sous le référentiel Backend/src/Packages/manifest.

Limites

Les limites suivantes s’appliquent à tous les types de packages NuGet, en mode de développement et en mode cloud :

  • Seuls les sous-dossiers BE et FE sont autorisés. Tout autre sous-dossier ou fichier se trouvant en dehors de ces dossiers entraîne une erreur de chargement.
  • Le dossier BE accepte uniquement les fichiers .xml. Tout autre type de fichier entraîne une erreur de chargement.
  • Un maximum de 10 fichiers d’élément est autorisé, ce qui signifie que le dossier BE peut contenir un WorkloadManifest.xml et jusqu’à 10 fichiers Item.xml. Le fait d’avoir plus de 10 fichiers d’élément dans le dossier entraîne une erreur de chargement.
  • Le sous-dossier Assets doit résider sous le dossier FE. Il peut contenir jusqu’à 15 fichiers, chaque fichier n’étant pas supérieur à 1,5 Mo.
  • Seuls les types de fichiers suivants sont autorisés dans le sous-dossier Assets : .jpeg, .jpg, .png.
  • Le dossier FE peut contenir au maximum 10 fichiers d’éléments plus un fichier product.json.
  • Chaque ressource du dossier Assets doit être référencée dans les fichiers d’éléments. Toute ressource référencée à partir d’un fichier d’élément manquant dans le dossier Assets entraîne une erreur de chargement.
  • Les noms de fichier des éléments doivent être uniques. Les noms de fichier en double entraînent une erreur de chargement.
  • Les noms de fichier doivent contenir des caractères alphanumériques (anglais) ou des traits d’union uniquement et ne peuvent pas dépasser une longueur de 32 caractères. L’utilisation d’autres caractères ou le dépassement de cette longueur entraînent une erreur de chargement.
  • La taille totale du package ne doit pas dépasser 20 Mo.
  • Reportez-vous au manifeste de charge de travail pour connaître les limitations spécifiques au manifeste.

Mode de développement local (devmode)

Le serveur principal de charge de travail (BE) fonctionne sur l’ordinateur du développeur. Les appels d’API de charge de travail sont transmis via Azure Relay, avec le côté de la charge de travail du canal Azure Relay géré par un utilitaire de ligne de commande spécialisé, DevGateway. Les appels d’API de contrôle de charge de travail sont envoyés directement à partir de la charge de travail vers Fabric, en contournant le canal Azure Relay. L’utilitaire DevGateway supervise également l’inscription de l’instance de développement locale de la charge de travail avec Fabric, dans le contexte d’un espace de travail spécifique. À l’arrêt de l’utilitaire DevGateway, l’inscription de l’instance de charge de travail est automatiquement annulée. Pour plus d’informations, consultez le Guide d’implémentation back-end.

Schéma DevMode BE

Le diagramme du mode de développement est l’architecture de schéma.

Mode de développement cloud (mode cloud)

Le back-end de charge de travail (BE) fonctionne dans les services du partenaire. Les appels d’API de charge de travail sont effectués directement vers le point de terminaison HTTPS, comme spécifié dans le manifeste de charge de travail. Dans ce scénario, l’utilitaire DevGateway n’est pas obligatoire. L’inscription de la charge de travail avec Fabric est effectuée en chargeant le package NuGet de charge de travail sur Fabric et en activant la charge de travail pour le locataire. Pour plus d’informations, consultez Gérer une charge de travail dans Fabric.

Schéma CloudMode BE

Diagramme de l’architecture de schéma BE en mode cloud.

Contenu connexe