Skillnader mellan logikappar med en enda standardklient jämfört med förbrukning av logikappar för flera klientorganisationer

Artikel
10/26/2024

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 förbruknings - eller standardvärdalternativet . 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 ett arbetsflöde för förbrukningslogikappen och standardarbetsflödet för logikappar. 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ö: Azure Logic Apps med flera klientorganisationer	– 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 för en klientorganisation Obs! Om ditt scenario kräver containrar skapar du en klientbaserade logikappar med Azure Arc-aktiverade Logic Apps. Mer information finns i Vad är Azure Arc-aktiverade Logic Apps?	– Fler inbyggda anslutningsappar som finns på körningsmiljön för en enskild klientorganisation för högre dataflöde och lägre kostnader i stor 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 anslutningsappar.	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 Azure Logic Apps med en klientorganisation.
Standard (App Service-miljön v3) Värdmiljö: App Service-miljön v3 (ASEv3) – Endast Windows-planer	Samma funktioner som en klientorganisation plus följande fördelar: – Isolera logikapparna helt. – Skapa och köra fler logikappar än i Azure Logic Apps med en enda klientorganisation. – 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 där du distribuerar dina logikappar.	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 Azure Logic Apps med en klientorganisation.

Standardlogikapp och arbetsflöde

Standardlogikappen och arbetsflödet drivs av den omdesignade Azure Logic Apps-körningen för en enda klientorganisation. Den här körningen använder Utökningsmodellen för Azure Functions och finns som ett tillägg i Azure Functions-körningen. 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. Du kan till exempel skapa, distribuera och köra en klientbaserade logikappar och deras 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 klientorganisationen beräknings- och bearbetningsresurser, vilket ger bättre prestanda på grund av deras närhet. Den här strukturen skiljer sig från förbrukningslogikappresursen 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. Mer information om Azure Logic Apps-körningen med en klientorganisation och utökningsbarhet för Azure Functions finns i följande dokumentation:

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 enskilda klientorganisationer 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 Azure Logic Apps-körningen med en enda klientorganisation och dina arbetsflöden tillsammans som en del av logikappens resurs eller projekt. Du kan använda allmänna steg eller uppgifter som skapar, monterar och zippar dina logikappresurser i färdiga artefakter. Om du vill distribuera infrastrukturen kan du fortfarande använda ARM-mallar för att separat etablera resurserna 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 distributionspipelines eftersom tjänstleverantörens anslutningar 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 en klientorganisation är en dedikerad instans av Azure Logic Apps-tjänsten, använder dedikerade resurser och körs separat från Azure Logic Apps med flera klienter. Att köra arbetsflöden i en dedikerad instans hjälper till att minska den inverkan som andra Azure-klienter kan ha på appprestanda, ä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 av logikapparna i Azure Logic Apps med flera klientorganisationer. 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änser 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	Standardlogikapp	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	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-aktiverade 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	Förbrukningslogikapp	Snabbstart: Skapa ett exempel på arbetsflöde för förbrukningslogikapp i Azure Logic Apps med flera klientorganisationer – Azure Portal
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	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 förbrukningslogikapp i Azure Logic Apps – ARM-mall för flera klientorganisationer
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 Portal visar sidan Logikappar till exempel både förbruknings- och standardlogikappresurser. 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åndskänsliga och tillståndslösa arbetsflöden

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

Stateful

Skapa ett tillståndskänsligt arbetsflöde när du behöver behålla, granska eller referera 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 mycket 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 har slutfört 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 anslutningsappar är inte tillgängliga eller tillåts inte
Stöder 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 avsökningsmönster

Det överordnade arbetsflödet väntar inte på att det underordnade arbetsflödet ska svara på deras första anrop. Den överordnade kontrollerar dock kontinuerligt barnets körningshistorik tills barnet har körts klart. 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. Den överordnade filen väntar dock inte på att det underordnade objektet ska returnera resultat. I stället fortsätter den överordnade åtgärden till nästa åtgärd i arbetsflödet och får resultatet när det underordnade objektet är klart. Underordnade tillståndskänsliga arbetsflöden som inte innehåller 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	Underordnat arbetsflöde	Underordnat beteende
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

Modellen med en klientorganisation och standardlogikappen innehåller många aktuella och nya funktioner, till exempel:

Skapa logikappar och deras arbetsflöden från hundratals 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 anslutningsappar är nu tillgängliga som inbyggda anslutningsappar i Standard-arbetsflöden. De inbyggda versionerna körs internt på Azure Logic Apps-körningen med en enda klientorganisation. Vissa inbyggda anslutningsappar kallas även informellt för anslutningsappar för tjänstleverantörer. En lista finns i Inbyggda anslutningsappar i Förbrukning och Standard.
- Du kan skapa egna anpassade inbyggda anslutningsappar för alla tjänster som du behöver med hjälp av utökningsramverket för Azure Logic Apps med en enda klientorganisation. 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 anslutningsapp och Skapa anpassade inbyggda anslutningsappar för standardlogikappar i Azure Logic Apps med en enda klientorganisation.
- 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- och XML-validering
  - 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 köras 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 fungerar inte anslutningar vid körning. 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 just nu, 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å åtkomst till nätverksfunktioner, till exempel ansluta och integrera privat med virtuella Azure-nätverk, ungefär som i 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 standardlogikapp . För den här uppgiften följer du samma steg för en förbrukningslogikapp , men på arbetsflödesnivå, inte på logikappens resursnivå.

Inbyggda anslutningsappar för Standard

Ett Standard-arbetsflöde kan använda många av samma inbyggda anslutningsappar som ett förbrukningsarbetsflöde, men inte alla. Tvärtom har ett Standard-arbetsflöde många inbyggda anslutningsappar som inte är tillgängliga i ett förbrukningsarbetsflö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 anslutningsversioner är andra inbyggda anslutningsappar som Azure API Management och Azure App Services tillgängliga.

I Azure Logic Apps för en klientorganisation 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 anslutningsappar kan erbjuda ett val, till exempel att använda en anslutningssträng, Microsoft Entra-ID eller en hanterad identitet. Alla inbyggda anslutningsappar körs i samma process som den omdesignade Azure Logic Apps-körningen. 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 har dessa funktioner ändrats, eller så är de 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 skjutfönster, Azure App Service och Azure API Management. 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 designern visas inbyggda utlösare och åtgärder med etiketten In-App , medan utlösare och åtgärder för hanterade anslutningsappar visas med etiketten Delad .

Tillståndslösa arbetsflöden kan endast 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. Ä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 modellen med en klientorganisation 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 byter namn på Infogade kodåtgärder, 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.
  - Gmail-anslutningsappen stöds för närvarande inte.
  - Anpassade hanterade anslutningsappar stöds för närvarande inte. Du kan dock skapa anpassade inbyggda åtgärder när du använder Visual Studio Code. Mer information finns i Skapa enklientbaserade arbetsflöden med Visual Studio Code.
  - Ett standardarbetsflöde för logikappar kan bara ha en utlösare och stöder inte flera utlösare.
Autentisering: Följande autentiseringstyper är för närvarande inte tillgängliga för Standard-arbetsflöden :
- Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) för inkommande anrop till begärandebaserade utlösare, till exempel utlösare för begäran och HTTP Webhook-utlösare.
- Hanterad identitetsautentisering: Stöd för både systemtilldelad och användartilldelad hanterad identitet är tillgänglig. Som standard aktiveras den systemtilldelade hanterade identiteten automatiskt. De flesta inbyggda tjänstleverantörsbaserade anslutningsappar stöder för närvarande inte val av användartilldelade hanterade identiteter för autentisering.
XML-transformering: Endast XSLT 1.0 stöds för närvarande.
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 en standardlogikapp visas utlösarhistorik och körningshistorik i Azure Portal på arbetsflödesnivå, inte på logikappens resursnivå. Mer information finns i Skapa en klientbaserade arbetsflöden med hjälp av Azure Portal.
Säkerhetskopiering och återställning för arbetsflödeskörningshistorik: Standardlogikappar stöder för närvarande inte säkerhetskopiering och återställning för arbetsflödeskörningshistorik.
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?
Azure API Management: Du kan för närvarande inte importera en standardlogikappresurs till Azure API Management. Du kan dock importera en förbrukningslogikappresurs .

Strikt 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:

Nästa steg

Vi vill också höra om dina upplevelser med Azure Logic Apps med en enda klientorganisation!

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.

Dela via