Miljö för en enskild klientorganisation jämfört med flera klienter och integreringstjänst för Azure Logic Apps

Azure Logic Apps är en molnbaserad plattform för att skapa och köra automatiserade arbetsflöden för logikappar 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 (business-to-business). Om du vill skapa en logikapp använder du antingen resurstypen Logikapp (förbrukning) eller resurstypen Logikapp (standard). Resurstypen Förbrukning körs i miljön för Azure Logic Apps klientorganisation eller integreringstjänst, medan resurstypen Standard körs i en Azure Logic Apps klientorganisationsmiljö.

Innan du väljer vilken resurstyp du ska använda kan du läsa den här artikeln för att lära dig hur resurstyperna och tjänstmiljöerna är i jämförelse med varandra. Du kan sedan bestämma vilken typ som är bäst att använda, baserat på scenariots behov, lösningskrav och miljön där du vill distribuera, vara värd för och köra dina arbetsflöden.

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

• Vad är Azure Logic Apps?
• Vad är ett logikapparbetsflöde?

Resurstyper och miljöer

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

I följande tabell sammanfattas kortfattat skillnaderna mellan resurstypen Logic App (Standard) och resurstypen Logikapp (förbrukning). Du får också lära dig hur miljön för en enskild klient kan jämföras med ISE-miljön (Multi-Tenant and Integration Service Environment) för distribution, värdskap och körning av logikappens arbetsflöden.

Logic App-resurs (standard)

Resurstypen Logic App (Standard) drivs av den omdesignade Azure Logic Apps körningen. Den här körningen använder Azure Functions modell för utökningsbarhet och finns som ett tillägg Azure Functions körningskörningen. Den här designen ger portabilitet, flexibilitet och bättre prestanda för dina logikapparbetsflöden samt 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 logikappar baserade på en klientorganisation och deras arbetsflöden i Azure App Service-miljön v3.

Resurstypen Standard introducerar en resursstruktur som kan vara värd för flera arbetsflöden, på samma sätt 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 klientorganisation beräknings- och bearbetningsresurser, vilket ger bättre prestanda tack vare 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. Om du vill ha mer information om en Azure Logic Apps och Azure Functions utökningsbarhet kan du läsa följande dokumentation:

• Azure Logic Apps Köra var som helst – djupdykning i körning
• Introduktion till Azure Functions
• Azure Functions utlösare och bindningar

Portabilitet och flexibilitet

När du skapar logikappar med hjälp av resurstypen Logic App (Standard) kan du distribuera och köra dina arbetsflöden i andra miljöer, till exempel Azure App Service-miljön v3. Om du använder Visual Studio Code med Azure Logic Apps-tillägget (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 för en enskild klientorganisation med hjälp 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 för flera innehavare, vilket kräver att du utvecklar mot en befintlig resurs som körs i Azure. Dessutom baseras modellen för flera innehavare för automatisering av resursdistribution för logikappar (förbrukning) helt på Azure Resource Manager-mallar (ARM-mallar), som kombinerar och hanterar resursetablering för både appar och infrastruktur.

Med resurstypen Logic App (Standard) blir distributionen enklare eftersom du kan separera appdistributionen från infrastrukturdistributionen. Du kan paketera en enda klientorganisation Azure Logic Apps och arbetsflöden tillsammans som en del av din logikapp. Du kan använda allmänna steg eller uppgifter som skapar, sätter samman och zippa dina logikappresurser till färdiga att distribuera 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 apparna för att köra dina arbetsflöden. Du kan också integrera dina artefakter 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 att skapa och distribuera 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 för att skapa distributionspipelines runt dina appprojekt och för att köra 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 logikapp 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 tack vare deras närhet.

Resurstypen Logic App (Standard) och Azure Logic Apps en enda klient 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 med mera. 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 motsvarigheter för hanterade anslutningar kallas API-anslutningar, som skapas och körs separat som Azure-resurser som du sedan 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å den Azure Logic Apps körningen. Därför ger inbyggda åtgärder och deras anslutningar bättre prestanda på grund av närhet till dina arbetsflöden. Den här designen fungerar också bra med distributionspipelines eftersom tjänstleverantörens anslutningar paketeras i samma byggartefakt.

Dataplacering

Logikappresurser som skapas med resurstypen Logikapp (Standard) finns i en enda klientorganisations-Azure Logic Apps, som inte lagrar, bearbetareller replikerar data utanför den region där du distribuerar dessa logikappresurser, vilket innebär att data i dina logikapparbetsflöden finns i samma region där du skapar och distribuerar deras överordnade resurser.

Skapa, skapa och distribuera alternativ

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

Miljö för en enskild klientorganisation

Miljö för flera innehavare

Integreringstjänstmiljö

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

I den här Azure Portal logikappsidan till exempel resurstyperna Förbrukning och Standard för logikappar. 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åndslösa och tillståndslösa arbetsflöden

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

• Stateful

  Skapa ett tillståndslöst arbetsflöde när du behöver behålla, granska eller referera till data från tidigare händelser. Dessa arbetsflöden sparar och överför alla indata och utdata för varje åtgärd och deras tillstånd till extern lagring, vilket gör det möjligt att granska körningsinformationen och historiken när varje körning är klar. Tillståndsful workflows 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 om arbetsflödena tills de har slutförts. Tillståndslösa arbetsflöden kan fortsätta att köras mycket längre än tillståndslösa arbetsflöden.

  Som standard körs tillståndsful-arbetsflöden i både multi-tenant och single-tenant Azure Logic Apps asynkront. Alla HTTP-baserade åtgärder följer standardmönstret för asynkrona åtgärder. Det här mönstret anger att när en HTTP-åtgärd anropar eller skickar en begäran till en slutpunkt, tjänst, system eller API returnerar mottagaren omedelbart svaret "202 ACCEPTED". Den här koden bekräftar att mottagaren godkände begäran men inte har slutfört bearbetningen. Svaret kan innehålla ett -huvud som anger URI:n och ett uppdaterings-ID som anroparen kan använda för att söka av eller kontrollera statusen för den asynkrona begäran tills mottagaren slutar bearbeta och returnerar ett location lyckat svar på "200 OK" eller annat svar som inte är 202. Anroparen behöver dock inte vänta tills begäran har bearbetas klart och kan fortsätta att köra nästa åtgärd. Mer information finns i Asynkron mikrotjänstintegrering tillämpar självbestämmande för mikrotjänster.

• 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 är klar för senare granskning. Dessa arbetsflöden sparar alla indata och utdata för varje åtgärd och deras tillstånd i minnet, inte i extern lagring. Därför har tillståndslösa arbetsflöden kortare körningar som vanligtvis är mindre än 5 minuter, snabbare prestanda med snabbare svarstider, högre dataflöde och lägre driftskostnader eftersom körningsinformationen och historiken inte sparas i extern lagring. Om avbrott inträffar återställs dock inte avbrytna körningar automatiskt, så anroparen måste skicka om avbrytna körningar manuellt.

  Viktigt

  Ett tillståndslöst arbetsflöde ger bästa möjliga prestanda vid hantering av data eller innehåll, till exempel en fil, som inte överskrider 64 kB i total storlek. Större innehållsstorlekar, till exempel flera stora bifogade filer, kan avsevärt göra arbetsflödets prestanda långsammare eller till och med orsaka att arbetsflödet kraschar på grund av minnesundantag. Om arbetsflödet kan behöva hantera större innehållsstorlekar använder du ett tillståndsful workflow i stället.

  Tillståndslösa arbetsflöden körs bara synkront, så de använder inte det standarda asynkrona åtgärdsmönster som används av tillståndsful-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 ett location sidhuvud avsöker inte ett tillståndslöst arbetsflöde den angivna URI:en för att kontrollera statusen. Om du vill följa det asynkrona standardåtgärdsmönstret använder du ett tillståndsful workflow 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 Create single-tenant based workflows in Visual Studio Code (Skapa arbetsflöden för en enskild klientorganisation) i Azure Portal.

  Anteckning

  Tillståndslösa arbetsflöden stöder för närvarande endast åtgärder för hanterade anslutningsappar, som distribueras i Azure och inte utlösare. Om du vill starta arbetsflödet väljer du antingen den inbyggda begäran, den Event Hubs eller den Service Bus utlösaren. Dessa utlösare körs inbyggt i Azure Logic Apps-körningen. Mer information om begränsade, otillgängliga eller icke-stödda utlösare, åtgärder och anslutningsappar finns i Funktioner som har ändrats, är begränsade, inte tillgängliga eller inte stöds.

Kapslade beteendeskillnader mellan tillståndslösa och tillståndslösa arbetsflöden

Du kan göra ett arbetsflöde anropningsbart från andra arbetsflöden som finns i samma logikappresurs (standard) med hjälp av begärandeutlösaren, HTTP Webhook-utlösareneller hanterade anslutningsutlösare som har typen ApiConnectionWebhook och kan ta emot HTTPS-begäranden.

Här följer beteendemönster som inkapslade arbetsflöden kan följa när ett överordnat arbetsflöde anropar ett underordnat arbetsflöde:

• Asynkront avsökningsmönster

  Den överordnade väntar inte på svar på det första anropet, men kontrollerar kontinuerligt barnets körningshistorik tills den underordnade körningen är klar. Som standard följer tillståndsfulla arbetsflöden det här mönstret, vilket är idealiskt för långvariga underordnade arbetsflöden som kan överskrida tidsgränsgränserna för förfrågningar.

• Synkront mönster ("fire and forget")

  Den underordnade bekräftar anropet genom att omedelbart returnera ett svar, och den överordnade fortsätter till nästa åtgärd utan att 202 ACCEPTED vänta på resultatet från den underordnade åtgärden. I stället får den överordnade användaren resultaten när det underordnade objektet har körts klart. Underordnade tillståndsful-arbetsflöden som inte innehåller en svarsåtgärd följer alltid det synkrona mönstret. För underordnade tillståndsful-arbetsflöden är körningshistoriken tillgänglig för granskning.

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

• Utlösa och vänta

  För ett underordnat tillståndslöst arbetsflöde väntar det överordnade objektet på ett svar som returnerar resultatet från det underordnade arbetsflödet. Det här mönstret fungerar ungefär som att använda den inbyggda HTTP-utlösaren eller åtgärden för att anropa ett underligt arbetsflöde. Underordnade tillståndslösa arbetsflöden som inte innehåller en svarsåtgärd returnerar omedelbart ett svar, men den överordnade väntar på att det underordnade ska slutföras innan nästa 202 ACCEPTED åtgärd fortsätter. Dessa beteenden gäller endast för underordnade tillståndslösa arbetsflöden.

Den här tabellen anger det underordnade arbetsflödets beteende baserat på om det överordnade och underordnade arbetsflödet är tillståndslösa eller är blandade arbetsflödestyper:

Andra funktioner för en enskild klientorganisationsmodell

Enklientsmodellen och resurstypen Logic App (Standard) innehåller många aktuella och nya funktioner, till exempel:

• Skapa logikappar och deras arbetsflöden från över 400 hanterade anslutningsappar för SaaS- (programvara som en tjänst) och PaaS-appar (plattform som en tjänst) och tjänster samt anslutningsappar för lokala system.

  • Fler hanterade anslutningsappar är nu tillgängliga som inbyggda åtgärder och körs på samma sätt som andra inbyggda åtgärder, till exempel Azure Functions. Inbyggda åtgärder körs inbyggt på Azure Logic Apps klient. Nya inbyggda åtgärder omfattar till exempel Azure Service Bus, Azure Event Hubs, SQL Server, MQ, DB2 och IBM Host File.

    Anteckning

    För den inbyggda SQL Server-versionen kan endast åtgärden Kör fråga ansluta direkt till virtuella Azure-nätverk utan att använda den lokala datagatewayen.

  • Du kan skapa egna inbyggda anslutningsappar för alla tjänster som du behöver med hjälp av Azure Logic Apps för utökningsbarhet. På samma sätt som med inbyggda åtgärder som Azure Service Bus och SQL Server, men till skillnad från anpassade hanterade anslutningsappar ,som för närvarande inte stöds, ger anpassade inbyggda anslutningsappar högre dataflöde, låg svarstid och lokal anslutning eftersom de körs i samma process som en enda klientkörning.

    Redigeringsfunktionerna är för närvarande endast tillgängliga i Visual Studio Code, men är inte aktiverat som standard. Om du vill skapa de här anslutningsapparna växlar du projektet från tilläggssamlingsbaserad (Node.js) till NuGet-paketbaserad (.NET). Mer information finns i Azure Logic Apps Running Anywhere - Built-in connector extensibility.

  • Du kan använda följande åtgärder för Liquid-åtgärder 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 klientorganisation (Standard) måste du ha Liquid-kartor, XML-kartor eller XML-scheman. Du kan ladda upp dessa artefakter Azure Portal från logikappens resursmeny under Artefakter, som innehåller avsnitten Scheman Kartor resurs. Eller så kan du lägga till dessa artefakter i Visual Studio Code-projektets artifacts-mapp med hjälp av mapparna Kartor scheman och scheman. Du kan sedan använda dessa artefakter i flera arbetsflöden inom 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 körning av molnanslutning. 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.

    Anteckning

    Som standard har logikappens (standard) resurstyp den system tilldelade hanterade identiteten automatiskt 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 anslutningarna vid körning. Om du vill visa den här inställningen går du till logikappens meny och Inställningar väljer Identitet.

    Den användar tilldelade hanterade identiteten är för närvarande inte tillgänglig för resurstypen Logic App (Standard).

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

  Innan du kör och testar logikappen kan du göra felsökningen 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 Create single-tenant based workflows in 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 aktiverat Logic Apps.

• Aktivera funktioner för diagnostikloggning och spårning för logikappen genom att använda 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, på liknande sätt som Azure Functions när du skapar och distribuerar dina logikappar med hjälp Azure Functions Premium planen. Mer information finns i följande dokumentation:

  • Nätverksalternativ för Azure Functions

  • Azure Logic Apps Köra 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 (förbrukning)men på nivån för enskilt arbetsflöde, inte resursnivån för logikappen.

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

För logikappresursen (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 inbyggt i Azure Logic Apps, medan hanterade anslutningsappar finns och körs i Azure. Vissa inbyggda utlösare och åtgärder är inte tillgängliga, till exempel skjutfönster, Batch, Azure App Services och Azure API Management. Om du vill starta ett tillståndslöst eller tillståndslöst arbetsflöde använder du den inbyggda upprepnings-, begäran-, HTTP-, HTTP-webhook-, Event Hubs- eller Service Bus-utlösaren. I designern visas inbyggda utlösare och åtgärder under fliken Inbyggt.

  För tillståndsfulla arbetsflöden visas utlösare och åtgärder för hanterade anslutningsappar under fliken Azure, förutom de otillgängliga åtgärder som anges nedan. För tillståndslösa arbetsflöden visas inte Azure-fliken när du vill välja en utlösare. Du kan bara välja åtgärder för hanterade anslutningsappar, inte utlösare. Även om du kan aktivera azure-värdbaserade hanterade anslutningsappar för tillståndslösa arbetsflöden visar designern inga hanterade anslutningsutlösare som du kan lägga till.

  Anteckning

  Om du vill köra lokalt Visual Studio Code kräver webhook-baserade utlösare och åtgärder ytterligare konfiguration. Mer information finns i Create single-tenant based workflows in 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:

    • Lokala datagatewayutlösare är inte tillgängliga, men gatewayåtgärder är tillgängliga.

    • Den inbyggda åtgärden, Azure Functions – Välj en Azure-funktion är nu Azure Function 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 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 abstraherar funktionens information som en anslutning, som du hittar i logikappsprojektets connections.json-fil, som är tillgänglig när du har skapat en anslutning i Visual Studio Code.

      Anteckning

      I modellen för en enskild 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 nyckeln i appens inställningar och använder nyckeln för autentisering när funktionen anropas.

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

    • Den inbyggda åtgärden, Inline Code, har bytt 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 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 AS2-åtgärderna (V2) och Åtgärderna För integrationskonton.

    • 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 Create single-tenant based workflows using Visual Studio Code.

• Autentisering: Följande autentiseringstyper är för närvarande inte tillgängliga för resurstypen Logic App (Standard):

  • Azure Active Directory Öppna Autentisering (Azure AD OAuth) för inkommande anrop till begärandebaserade utlösare, till exempel begärandeutlösaren och HTTP Webhook-utlösaren.

  • Användar tilldelad hanterad identitet. För närvarande är endast den system tilldelade hanterade identiteten tillgänglig och automatiskt aktiverad.

• 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 brytpunkter 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 för närvarande, inte utlösare. Mer information finns i Create single-tenant based workflows in 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å logikappnivå. Mer information finns i Skapa arbetsflöden för en enskild klient 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 Logic App (Standard) till en integrationstjänstmiljö (ISE) eller till Azure-distributionsfack.

• Azure API Management: Du kan för närvarande inte importera resurstypen Logic App (Standard) till Azure API Management. Du kan dock importera resurstypen Logikapp (förbrukning).

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

Om din miljö har strikta nätverkskrav eller brandväggar som begränsar trafiken måste du tillåta åtkomst för alla utlösare eller åtgärdsanslutningar i logikappens arbetsflöden. Om du vill hitta fullständigt kvalificerade domännamn (FQDN) för dessa anslutningar kan du läsa motsvarande avsnitt i följande avsnitt:

• Brandväggsbehörigheter för enskilda klientlogikappar – Visual Studio Kod
• Brandväggsbehörigheter för enskilda klientlogikappar – Azure Portal

Nästa steg

• Skapa arbetsflöden baserade på en enskild klientorganisation i Azure Portal
• Skapa arbetsflöden baserade på en enskild klient i Visual Studio Code

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

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