DevServer con Microsoft Fabric

DevServer è il server web locale eseguito durante lo sviluppo di un carico di lavoro Fabric. Gestisce il tuo front-end (SPA) su localhost e fornisce un piccolo set di endpoint HTTP che Fabric chiama durante lo sviluppo per recuperare i manifesti del prodotto e dell'elemento. In combinazione con il DevGateway, Fabric può caricare l'interfaccia utente del tuo carico di lavoro in un iFrame e leggere i dati del manifesto senza pubblicare alcun elemento nel tuo tenant.

Operazioni di DevServer

• Ospita il front-end del carico di lavoro su HTTP in localhost (ad esempio, http://localhost:60006) in modo che Fabric possa caricarlo in un iFrame.
• Serve gli asset statici a cui fanno riferimento i manifesti (icone, stringhe localizzate, immagini).
• Espone gli endpoint JSON locali usati da Fabric per leggere i manifesti durante lo sviluppo.
• Consente cicli rapidi di aggiornamento con ricaricamento rapido nella maggior parte delle impostazioni.

Dove DevServer viene chiamato da Fabric

Quando si abilita la modalità di sviluppo e si avvia devGateway e DevServer:

• Fabric naviga al frontend attraverso l'endpoint frontend definito dal manifesto del carico di attività (vedere Manifesto del carico di attività). In fase di sviluppo, in genere punta a un URL localhost esposto dal server di sviluppo.
• Fabric esegue una query in DevServer per i metadati destinati al prodotto in modo da poter effettuare il rendering della navigazione, dei riquadri e di altre interfacce utente per il flusso di lavoro. In questo modo è possibile iterare su Product.json e sui manifesti degli elementi senza ricostruire e caricare un pacchetto.

Endpoint locali forniti da DevServer

Le route esatte possono variare in base al modello, ma il repository di esempio espone un piccolo set di endpoint stimabili:

• GET / — restituisce la tua applicazione web (UI Fabric viene caricata in un iFrame).
• GET /manifests: restituisce un payload JSON che aggrega il manifesto del prodotto e i manifesti item usati dal front-end. Questa rispecchia la struttura che Fabric si aspetta al momento della pubblicazione (vedere Manifest del prodotto e Manifest dell'elemento).
• GET /assets/... : fornisce icone, immagini e stringhe localizzate a cui fanno riferimento i manifesti.

Flusso di sviluppo tipico

1. Avviare DevServer dal repository di esempio per ospitare il front-end in localhost.
2. Avviare DevGateway per registrare il carico di lavoro locale con Fabric.
3. Apri l'area di lavoro di Fabric e avvia il punto di ingresso del carico; Fabric carica la tua app in un iFrame e chiama gli endpoint del tuo DevServer per leggere i dati del manifesto.
4. Modificare i file dell'interfaccia utente o manifesto e aggiornare; le modifiche diventano effettive immediatamente senza ricomprimere.

Per informazioni su come avviare ogni processo, vedere l'esercitazione introduttiva e la guida all'installazione.

Relazione con i manifesti pubblicati

Nell'ambiente di produzione, i manifesti del carico di lavoro vengono inseriti in un pacchetto e caricati come parte del pacchetto NuGet del carico di lavoro (vedere Panoramica del manifesto). Durante lo sviluppo, gli endpoint locali di DevServer fungono da supporto leggero per i file in pacchetto, in modo da poter eseguire rapidamente l'iterazione:

• Schema e regole sono uguali a per i manifesti pubblicati.
• DevServer influisce solo sullo sviluppo locale; non cambia il funzionamento della pubblicazione.

Suggerimenti per la risoluzione dei problemi

• Se l'iFrame mostra una pagina vuota, verificare che DevServer sia in esecuzione e che l'endpoint front-end nel manifesto punti all'URL localhost corretto.
• Se mancano icone o stringhe, controllare i assets percorsi e che il DevServer fornisca tali file in /assets.
• Se Fabric non riesce a trovare i manifesti, verificare che la /manifests route esista nel modello e restituisca json valido.

Stub di endpoint remoti per lo sviluppo locale

DevServer include implementazioni stub predefinite per gli endpoint remoti, consentendo di testare i processi e le notifiche del ciclo di vita in locale senza eseguire la distribuzione in Azure o in altri servizi cloud. Questi stub intercettano le chiamate che normalmente passano agli endpoint remoti di produzione e le gestiscono sul computer locale.

Che cosa sono gli stub di endpoint remoti?

Gli stub di endpoint remoti sono implementazioni locali del contratto di endpoint remoto che:

• Ricevere richieste di esecuzione del lavoro e notifiche sul ciclo di vita da Fabric
• Registrare i dettagli della richiesta nella console per ottenere visibilità immediata
• Fornire implementazioni di esempio che illustrano come interagire con OneLake e altri servizi di Fabric
• Illustrare la gestione dei token e i modelli di autenticazione
• Abilitare l'iterazione rapida senza distribuzione cloud

Funzionalità supportate dagli stub

Gli stub DevServer supportano:

Esecuzione dell'attività

• Trigger di lavori su richiesta e pianificati
• Gestione del ciclo di vita dei processi (avvio, stato, annullamento)
• Implementazioni di esempio che illustrano i modelli di elaborazione dei dati
• Esempi di integrazione di OneLake

Notifiche del ciclo di vita

• Notifiche di creazione di elementi
• Notifiche di aggiornamento degli elementi
• Eliminazione di elementi e notifiche di eliminazione temporanea
• Modelli di provisioning dell'infrastruttura di esempio

Come funziona

Quando si esegue il DevServer con endpoint remoti configurati:

1. Reindirizzamento automatico : tutte le chiamate di endpoint remoto definite nel manifesto dell'elemento vengono reindirizzate automaticamente al computer locale
2. Registrazione della console : i dettagli della richiesta, i token e i payload vengono visualizzati nella console di DevServer
3. Esecuzione di esempio: eseguono le implementazioni stub che illustrano le migliori pratiche
4. Accesso ai token : si ricevono token di Infrastruttura effettivi che possono essere usati per chiamare le API di Infrastruttura e accedere a OneLake

Utilizzo degli stub per endpoint remoti

Per usare gli stub dell'endpoint remoto per i test locali:

1. Configurare il manifesto dell'elemento - Definire processi o notifiche del ciclo di vita come si farebbe per l'ambiente di produzione (vedere Abilitare processi remoti e Abilitare le notifiche del ciclo di vita degli elementi)

2. Avviare DevServer : avviare il server di sviluppo seguendo la guida introduttiva

3. Registrare il carico di lavoro locale : usare DevGateway per registrare il carico di lavoro con Fabric

4. Operazioni di attivazione in Fabric - eseguire azioni che attivano processi o notifiche del ciclo di vita:

   • Creare, aggiornare o eliminare elementi per le notifiche del ciclo di vita
   • Attivare i processi manualmente o tramite pianificazioni

5. Osservare l'esecuzione dello stub : controllare la console di DevServer per:

   • Dettagli della richiesta in ingresso
   • Informazioni sul token di autenticazione
   • Esempi di accesso a OneLake
   • Modelli di esecuzione dei lavori

Esempio di output della console

Quando viene attivato un processo, viene visualizzato un output simile al seguente:

🔔 Job execution request received
   Job Type: MyWorkload.DataProcessor.RefreshData
   Instance ID: abc123-def456
   Workspace ID: 11111111-2222-3333-4444-555555555555
   Item ID: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

🔑 Authentication tokens received
   Subject Token: eyJ0eXAiOiJKV1QiLCJhbGc...
   App Token: eyJ0eXAiOiJKV1QiLCJhbGc...
   Tenant ID: bbbbcccc-1111-dddd-2222-eeee3333ffff

📦 OneLake access example
   Getting OneLake token for scope: https://storage.azure.com/.default
   Reading from: /workspaces/{workspaceId}/items/{itemId}/files/

✅ Job execution completed

Vantaggi del test degli stub locali

• No distribuzione Azure obbligatoria - Testare la logica degli endpoint remoti senza risorse cloud
• Iterazione rapida: visualizzare immediatamente i risultati nella console
• Esempi di gestione dei token - Informazioni sui modelli di autenticazione con token reali
• Integrazione di OneLake - Testare i modelli di accesso ai dati in modo sicuro
• Codice di esempio : vedere implementazioni funzionanti per guidare il codice di produzione

Passaggio alla produzione

Le implementazioni stub forniscono codice di esempio che è possibile adattare per la produzione:

1. Esaminare l'implementazione dello stub nella codebase di DevServer
2. Implementare gli endpoint di produzione usando i modelli illustrati
3. Distribuire gli endpoint in Azure Functions, Container Instances o altre opzioni di hosting
4. Aggiornare la configurazione del manifesto in modo che punti agli endpoint di produzione (vedere Abilitare endpoint remoti)

Gli stub usano gli stessi modelli di autenticazione e contratti API di produzione, semplificando la transizione.

Vedere anche

• DevGateway
• Abilitare endpoint remoti
• Abilitare processi remoti
• Abilitare le notifiche relative al ciclo di vita degli elementi
• Autenticare gli endpoint remoti
• Manifesto del carico di lavoro
• Manifesto del prodotto
• Manifesto dell'elemento
• Panoramica del manifesto