Differenze tra app per la logica a tenant singolo Standard e app per la logica multi-tenant a consumo
App per la logica di Azure è una piattaforma basata sul cloud per la creazione e l'esecuzione di flussi di lavoro automatizzati di app per la logica che integrano app, dati, servizi e sistemi. Con questa piattaforma è possibile sviluppare rapidamente soluzioni di integrazione altamente scalabili per scenari aziendali e B2B. Quando si crea una risorsa dell'app per la logica, selezionare il tipo di flusso di lavoro Consumo o Il tipo di flusso di lavoro Standard . Un'app per la logica a consumo può avere un solo flusso di lavoro eseguito in App per la logica di Azure multi-tenant o in un ambiente del servizio di integrazione. Un'app per la logica Standard può avere uno o più flussi di lavoro eseguiti in App per la logica di Azure a tenant singolo o in un ambiente del servizio app v3 (A edizione Standard v3).
Prima di scegliere la risorsa dell'app per la logica da creare, vedere la guida seguente per informazioni sul confronto tra i tipi di flusso di lavoro dell'app per la logica. È quindi possibile scegliere meglio il flusso di lavoro e l'ambiente dell'app per la logica più adatti allo scenario, ai requisiti della soluzione e alla destinazione in cui si vuole distribuire ed eseguire i flussi di lavoro.
Se non si ha familiarità con App per la logica di Azure, vedere Che cos'è App per la logica di Azure? e Che cos'è un flusso di lavoro dell'app per la logica?.
Tipi e ambienti del flusso di lavoro dell'app per la logica
La tabella seguente riepiloga le differenze tra un flusso di lavoro dell'app per la logica a consumo e un flusso di lavoro dell'app per la logica Standard. Si apprenderà anche come l'ambiente a tenant singolo differisce dall'ambiente multi-tenant e da un ambiente del servizio di integrazione (I edizione Standard) per la distribuzione, l'hosting e l'esecuzione dei flussi di lavoro.
| Tipo di risorsa | Vantaggi | Condivisione e utilizzo delle risorse | Modello di determinazione prezzi e fatturazione | Gestione dei limiti |
|---|---|---|---|---|
| App per la logica (consumo) Ambiente host: App per la logica di Azure multi-tenant |
- È più semplice iniziare - Pagamento in base al consumo - Completamente gestito |
Una singola app per la logica può avere un solo flusso di lavoro. Le app per la logica nei tenant di Microsoft Entra condividono la stessa elaborazione (calcolo), archiviazione, rete e così via. Ai fini della ridondanza, i dati vengono replicati nell'area abbinata. Per la disponibilità elevata, l'archiviazione con ridondanza geografica è abilitata. |
Consumo (pagamento per esecuzione) | App per la logica di Azure gestisce i valori predefiniti per questi limiti, ma è possibile modificare alcuni di questi valori, se tale opzione esiste per un limite specifico. |
| App per la logica (consumo) Ambiente host: Ambiente del servizio di integrazione (I edizione Standard) Nota: il 31 agosto 2024 l'opzione I edizione Standard verrà ritirata. Dal 1° novembre 2022 non è più possibile creare un edizione Standard. È invece possibile creare un'app per la logica Standard, che viene eseguita in App per la logica di Azure a tenant singolo, può includere più flussi di lavoro e offre le stesse funzionalità di un I edizione Standard più altro. |
- Scalabilità aziendale per carichi di lavoro di grandi dimensioni - 20+ I edizione Standard connettori specifici che si connettono direttamente alle reti virtuali - Prezzi prevedibili con utilizzo incluso e scalabilità controllata dal cliente |
Una singola app per la logica può avere un solo flusso di lavoro. Le app per la logica nello stesso ambiente condividono la stessa elaborazione (calcolo), archiviazione, rete e così via. I dati rimangono nella stessa area in cui si distribuisce l'I edizione Standard. |
I edizione Standard (fisso) | App per la logica di Azure gestisce i valori predefiniti per questi limiti, ma è possibile modificare alcuni di questi valori, se tale opzione esiste per un limite specifico. |
| App per la logica (standard) Ambiente host: App per la logica di Azure a tenant singolo Nota: se lo scenario richiede contenitori, creare app per la logica basate su tenant singolo usando App per la logica abilitate per Azure Arc. Per altre informazioni, vedere Che cos'è App per la logica con abilitazione di Azure Arc? |
- Eseguire usando il runtime di App per la logica di Azure a tenant singolo. Gli slot di distribuzione non sono attualmente supportati. - Più connettori predefiniti per una velocità effettiva più elevata e costi inferiori su larga scala - Maggiore controllo e funzionalità di ottimizzazione per le impostazioni di runtime e prestazioni - Supporto integrato per reti virtuali ed endpoint privati. - Creare connettori predefiniti. |
Una singola app per la logica può avere più flussi di lavoro con stato e senza stato. I flussi di lavoro in un'unica app per la logica e tenant condividono la stessa elaborazione (calcolo), archiviazione, rete e così via. I dati rimangono nella stessa area in cui si distribuiscono le app per la logica. |
Standard, basato su un piano di hosting con un piano tariffario selezionato. Se si eseguono flussi di lavoro con stato, che usano l'archiviazione esterna, il runtime di App per la logica di Azure effettua transazioni di archiviazione che seguono Archiviazione di Azure prezzi. |
È possibile modificare i valori predefiniti per molti limiti, in base alle esigenze dello scenario. Importante: alcuni limiti hanno limiti massimi massimi rigidi. In Visual Studio Code le modifiche apportate ai valori limite predefiniti nei file di configurazione del progetto dell'app per la logica non verranno visualizzate nell'esperienza di progettazione. Per altre informazioni, vedere Modificare le impostazioni dell'app e dell'ambiente per le app per la logica in App per la logica di Azure a tenant singolo. |
| App per la logica (standard) Ambiente host: ambiente del servizio app v3 (A edizione Standard v3) - Solo piani di Windows |
Le stesse funzionalità del tenant singolo e i vantaggi seguenti: - Isolare completamente le app per la logica. - Creare ed eseguire più app per la logica rispetto a App per la logica di Azure a tenant singolo. - Pagare solo per il piano A edizione Standard servizio app, indipendentemente dal numero di app per la logica create ed eseguite. - Può abilitare la scalabilità automatica o la scalabilità manuale con più istanze di macchine virtuali o un piano di servizio app diverso. - Eredita la configurazione di rete dall'oggetto A edizione Standard v3 selezionato. Ad esempio, quando viene distribuito in un'A edizione Standard interna, i flussi di lavoro possono accedere alle risorse in una rete virtuale associata a A edizione Standard e avere punti di accesso interni. Nota: se l'accesso è stato eseguito dall'esterno di un edizione Standard interno, le cronologie di esecuzione per i flussi di lavoro in tale A edizione Standard non possono accedere agli input e agli output delle azioni. |
Una singola app per la logica può avere più flussi di lavoro con stato e senza stato. I flussi di lavoro in un'unica app per la logica e tenant condividono la stessa elaborazione (calcolo), archiviazione, rete e così via. I dati rimangono nella stessa area in cui si distribuiscono le app per la logica. |
Piano di servizio app | È possibile modificare i valori predefiniti per molti limiti, in base alle esigenze dello scenario. Importante: alcuni limiti hanno limiti massimi massimi rigidi. In Visual Studio Code le modifiche apportate ai valori limite predefiniti nei file di configurazione del progetto dell'app per la logica non verranno visualizzate nell'esperienza di progettazione. Per altre informazioni, vedere Modificare le impostazioni dell'app e dell'ambiente per le app per la logica in App per la logica di Azure a tenant singolo. |
App per la logica standard e flusso di lavoro
L'app per la logica standard e il flusso di lavoro sono basati sul runtime di App per la logica di Azure a tenant singolo riprogettata. Questo runtime usa il modello di estendibilità Funzioni di Azure ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e prestazioni maggiori per i flussi di lavoro dell'app per la logica, oltre ad altre funzionalità e vantaggi ereditati dalla piattaforma Funzioni di Azure e dall'ecosistema di servizi app Azure. Ad esempio, è possibile creare, distribuire ed eseguire app per la logica basate su tenant singolo e i relativi flussi di lavoro in app Azure Ambiente del servizio v3 (solo piani di Windows).
L'app per la logica Standard introduce una struttura di risorse che può ospitare più flussi di lavoro, analogamente a come un'app per le funzioni di Azure possa ospitare più funzioni. Con un mapping da 1 a molti, i flussi di lavoro nella stessa app per la logica e la stessa condivisione tenant condividono risorse di calcolo ed elaborazione, offrendo prestazioni migliori a causa della prossimità. Questa struttura è diversa dalla risorsa app per la logica a consumo in cui è disponibile un mapping da 1 a 1 tra la risorsa dell'app per la logica e un flusso di lavoro.
Per altre informazioni sulla portabilità, la flessibilità e i miglioramenti delle prestazioni, continuare a esaminare le sezioni seguenti. Per altre informazioni sul runtime di App per la logica di Azure a tenant singolo e sull'estendibilità Funzioni di Azure, vedere la documentazione seguente:
- App per la logica di Azure in esecuzione ovunque - Approfondimento del runtime
- Introduzione a Funzioni di Azure
- Trigger e associazioni di Funzioni di Azure
Portabilità e flessibilità
Quando si crea un'app per la logica e un flusso di lavoro Standard, è possibile distribuire ed eseguire il flusso di lavoro in altri ambienti, ad esempio app Azure Ambiente del servizio v3 (solo piani di Windows). Se si usa Visual Studio Code con l'estensione App per la logica di Azure (Standard), è possibile sviluppare, compilare ed eseguire il flusso di lavoro nell'ambiente di sviluppo senza dover eseguire la distribuzione in Azure. Se lo scenario richiede contenitori, è possibile creare app per la logica a tenant singolo usando App per la logica abilitate per Azure Arc. Per altre informazioni, vedere Che cos'è App per la logica abilitate per Azure Arc?
Queste funzionalità offrono importanti miglioramenti e vantaggi sostanziali rispetto al modello multi-tenant, che richiede lo sviluppo rispetto a una risorsa in esecuzione esistente in Azure. Il modello multi-tenant per automatizzare la distribuzione delle risorse dell'app per la logica a consumo si basa sui modelli di Azure Resource Manager (modelli arm), che combinano e gestiscono il provisioning delle risorse per le app e l'infrastruttura.
Con la risorsa app per la logica Standard, la distribuzione diventa più semplice perché è possibile separare la distribuzione di app dalla distribuzione dell'infrastruttura. È possibile creare un pacchetto di runtime App per la logica di Azure tenant singolo e i flussi di lavoro insieme come parte della risorsa o del progetto dell'app per la logica. È possibile usare passaggi o attività generici che compilano, assemblano e comprimono le risorse dell'app per la logica in artefatti pronti per la distribuzione. Per distribuire l'infrastruttura, è comunque possibile usare i modelli arm per effettuare separatamente il provisioning di tali risorse insieme ad altri processi e pipeline usati per tali scopi.
Per distribuire l'app, copiare gli artefatti nell'ambiente host e quindi avviare le app per eseguire i flussi di lavoro. In alternativa, integrare gli artefatti nelle pipeline di distribuzione usando gli strumenti e i processi già noti e usati. In questo modo, è possibile distribuire usando gli strumenti scelti, indipendentemente dallo stack di tecnologie usato per lo sviluppo.
Usando le opzioni di compilazione e distribuzione standard, è possibile concentrarsi sullo sviluppo di app separatamente dalla distribuzione dell'infrastruttura. Di conseguenza, si ottiene un modello di progetto più generico in cui è possibile applicare molte opzioni di distribuzione simili o le stesse usate per un'app generica. È anche possibile usufruire di un'esperienza più coerente quando si compilano pipeline di distribuzione per le app e quando si eseguono i test e le convalide necessari prima della pubblicazione nell'ambiente di produzione.
Prestazioni
Con un'app per la logica Standard è possibile creare ed eseguire più flussi di lavoro nella stessa singola risorsa e tenant dell'app per la logica. Con questo mapping da 1 a molti, questi flussi di lavoro condividono risorse, ad esempio calcolo, elaborazione, archiviazione e rete, offrendo prestazioni migliori a causa della loro prossimità.
La risorsa dell'app per la logica Standard e il runtime di App per la logica di Azure tenant singolo offrono un altro miglioramento significativo rendendo disponibili i connettori gestiti più diffusi come operazioni del connettore predefinite. Ad esempio, è possibile usare le operazioni predefinite del connettore per bus di servizio di Azure, Hub eventi di Azure, SQL Server e altri. Nel frattempo, le versioni del connettore gestito sono ancora disponibili e continuano a funzionare.
Quando si usano le nuove operazioni predefinite del connettore, si creano connessioni denominate connessioni predefinite o connessioni del provider di servizi. Le controparti della connessione gestita sono denominate connessioni API, che vengono create ed eseguite separatamente come risorse di Azure che è necessario distribuire usando i modelli di Resource Manager. Le operazioni predefinite e le relative connessioni vengono eseguite localmente nello stesso processo che esegue i flussi di lavoro. Entrambi sono ospitati nel runtime di App per la logica di Azure a tenant singolo. Di conseguenza, le operazioni predefinite e le relative connessioni offrono prestazioni migliori a causa della prossimità con i flussi di lavoro. Questa progettazione funziona anche bene con le pipeline di distribuzione perché le connessioni del provider di servizi vengono inserite nello stesso artefatto di compilazione.
Residenza dei dati
Le risorse dell'app per la logica standard sono ospitate in App per la logica di Azure a tenant singolo, che non archivia, elabora o replica i dati all'esterno dell'area in cui si distribuiscono queste risorse dell'app per la logica, ovvero i dati nei flussi di lavoro rimangono nella stessa area in cui si creano e distribuiscono le risorse padre.
Accesso diretto alle risorse nelle reti virtuali di Azure
I flussi di lavoro eseguiti in App per la logica di Azure a tenant singolo o in un ambiente del servizio di integrazione (I edizione Standard) possono accedere direttamente a risorse protette, ad esempio macchine virtuali (VM), altri servizi e sistemi esistenti in una rete virtuale di Azure.
Sia i App per la logica di Azure a tenant singolo che i edizione Standard sono istanze dedicate del servizio App per la logica di Azure, usano risorse dedicate ed eseguite separatamente da App per la logica di Azure multi-tenant. L'esecuzione di flussi di lavoro in un'istanza dedicata consente di ridurre l'impatto che altri tenant di Azure potrebbero avere sulle prestazioni dell'app, noto anche come effetto "vicino rumoroso".
I App per la logica di Azure a tenant singolo e i edizione Standard offrono anche i vantaggi seguenti:
I propri indirizzi IP statici, separati dagli indirizzi IP statici condivisi dalle app per la logica nel App per la logica di Azure multi-tenant. È anche possibile configurare un unico indirizzo IP in uscita pubblico, statico e prevedibile per comunicare con i sistemi di destinazione. In questo modo, non è necessario configurare aperture firewall aggiuntive in tali sistemi di destinazione per ogni I edizione Standard.
Aumento dei limiti per durata dell'esecuzione, conservazione dell'archiviazione, velocità effettiva, timeout di richieste e risposte HTTP, dimensioni dei messaggi e richieste di connettori personalizzati. Per altre informazioni, vedere Limiti e configurazione per App per la logica di Azure.
Opzioni di creazione, compilazione e distribuzione
Per creare una risorsa dell'app per la logica in base all'ambiente desiderato, sono disponibili più opzioni, ad esempio:
Ambiente a tenant singolo
Ambiente multi-tenant
Ambiente del servizio di integrazione
| Opzione | Risorse e strumenti | Ulteriori informazioni |
|---|---|---|
| Azure portal | App per la logica di consumo distribuita in una risorsa I edizione Standard esistente | Uguale a Avvio rapido: Creare un flusso di lavoro dell'app per la logica a consumo in App per la logica di Azure multi-tenant, portale di Azure, ma selezionare un edizione Standard di I edizione Standard e non un'area multi-tenant. |
Anche se le esperienze di sviluppo variano a seconda che si creino risorse di app per la logica a consumo o Standard, è possibile trovare e accedere a tutte le app per la logica distribuite nella sottoscrizione di Azure.
Ad esempio, nella portale di Azure la pagina App per la logica mostra le risorse dell'app per la logica a consumo e standard. In Visual Studio Code le app per la logica distribuite vengono visualizzate nella sottoscrizione di Azure, ma le app per la logica a consumo vengono visualizzate nella finestra di Azure sotto l'estensione App per la logica di Azure (consumo), mentre le app per la logica Standard vengono visualizzate nella sezione Risorse.
Flussi di lavoro con stato e senza stato
All'interno di un'app per la logica Standard è possibile creare i tipi di flusso di lavoro seguenti:
Stateful
Creare un flusso di lavoro con stato quando è necessario mantenere, esaminare o fare riferimento ai dati degli eventi precedenti. Questi flussi di lavoro salvano tutti gli input, gli output e gli stati delle operazioni nell'archiviazione esterna. Queste informazioni consentono di esaminare i dettagli e la cronologia dell'esecuzione del flusso di lavoro al termine di ogni esecuzione. I flussi di lavoro con stato offrono resilienza elevata se si verificano interruzioni. Dopo il ripristino dei servizi e dei sistemi, è possibile ricostruire le esecuzioni interrotte dallo stato salvato ed eseguire nuovamente i flussi di lavoro fino al completamento. I flussi di lavoro con stato possono continuare l'esecuzione per molto più tempo rispetto ai flussi di lavoro senza stato.
Per impostazione predefinita, i flussi di lavoro con stato in App per la logica di Azure multi-tenant e a tenant singolo vengono eseguiti in modo asincrono. Tutte le azioni basate su HTTP seguono il modello di operazione asincrona standard. Dopo che un'azione HTTP chiama o invia una richiesta a un endpoint, un servizio, un sistema o un'API, il ricevitore della richiesta restituisce immediatamente una risposta "202 ACCEPTED". Questo codice conferma che il ricevitore ha accettato la richiesta ma non ha terminato l'elaborazione. La risposta può includere un'intestazione
locationche specifica l'URI e un ID di aggiornamento che il chiamante può usare per eseguire il polling o controllare lo stato della richiesta asincrona finché il ricevitore non interrompe l'elaborazione e restituisce una risposta di esito positivo "200 OK" o un'altra risposta non 202. Tuttavia, il chiamante non deve attendere il completamento dell'elaborazione della richiesta e può continuare a eseguire l'azione successiva. Per altre informazioni, vedere Integrazione asincrona di microservizi applica l'autonomia dei microservizi.Apolide
Creare un flusso di lavoro senza stato quando non è necessario mantenere, esaminare o fare riferimento ai dati degli eventi precedenti nell'archiviazione esterna dopo il completamento di ogni esecuzione per una revisione successiva. Questi flussi di lavoro salvano tutti gli input e gli output per ogni azione e i relativi stati in memoria, non solo nell'archiviazione esterna. Di conseguenza, i flussi di lavoro senza stato hanno esecuzioni più brevi che in genere terminano in 5 minuti o meno, prestazioni più veloci con tempi di risposta più rapidi, velocità effettiva più elevata e costi di esecuzione ridotti perché l'archiviazione esterna non salva i dettagli e la cronologia dell'esecuzione del flusso di lavoro. Tuttavia, se si verificano interruzioni, le esecuzioni interrotte non vengono ripristinate automaticamente, quindi il chiamante deve inviare manualmente le esecuzioni interrotte.
Un flusso di lavoro senza stato offre prestazioni ottimali quando si gestiscono dati o contenuti che non superano i 64 KB di dimensioni totali , ad esempio un file. Dimensioni di contenuto maggiori, ad esempio più allegati di grandi dimensioni, potrebbero rallentare significativamente le prestazioni del flusso di lavoro o persino causare l'arresto anomalo del flusso di lavoro a causa di eccezioni di memoria insufficiente. Se il flusso di lavoro potrebbe dover gestire dimensioni di contenuto maggiori, usare invece un flusso di lavoro con stato.
Nei flussi di lavoro senza stato sono disponibili azioni del connettore gestito, ma i trigger del connettore gestito non sono disponibili. Per avviare il flusso di lavoro, selezionare invece un trigger predefinito, ad esempio Richiesta, Hub eventi o bus di servizio trigger. Questi trigger vengono eseguiti in modo nativo nel runtime di App per la logica di Azure. Il trigger Ricorrenza non è disponibile per i flussi di lavoro senza stato ed è disponibile solo per i flussi di lavoro con stato. Per altre informazioni su trigger, azioni e connettori limitati, non disponibili o non supportati, vedere Modifica, limitazioni, funzionalità non disponibili o non supportate.
I flussi di lavoro senza stato vengono eseguiti solo in modo sincrono, quindi non usano il modello di operazione asincrona standard usato dai flussi di lavoro con stato. Tutte le azioni basate su HTTP che restituiscono invece una risposta "202 ACCEPTED" continuano al passaggio successivo dell'esecuzione del flusso di lavoro. Se la risposta include un'intestazione
location, un flusso di lavoro senza stato non eseguirà il polling dell'URI specificato per controllare lo stato. Per seguire il modello di operazione asincrona standard, usare invece un flusso di lavoro con stato.Per semplificare il debug, è possibile abilitare la cronologia di esecuzione per un flusso di lavoro senza stato, che ha un impatto sulle prestazioni e quindi disabilitare la cronologia di esecuzione al termine. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo in Visual Studio Code o Creare flussi di lavoro basati su tenant singolo nella portale di Azure.
Importante
È necessario decidere il tipo di flusso di lavoro, con stato o senza stato, da implementare in fase di creazione. Le modifiche apportate al tipo di flusso di lavoro dopo la creazione generano errori di runtime.
Differenze di riepilogo tra flussi di lavoro con stato e senza stato
| Con stato | Senza stato |
|---|---|
| Archivia cronologia di esecuzione, input e output | Non archivia la cronologia di esecuzione, gli input o gli output per impostazione predefinita |
| I trigger del connettore gestito sono disponibili e consentiti | I trigger del connettore gestito non sono disponibili o non sono consentiti |
| Supporta la suddivisione in blocchi | Nessun supporto per la suddivisione in blocchi |
| Supporta operazioni asincrone | Nessun supporto per le operazioni asincrone |
| Modificare la durata massima di esecuzione predefinita nella configurazione host | Ideale per i flussi di lavoro con durata massima inferiore a 5 minuti |
| Gestisce messaggi di grandi dimensioni | Ideale per la gestione di piccole dimensioni dei messaggi (inferiore a 64 KB) |
Differenze di comportamento annidate tra flussi di lavoro con stato e senza stato
È possibile rendere un flusso di lavoro chiamabile da altri flussi di lavoro presenti nella stessa app per la logica Standard usando il trigger Request, il trigger Webhook HTTP o i trigger del connettore gestito con il tipo Api Connessione ionWebhook e possono ricevere richieste HTTPS.
L'elenco seguente descrive i modelli di comportamento che i flussi di lavoro annidati possono seguire dopo che un flusso di lavoro padre chiama un flusso di lavoro figlio:
Modello di polling asincrono
Il flusso di lavoro padre non attende che il flusso di lavoro figlio risponda alla chiamata iniziale. Tuttavia, l'elemento padre controlla continuamente la cronologia di esecuzione dell'elemento figlio fino al termine dell'esecuzione dell'elemento figlio. Per impostazione predefinita, i flussi di lavoro con stato seguono questo modello, ideale per flussi di lavoro figlio con esecuzione prolungata che potrebbero superare i limiti di timeout delle richieste.
Modello sincrono ("fuoco e dimentica")
Il flusso di lavoro figlio riconosce la chiamata del flusso di lavoro padre restituendo immediatamente una
202 ACCEPTEDrisposta. Tuttavia, l'elemento padre non attende che il figlio restituisca i risultati. L'elemento padre continua invece all'azione successiva nel flusso di lavoro e riceve i risultati al termine dell'esecuzione dell'elemento figlio. I flussi di lavoro con stato figlio che non includono un'azione Risposta seguono sempre il modello sincrono e forniscono una cronologia di esecuzione da esaminare.Per abilitare questo comportamento, nella definizione JSON del flusso di lavoro impostare la
operationOptionsproprietà suDisableAsyncPattern. Per altre informazioni, vedere Trigger and action types - Operation options .For more information, see Trigger and action types - Operation options.Trigger e attesa
I flussi di lavoro senza stato vengono eseguiti in memoria. Pertanto, quando un flusso di lavoro padre chiama un flusso di lavoro figlio senza stato, l'elemento padre attende una risposta che restituisce i risultati dell'elemento figlio. Questo modello funziona in modo analogo all'uso del trigger o dell'azione HTTP predefinito per chiamare un flusso di lavoro figlio. I flussi di lavoro figlio senza stato che non includono un'azione Response restituiscono immediatamente una
202 ACCEPTEDrisposta, ma l'elemento padre attende il completamento dell'elemento figlio prima di continuare con l'azione successiva. Questi comportamenti si applicano solo ai flussi di lavoro senza stato figlio.
La tabella seguente identifica il comportamento del flusso di lavoro figlio in base al fatto che l'elemento padre e figlio siano con stato, senza stato o siano tipi di flusso di lavoro misti. Elenco dopo la tabella
| Flusso di lavoro padre | Flusso di lavoro figlio | Comportamento figlio |
|---|---|---|
| Con stato | Con stato | Asincrona o sincrona con "operationOptions": "DisableAsyncPattern" l'impostazione |
| Con stato | Senza stato | Trigger e attesa |
| Senza stato | Con stato | Sincrona |
| Senza stato | Senza stato | Trigger e attesa |
Altre funzionalità del modello a tenant singolo
Il modello a tenant singolo e l'app per la logica Standard includono molte funzionalità correnti e nuove, ad esempio:
Creare app per la logica e i relativi flussi di lavoro da centinaia di connettori gestiti per app e servizi SaaS (Software-as-a-Service) e paaS (Platform-as-a-Service) e connettori per i sistemi locali.
I connettori gestiti sono ora disponibili come connettori predefiniti nei flussi di lavoro Standard. Le versioni predefinite vengono eseguite in modo nativo nel runtime di App per la logica di Azure a tenant singolo. Alcuni connettori predefiniti sono noti in modo informale anche come connettori del provider di servizi. Per un elenco, vedere Connettori predefiniti in Consumo e Standard.
È possibile creare connettori predefiniti personalizzati per qualsiasi servizio necessario usando il framework di estendibilità a tenant singolo App per la logica di Azure. Analogamente ai connettori predefiniti, ad esempio bus di servizio di Azure e SQL Server, i connettori predefiniti personalizzati offrono una velocità effettiva superiore, una bassa latenza e una connettività locale perché vengono eseguiti nello stesso processo del runtime a tenant singolo. Tuttavia, i connettori predefiniti personalizzati non sono simili ai connettori gestiti personalizzati, che non sono attualmente supportati. Per altre informazioni, vedere Panoramica del connettore personalizzato e Creare connettori predefiniti personalizzati per le app per la logica Standard in App per la logica di Azure a tenant singolo.
È possibile utilizzare le azioni seguenti per Operazioni liquide e operazioni XML senza un account di integrazione. Queste operazioni includono le azioni seguenti:
XML: Trasformare xml e convalida XML
Liquid: trasformare JSON in JSON, trasformare JSON in testo, trasformare XML in JSON e trasformare XML in testo
Nota
Per usare queste azioni nei flussi di lavoro Standard, è necessario disporre di mappe liquide, mappe XML o XML Schema. È possibile caricare questi elementi nel portale di Azure dal menu delle risorse dell'app per la logica, in Artefatti, che include le sezioni Schemi e Mappe. In alternativa, è possibile aggiungere questi artefatti alla cartella Artifacts del progetto di Visual Studio Code usando le rispettive cartelle Mappe e Schemi. È quindi possibile usare questi artefatti in più flussi di lavoro all'interno della stessa app per la logica.
I flussi di lavoro dell'app per la logica standard possono essere eseguiti ovunque, perché App per la logica di Azure genera stringa di connessione di firma di accesso condiviso che queste app per la logica possono usare per inviare richieste all'endpoint del runtime di connessione cloud. App per la logica di Azure salva questi stringa di connessione con altre impostazioni dell'applicazione in modo da poter archiviare facilmente questi valori in Azure Key Vault quando si esegue la distribuzione in Azure.
I flussi di lavoro delle app per la logica standard supportano l'abilitazione dell'identità gestita assegnata dal sistema e di più identità gestite assegnate dall'utente contemporaneamente, anche se è possibile selezionare una sola identità da usare alla volta. Sebbene i connettori basati su provider di servizi supportino l'uso dell'identità assegnata dal sistema, la maggior parte attualmente non supporta la selezione delle identità gestite assegnate dall'utente per l'autenticazione, ad eccezione di SQL Server e dei connettori HTTP.
Nota
Per impostazione predefinita, l'identità assegnata dal sistema è già abilitata per autenticare le connessioni in fase di esecuzione. Questa identità è diversa dalle credenziali di autenticazione o stringa di connessione usate quando si crea una connessione. Se si disabilita questa identità, le connessioni non funzioneranno in fase di esecuzione. Per visualizzare questa impostazione, nel menu dell'app per la logica, in Impostazioni selezionare Identità.
È possibile eseguire, testare ed eseguire il debug in locale delle app per la logica e i relativi flussi di lavoro nell'ambiente di sviluppo di Visual Studio Code.
Prima di eseguire e testare l'app per la logica, è possibile semplificare il debug aggiungendo e usando punti di interruzione all'interno del file workflow.json per un flusso di lavoro. Tuttavia, i punti di interruzione sono supportati solo per le azioni in questo momento, non per i trigger. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo in Visual Studio Code.
Pubblicare o distribuire direttamente app per la logica e i relativi flussi di lavoro da Visual Studio Code a vari ambienti di hosting, ad esempio App per la logica abilitate per Azure e Azure Arc.
Abilitare le funzionalità di registrazione e traccia di diagnostica per l'app per la logica usando Application Insights quando sono supportate dalle impostazioni della sottoscrizione di Azure e dell'app per la logica.
Accedere alle funzionalità di rete, ad esempio connettersi e integrare privatamente con le reti virtuali di Azure, in modo analogo a Funzioni di Azure quando si creano e distribuiscono le app per la logica usando il piano Funzioni di Azure Premium. Per altre informazioni, vedere la documentazione seguente:
Rigenerare le chiavi di accesso per le connessioni gestite usate dai singoli flussi di lavoro in un'app per la logica Standard . Per questa attività, seguire gli stessi passaggi per un'app per la logica a consumo, ma a livello di flusso di lavoro, non a livello di risorsa dell'app per la logica.
Connettori predefiniti per Standard
Un flusso di lavoro Standard può usare molti degli stessi connettori predefiniti di un flusso di lavoro a consumo, ma non tutti. Viceversa, un flusso di lavoro Standard include molti connettori predefiniti che non sono disponibili in un flusso di lavoro a consumo.
Ad esempio, un flusso di lavoro Standard include connettori gestiti e connettori predefiniti per BLOB di Azure, Azure Cosmos DB, Hub eventi di Azure, bus di servizio di Azure, DB2, FTP, MQ, SFTP, SQL Server e altri. Anche se un flusso di lavoro a consumo non ha queste stesse versioni predefinite del connettore, sono disponibili altri connettori predefiniti, ad esempio Azure Gestione API e servizi app Azure.
Nei App per la logica di Azure a tenant singolo, i connettori predefiniti con attributi specifici sono noti in modo informale come provider di servizi. Alcuni connettori predefiniti supportano solo un unico modo per autenticare una connessione al servizio sottostante. Altri connettori predefiniti possono offrire una scelta, ad esempio l'uso di un stringa di connessione, un ID Microsoft Entra o un'identità gestita. Tutti i connettori predefiniti vengono eseguiti nello stesso processo del runtime di App per la logica di Azure riprogettata. Per altre informazioni, vedere l'elenco dei connettori predefiniti per i flussi di lavoro dell'app per la logica Standard.
Funzionalità modificate, limitate, non disponibili o non supportate
Per il flusso di lavoro dell'app per la logica Standard , queste funzionalità sono state modificate o sono attualmente limitate, non disponibili o non supportate:
Trigger e azioni: i trigger e le azioni predefiniti vengono eseguiti in modo nativo in App per la logica di Azure, mentre i connettori gestiti sono ospitati ed eseguiti usando risorse condivise in Azure. Per i flussi di lavoro Standard, alcuni trigger e azioni predefiniti non sono attualmente disponibili, ad esempio finestra temporale scorrevole, servizio app Azure e Azure Gestione API. Per avviare un flusso di lavoro con stato o senza stato, usare un trigger predefinito, ad esempio request, Hub eventi o bus di servizio trigger. Il trigger Ricorrenza è disponibile per i flussi di lavoro con stato, ma non per i flussi di lavoro senza stato. Nella finestra di progettazione vengono visualizzati trigger e azioni predefiniti con l'etichetta In-App , mentre i trigger e le azioni del connettore gestito vengono visualizzati con l'etichetta Condiviso .
Per i flussi di lavoro senza stato, sono disponibili azioni del connettore gestito, ma i trigger del connettore gestito non sono disponibili. Anche se è possibile abilitare i connettori gestiti per i flussi di lavoro senza stato, la finestra di progettazione non mostra alcun trigger del connettore gestito da aggiungere.
Nota
Per l'esecuzione in locale in Visual Studio Code, i trigger e le azioni basati su webhook richiedono un'installazione aggiuntiva. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo in Visual Studio Code.
I trigger e le azioni seguenti sono stati modificati o sono attualmente limitati, non supportati o non disponibili:
L'azione predefinita, Funzioni di Azure: scegliere una funzione di Azure è ora Funzioni di Azure Operazioni - Chiamare una funzione di Azure. Questa azione attualmente funziona solo per le funzioni create dal modello trigger HTTP.
Nella portale di Azure è possibile selezionare una funzione trigger HTTP a cui è possibile accedere creando una connessione tramite l'esperienza utente. Se si esamina la definizione JSON dell'azione della funzione nella visualizzazione codice o nel file workflow.json usando Visual Studio Code, l'azione fa riferimento alla funzione usando un
connectionNameriferimento. Questa versione astrae le informazioni della funzione come connessione, che è possibile trovare nel file di connections.json del progetto dell'app per la logica, disponibile dopo aver creato una connessione in Visual Studio Code.Nota
Nel modello a tenant singolo l'azione della funzione supporta solo l'autenticazione delle stringhe di query. App per la logica di Azure ottiene la chiave predefinita dalla funzione quando si effettua la connessione, archivia la chiave nelle impostazioni dell'app e usa la chiave per l'autenticazione quando si chiama la funzione.
Come nel modello multi-tenant, se ad esempio si rinnova questa chiave, tramite l'esperienza di Funzioni di Azure nel portale, l'azione della funzione non funziona più a causa della chiave non valida. Per risolvere questo problema, è necessario ricreare la connessione alla funzione che si vuole chiamare o aggiornare le impostazioni dell'app con la nuova chiave.
L'azione predefinita, Codice inline, viene rinominata Operazioni codice inline, non richiede più un account di integrazione e ha aggiornato i limiti.
L'azione predefinita, App per la logica di Azure: scegliere un flusso di lavoro dell'app per la logica è ora Operazioni flusso di lavoro - Richiamare un flusso di lavoro in questa app del flusso di lavoro.
Il connettore Gmail attualmente non è supportato.
Attualmente i connettori gestiti personalizzati non sono supportati. Tuttavia, è possibile creare operazioni predefinite personalizzate quando si usa Visual Studio Code. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo con Visual Studio Code.
Un flusso di lavoro dell'app per la logica Standard può avere un solo trigger e non supporta più trigger.
Autenticazione: i tipi di autenticazione seguenti non sono attualmente disponibili per i flussi di lavoro Standard :
Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) per le chiamate in ingresso ai trigger basati su richiesta, ad esempio il trigger request e il trigger Webhook HTTP.
Autenticazione dell'identità gestita: è disponibile il supporto dell'identità gestita assegnata dal sistema e dell'utente. Per impostazione predefinita, l'identità gestita assegnata dal sistema viene abilitata automaticamente. Tuttavia, la maggior parte dei connettori predefiniti basati su provider di servizi non supporta attualmente la selezione delle identità gestite assegnate dall'utente per l'autenticazione.
Trasformazione XML: attualmente è supportato solo XSLT 1.0.
Debug dei punti di interruzione in Visual Studio Code: sebbene sia possibile aggiungere e usare punti di interruzione all'interno del file workflow.json per un flusso di lavoro, i punti di interruzione sono supportati solo per le azioni in questo momento, non per i trigger. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo in Visual Studio Code.
Cronologia dei trigger e cronologia di esecuzione: per un'app per la logica Standard, la cronologia dei trigger e la cronologia di esecuzione nella portale di Azure viene visualizzata a livello di flusso di lavoro, non a livello di risorsa dell'app per la logica. Per altre informazioni, vedere Creare flussi di lavoro basati su tenant singolo usando il portale di Azure.
Backup e ripristino per la cronologia di esecuzione del flusso di lavoro: le app per la logica Standard attualmente non supportano il backup e il ripristino per la cronologia di esecuzione del flusso di lavoro.
Destinazioni di distribuzione: non è possibile distribuire una risorsa dell'app per la logica Standard in un ambiente del servizio di integrazione (I edizione Standard) né in slot di distribuzione di Azure.
Azure Gestione API: attualmente non è possibile importare una risorsa dell'app per la logica Standard in Azure Gestione API. Tuttavia, è possibile importare una risorsa dell'app per la logica a consumo .
Autorizzazioni rigorose per il traffico di rete e firewall
Se l'ambiente ha requisiti di rete o firewall rigorosi che limitano il traffico, è necessario consentire l'accesso per qualsiasi connessione di trigger o azione nei flussi di lavoro. Facoltativamente, è possibile consentire il traffico dai tag del servizio e usare lo stesso livello di restrizioni o criteri di app Azure Servizio. È anche necessario trovare e usare i nomi di dominio completi (FQDN) per le connessioni. Per altre informazioni, vedere le sezioni corrispondenti nella documentazione seguente:
- Autorizzazioni del firewall per le app per la logica a tenant singolo - portale di Azure
- Autorizzazioni del firewall per le app per la logica a tenant singolo - Visual Studio Code
Passaggi successivi
- Creare flussi di lavoro basati su tenant singolo nel portale di Azure
- Creare flussi di lavoro basati su tenant singolo in Visual Studio Code
Vorremmo anche ascoltare le vostre esperienze con App per la logica di Azure a tenant singolo.
- Per i bug o i problemi, creare i problemi in GitHub.
- Per domande, richieste, commenti e altri commenti, usare questo modulo di feedback.