Skillnader mellan standard logikappar för enskild klient jämfört med förbrukningslogikappar för flera klienter

Azure Logic Apps är en molnbaserad plattform för att skapa och köra automatiserade logikapparbetsflöden som integrerar dina appar, data, tjänster och system. Med den här plattformen kan du snabbt utveckla mycket skalbara integreringslösningar för dina B2B-scenarier (företag till företag). När du skapar en logikappresurs väljer du antingen alternativet för konsumtion eller standardalternativet. En logikapp för förbrukning kan bara ha ett arbetsflöde som körs i Azure Logic Apps med flera klientorganisationer. En standardlogikapp kan ha ett eller flera arbetsflöden som körs i Azure Logic Apps för en enda klientorganisation eller en App Service-miljön v3 (ASE v3).

Innan du väljer vilken logikappresurs du vill skapa kan du läsa följande guide för att lära dig hur logikappens arbetsflödestyper jämförs med varandra. Du kan sedan göra ett bättre val om vilket logikapparbetsflöde och vilken miljö som passar bäst för ditt scenario, lösningskrav och det mål där du vill distribuera och köra dina arbetsflöden.

Om du inte har använt Azure Logic Apps tidigare läser du Vad är Azure Logic Apps? och Vad är ett logikapparbetsflöde?.

Arbetsflödestyper och miljöer för logikappar

I följande tabell sammanfattas skillnaderna mellan logikappens förbrukningsarbetsflöde och standardarbetsflöde för logikappen. Du får också lära dig hur miljön för en enskild klient skiljer sig från miljön för flera klienter för att distribuera, vara värd för och köra dina arbetsflöden.

Värdalternativ	Förmåner	Resursdelning och resursanvändning	Pris- och faktureringsmodell	Begränsningshantering
Förbrukning Värdmiljö: Multitenant Azure Logic Apps	– Enklast att komma igång - Betala för det du använder – Fullständigt hanterad	En enskild logikappresurs kan bara ha ett arbetsflöde. Alla logikappar i Microsoft Entra-klienter delar samma bearbetning (beräkning), lagring, nätverk och så vidare. I redundanssyfte replikeras data i den kopplade regionen. För hög tillgänglighet är geo-redundant lagring (GRS) aktiverat.	Förbrukning (betala per körning)	Azure Logic Apps hanterar standardvärdena för dessa gränser, men du kan ändra några av dessa värden om det alternativet finns för en specifik gräns.
Standard (arbetsflödestjänstplan) Värdmiljö: Azure Logic Apps med enkelklient Obs! Om ditt scenario kräver containrar, skapar du logikappar baserade på enskild klient med Azure Arc-aktiverade Logic Apps. Mer information finns i Vad är Azure Arc-aktiverade Logic Apps?	– Fler inbyggda kontakter som finns på singelhyresgästmiljön för högre dataflöde och lägre kostnader vid större skala – Mer kontroll- och finjusteringsfunktioner kring körnings- och prestandainställningar – Integrerat stöd för virtuella nätverk och privata slutpunkter. – Skapa egna inbyggda kopplingar.	En enskild logikappresurs kan ha flera tillståndskänsliga och tillståndslösa arbetsflöden. Arbetsflöden i en enda logikapp och klientorganisation delar samma bearbetning (beräkning), lagring, nätverk och så vidare. Data finns kvar i samma region där du distribuerar logikappen.	Standard, baserat på en värdplan med en vald prisnivå. Om du kör tillståndskänsliga arbetsflöden, som använder extern lagring, gör Azure Logic Apps-körningen lagringstransaktioner som följer prissättningen för Azure Storage.	Du kan ändra standardvärdena för många gränser baserat på ditt scenarios behov. Viktigt: Vissa gränser har hårda övre maxvärden. I Visual Studio Code visas inte de ändringar du gör i standardgränsvärdena i konfigurationsfilerna för logikappens projekt i designerupplevelsen. Mer information finns i Redigera app- och miljöinställningar för logikappar i enkelinstans Azure Logic Apps.
Standard (App Service Environment v3) Värdmiljö: App Service-miljön v3 (ASEv3) – Endast Windows-planer	Samma funktioner som enskild hyresgäst plus följande fördelar: – Isolera dina logikappar helt. – Skapa och kör fler logikappar än i Azure Logic Apps med en single-tenant miljö. – Betala endast för ASE App Service-planen, oavsett antalet logikappar som du skapar och kör. – Kan aktivera automatisk skalning eller skala manuellt med fler virtuella datorinstanser eller en annan App Service-plan. – Ärv nätverkskonfigurationen från den valda ASEv3. När du till exempel distribuerar till en intern ASE kan arbetsflöden komma åt resurserna i ett virtuellt nätverk som är associerat med ASE och ha interna åtkomstpunkter. Obs! Om du använder utanför en intern ASE kör du historik för arbetsflöden där ASE inte kan komma åt åtgärdsindata och utdata.	En enda logikapp kan ha flera tillståndskänsliga och tillståndslösa arbetsflöden. Arbetsflöden i en enda logikapp och klientorganisation delar samma bearbetning (beräkning), lagring, nätverk och så vidare. Data finns kvar i samma region som du distribuerar dina logikappar till.	App Service-plan	Du kan ändra standardvärdena för många gränser baserat på ditt scenarios behov. Viktigt: Vissa gränser har hårda övre maxvärden. I Visual Studio Code visas inte de ändringar du gör i standardgränsvärdena i konfigurationsfilerna för logikappens projekt i designerupplevelsen. Mer information finns i Redigera app- och miljöinställningar för logikappar i enkelinstans Azure Logic Apps.

Standardlogik-app och arbetsprocess

Standardlogikappen och arbetsflödet drivs av den omdesignade Azure Logic Apps-körningen för en enda klientorganisation. Den här körmiljön använder utökningsmodellen för Azure Functions och finns som ett tillägg i Azure Functions körmiljö. Den här designen ger portabilitet, flexibilitet och mer prestanda för dina logikapparbetsflöden plus andra funktioner och fördelar som ärvs från Azure Functions-plattformen och Azure App Service-ekosystemet. Till exempel kan du skapa, distribuera och köra en klientbaserad logikapp och dess arbetsflöden i Azure App Service-miljön v3 (endast Windows-planer).

Standardlogikappen introducerar en resursstruktur som kan vara värd för flera arbetsflöden, ungefär som hur en Azure-funktionsapp kan vara värd för flera funktioner. Med en 1-till-många-mappning delar arbetsflöden i samma logikapp och klientorganisation beräknings- och bearbetningsresurser, vilket ger bättre prestanda tack vare deras närhet. Den här strukturen skiljer sig från Consumption-resursen för logikappar där du har en 1-till-1-mappning mellan logikappresursen och ett arbetsflöde.

Om du vill veta mer om portabilitet, flexibilitet och prestandaförbättringar kan du fortsätta att granska följande avsnitt. För mer information om single-tenant-körningen för Azure Logic Apps och utökningsbarheten i Azure Functions, se följande dokumentation:

• Azure Logic Apps körs var som helst – Djupdykning i körning
• Introduktion till Azure Functions
• Azure Functions-utlösare och bindningar

Portabilitet och flexibilitet

När du skapar en standardlogikapp och ett arbetsflöde kan du distribuera och köra arbetsflödet i andra miljöer, till exempel Azure App Service-miljön v3 (endast Windows-planer). Om du använder Visual Studio Code med Tillägget Azure Logic Apps (Standard) kan du lokalt utveckla, skapa och köra arbetsflödet i utvecklingsmiljön utan att behöva distribuera till Azure. Om ditt scenario kräver containrar kan du skapa logikappar för en enkel klient med hjälp av Azure Arc-aktiverade Logic Apps. Mer information finns i Vad är Azure Arc-aktiverade Logic Apps?

Dessa funktioner ger stora förbättringar och betydande fördelar jämfört med modellen med flera klientorganisationer, vilket kräver att du utvecklar mot en befintlig resurs som körs i Azure. Multitenantmodellen för automatisering av resursdistribution av förbrukningslogikappar baseras på Azure Resource Manager-mallar (ARM-mallar) som kombinerar och hanterar resursetablering för både appar och infrastruktur.

Med standardlogikappresursen blir distributionen enklare eftersom du kan separera appdistributionen från infrastrukturdistributionen. Du kan paketera körmiljön för den enkelklient Azure Logic Apps och dina arbetsflöden tillsammans som en del av din logikapplikationsresurs eller ditt projekt. Du kan använda allmänna steg eller uppgifter som skapar, monterar och zippar dina logikappresurser i färdiga artefakter. För att distribuera infrastrukturen kan du fortfarande använda ARM-mallar för att separat skapa de resurser tillsammans med andra processer och pipelines som du använder för dessa ändamål.

Om du vill distribuera din app kopierar du artefakterna till värdmiljön och startar sedan dina appar för att köra dina arbetsflöden. Eller integrera artefakterna i distributionspipelines med hjälp av de verktyg och processer som du redan känner till och använder. På så sätt kan du distribuera med dina egna valda verktyg, oavsett vilken teknikstack du använder för utveckling.

Genom att använda standardversions- och distributionsalternativ kan du fokusera på apputveckling separat från infrastrukturdistribution. Därför får du en mer allmän projektmodell där du kan använda många liknande eller samma distributionsalternativ som du använder för en allmän app. Du kan också dra nytta av en mer konsekvent upplevelse när du skapar distributionspipelines för dina appar och när du kör nödvändiga tester och valideringar innan du publicerar till produktion.

Prestanda

Med en standardlogikapp kan du skapa och köra flera arbetsflöden i samma enskild logikappresurs och klientorganisation. Med den här 1-till-många-mappningen delar dessa arbetsflöden resurser, till exempel beräkning, bearbetning, lagring och nätverk, vilket ger bättre prestanda på grund av deras närhet.

Standard logic app-resursen och Azure Logic Apps-körningen med en enda klientorganisation ger ytterligare en betydande förbättring genom att göra de mer populära hanterade anslutningsapparna tillgängliga som inbyggda anslutningsåtgärder. Du kan till exempel använda inbyggda anslutningsåtgärder för Azure Service Bus, Azure Event Hubs, SQL Server och andra. Under tiden är de hanterade anslutningsversionerna fortfarande tillgängliga och fortsätter att fungera.

När du använder de nya inbyggda anslutningsåtgärderna skapar du anslutningar som kallas inbyggda anslutningar eller tjänstleverantörsanslutningar. Deras hanterade anslutningsmotsvarigheter kallas API-anslutningar, som skapas och körs separat som Azure-resurser som du också måste distribuera med hjälp av ARM-mallar. Inbyggda åtgärder och deras anslutningar körs lokalt i samma process som kör dina arbetsflöden. Båda finns på Azure Logic Apps-körningen med en enda klientorganisation. Därför ger inbyggda åtgärder och deras anslutningar bättre prestanda på grund av närheten till dina arbetsflöden. Den här designen fungerar också bra med distributionsflöden eftersom kopplingarna till tjänstleverantören paketeras i samma byggartefakt.

Dataresidens

Standardresurser för logikappar finns i Azure Logic Apps med en enda klientorganisation, som inte lagrar, bearbetar eller replikerar data utanför den region där du distribuerar dessa logikappresurser, vilket innebär att data i dina arbetsflöden finns kvar i samma region där du skapar och distribuerar deras överordnade resurser.

Direktåtkomst till resurser i virtuella Azure-nätverk

Arbetsflöden som körs i azure logic apps med en enda klientorganisation kan direkt komma åt skyddade resurser som virtuella datorer (VM), andra tjänster och system som finns i ett virtuellt Azure-nätverk.

Azure Logic Apps för enskild klientorganisation är en dedikerad instans av Azure Logic Apps-tjänsten, använder avsedda resurser och körs separat från flerklientlösningen av Azure Logic Apps. Att köra arbetsflöden i en dedikerad instans hjälper till att minska de effekter som andra Azure-klienter kan ha på appens prestanda, även kallat "bullriga grannar"-effekten.

Azure Logic Apps för en klientorganisation ger också följande fördelar:

• Dina egna statiska IP-adresser, som är separata från de statiska IP-adresser som delas mellan logikapparna i Azure Logic Apps för flera användare. Du kan också konfigurera en enda offentlig, statisk och förutsägbar utgående IP-adress för att kommunicera med målsystem. På så sätt behöver du inte konfigurera extra brandväggsöppningar på dessa målsystem.

• Ökade gränser för körningens varaktighet, lagringsbevarande, dataflöde, tidsgräns för HTTP-begäranden och svar, meddelandestorlekar och anpassade anslutningsbegäranden. Mer information finns i Gränser och konfiguration för Azure Logic Apps.

Skapa, skapa och distribuera alternativ

Om du vill skapa en logikappresurs baserat på den miljö du vill använda har du flera alternativ, till exempel:

Miljö för enskild klientorganisation

Alternativ	Resurser och verktyg	Mer information
Azure Portal	Standard-logikapp	Skapa ett exempel på ett standardarbetsflöde för logikappar i Azure Logic Apps med en enda klient – Azure Portal
Visual Studio-koden	Tillägg för Azure Logic Apps (Standard)	Skapa ett exempel på ett standardarbetsflöde för logikappar i Azure Logic Apps med en enda klientorganisation – Visual Studio Code
Azure CLI (kommandoradsgränssnittet för Azure)	Logic Apps Azure CLI-tillägg	az logicapp
Azure Resource Manager	- Lokal - DevOps	Azure Logic Apps för en klientorganisation
Azure Arc-aktiverade Logic Apps	Azure Arc-aktiverat Logic Apps-exempel	- Vad är Azure Arc-stödda Logic Apps? - Skapa och distribuera arbetsflöden för en klientbaserad logikapp med Azure Arc-aktiverade Logic Apps
REST-API för Azure	Azure App Service REST API* Obs! Rest-API:et för standardlogikappen ingår i Rest-API:et för Azure App Service.	Kom igång med Azure REST API-referens

Miljö för flera klientorganisationer

Alternativ	Resurser och verktyg	Mer information
Azure Portal	Konsumtionslogikapp	Snabbstart: Skapa ett exempel på arbetsflöde för konsumtionslogikapp i Azure Logic Apps med flera klientorganisationer – Azure-portalen
Visual Studio-koden	Tillägg för Azure Logic Apps (förbrukning)	Snabbstart: Skapa ett exempel på arbetsflöde för förbrukningslogikapp i Azure Logic Apps med flera klientorganisationer – Visual Studio Code
Azure CLI (kommandoradsgränssnittet för Azure)	Logic Apps Azure CLI-tillägg	- Snabbstart: Skapa och hantera arbetsflöden för förbrukningslogikapp i Azure Logic Apps med flera klienter – Azure CLI - az logic
Azure Resource Manager	Skapa en ARM-mall för logikappen	Snabbstart: Skapa och distribuera arbetsflöden för konsumtionslogikapp i Azure Logic Apps – ARM-mall med flera klienter
Azure PowerShell	Az.LogicApp-modul	Kom igång med Azure PowerShell
REST-API för Azure	Azure Logic Apps REST API	Kom igång med Azure REST API-referens

Även om dina utvecklingsupplevelser skiljer sig åt beroende på om du skapar resurser för förbrukning eller standardlogikapp kan du hitta och komma åt alla dina distribuerade logikappar under din Azure-prenumeration.

I Azure-portalen visar sidan Logikappar både Förbrukning- och Standard-logikappresurser. I Visual Studio Code visas distribuerade logikappar under din Azure-prenumeration, men Förbrukningslogikappar visas i Azure-fönstret under Tillägget Azure Logic Apps (Förbrukning), medan Standard-logikappar visas under avsnittet Resurser .

Tillståndsbaserade och tillståndslösa arbetsflöden

I en standardlogikapp kan du skapa följande arbetsflödestyper:

• Stateful

  Skapa ett tillståndsbärande arbetsflöde när du behöver behålla, granska eller hänvisa till data från tidigare händelser. Dessa arbetsflöden sparar alla åtgärders indata, utdata och tillstånd till extern lagring. Den här informationen gör det möjligt att granska arbetsflödets körningsinformation och historik när varje körning har slutförts. Tillståndskänsliga arbetsflöden ger hög återhämtning om avbrott inträffar. När tjänster och system har återställts kan du rekonstruera avbrutna körningar från det sparade tillståndet och köra arbetsflödena igen. Tillståndskänsliga arbetsflöden kan fortsätta köras längre än tillståndslösa arbetsflöden.

  Som standard körs tillståndskänsliga arbetsflöden i både Azure Logic Apps för flera klienter och en klientorganisation asynkront. Alla HTTP-baserade åtgärder följer standardmönstret för asynkrona åtgärder. När en HTTP-åtgärd anropar eller skickar en begäran till en slutpunkt, tjänst, system eller API returnerar begärandemottagaren omedelbart svaret "202 ACCEPTED" . Den här koden bekräftar att mottagaren accepterade begäran men inte är klar med bearbetningen. Svaret kan innehålla en location rubrik som anger URI:n och ett uppdaterings-ID som anroparen kan använda för att avsöka eller kontrollera statusen för den asynkrona begäran tills mottagaren slutar bearbeta och returnerar ett "200 OK" -svar eller annat icke-202-svar. Anroparen behöver dock inte vänta på att begäran ska slutföra bearbetningen och kan fortsätta att köra nästa åtgärd. Mer information finns i Asynkron mikrotjänstintegrering framtvingar mikrotjänstautonomi.

• Statslös

  Skapa ett tillståndslöst arbetsflöde när du inte behöver behålla, granska eller referera till data från tidigare händelser i extern lagring när varje körning har slutförts för senare granskning. Dessa arbetsflöden sparar alla indata och utdata för varje åtgärd och deras tillstånd endast i minnet, inte i extern lagring. Därför har tillståndslösa arbetsflöden kortare körningar som vanligtvis avslutas på 5 minuter eller mindre, snabbare prestanda med snabbare svarstider, högre dataflöde och minskade driftskostnader eftersom extern lagring inte sparar arbetsflödets körningsinformation och historik. Men om avbrott inträffar återställs inte avbrutna körningar automatiskt, så anroparen måste skicka avbrutna körningar manuellt igen.

  Ett tillståndslöst arbetsflöde ger bästa prestanda vid hantering av data eller innehåll som inte överstiger 64 KB i total storlek, till exempel en fil. Större innehållsstorlekar, till exempel flera stora bifogade filer, kan avsevärt försämra arbetsflödets prestanda eller till och med orsaka att arbetsflödet kraschar på grund av undantag om slut på minne. Om arbetsflödet kan behöva hantera större innehållsstorlekar använder du ett tillståndskänsligt arbetsflöde i stället.

  Kommentar

  I tillståndslösa arbetsflöden kan du bara använda push-utlösare där du inte anger något schema för körning för arbetsflödet. Dessa webhook-baserade utlösare väntar på att en händelse inträffar eller att data blir tillgängliga. Upprepningsutlösaren är till exempel endast tillgänglig för tillståndskänsliga arbetsflöden. Starta arbetsflödet genom att välja en push-utlösare, till exempel utlösaren Request, Event Hubs eller Service Bus. Mer information om begränsade, otillgängliga eller ej stödda utlösare, åtgärder och anslutningsappar finns i Ändrade, begränsade, otillgängliga eller funktioner som inte stöds.

  Tillståndslösa arbetsflöden körs endast synkront, så de använder inte standardmönstret för asynkrona åtgärder som används av tillståndskänsliga arbetsflöden. I stället fortsätter alla HTTP-baserade åtgärder som returnerar ett "202 ACCEPTED" -svar till nästa steg i arbetsflödeskörningen. Om svaret innehåller en location rubrik avsöks inte den angivna URI:n av ett tillståndslöst arbetsflöde för att kontrollera statusen. Om du vill följa standardmönstret för asynkrona åtgärder använder du ett tillståndskänsligt arbetsflöde i stället.

  För enklare felsökning kan du aktivera körningshistorik för ett tillståndslöst arbetsflöde, vilket påverkar prestandan, och sedan inaktivera körningshistoriken när du är klar. Mer information finns i Skapa enklientbaserade arbetsflöden i Visual Studio Code eller Skapa arbetsflöden med en klientorganisation i Azure Portal.

Viktigt!

Du måste bestämma vilken arbetsflödestyp, antingen tillståndskänslig eller tillståndslös, som ska implementeras när du skapar. Ändringar av arbetsflödestypen efter skapande resulterar i körningsfel.

Sammanfattningsskillnader mellan tillståndskänsliga och tillståndslösa arbetsflöden

Tillståndskänsliga	Tillståndslös
Lagrar körningshistorik, indata och utdata	Lagrar inte körningshistorik, indata eller utdata som standard
Utlösare för hanterade anslutningsappar är tillgängliga och tillåtna	Utlösare för hanterade anslutningar är inte tillgängliga eller inte tillåtna
Stödjer segmentering	Inget stöd för segmentering
Stöder asynkrona åtgärder	Inget stöd för asynkrona åtgärder
Redigera standardlängden för maximal körning i värdkonfigurationen	Bäst för arbetsflöden med maximal varaktighet under 5 minuter
Hanterar stora meddelanden	Bäst för att hantera små meddelandestorlekar (under 64 KB)

Kapslade beteendeskillnader mellan tillståndskänsliga och tillståndslösa arbetsflöden

Du kan göra ett arbetsflöde anropsbart från andra arbetsflöden som finns i samma standardlogikapp med hjälp av utlösaren Förfrågning, HTTP Webhook-utlösare eller hanterade anslutningsutlösare som har typen ApiConnectionWebhook och kan ta emot HTTPS-begäranden.

I följande lista beskrivs de beteendemönster som kapslade arbetsflöden kan följa efter att ett överordnat arbetsflöde anropar ett underordnat arbetsflöde:

• Asynkront sonderingsmönster

  Det överordnade arbetsflödet väntar inte på att det underordnade arbetsflödet ska svara på dess första anrop. Den överordnade kontrollerar dock kontinuerligt barnets körningshistorik tills barnet har avslutat sin körning. Som standard följer tillståndskänsliga arbetsflöden det här mönstret, vilket är idealiskt för långvariga underordnade arbetsflöden som kan överskrida tidsgränsen för begäran.

• Synkront mönster ("eld och glöm")

  Det underordnade arbetsflödet bekräftar det överordnade arbetsflödets anrop genom att omedelbart returnera ett 202 ACCEPTED svar. Föräldern väntar dock inte på att barnet ska returnera resultat. I stället fortsätter föräldern till nästa steg i arbetsflödet och får resultaten när barnet har avslutat körningen. Underordnade tillståndskänsliga arbetsflöden som inte inkluderar en Svars-åtgärd följer alltid det synkrona mönstret och tillhandahåller en körningshistorik som du kan granska.

  Om du vill aktivera det här beteendet i arbetsflödets JSON-definition anger du operationOptions egenskapen till DisableAsyncPattern. Mer information finns i Utlösar- och åtgärdstyper – Åtgärdsalternativ.

• Utlösare och vänta

  Tillståndslösa arbetsflöden körs i minnet. Så när ett överordnat arbetsflöde anropar ett underordnat tillståndslöst arbetsflöde väntar den överordnade användaren på ett svar som returnerar resultatet från det underordnade. Det här mönstret fungerar på samma sätt som den inbyggda HTTP-utlösaren eller åtgärden för att anropa ett underordnat arbetsflöde. Underordnade tillståndslösa arbetsflöden som inte innehåller en svarsåtgärd returnerar omedelbart ett 202 ACCEPTED svar, men den överordnade väntar på att barnet ska slutföras innan nästa åtgärd fortsätter. Dessa beteenden gäller endast för underordnade tillståndslösa arbetsflöden.

I följande tabell identifieras det underordnade arbetsflödets beteende baserat på om över- och underordnad är tillståndskänsliga, tillståndslösa eller är blandade arbetsflödestyper. Listan efter tabellen

Överordnat arbetsflöde	Underliggande arbetsflöde	Barnbeteende
Tillståndskänsliga	Tillståndskänsliga	Asynkron eller synkron med "operationOptions": "DisableAsyncPattern" inställning
Tillståndskänsliga	Tillståndslös	Utlösare och vänta
Tillståndslös	Tillståndskänsliga	Synkront
Tillståndslös	Tillståndslös	Utlösare och vänta

Andra modellfunktioner för en klientorganisation

Enkelhyresgästsmodellen och Standard-logikappen innehåller många aktuella och nya funktioner, till exempel:

• Skapa logikappar och deras arbetsflöden från över 1 400 hanterade anslutningsappar för SaaS (Software-as-a-Service) och PaaS-appar (Plattform som en tjänst) samt anslutningsappar för lokala system.

  • Fler hanterade anslutningar är nu tillgängliga som inbyggda anslutningar i standardarbetsflöden. De inbyggda versionerna körs naturligt på Azure Logic Apps-körningsmiljön med en enda klientorganisation. Vissa inbyggda kontakter kallas även informellt för tjänstleverantörkontakter. För en lista, se Inbyggda anslutningar i Förbrukning och Standard.

  • Du kan skapa egna anpassade inbyggda kopplingar för alla tjänster du behöver med hjälp av Azure Logic Apps utbyggnadsramverk för enskilda klienter. På samma sätt som inbyggda anslutningsappar som Azure Service Bus och SQL Server ger anpassade inbyggda anslutningsappar högre dataflöde, låg svarstid och lokal anslutning eftersom de körs i samma process som körningen med en klientorganisation. Anpassade inbyggda anslutningsappar liknar dock inte anpassade hanterade anslutningsappar, som för närvarande inte stöds. Mer information finns i Översikt över anpassad anslutning och Skapa anpassade inbyggda anslutare för standardlogikappar i enskild klientorganisation av Azure Logic Apps.

  • Du kan använda följande åtgärder för Liquid Operations och XML-åtgärder utan ett integrationskonto. Dessa åtgärder omfattar följande åtgärder:

    • XML: Transformera XML, XML-validering, XML-sammansättning med schema och XML-parsning med schema

    • Flytande: Transformera JSON till JSON, transformera JSON till TEXT, transformera XML till JSON och transformera XML till text

    Kommentar

    Om du vill använda dessa åtgärder i Standard-arbetsflöden måste du ha Liquid-kartor, XML-kartor eller XML-scheman. Du kan ladda upp dessa artefakter i Azure Portal från logikappens resursmeny under Artefakter, som innehåller avsnitten Scheman och Kartor. Eller så kan du lägga till dessa artefakter i visual Studio Code-projektets artefaktmapp med hjälp av respektive mappar för Kartor och scheman . Du kan sedan använda dessa artefakter i flera arbetsflöden i samma logikapp.

  • Standardarbetsflöden för logikappar kan utlösas var som helst eftersom Azure Logic Apps genererar signatur för delad åtkomst (SAS) anslutningssträng som dessa logikappar kan använda för att skicka begäranden till slutpunkten för molnanslutningskörning. Azure Logic Apps sparar dessa anslutningssträng med andra programinställningar så att du enkelt kan lagra dessa värden i Azure Key Vault när du distribuerar i Azure.

  • Arbetsflöden för standardlogikappar stöder aktivering av både den systemtilldelade hanterade identiteten och flera användartilldelade hanterade identiteter samtidigt, även om du bara kan välja en identitet att använda i taget. Även om inbyggda tjänstleverantörsbaserade anslutningsappar stöder användning av den systemtilldelade identiteten stöder de flesta för närvarande inte val av användartilldelade hanterade identiteter för autentisering, förutom SQL Server och HTTP-anslutningsappar.

    Kommentar

    Som standard är den systemtilldelade identiteten redan aktiverad för att autentisera anslutningar vid körning. Den här identiteten skiljer sig från autentiseringsuppgifterna eller anslutningssträng som du använder när du skapar en anslutning. Om du inaktiverar den här identiteten kommer anslutningar inte att fungera vid drift. Om du vill visa den här inställningen går du till logikappens meny och väljer Identitet under Inställningar.

• Du kan köra, testa och felsöka logikappar lokalt och deras arbetsflöden i Visual Studio Code-utvecklingsmiljön.

  Innan du kör och testar logikappen kan du göra felsökning enklare genom att lägga till och använda brytpunkter i workflow.json-filen för ett arbetsflöde. Brytpunkter stöds dock endast för åtgärder för närvarande, inte utlösare. Mer information finns i Skapa enklientbaserade arbetsflöden i Visual Studio Code.

• Publicera eller distribuera logikappar direkt och deras arbetsflöden från Visual Studio Code till olika värdmiljöer som Azure och Azure Arc-aktiverade Logic Apps.

• Aktivera funktioner för diagnostikloggning och spårning för logikappen med hjälp av Application Insights när det stöds av inställningarna för din Azure-prenumeration och logikapp.

• Få tillgång till nätverksfunktioner, såsom anslutning och privat integration med virtuella Azure-nätverk, liknande Azure Functions när du skapar och distribuerar dina logikappar med hjälp av Azure Functions Premium-planen. Mer information finns i följande dokumentation:

  • Nätverksalternativ för Azure Functions

  • Azure Logic Apps körs var som helst – Nätverksmöjligheter med Azure Logic Apps

• Återskapa åtkomstnycklar för hanterade anslutningar som används av enskilda arbetsflöden i en Standard logikapp. För den här uppgiften följer du samma steg för en logikapp för konsumtion, men på arbetsflödesnivå, inte på logikappens resursnivå.

Inbyggda kontakter för Standard

Ett Standard-arbetsflöde kan använda många av samma inbyggda anslutningar som ett förbrukningsflöde, men inte alla. Tvärtom har ett standardarbetsflöde många inbyggda kontakter som inte är tillgängliga i ett konsumtionsarbetsflöde.

Ett Standard-arbetsflöde har till exempel både hanterade anslutningsappar och inbyggda anslutningsappar för Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server med flera. Även om ett förbrukningsarbetsflöde inte har samma inbyggda anslutningar, är andra inbyggda anslutningar som Azure API Management och Azure App Services tillgängliga.

I Azure Logic Apps för enskilda klienter kallas inbyggda anslutningsappar med specifika attribut informellt för tjänstleverantörer. Vissa inbyggda anslutningsappar stöder bara ett enda sätt att autentisera en anslutning till den underliggande tjänsten. Andra inbyggda anslutningsverktyg kan erbjuda ett val, till exempel att använda en anslutningssträng, Microsoft Entra-ID eller en hanterad identitet. Alla inbyggda anslutningar körs i samma process som den omdesignade Azure Logic Apps-körmiljön. Mer information finns i den inbyggda anslutningslistan för standardarbetsflöden för logikappar.

Viktigt!

Se till att konfigurera och testa alla tjänstleverantörsbaserade utlösare korrekt för att bekräfta att åtgärden lyckades. En misslyckad tjänstleverantörsbaserad utlösare kan skapa onödig skalning, vilket avsevärt kan öka dina faktureringskostnader. Ett vanligt misstag är till exempel att ange en utlösare utan att ge logikappen behörighet eller åtkomst till målet, till exempel en Service Bus-kö, Azure Storage-blobcontainer och så vidare. Se också till att du övervakar sådana utlösare hela tiden så att du snabbt kan identifiera och åtgärda eventuella problem.

Ändrade, begränsade, otillgängliga eller funktioner som inte stöds

För arbetsflödet för standardlogikappen är följande funktioner olika, för närvarande begränsade, otillgängliga eller stöds inte:

• Utlösare och åtgärder: Inbyggda utlösare och åtgärder körs internt i Azure Logic Apps, medan hanterade anslutningsappar hanteras och körs med delade resurser i Azure. För Standard-arbetsflöden är vissa inbyggda utlösare och åtgärder för närvarande inte tillgängliga, till exempel Azure App Service-åtgärder. Om du vill starta ett tillståndskänsligt eller tillståndslöst arbetsflöde använder du en inbyggd utlösare, till exempel begäran, händelsehubbar eller Service Bus-utlösare. Upprepningsutlösaren är tillgänglig för tillståndskänsliga arbetsflöden, men inte tillståndslösa arbetsflöden. I anslutningsgalleriet visas inbyggda utlösare och åtgärder när du väljer inbyggt filtret, medan hanterade anslutningars utlösare och åtgärder visas när du väljer delat filtret.

  Tillståndslösa arbetsflöden kan bara använda push-utlösare där du inte anger något schema för körning av arbetsflödet. Dessa webhook-baserade utlösare väntar på att en händelse inträffar eller att data blir tillgängliga. Upprepningsutlösaren är till exempel endast tillgänglig för tillståndskänsliga arbetsflöden. Starta arbetsflödet genom att välja en push-utlösare, till exempel utlösaren Request, Event Hubs eller Service Bus. Även om du kan aktivera hanterade anslutningsappar för tillståndslösa arbetsflöden, visar inte anslutningsgalleriet några avsökningsutlösare för hanterade anslutningsappar som du kan lägga till.

  Kommentar

  Om du vill köra lokalt i Visual Studio Code kräver webhook-baserade utlösare och åtgärder ytterligare konfiguration. Mer information finns i Skapa enklientbaserade arbetsflöden i Visual Studio Code.

  • Följande utlösare och åtgärder har antingen ändrats eller är för närvarande begränsade, stöds inte eller är otillgängliga:

    • Den inbyggda åtgärden Azure Functions – Välj en Azure-funktion är nu Azure Functions Operations – Anropa en Azure-funktion. Den här åtgärden fungerar för närvarande endast för funktioner som skapas från HTTP-utlösarmallen .

      I Azure Portal kan du välja en HTTP-utlösarfunktion som du kan komma åt genom att skapa en anslutning via användarupplevelsen. Om du inspekterar funktionsåtgärdens JSON-definition i kodvyn eller den workflow.json filen med hjälp av Visual Studio Code refererar åtgärden till funktionen med hjälp av en connectionName referens. Den här versionen sammanfattar funktionens information som en anslutning, som du hittar i logikappprojektets connections.json-fil , som är tillgänglig när du har skapat en anslutning i Visual Studio Code.

      Kommentar

      I single-tenant-modellen stöder funktionsåtgärden endast frågesträngsautentisering. Azure Logic Apps hämtar standardnyckeln från funktionen när du upprättar anslutningen, lagrar den nyckeln i appens inställningar och använder nyckeln för autentisering när du anropar funktionen.

      Precis som i multitenantmodellen fungerar funktionsåtgärden inte längre på grund av den ogiltiga nyckeln om du förnyar den här nyckeln, till exempel via Azure Functions-upplevelsen i portalen. För att åtgärda det här problemet måste du återskapa anslutningen till den funktion som du vill anropa eller uppdatera appens inställningar med den nya nyckeln.

    • Den inbyggda åtgärden Inline Code byts namn till Inline Code Operations, kräver inte längre ett integrationskonto och har uppdaterade gränser.

    • Den inbyggda åtgärden Azure Logic Apps – Välj ett logic app-arbetsflöde är nu Arbetsflödesåtgärder – Anropa ett arbetsflöde i den här arbetsflödesappen.

    • Ett Standard-arbetsflöde kan bara ha en utlösare och stöder inte flera utlösare.

• Autentisering

  • Vissa begärandebaserade utlösare som hanterar inkommande anrop, till exempel begärandeutlösaren, stöder för närvarande inte Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), medan andra som HTTP Webhook-utlösaren har det här stödet.

  • Vissa inbyggda tjänstleverantörsbaserade anslutningsappar stöder för närvarande inte val av användartilldelad hanterad identitet för autentisering. Både systemtilldelade och användartilldelade hanterade identiteter är allmänt tillgängliga. Som standard aktiveras den systemtilldelade hanterade identiteten automatiskt.

• Felsökning av brytpunkt i Visual Studio Code: Även om du kan lägga till och använda brytpunkter i workflow.json-filen för ett arbetsflöde, stöds brytpunkter endast för åtgärder just nu, inte utlösare. Mer information finns i Skapa enklientbaserade arbetsflöden i Visual Studio Code.

• Utlösarhistorik och körningshistorik: För ett standardarbetsflöde för logikappar visas utlösarhistorik och körningshistorik i Azure Portal på arbetsflödesnivå, inte på resursnivå för logikappen. För mer information, granska Skapa ett klientbaserat arbetsflöde med hjälp av Azure Portal.

• Terraform-mallar: Du kan inte använda dessa mallar med en standardlogikappresurs för fullständig infrastrukturdistribution. Mer information finns i Vad är Terraform i Azure?

Strikta nätverks- och brandväggstrafikbehörigheter

Om din miljö har strikta nätverkskrav eller brandväggar som begränsar trafiken måste du tillåta åtkomst för utlösar- eller åtgärdsanslutningar i dina arbetsflöden. Du kan också tillåta trafik från tjänsttaggar och använda samma nivå av begränsningar eller principer som Azure App Service. Du måste också hitta och använda de fullständigt kvalificerade domännamnen (FQDN) för dina anslutningar. Mer information finns i motsvarande avsnitt i följande dokumentation:

• Brandväggsbehörigheter för logikappar för en enda klient – Azure-portalen
• Brandväggsbehörigheter för logikappar för enskild klientorganisation – Visual Studio Code

Nästa steg

• Skapa enkla klientbaserade arbetsflöden i Azure-portalen
• Skapa single-tenant-baserade arbetsflöden i Visual Studio Code

Vi vill också höra om dina erfarenheter med single-tenant Azure Logic Apps!

• För buggar eller problem skapar du dina problem i GitHub.
• För frågor, begäranden, kommentarer och annan feedback använder du det här feedbackformuläret.