Delen via

Inleiding tot workloads (preview)

  • Artikel

In dit hoofdstuk worden de belangrijkste onderdelen van ons systeem geïntroduceerd en wordt een overzicht van de architectuur geboden. Deze onderdelen werken samen om een robuust en flexibel platform te creëren voor uw ontwikkelingsbehoeften. Laten we dieper ingaan op deze onderdelen en hun rollen in onze architectuur.

Infrastructuurworkloadarchitectuur

Enkele van de belangrijkste aspecten van de infrastructuurworkloadarchitectuur zijn:

  • Het verwerkt gegevensverwerking, opslag en beheer. Het valideert Microsoft Entra ID-tokens voordat deze worden verwerkt en communiceert met externe Azure-services, zoals Lakehouse.

  • De front-endworkload (FE) biedt een gebruikersinterface voor het maken, ontwerpen, beheren en uitvoeren van taken.

  • Gebruikersinteracties via de FE initiëren aanvragen naar de BE, hetzij direct of indirect via de Infrastructuurback-end (Fabric BE).

Zie het overzicht van back-endverificatie en autorisatie en de overzichtsdiagrammen van verificatie in de verificatie voor gedetailleerdere diagrammen met de communicatie en verificatie van de verschillende onderdelen.

Front-end (FE)

De front-end fungeert als de basis van de gebruikerservaring (UX) en het gedrag, die binnen een iframe in de Fabric-portal werkt. Het biedt de Fabric-partner een specifieke gebruikersinterface-ervaring, waaronder een itemeditor. De SDK voor de extensieclient biedt de benodigde interfaces, API's en bootstrap-functies om een reguliere web-app te transformeren in een Micro Frontend-web-app die naadloos werkt in de Fabric-portal.

Back-end (BE)

De back-end is het powerhouse voor gegevensverwerking en metagegevensopslag. Er worden CRUD-bewerkingen gebruikt om workloaditems samen met metagegevens te maken en te beheren en taken uit te voeren om gegevens in de opslag te vullen. De communicatiebrug tussen de front-end en back-end wordt tot stand gebracht via openbare API's.

De workloads kunnen in twee omgevingen worden uitgevoerd: lokaal en in de cloud. In lokale (devmode) wordt de workload uitgevoerd op de computer van de ontwikkelaar, met API-aanroepen die worden beheerd door het devGateway-hulpprogramma. Dit hulpprogramma verwerkt ook workloadregistratie met Fabric. In de cloudmodus wordt de workload uitgevoerd op de partnerservices, waarbij API-aanroepen rechtstreeks naar een HTTPS-eindpunt worden uitgevoerd.

Ontwikkelomgeving

Notitie

Voor elke ontwikkelmodus wordt een ander pakket gemaakt bij het bouwen van de BE-oplossing in Visual Studio.

  • Workloadpakket voor dev-modus: wanneer u de back-endoplossing in Visual Studio bouwt, gebruikt u de parameter Foutopsporing om een BE NuGet-pakket te maken dat kan worden geladen in de Fabric-tenant met behulp van de DevGateway-toepassing.

Diagram van de architectuur van de ontwikkelaarsmodus.

  • Workloadpakket voor cloudmodus: bij het bouwen van de BE-oplossing in Visual Studio gebruikt u de releaseparameter om een zelfstandig workloadpakket (BE en FE) te maken. Dit pakket kan rechtstreeks naar de tenant worden geüpload.

Diagram van de cloudmodusarchitectuur.

NuGet-pakketstructuur workload

De workload wordt verpakt als een NuGet-pakket, waarbij back-end- en front-endonderdelen worden gecombineerd. De structuur voldoet aan specifieke naamconventies en wordt afgedwongen door Fabric voor consistentie in uploadscenario's. Het NuGet-pakket dat is ontworpen om workloads weer te geven, is gestructureerd met zowel back-end- als front-endonderdelen.

Back-endstructuur

Het back-endsegment bestaat uit .xml bestanden die de workload en de bijbehorende items definiëren, die essentieel zijn voor registratie bij Fabric.

Belangrijke onderdelen
  • WorkloadManifest.xml - Het configuratiebestand van de werkbelasting, dat vereist is om deze exacte naam te hebben voor de verificatie van Fabric.
  • Item1.xml, , - Item2.xml... Manifesten voor afzonderlijke items met flexibele naamgeving, volgens de XML-indeling.

Front-endstructuur

De front-endsectie bevat .json bestanden met informatie over het product en de items voor de front-end, samen met een map 'assets' voor pictogrammen.

Belangrijke onderdelen
  • Product.json - Het belangrijkste manifest voor de front-end van uw product, dat precies moet worden genoemd voor de verificatie van Fabric.
  • assets map - Slaat alle .svg pictogrammen icon1.svg, icon2.svggebruikt ... door de front-end.

Verplichte structuurnaleving

De structuur, inclusief specifieke submapnamen ('BE', 'FE', 'assets'),, is verplicht en afgedwongen door Fabric voor alle uploadscenario's, waaronder test- en ontwikkelingspakketten. De structuur wordt opgegeven in de .nuspec bestanden in de opslagplaats onder de ./src/Packages/manifest/ManifestPackage map.

Tijdens de ontwikkelingscyclus kan het testen van een workload op een niet-productietenant worden uitgevoerd in twee modi, lokaal (devmode) en cloudmodus (tenantmodus).

Limieten

De volgende limieten zijn van toepassing op alle typen NuGet-pakketten, zowel in de ontwikkelingsmodus als in de cloudmodus:

  • Alleen BE en FE submappen zijn toegestaan. Alle andere submappen of bestanden die zich buiten deze mappen bevinden, leiden tot een uploadfout.
  • De BE map accepteert alleen .xml bestanden. Elk ander bestandstype resulteert in een uploadfout.
  • Maximaal 10 itembestanden zijn toegestaan, wat betekent dat de BE map één WorkloadManifest.xml en maximaal 10 Item.xml bestanden kan bevatten. Als u meer dan 10 itembestanden in de map hebt, treedt er een uploadfout op.
  • De Assets submap moet zich onder de FE map bevinden. Het kan maximaal 15 bestanden bevatten, waarbij elk bestand niet groter is dan 1,5 MB.
  • Alleen de volgende bestandstypen zijn toegestaan in de Assets submap: .jpeg, , .jpg.png.
  • De FE map kan maximaal 10 itembestanden plus één product.json bestand bevatten.
  • Naar elke asset in de Assets map moet worden verwezen in de itembestanden. Elke asset waarnaar wordt verwezen vanuit een itembestand dat ontbreekt in de Assets map, resulteert in een uploadfout.
  • Bestandsnamen voor items moeten uniek zijn. Dubbele bestandsnamen resulteren in een uploadfout.
  • Bestandsnamen moeten alleen alfanumerieke (Engelse) tekens of afbreekstreepjes bevatten en mogen niet langer zijn dan 32 tekens. Als u andere tekens gebruikt of deze lengte overschrijdt, resulteert dit in een uploadfout.
  • De totale pakketgrootte mag niet groter zijn dan 20 MB.
  • Raadpleeg de definitie van het workloadmanifest voor manifestspecifieke beperkingen.

Lokale ontwikkelingsmodus (devmode)

De back-end van de werkbelasting (BE) werkt op de computer van de ontwikkelaar. Workload-API-aanroepen worden verzonden via Azure Relay, met de workloadzijde van het Azure Relay-kanaal dat wordt beheerd door een speciaal opdrachtregelprogramma, DevGateway. API-aanroepen voor workloadbeheer worden rechtstreeks vanuit de workload naar Fabric verzonden, waardoor het Azure Relay-kanaal wordt overgeslagen. Het hulpprogramma DevGateway houdt ook toezicht op de registratie van het lokale ontwikkelexemplaren van de workload met Fabric, binnen de context van een specifieke capaciteit. Dit zorgt ervoor dat de workload beschikbaar is in alle werkruimten die aan die capaciteit zijn toegewezen. Na beëindiging van het DevGateway-hulpprogramma wordt de registratie van het workloadexemplaren automatisch opnieuw gestart. Zie de handleiding voor back-end-implementatie voor meer informatie.

DevMode BE-schema

Diagram van de ontwikkelmodus zijn schemaarchitectuur.

Cloudontwikkelingsmodus (cloudmodus)

De back-end van de workload (BE) werkt binnen de services van de partner. Api-aanroepen van werkbelastingen worden rechtstreeks naar het HTTPS-eindpunt uitgevoerd, zoals is opgegeven in het workloadmanifest. In dit scenario is het hulpprogramma DevGateway niet vereist. De registratie van de workload met Fabric wordt bereikt door het NuGet-workloadpakket te uploaden naar Fabric en vervolgens de workload voor de tenant te activeren. Zie Een workload beheren in Fabric voor meer informatie.

CloudMode BE-schema

Diagram van de be-schemaarchitectuur in de cloudmodus.

Lakehouse-integratie

Onze architectuur is ontworpen om probleemloos te integreren met Lakehouse, waardoor bewerkingen zoals het opslaan, lezen en ophalen van gegevens mogelijk zijn. Deze interactie wordt gefaciliteerd via Azure Relay en de Fabric SDK, waardoor beveiligde en geverifieerde communicatie wordt gegarandeerd.

Verificatie en beveiliging

We gebruiken Microsoft Entra ID (voorheen Azure Active Directory) voor robuuste en veilige verificatie, zodat alle interacties in de architectuur zijn geautoriseerd en beveiligd. Raadpleeg de verificatiedocumenten voor een volledige inleiding tot de workloadverificatie zoals weergegeven in het bovenstaande diagram:

Gerelateerde inhoud