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 di app per la logica automatizzati che integrano le app, i dati, i servizi e i 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 l'opzione di hosting A consumo o 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. 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 (ASE 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 per la distribuzione, l'hosting e l'esecuzione dei flussi di lavoro.

App per la logica Standard e flusso di lavoro

L'app per la logica Standard e il flusso di lavoro sono basati sul runtime riprogettata di App per la logica di Azure a tenant singolo. Questo runtime usa il modello di estendibilità di Funzioni di Azure ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e più prestazioni per il flussi di lavoro delle app per la logica, oltre ad altre funzionalità e vantaggi ereditati dalla piattaforma Funzioni di Azure e dall'ecosistema del Servizio app di Azure. Ad esempio, è possibile creare, distribuire ed eseguire app per la logica basate su tenant singolo e i relativi flussi di lavoro nell'Ambiente del servizio app di Azure 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à di 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 Standard e un flusso di lavoro, è possibile distribuire ed eseguire il flusso di lavoro in altri ambienti, ad esempio Ambiente del servizio app di Azure 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 in locale 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 Appper la logica abilitate per Azure Arc. Per altre informazioni, vedere Che cos'è App per la logica abilitata 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 l'automazione della distribuzione della risorsa 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 sia per le app sia per 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 del runtime di App per la logica di Azure a 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 di 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 a tenant singolo offrono un ulteriore miglioramento significativo rendendo disponibili i connettori gestiti più diffusi come operazioni del connettore predefinite. Ad esempio, è possibile usare operazioni di connettori predefiniti per il 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 connessionidel provider di servizi. Le controparti della connessione gestita sono denominate connessioniAPI, che vengono create ed eseguite separatamente come risorse di Azure che è necessario distribuire usando i modelli di ARM. 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 grazie alla vicinanza ai flussi di lavoro. Questa progettazione funziona bene anche 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 risorsedell'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 possono accedere direttamente a risorse protette, ad esempio macchine virtuali (VM), altri servizi e sistemi presenti in una retevirtuale di Azure.

App per la logica di Azure a tenant singolo è un'istanza dedicata del servizio App per la logica di Azure, usa risorse dedicate e viene eseguita 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".

App per la logica di Azure a tenant singolo offre anche i vantaggi seguenti:

• Disponibilità di indirizzi IP statici separati dagli indirizzi IP statici condivisi dalle app per la logica nelle 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 ulteriori aperture del firewall in questi sistemi di destinazione.

• 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

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, nel portale di Azure la pagina App per la logica mostra sia le risorse dell'app per la logica A consumo che 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 (A 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:

• Con stato

  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 criterio di operazione asincrono standard. Dopo che un'azione HTTP chiama o invia una richiesta a un endpoint, un servizio, un sistema o un'API, il destinatario della richiesta restituisce immediatamente una risposta "202 ACCEPTED". Questo codice conferma che il destinatario ha accettato la richiesta ma non ha terminato l'elaborazione. La risposta può includere un'intestazione location che 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 destinatario 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'autonomiadei microservizi.

• Senza stato

  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.

  Nota

  Nei flussi di lavoro senza stato, è possibile usare solo trigger push in cui non si specifica una pianificazione per l'esecuzione del flusso di lavoro. Questi trigger basati su webhook attendono che si verifichi un evento o che dei dati diventino disponibili. Ad esempio, il trigger Ricorrenza è disponibile solo per i flussi di lavoro con stato. Per avviare il flusso di lavoro, selezionare un trigger push, ad esempio trigger Richiesta, Hub eventi o Bus di servizio. 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 nel portale di Azure.

Differenze di riepilogo tra flussi di lavoro con stato e senza stato

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 ApiConnectionWebhook 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 limitidi 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 ACCEPTED risposta. 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 operationOptions proprietà su DisableAsyncPattern. Per altre informazioni, vedere Trigger e tipi di azioni - Opzioni operazioni.

• 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 ACCEPTED risposta, 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

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 1.400 connettori gestiti per Software-as-a-Service (SaaS) e app e servizi PaaS (Platform-as-a-Service) e connettori per 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 A consumo e Standard.

  • È possibile creare connettori predefiniti personalizzati per qualsiasi servizio necessario usando il framework di estendibilità App per la logica di Azure a tenant singolo. Analogamente ai connettori predefiniti, ad esempio il Bus di servizio di Azure e SQL Server, questi connettori predefiniti offrono una velocità effettiva più elevata, una bassa latenza, e una connettività locale in quanto sono eseguiti nello stesso processo quale runtime a tenant singolo. Tuttavia, i connettori predefiniti personalizzati non sono simili ai connettorigestiti 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 seguenti azioni:

    • XML: trasformare XML, convalida XML, xml compose con schema e analisi XML con schema

    • Liquid: trasformare JSON in JSON, trasformare JSON in TESTO, trasformare XML in JSONe 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 artefatti nel portale di Azure dal menu delle risorse dell'app per la logica, in Artifacts, 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 vari flussi di lavoro all'interno della stessa app per la logica.

  • I flussi di lavoro delle app per la logica standard possono essere attivati 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 queste stringhe 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 nel runtime. Questa identità è diversa dalle credenziali di autenticazione o dalla stringa di connessione usata quando si crea una connessione. Se si disabilita questa identità, le connessioni non funzioneranno nel runtime. 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, al momento i punti di interruzione sono supportati solo per le azioni, 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 pianoPremium di Funzioni di Azure. Per altre informazioni, vedere la documentazione seguente:

  • Opzioni di rete di Funzioni di Azure

  • App per la logica di Azure in esecuzione ovunque - Possibilità di rete con App per la logica di Azure

• 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 quello 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 Gestione API di Azure e Servizi app di Azure.

In 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 una stringa di connessione, un ID Microsoft Entra o un'identità gestita. Tutti i connettori predefiniti vengono eseguiti nello stesso processo del runtime riprogettato di App per la logica di Azure. 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 , le funzionalità seguenti sono diverse, 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 e operazioni del servizio app Azure. Per avviare un flusso di lavoro con stato o senza stato, usare un trigger predefinito, ad esempio richiesta, Hub eventi o trigger del Bus di servizio. 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 gestiti vengono visualizzati con l'etichetta Condiviso .

  I flussi di lavoro senza stato possono usare solo trigger push in cui non si specifica una pianificazione per l'esecuzione del flusso di lavoro. Questi trigger basati su webhook attendono che si verifichi un evento o che dei dati diventino disponibili. Ad esempio, il trigger Ricorrenza è disponibile solo per i flussi di lavoro con stato. Per avviare il flusso di lavoro, selezionare un trigger push, ad esempio trigger Richiesta, Hub eventi o Bus di servizio. Sebbene sia possibile abilitare connettori gestiti per i flussi di lavoro senza stato, la raccolta di connettori non mostra alcun trigger di polling 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 Operazioni di Funzioni di Azure - Chiamare una funzionedi Azure. Questa azione attualmente funziona solo per le funzioni create dal modello trigger HTTP.

      Nel 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 connectionName riferimento. Questa versione astrae le informazioni della funzione come connessione, che è possibile trovare nel file 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 tale 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 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 appdel flusso di lavoro.

    • 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 Standard può avere un solo trigger e non supporta più trigger.

• Autenticazione

  • Alcuni trigger basati su richiesta che gestiscono le chiamate in ingresso, ad esempio il trigger di richiesta, attualmente non supportano Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), mentre altri, ad esempio il trigger Webhook HTTP, dispongono di questo supporto.

  • Alcuni connettori predefiniti basati su provider di servizi attualmente non supportano la selezione dell'identità gestita assegnata dall'utente per l'autenticazione. Tuttavia, sia il supporto dell'identità gestita assegnata dal sistema che l'identità gestita assegnata dall'utente sono disponibili in generale. Per impostazione predefinita, l'identità gestita assegnata dal sistema viene abilitata automaticamente.

• 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 flusso di lavoro dell'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.

• Modelli Terraform: non è possibile usare questi modelli con una risorsa dell'app per la logica Standard per la distribuzione completa dell'infrastruttura. Per altre informazioni, vedere Che cos'è Terraform in Azure?

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 tutte le connessioni di trigger o azione presenti nel flusso di lavoro. Facoltativamente, è possibile consentire il traffico dai tag del servizio e usare lo stesso livello di restrizioni o criteri del servizio app di Azure. È 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

È anche possibile conoscere le 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.