Tjänstmiljö för enskild klientorganisation jämfört med flera klientorganisationer och integreringstjänst för Azure Logic Apps

Artikel
03/10/2023
24 minuter för att läsa

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 integrationslösningar för dina B2B-scenarier (företag och företag till företag). Om du vill skapa en logikapp använder du antingen resurstypen Logikapp (förbrukning) eller resurstypen Logikapp (Standard ). Resurstypen Förbrukning körs i Azure Logic Apps eller integrationstjänstmiljön för flera klientorganisationer, medan standardresurstypen körs i Azure Logic Apps-miljön med en enda klientorganisation.

Innan du väljer vilken resurstyp du vill använda kan du läsa den här artikeln för att lära dig hur resurstyperna och tjänstmiljöerna skiljer sig från varandra. Sedan kan du bestämma vilken typ som passar bäst för ditt scenarios behov, lösningskrav och miljön där du vill distribuera och köra dina arbetsflöden.

Om du inte har använt Azure Logic Apps tidigare kan du läsa följande dokumentation:

Resurstyper och miljöer

Om du vill skapa arbetsflöden för logikappar väljer du resurstypen Logikapp baserat på ditt scenario, lösningskrav, de funktioner du vill använda och den miljö där du vill köra dina arbetsflöden.

I följande tabell sammanfattas kort skillnaderna mellan resurstypen Logikapp (Standard) och resurstypen Logikapp (förbrukning). Du får också lära dig hur miljön för en enskild klient skiljer sig från miljön för flera klientorganisationer och integrationstjänstmiljön (ISE) för distribution, värdhantering och körning av logikappens arbetsflöden.

Resurstyp	Fördelar	Resursdelning och -användning	Pris- och faktureringsmodell	Begränsningshantering
Logikapp (förbrukning) Värdmiljö: Azure Logic Apps för flera klientorganisationer	– Enklast att komma igång – Betala för vad du använder – Fullständigt hanterad	En enda logikapp kan bara ha ett arbetsflöde. Logikappar i Azure Active Directory-klientorganisationer 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.
Logikapp (förbrukning) Värdmiljö: Integration Service Environment (ISE)	– Företagsskala för stora arbetsbelastningar – Över 20 ISE-specifika anslutningsappar som ansluter direkt till virtuella nätverk – Förutsägbar prissättning med inkluderad användning och kundkontrollerad skalning	En enda logikapp kan bara ha ett arbetsflöde. Logikappar i samma miljö delar samma bearbetning (beräkning), lagring, nätverk och så vidare. Data finns kvar i samma region där du distribuerar ISE.	ISE (fast)	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.
Logikapp (standard) Värdmiljö: Azure Logic Apps för enskild klientorganisation Obs! Om ditt scenario kräver containrar skapar du logikappar baserade på en klientorganisation med Hjälp av Azure Arc-aktiverade Logic Apps. Mer information finns i Vad är Azure Arc-aktiverat Logic Apps?	– Kör med Azure Logic Apps-körningen för en enskild klientorganisation. Distributionsfack stöds inte för närvarande. – Fler inbyggda anslutningsappar 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 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.	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 maxgränser. I Visual Studio Code visas inte de ändringar du gör i standardgränsvärdena i konfigurationsfilerna för logikappsprojektet i designerupplevelsen. Mer information finns i Redigera app- och miljöinställningar för logikappar i Azure Logic Apps med en enda klientorganisation.
Logikapp (standard) Värdmiljö: App Service-miljön v3 (ASEv3) – Endast Windows-planer	Samma funktioner som en enskild klientorganisation plus följande fördelar: – Isolera logikapparna fullständigt. – Skapa och kör fler logikappar än i Azure Logic Apps med en enda klientorganisation. – Betala endast för ASE-App Service plan, oavsett antalet logikappar som du skapar och kör. – Kan aktivera automatisk skalning eller skala manuellt med fler instanser av virtuella datorer eller en annan App Service plan. – Ärv nätverkskonfigurationen från den valda ASEv3. När arbetsflöden till exempel distribueras till en intern ASE kan de komma åt resurserna i ett virtuellt nätverk som är associerat med ASE och ha interna åtkomstpunkter. Obs! Om du kommer åt utanför en intern ASE kör du historik för arbetsflöden i den ASE:en som 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 maxgränser. I Visual Studio Code visas inte de ändringar du gör i standardgränsvärdena i konfigurationsfilerna för logikappsprojektet i designerupplevelsen. Mer information finns i Redigera app- och miljöinställningar för logikappar i Azure Logic Apps med en enda klientorganisation.

Logikappresurs (standard)

Resurstypen Logic App (Standard) drivs av den omdesignade Azure Logic Apps-körningen för en enskild klientorganisation. Den här körningen använder Azure Functions utökningsmodell och finns som ett tillägg på 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 ärvts från Azure Functions-plattformen och Azure App Service ekosystem. Du kan till exempel skapa, distribuera och köra logikappar baserade på en klientorganisation och deras arbetsflöden i Azure App Service Environment v3 (endast Windows-planer).

Resurstypen Standard introducerar en resursstruktur som kan vara värd för flera arbetsflöden, ungefär som 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 logikappresursen (förbrukning) där du har en 1-till-1-mappning mellan en logikappresurs och ett arbetsflöde.

Om du vill veta mer om portabilitet, flexibilitet och prestandaförbättringar kan du fortsätta med följande avsnitt. Mer information om Azure Logic Apps-körningen för en klient och Azure Functions utökningsbarhet finns i följande dokumentation:

Portabilitet och flexibilitet

När du skapar logikappar med hjälp av resurstypen Logikapp (Standard) kan du distribuera och köra dina arbetsflöden i andra miljöer, till exempel Azure App Service Environment 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 dina arbetsflöden i utvecklingsmiljön utan att behöva distribuera till Azure. Om ditt scenario kräver containrar skapar du logikappar baserade på en klientorganisation med Hjälp av Azure Arc-aktiverade Logic Apps. Mer information finns i Vad är Azure Arc-aktiverat 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. Dessutom baseras modellen för flera klientorganisationer för automatisering av resursdistribution av logikappar (förbrukning) på Azure Resource Manager-mallar (ARM-mallar), som kombinerar och hanterar resursetablering för både appar och infrastruktur.

Med resurstypen Logikapp (Standard) blir distributionen enklare eftersom du kan separera appdistributionen från infrastrukturdistributionen. Du kan paketera Azure Logic Apps-körningen och arbetsflödena med en enda klient som en del av din logikapp. 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 etablera resurserna separat 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 standardalternativ för kompilering och distribution 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 hjälp av resurstypen Logikapp (Standard) kan du skapa och köra flera arbetsflöden i samma 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.

Resurstypen Logic App (Standard) och Azure Logic Apps-körning 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 åtgärder. Du kan till exempel använda inbyggda åtgärder för Azure Service Bus, Azure Event Hubs, SQL och andra. Under tiden är de hanterade anslutningsversionerna fortfarande tillgängliga och fortsätter att fungera.

När du använder de nya inbyggda åtgärderna skapar du anslutningar som kallas inbyggda anslutningar eller tjänstleverantörsanslutningar. Deras hanterade anslutningsmotparter 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 i 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örsanslutningarna paketeras i samma byggartefakt.

Dataplacering

Logikappresurser som skapas med resurstypen Logikapp (Standard) 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 logikappens 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 antingen Azure Logic Apps (Standard) eller en integrationstjänstmiljö (ISE) kan komma åt skyddade resurser som virtuella datorer, andra tjänster och system som finns i ett virtuellt Azure-nätverk. Både Azure Logic Apps (Standard) och en ISE är dedikerade instanser av Azure Logic Apps-tjänsten som använder dedikerade resurser och körs separat från den globala Azure Logic Apps-tjänsten för flera klientorganisationer.

Genom att köra logikappar i din egen dedikerade instans kan du minska den inverkan som andra Azure-klientorganisationer kan ha på appens prestanda, även kallat effekten "bullriga grannar".

Azure Logic Apps (Standard) och en ISE 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 tjänsten för 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 för varje ISE.
Ökade gränser för körningens varaktighet, kvarhållning av lagring, dataflöde, tidsgränser för HTTP-begäranden och svar, meddelandestorlekar och anpassade anslutningsbegäranden. Mer information finns i Begränsningar och konfiguration för Azure Logic Apps.

Skapa, skapa och distribuera alternativ

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

Miljö för en enda klientorganisation

Alternativ	Resurser och verktyg	Mer information
Azure Portal	Resurstyp för logikapp (standard)	Skapa ett exempel på ett standardarbetsflöde för logikappar i Azure Logic Apps med en enda klient – Azure Portal
Visuell Studio-kod	Azure Logic Apps-tillägg (standard)	Skapa ett exempel på ett standardarbetsflöde för logikappar i Azure Logic Apps med en enda klientorganisation – Visual Studio Code
Azure CLI	Azure CLI-tillägg för Logic Apps	az logicapp
Azure Resource Manager	- Lokala - DevOps	Azure Logic Apps för enskild klientorganisation
Azure Arc-aktiverade Logic Apps	Azure Arc-aktiverat Logic Apps-exempel	- Vad är Azure Arc-aktiverade Logic Apps? - Skapa och distribuera logikappsarbetsflöden baserade på en klientorganisation med Azure Arc-aktiverade Logic Apps

Miljö för flera klientorganisationer

Alternativ	Resurser och verktyg	Mer information
Azure Portal	Resurstyp för logikapp (förbrukning)	Snabbstart: Skapa ett exempel på ett arbetsflöde för förbrukningslogikapp i Azure Logic Apps för flera klientorganisationer – Azure Portal
Visuell Studio-kod	Azure Logic Apps-tillägg (förbrukning)	Snabbstart: Skapa ett exempel på ett arbetsflöde för förbrukningslogikapp i Azure Logic Apps för flera klientorganisationer – Visual Studio Code
Azure CLI	Azure CLI-tillägg för Logic Apps	- Snabbstart: Skapa och hantera arbetsflöden för förbrukningslogikapp i Azure Logic Apps för flera klientorganisationer – Azure CLI - az logic
Azure Resource Manager	Skapa en logikapp ARM-mall	Snabbstart: Skapa och distribuera arbetsflöden för förbrukningslogikapp i Azure Logic Apps för flera klientorganisationer – ARM-mall
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

Integrationstjänstmiljö

Alternativ	Resurser och verktyg	Mer information
Azure Portal	Resurstyp för logikapp (förbrukning) med en befintlig ISE-resurs	Samma som snabbstart: Skapa ett exempel på ett arbetsflöde för förbrukningslogikapp i Azure Logic Apps för flera klientorganisationer – Azure Portal, men välj en ISE, inte en region för flera klientorganisationer.

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

I Azure Portal visar sidan Logikappar till exempel resurstyperna Förbrukning och Standardlogikapp. I Visual Studio Code visas distribuerade logikappar under din Azure-prenumeration, men de grupperas efter det tillägg som du använde, nämligen Azure: Logic Apps (Förbrukning) och Azure: Logic Apps (Standard).

Tillståndskänsliga och tillståndslösa arbetsflöden

Med resurstypen Logikapp (Standard) kan du skapa dessa arbetsflödestyper i samma logikapp:

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 körningsinformationen och historiken för arbetsflödet 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 att köras mycket längre än tillståndslösa arbetsflöden.

Som standard körs tillståndskänsliga arbetsflöden i Azure Logic Apps för både flera klientorganisationer och enskilda klientorganisationer 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 status 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.
Tillståndslö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 slutförs på 5 minuter eller mindre, snabbare prestanda med snabbare svarstider, högre dataflöde och minskade driftskostnader eftersom extern lagring inte sparar information och historik för arbetsflödeskörningen. Om avbrott inträffar återställs dock inte avbrutna körningar automatiskt, så anroparen måste skicka om avbrutna körningar manuellt.

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 minnesbrist. Om arbetsflödet kan behöva hantera större innehållsstorlekar använder du ett tillståndskänsligt arbetsflöde i stället.

I tillståndslösa arbetsflöden är åtgärder för hanterade anslutningsappar tillgängliga, men utlösare för hanterade anslutningsappar är inte tillgängliga. Så om du vill starta arbetsflödet väljer du en inbyggd utlösare i stället, till exempel Request, Event Hubs eller Service Bus-utlösaren. Dessa utlösare körs internt i Azure Logic Apps-körmiljön. Upprepningsutlösaren är inte tillgänglig för tillståndslösa arbetsflöden och är endast tillgänglig för tillståndskänsliga arbetsflöden. Mer information om begränsade, otillgängliga eller icke-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 bara 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 svaret "202 ACCEPTED" 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 arbetsflöden baserade på en klientorganisation i Visual Studio Code eller Skapa arbetsflöden baserade på 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 den skapas. Ändringar i arbetsflödestypen efter skapandet 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 hanterad anslutningsapp är tillgängliga och tillåtna	Utlösare för hanterad anslutningsapp ä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 hantering av 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 logikappresurs (Standard) med hjälp av utlösaren Begäran, HTTP Webhook-utlösare eller utlösare för hanterad anslutningsapp 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å det första anropet. Den överordnade kontrollen kontrollerar dock kontinuerligt barnets körningshistorik tills den underordnade körningen är klar. 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äranden.
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 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 har slutfört körningen. 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 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 det underordnade ska slutföras innan nästa åtgärd fortsätter. Dessa beteenden gäller endast för underordnade tillståndslösa arbetsflöden.

Följande tabell identifierar 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 enda klientorganisation

Resurstypen för en enskild klientorganisation och Logic App (Standard) innehåller många aktuella och nya funktioner, till exempel:

Skapa logikappar och deras arbetsflöden från hundratals hanterade anslutningsappar för SaaS-appar (Programvara som en tjänst) 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 arbetsflöden för standardlogikappar. De inbyggda versionerna körs internt på Azure Logic Apps-körningen med en enda klientorganisation. Vissa inbyggda anslutningsappar kallas även informellt för tjänstleverantörsanslutningar. 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, till exempel 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 för en enda klientorganisation. Anpassade inbyggda anslutningsappar liknar dock inte anpassade hanterade anslutningsappar, som för närvarande inte stöds. Mer information finns i Översikt över anpassade anslutningsappar 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-verifiering
  - Liquid: Transformera JSON till JSON, transformera JSON till TEXT, transformera XML till JSON och transformera XML till text
  Anteckning
  
  Om du vill använda dessa åtgärder i Azure Logic Apps (Standard) för en enskild klientorganisation 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 artifacts-mapp med hjälp av respektive mappar för Kartor och Scheman . Du kan sedan använda dessa artefakter i flera arbetsflöden i samma logikappresurs.
- Logic App-resurser (Standard) kan köras var som helst eftersom Azure Logic Apps genererar SAS-anslutningssträngar (Signatur för delad åtkomst) som dessa logikappar kan använda för att skicka begäranden till slutpunkten för molnanslutningskörningen. Azure Logic Apps-tjänsten sparar dessa anslutningssträngar med andra programinställningar så att du enkelt kan lagra dessa värden i Azure Key Vault när du distribuerar i Azure.
- Resurstypen Logic App (Standard) har stöd för att aktivera den systemtilldelade hanterade identiteten och flera användartilldelade hanterade identiteter samtidigt, men du kan fortfarande bara välja en identitet som ska användas när som helst.
  
  Anteckning
  
  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ängen 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 dina logikappar och deras arbetsflöden lokalt i Visual Studio Code-utvecklingsmiljön.

Innan du kör och testar logikappen kan du göra det enklare att felsöka genom att lägga till och använda brytpunkter i filen workflow.json för ett arbetsflöde. Brytpunkter stöds dock bara för åtgärder just nu, inte utlösare. Mer information finns i Skapa arbetsflöden baserade på en klientorganisation i Visual Studio Code.
Publicera eller distribuera logikappar och deras arbetsflöden direkt 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 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 logikappresurs (Standard). För den här uppgiften följer du samma steg för Logic Apps-resursen (förbrukning), men på enskild arbetsflödesnivå, inte på logikappens resursnivå.

Inbyggda anslutningsappar för Standard

Ett standardarbetsflöde för logikappar har många av samma inbyggda anslutningsappar som ett arbetsflöde för förbrukningslogikappen, men inte alla. Tvärtom har ett standardarbetsflöde för logikappar många inbyggda anslutningsappar som inte är tillgängliga i ett arbetsflöde för förbrukningslogikappen.

Ett standardarbetsflöde för logikappar 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 arbetsflöde för förbrukningslogikappen inte har samma inbyggda anslutningsversioner är andra inbyggda anslutningsappar som Azure API Management, Azure App Services och Batch tillgängliga.

I Azure Logic Apps med en enda 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 alternativ, till exempel att använda en anslutningssträng, Azure Active Directory (Azure AD) 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 arbetsflöden för standardlogikappar.

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

För Logic App-resursen (Standard) 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 finns och körs i Azure. För standardarbetsflöden är vissa inbyggda utlösare och åtgärder för närvarande inte tillgängliga, till exempel Skjutfönster, Batch, 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 som Request, Event Hubs eller Service Bus-utlösaren. 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 på fliken Inbyggd , medan utlösare och åtgärder för hanterade anslutningsappar visas på fliken Azure .

För tillståndslösa arbetsflöden är åtgärder för hanterade anslutningsappar tillgängliga, men utlösare för hanterade anslutningsappar är inte tillgängliga. Azure-fliken visas bara när du kan välja åtgärder för hanterad anslutningsapp. Även om du kan aktivera hanterade anslutningsappar för tillståndslösa arbetsflöden visar designern inte några utlösare för hanterade anslutningsappar som du kan lägga till.

Anteckning

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 arbetsflöden baserade på en klientorganisation i Visual Studio Code.
- Dessa utlösare och åtgärder har antingen ändrats eller är för närvarande begränsade, stöds inte eller är inte tillgängliga:
  - Den inbyggda åtgärden Azure Functions – Välj en Azure-funktion är nu Azure-funktionsåtgärder – 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 filen workflow.json 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.
    
    Anteckning
    
    I modellen med en klientorganisation stöder funktionsåtgärden endast autentisering med frågesträngar. Azure Logic Apps hämtar standardnyckeln från funktionen när du upprättar anslutningen, lagrar nyckeln i appens inställningar och använder nyckeln för autentisering när du anropar funktionen.
    
    Precis som i modellen med flera klientorganisationer fungerar funktionsåtgärden inte längre på grund av den ogiltiga nyckeln om du till exempel förnyar den här nyckeln 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 , Infogad kod, har bytt namn till 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 logikapparbetsflöde är nu Arbetsflödesåtgärder – Anropa ett arbetsflöde i den här arbetsflödesappen.
  - Vissa utlösare och åtgärder för integrationskonton är inte tillgängliga, till exempel ÅTGÄRDERNA AS2 (V2) och RosettaNet.
  - 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 arbetsflöden baserade på en klientorganisation med Visual Studio Code.
Autentisering: Följande autentiseringstyper är för närvarande inte tillgängliga för resurstypen Logikapp (Standard ):
- Azure Active Directory Open Authentication (Azure AD OAuth) för inkommande anrop till begärandebaserade utlösare, till exempel utlösaren Request och HTTP Webhook.
- Användartilldelad hanterad identitet. För närvarande är endast den systemtilldelade hanterade identiteten tillgänglig och aktiverad automatiskt.
XML-transformering: Stöd för att referera till sammansättningar från kartor är för närvarande inte tillgängligt. Dessutom stöds endast XSLT 1.0 för närvarande.
Felsökning av brytpunkt i Visual Studio Code: Även om du kan lägga till och använda brytpunkter i filen workflow.json för ett arbetsflöde stöds brytpunkter endast för åtgärder just nu, inte utlösare. Mer information finns i Skapa arbetsflöden baserade på en klientorganisation i Visual Studio Code.
Utlösarhistorik och körningshistorik: För resurstypen Logikapp (Standard) visas utlösarhistorik och körningshistorik i Azure Portal på arbetsflödesnivå, inte på logikappsnivå. Mer information finns i Skapa arbetsflöden för en enskild klientorganisation med hjälp av Azure Portal.
Zoomkontroll: Zoomkontrollen är för närvarande inte tillgänglig i designern.
Distributionsmål: Du kan inte distribuera resurstypen Logikapp (Standard) till en integrationstjänstmiljö (ISE) eller till Azure-distributionsplatser.
Azure API Management: Du kan för närvarande inte importera resurstypen Logikapp (Standard) till Azure API Management. Du kan dock importera resurstypen Logikapp (förbrukning).

Strikta trafikbehörigheter för nätverk och brandvägg

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 för en enda klientorganisation!

Skapa dina problem i GitHub för buggar eller problem.
Använd det här feedbackformuläret för frågor, begäranden, kommentarer och annan feedback.