Verschillen tussen standaard logische apps met één tenant versus multitenant-logische apps voor verbruik

Azure Logic Apps is een cloudplatform voor het maken en uitvoeren van geautomatiseerde werkstromen voor logische apps die uw apps, gegevens, services en systemen integreren. Met dit platform kunt u snel zeer schaalbare integratieoplossingen ontwikkelen voor uw bedrijfs- en B2B-scenario's (business-to-business). Wanneer u een logische app-resource maakt, selecteert u de optie Verbruik of Standaardhosting . Een logische app Verbruik kan slechts één werkstroom hebben die wordt uitgevoerd in multitenant Azure Logic Apps. Een standaard logische app kan een of meerdere werkstromen hebben die worden uitgevoerd in Azure Logic Apps met één tenant of een App Service Environment v3 (ASE v3).

Voordat u kiest welke logische app-resource u wilt maken, raadpleegt u de volgende handleiding om te leren hoe de werkstroomtypen van de logische app zich met elkaar vergelijken. Vervolgens kunt u een betere keuze maken over welke werkstroom en omgeving van logische apps het beste past bij uw scenario, oplossingsvereisten en de bestemming waar u uw werkstromen wilt implementeren en uitvoeren.

Als u geen toegang hebt tot Azure Logic Apps, bekijkt u wat is Azure Logic Apps? en wat is een werkstroom voor een logische app?

Werkstroomtypen en omgevingen voor logische apps

De volgende tabel bevat een overzicht van de verschillen tussen een werkstroom voor logische apps verbruik en de werkstroom van de standaard logische app. U leert ook hoe de omgeving met één tenant verschilt van de omgeving met meerdere tenants voor het implementeren, hosten en uitvoeren van uw werkstromen.

Hostingoptie	Vergoedingen	Resources delen en gebruiken	Prijs- en factureringsmodel	Beheer van limieten
Verbruik Hostomgeving: Multitenant Azure Logic Apps	- Eenvoudigste om aan de slag te gaan - Betalen voor wat u gebruikt - Volledig beheerd	Eén resource voor logische apps kan slechts één werkstroom hebben. Alle logische apps in Microsoft Entra-tenants delen dezelfde verwerking (compute), opslag, netwerk enzovoort. Voor redundantiedoeleinden worden gegevens gerepliceerd in de gekoppelde regio. Voor hoge beschikbaarheid is geografisch redundante opslag (GRS) ingeschakeld.	Verbruik (betalen per uitvoering)	Azure Logic Apps beheert de standaardwaarden voor deze limieten, maar u kunt een aantal van deze waarden wijzigen als deze optie bestaat voor een specifieke limiet.
Standard (Werkstroomserviceplan) Hostomgeving: Azure Logic Apps met één tenant Opmerking: Als voor uw scenario containers zijn vereist, maakt u logische apps met één tenant met behulp van Logic Apps met Azure Arc. Raadpleeg voor meer informatie Wat is Logic Apps met Azure Arc?	- Meer ingebouwde connectors die worden gehost op de runtime met één tenant voor hogere doorvoer en lagere kosten op schaal - Meer controle- en afstemmingsmogelijkheden rond runtime- en prestatie-instellingen - Geïntegreerde ondersteuning voor virtuele netwerken en privé-eindpunten. - Maak uw eigen ingebouwde connectors.	Een resource voor één logische app kan meerdere stateful en stateless werkstromen hebben. Werkstromen in één logische app en tenant delen dezelfde verwerking (compute), opslag, netwerk enzovoort. Gegevens blijven in dezelfde regio waar u uw logische app implementeert.	Standard, op basis van een hostingabonnement met een geselecteerde prijscategorie. Als u stateful werkstromen uitvoert die gebruikmaken van externe opslag, maakt de Azure Logic Apps-runtime opslagtransacties die voldoen aan de prijzen van Azure Storage.	U kunt de standaardwaarden voor veel limieten wijzigen op basis van de behoeften van uw scenario. Belangrijk: sommige limieten hebben harde maximumwaarden. In Visual Studio Code worden de wijzigingen die u aanbrengt in de standaardlimietwaarden in de configuratiebestanden van uw logische app-project niet weergegeven in de ontwerpfunctie. Zie App- en omgevingsinstellingen bewerken voor logische apps in Azure Logic Apps met één tenant voor meer informatie.
Standard (App Service Environment v3) Hostomgeving: App Service Environment v3 (ASEv3) - alleen Windows-abonnementen	Dezelfde mogelijkheden als één tenant plus de volgende voordelen: - Uw logische apps volledig isoleren. - Meer logische apps maken en uitvoeren dan in Azure Logic Apps met één tenant. - Betaal alleen voor het ASE App Service-plan, ongeacht het aantal logische apps dat u maakt en uitvoert. - Kan automatisch schalen of handmatig schalen met meer exemplaren van virtuele machines of een ander App Service-plan inschakelen. - De netwerkinstallatie overnemen van de geselecteerde ASEv3. Wanneer u bijvoorbeeld implementeert in een interne ASE, hebben werkstromen toegang tot de resources in een virtueel netwerk dat is gekoppeld aan de ASE en interne toegangspunten. Opmerking: als deze toegankelijk zijn vanaf buiten een interne ASE, voert u geschiedenissen uit voor werkstromen in die ASE heeft geen toegang tot actie-invoer en -uitvoer.	Eén logische app kan meerdere stateful en stateless werkstromen hebben. Werkstromen in één logische app en tenant delen dezelfde verwerking (compute), opslag, netwerk enzovoort. Gegevens blijven in dezelfde regio waar u uw logische apps implementeert.	App Service-plan	U kunt de standaardwaarden voor veel limieten wijzigen op basis van de behoeften van uw scenario. Belangrijk: sommige limieten hebben harde maximumwaarden. In Visual Studio Code worden de wijzigingen die u aanbrengt in de standaardlimietwaarden in de configuratiebestanden van uw logische app-project niet weergegeven in de ontwerpfunctie. Zie App- en omgevingsinstellingen bewerken voor logische apps in Azure Logic Apps met één tenant voor meer informatie.

Standaard logische app en werkstroom

De standaard logische app en werkstroom worden mogelijk gemaakt door de opnieuw ontworpen Azure Logic Apps-runtime met één tenant. Deze runtime maakt gebruik van het Azure Functions-uitbreidbaarheidsmodel en wordt gehost als een extensie in de Azure Functions-runtime. Dit ontwerp biedt draagbaarheid, flexibiliteit en meer prestaties voor uw werkstromen voor logische apps plus andere mogelijkheden en voordelen die zijn overgenomen van het Azure Functions-platform en het Azure-app Service-ecosysteem. U kunt bijvoorbeeld logische apps met één tenant en hun werkstromen maken, implementeren en uitvoeren in Azure-app Service Environment v3 (alleen Windows-abonnementen).

De logische standaard-app introduceert een resourcestructuur die meerdere werkstromen kan hosten, vergelijkbaar met hoe een Azure-functie-app meerdere functies kan hosten. Met een 1-op-veel-toewijzing delen werkstromen in dezelfde logische app en tenant reken- en verwerkingsresources en bieden ze betere prestaties vanwege hun nabijheid. Deze structuur verschilt van de resource van de logische app Verbruik , waarbij u een 1-op-1-toewijzing hebt tussen de resource van de logische app en een werkstroom.

Raadpleeg de volgende secties voor meer informatie over draagbaarheid, flexibiliteit en prestatieverbeteringen. Raadpleeg de volgende documentatie voor meer informatie over de Azure Logic Apps-runtime met één tenant en de uitbreidbaarheid van Azure Functions:

• Azure Logic Apps die overal worden uitgevoerd - Uitgebreide informatie over runtime
• Inleiding tot Azure Functions
• Azure Functions-triggers en -bindingen

Draagbaarheid en flexibiliteit

Wanneer u een standaard logische app en werkstroom maakt, kunt u uw werkstroom implementeren en uitvoeren in andere omgevingen, zoals Azure-app Service Environment v3 (alleen Windows-abonnementen). Als u Visual Studio Code gebruikt met de Azure Logic Apps-extensie (Standard), kunt u uw werkstroom lokaal ontwikkelen, bouwen en uitvoeren in uw ontwikkelomgeving zonder dat u in Azure hoeft te implementeren. Als voor uw scenario containers zijn vereist, kunt u logische apps met één tenant maken met behulp van Logic Apps met Azure Arc. Zie Wat is Logic Apps met Azure Arc? voor meer informatie.

Deze mogelijkheden bieden grote verbeteringen en aanzienlijke voordelen in vergelijking met het multitenant-model. Hiervoor moet u zich ontwikkelen op basis van een bestaande actieve resource in Azure. Het multitenant-model voor het automatiseren van resource-implementatie van logische apps voor verbruik is gebaseerd op Arm-sjablonen (Azure Resource Manager) die resourceinrichting combineren en verwerken voor zowel apps als infrastructuur.

Met de resource van de standaard logische app wordt de implementatie eenvoudiger omdat u de implementatie van apps kunt scheiden van de infrastructuurimplementatie. U kunt de Azure Logic Apps-runtime met één tenant en uw werkstromen samen verpakken als onderdeel van uw resource of project van uw logische app. U kunt algemene stappen of taken gebruiken die uw resources voor logische apps bouwen, samenstellen en zippen in kant-en-klare artefacten. Als u uw infrastructuur wilt implementeren, kunt u arm-sjablonen nog steeds gebruiken om deze resources afzonderlijk in te richten, samen met andere processen en pijplijnen die u voor deze doeleinden gebruikt.

Als u uw app wilt implementeren, kopieert u de artefacten naar de hostomgeving en start u vervolgens uw apps om uw werkstromen uit te voeren. Of integreer uw artefacten in implementatiepijplijnen met behulp van de hulpprogramma's en processen die u al kent en gebruikt. Op die manier kunt u implementeren met behulp van uw eigen gekozen hulpprogramma's, ongeacht de technologiestack die u gebruikt voor ontwikkeling.

Door standaardopties voor bouwen en implementeren te gebruiken, kunt u zich richten op app-ontwikkeling afzonderlijk van de implementatie van de infrastructuur. Als gevolg hiervan krijgt u een meer algemeen projectmodel waarin u veel vergelijkbare of dezelfde implementatieopties kunt toepassen die u voor een algemene app gebruikt. U profiteert ook van een consistentere ervaring wanneer u implementatiepijplijnen voor uw apps bouwt en wanneer u de vereiste tests en validaties uitvoert voordat u naar productie publiceert.

Prestaties

Met een standaard logische app kunt u meerdere werkstromen maken en uitvoeren in dezelfde resource en tenant voor één logische app. Met deze 1-op-veel-toewijzing delen deze werkstromen resources, zoals rekenkracht, verwerking, opslag en netwerk, en bieden ze betere prestaties vanwege hun nabijheid.

De Resource van de standaard logische app en de Azure Logic Apps-runtime met één tenant bieden een andere aanzienlijke verbetering door de populaire beheerde connectors beschikbaar te maken als ingebouwde connectorbewerkingen. U kunt bijvoorbeeld ingebouwde connectorbewerkingen gebruiken voor Azure Service Bus, Azure Event Hubs, SQL Server en andere. Ondertussen zijn de versies van de beheerde connector nog steeds beschikbaar en blijven ze werken.

Wanneer u de nieuwe ingebouwde connectorbewerkingen gebruikt, maakt u verbindingen die ingebouwde verbindingen of serviceproviderverbindingen worden genoemd. Hun tegenhangers voor beheerde verbindingen worden API-verbindingen genoemd, die afzonderlijk worden gemaakt en uitgevoerd als Azure-resources die u ook moet implementeren met behulp van ARM-sjablonen. Ingebouwde bewerkingen en de bijbehorende verbindingen worden lokaal uitgevoerd in hetzelfde proces waarin uw werkstromen worden uitgevoerd. Beide worden gehost in de Azure Logic Apps-runtime met één tenant. Als gevolg hiervan bieden ingebouwde bewerkingen en hun verbindingen betere prestaties vanwege de nabijheid van uw werkstromen. Dit ontwerp werkt ook goed met implementatiepijplijnen omdat de verbindingen van de serviceprovider zijn verpakt in hetzelfde build-artefact.

Gegevensresidentie

Standaardbronnen voor logische apps worden gehost in Azure Logic Apps met één tenant, die geen gegevens opslaat, verwerkt of repliceert buiten de regio waar u deze logische app-resources implementeert, wat betekent dat gegevens in uw werkstromen in dezelfde regio blijven waar u hun bovenliggende resources maakt en implementeert.

Directe toegang tot resources in virtuele Azure-netwerken

Werkstromen die worden uitgevoerd in azure Logic Apps met één tenant, hebben rechtstreeks toegang tot beveiligde resources, zoals virtuele machines (VM's), andere services en systemen die aanwezig zijn in een virtueel Azure-netwerk.

Azure Logic Apps met één tenant is een toegewezen instantie van de Azure Logic Apps-service, maakt gebruik van toegewezen resources en wordt afzonderlijk uitgevoerd van Multitenant Azure Logic Apps. Het uitvoeren van werkstromen in een toegewezen exemplaar helpt de impact die andere Azure-tenants kunnen hebben op app-prestaties te verminderen, ook wel bekend als het effect 'lawaaierige buren'.

Azure Logic Apps met één tenant biedt ook de volgende voordelen:

• Uw eigen statische IP-adressen, die gescheiden zijn van de statische IP-adressen die worden gedeeld door de logische apps in de multitenant Azure Logic Apps. U kunt ook één openbaar, statisch en voorspelbaar uitgaand IP-adres instellen om te communiceren met doelsystemen. Op die manier hoeft u geen extra firewallopeningen in te stellen op die doelsystemen.

• Verhoogde limieten voor de uitvoeringsduur, opslagbewaring, doorvoer, time-outs voor HTTP-aanvragen en -reacties, berichtgrootten en aangepaste connectoraanvragen. Raadpleeg limieten en configuratie voor Azure Logic Apps voor meer informatie.

Opties voor maken, bouwen en implementeren

Als u een logische app-resource wilt maken op basis van de gewenste omgeving, hebt u meerdere opties, bijvoorbeeld:

Omgeving met één tenant

Optie	Bronnen en hulpprogramma's	Meer informatie
Azure Portal	Standaard logische app	Een voorbeeld van een standaardwerkstroom voor logische apps maken in Azure Logic Apps met één tenant - Azure Portal
Visual Studio Code	Azure Logic Apps-extensie (Standard)	Een voorbeeld van een standaardwerkstroom voor logische apps maken in Azure Logic Apps met één tenant - Visual Studio Code
Azure-CLI	Azure CLI-extensie voor Logic Apps	az logicapp
Azure Resource Manager	- Lokaal - DevOps	Azure Logic Apps met één tenant
Logic Apps met Azure Arc	Logic Apps-voorbeeld met Azure Arc	- Wat is Logic Apps met Azure Arc? - Logische app-werkstromen met één tenant maken en implementeren met Logic Apps met Azure Arc
Azure REST API	AZURE-APP Service REST API* Opmerking: de REST API van de standaard logische app is opgenomen in de Azure-app Service REST API.	Aan de slag met azure REST API-naslaginformatie

Multitenant-omgeving

Optie	Bronnen en hulpprogramma's	Meer informatie
Azure Portal	Logische app verbruik	Quickstart: Een voorbeeld van een werkstroom voor logische apps verbruik maken in Multitenant Azure Logic Apps - Azure Portal
Visual Studio Code	Azure Logic Apps-extensie (verbruik)	Quickstart: Een voorbeeldwerkstroom voor logische apps voor verbruik maken in multitenant Azure Logic Apps - Visual Studio Code
Azure-CLI	Azure CLI-extensie voor Logic Apps	- Quickstart: Werkstromen voor logische apps voor verbruik maken en beheren in multitenant Azure Logic Apps - Azure CLI - az logic
Azure Resource Manager	Een ARM-sjabloon voor een logische app maken	Quickstart: Werkstromen voor logische apps voor verbruik maken en implementeren in multitenant Azure Logic Apps - ARM-sjabloon
Azure PowerShell	Az.LogicApp-module	Aan de slag met Azure PowerShell
Azure REST API	Azure Logic Apps REST API	Aan de slag met azure REST API-naslaginformatie

Hoewel uw ontwikkelervaringen verschillen op basis van het feit of u resources voor verbruiks- of Standard-logische apps maakt, kunt u al uw geïmplementeerde logische apps vinden en openen onder uw Azure-abonnement.

Op de pagina logische apps in Azure Portal worden bijvoorbeeld zowel de resources verbruik als de standaard logische app weergegeven. In Visual Studio Code worden geïmplementeerde logische apps weergegeven onder uw Azure-abonnement, maar logische verbruiks-apps worden weergegeven in het Azure-venster onder de extensie Azure Logic Apps (Verbruik), terwijl Standaard logische apps worden weergegeven onder de sectie Resources .

Stateful en stateless werkstromen

In een standaard logische app kunt u de volgende werkstroomtypen maken:

• Stateful

  Maak een stateful werkstroom wanneer u gegevens uit eerdere gebeurtenissen wilt bewaren, controleren of ernaar wilt verwijzen. Met deze werkstromen worden alle invoer, uitvoer en statussen van alle bewerkingen opgeslagen in externe opslag. Deze informatie maakt het controleren van de details en geschiedenis van de werkstroomuitvoering mogelijk nadat elke uitvoering is voltooid. Stateful werkstromen bieden een hoge tolerantie als er storingen optreden. Nadat services en systemen zijn hersteld, kunt u onderbroken uitvoeringen van de opgeslagen status reconstrueren en de werkstromen opnieuw uitvoeren tot voltooiing. Stateful werkstromen kunnen veel langer worden uitgevoerd dan staatloze werkstromen.

  Stateful werkstromen in zowel multitenant als azure Logic Apps met één tenant worden standaard asynchroon uitgevoerd. Alle HTTP-acties volgen het standaard asynchrone bewerkingspatroon. Nadat een HTTP-actie een aanvraag heeft aangeroepen of verzonden naar een eindpunt, service, systeem of API, retourneert de ontvanger van de aanvraag onmiddellijk een antwoord '202 GEACCEPTEERD' . Deze code bevestigt dat de ontvanger de aanvraag heeft geaccepteerd, maar nog niet is verwerkt. Het antwoord kan een location header bevatten die de URI en een vernieuwings-id aangeeft die de beller kan gebruiken om de status van de asynchrone aanvraag te controleren totdat de ontvanger de verwerking stopt en een geslaagd antwoord van 200 OK of een ander niet-202-antwoord retourneert. De beller hoeft echter niet te wachten tot de aanvraag is verwerkt en kan de volgende actie blijven uitvoeren. Zie Asynchrone microservice-integratie dwingt microserviceautonomie af voor meer informatie.

• Staatloos

  Maak een staatloze werkstroom wanneer u geen gegevens van eerdere gebeurtenissen in externe opslag hoeft te bewaren, controleren of ernaar te verwijzen nadat elke uitvoering is voltooid voor later onderzoek. Met deze werkstromen worden alle invoer en uitvoer voor elke actie en hun statussen alleen in het geheugen opgeslagen, niet in externe opslag. Als gevolg hiervan hebben staatloze werkstromen kortere uitvoeringen die meestal binnen 5 minuten of minder worden voltooid, snellere prestaties met snellere reactietijden, hogere doorvoer en lagere lopende kosten omdat externe opslag de details en geschiedenis van de werkstroomuitvoering niet opslaat. Als er echter storingen optreden, worden onderbroken uitvoeringen niet automatisch hersteld, dus moet de aanroeper onderbroken uitvoeringen handmatig opnieuw indienen.

  Een staatloze werkstroom biedt de beste prestaties bij het verwerken van gegevens of inhoud die niet groter is dan 64 kB in totale grootte, zoals een bestand. Grotere inhoudsgrootten, zoals meerdere grote bijlagen, kunnen de prestaties van uw werkstroom aanzienlijk vertragen of zelfs ertoe leiden dat uw werkstroom vastloopt vanwege uitzonderingen met onvoldoende geheugen. Als uw werkstroom mogelijk grotere inhoudsgrootten moet verwerken, gebruikt u in plaats daarvan een stateful werkstroom.

  Notitie

  In staatloze werkstromen kunt u alleen pushtriggers gebruiken waarbij u geen schema opgeeft voor uitvoering voor uw werkstroom. Deze webhook-triggers wachten tot er een gebeurtenis plaatsvindt of dat er gegevens beschikbaar zijn. De trigger Terugkeerpatroon is bijvoorbeeld alleen beschikbaar voor stateful werkstromen. Als u uw werkstroom wilt starten, selecteert u een push-trigger, zoals de aanvraag-, Event Hubs- of Service Bus-trigger. Zie Gewijzigd, beperkt, niet beschikbaar of niet-ondersteunde triggers, acties en connectors voor meer informatie over gewijzigde, beperkte, niet-ondersteunde of niet-ondersteunde mogelijkheden.

  Staatloze werkstromen worden alleen synchroon uitgevoerd, zodat ze niet gebruikmaken van het standaard asynchrone bewerkingspatroon dat wordt gebruikt door stateful werkstromen. In plaats daarvan gaan alle HTTP-acties die een antwoord '202 GEACCEPTEERD' retourneren, verder met de volgende stap in de uitvoering van de werkstroom. Als het antwoord een location header bevat, wordt de opgegeven URI niet door een staatloze werkstroom gecontroleerd om de status te controleren. Als u het standaard asynchrone bewerkingspatroon wilt volgen, gebruikt u in plaats daarvan een stateful werkstroom.

  Voor eenvoudigere foutopsporing kunt u de uitvoeringsgeschiedenis inschakelen voor een staatloze werkstroom, wat invloed heeft op de prestaties en vervolgens de uitvoeringsgeschiedenis uitschakelen wanneer u klaar bent. Zie Werkstromen met één tenant maken in Visual Studio Code of Op één tenant gebaseerde werkstromen maken in Azure Portal voor meer informatie.

Belangrijk

U moet beslissen over het werkstroomtype, stateful of staatloos, om te implementeren tijdens het maken. Wijzigingen in het werkstroomtype na het maken veroorzaken van runtimefouten.

Overzichtsverschillen tussen stateful en stateless werkstromen

Stateful	Staatloos:
Slaat uitvoeringsgeschiedenis, invoer en uitvoer op	Slaat de uitvoeringsgeschiedenis, invoer of uitvoer niet standaard op
Triggers voor beheerde connectors zijn beschikbaar en toegestaan	Triggers voor beheerde connectors zijn niet beschikbaar of zijn niet toegestaan
Ondersteunt segmentering	Geen ondersteuning voor segmentering
Ondersteunt asynchrone bewerkingen	Geen ondersteuning voor asynchrone bewerkingen
Standaardduur voor maximale uitvoering bewerken in hostconfiguratie	Het meest geschikt voor werkstromen met een maximale duur van minder dan 5 minuten
Verwerkt grote berichten	Het beste voor het verwerken van kleine berichtgrootten (minder dan 64 kB)

Geneste gedragsverschillen tussen stateful en stateless werkstromen

U kunt een werkstroom aanroepen vanuit andere werkstromen die aanwezig zijn in dezelfde standaard logische app met behulp van de aanvraagtrigger, http-webhooktrigger of beheerde connectortriggers die het type ApiConnectionWebhook hebben en HTTPS-aanvragen kunnen ontvangen.

In de volgende lijst worden de gedragspatronen beschreven die geneste werkstromen kunnen volgen nadat een bovenliggende werkstroom een onderliggende werkstroom aanroept:

• Asynchroon pollingpatroon

  De bovenliggende werkstroom wacht niet totdat de onderliggende werkstroom reageert op de eerste aanroep. Het bovenliggende item controleert echter voortdurend de uitvoeringsgeschiedenis van het kind totdat het onderliggende item is uitgevoerd. Stateful werkstromen volgen dit patroon standaard. Dit is ideaal voor langlopende onderliggende werkstromen die mogelijk de time-outlimieten van aanvragen overschrijden.

• Synchroon patroon ('fire and forget')

  De onderliggende werkstroom bevestigt de aanroep van de bovenliggende werkstroom door onmiddellijk een 202 ACCEPTED antwoord te retourneren. Het bovenliggende item wacht echter niet totdat het kind resultaten retourneert. In plaats daarvan gaat het bovenliggende item door naar de volgende actie in de werkstroom en ontvangt de resultaten wanneer het onderliggende item is uitgevoerd. Onderliggende stateful werkstromen die geen antwoordactie bevatten, volgen altijd het synchrone patroon en bieden een uitvoeringsgeschiedenis die u kunt controleren.

  Als u dit gedrag wilt inschakelen, stelt u in de JSON-definitie van de werkstroom de operationOptions eigenschap in op DisableAsyncPattern. Zie Trigger- en actietypen - Bewerkingsopties voor meer informatie.

• Activeren en wachten

  Staatloze werkstromen worden uitgevoerd in het geheugen. Dus wanneer een bovenliggende werkstroom een onderliggende staatloze werkstroom aanroept, wacht de bovenliggende werkstroom op een antwoord dat de resultaten van het onderliggende item retourneert. Dit patroon werkt op dezelfde manier als het gebruik van de ingebouwde HTTP-trigger of -actie om een onderliggende werkstroom aan te roepen. Onderliggende staatloze werkstromen die geen antwoordactie bevatten, retourneren onmiddellijk een 202 ACCEPTED antwoord, maar het bovenliggende item wacht totdat het kind is voltooid voordat u verdergaat met de volgende actie. Dit gedrag is alleen van toepassing op onderliggende staatloze werkstromen.

De volgende tabel identificeert het gedrag van de onderliggende werkstroom op basis van of het bovenliggende en onderliggende werkstroom stateful, staatloos of gemengde werkstroomtypen zijn. De lijst na de tabel

Bovenliggende werkstroom	Onderliggende werkstroom	Onderliggend gedrag
Stateful	Stateful	Asynchroon of synchroon met "operationOptions": "DisableAsyncPattern" instelling
Stateful	Staatloos:	Activeren en wachten
Staatloos:	Stateful	Synchroon
Staatloos:	Staatloos:	Activeren en wachten

Andere mogelijkheden voor één tenantmodel

Het model met één tenant en de logische standaard-app bevatten veel huidige en nieuwe mogelijkheden, bijvoorbeeld:

• Maak logische apps en hun werkstromen van honderden beheerde connectors voor SaaS-apps (Software-as-a-Service) en PaaS-apps (Platform-as-a-Service) en services plus connectors voor on-premises systemen.

  • Meer beheerde connectors zijn nu beschikbaar als ingebouwde connectors in standaardwerkstromen. De ingebouwde versies worden systeemeigen uitgevoerd op de Azure Logic Apps-runtime met één tenant. Sommige ingebouwde connectors worden ook wel bekend als connectors van serviceproviders. Raadpleeg ingebouwde connectors in Verbruik en Standard voor een lijst.

  • U kunt uw eigen aangepaste ingebouwde connectors maken voor elke service die u nodig hebt met behulp van het Azure Logic Apps-uitbreidbaarheidsframework met één tenant. Net als bij ingebouwde connectors zoals Azure Service Bus en SQL Server bieden aangepaste ingebouwde connectors een hogere doorvoer, lage latentie en lokale connectiviteit, omdat ze worden uitgevoerd in hetzelfde proces als de runtime met één tenant. Aangepaste ingebouwde connectors zijn echter niet vergelijkbaar met aangepaste beheerde connectors, die momenteel niet worden ondersteund. Raadpleeg het overzicht van aangepaste connectors en maak aangepaste ingebouwde connectors voor Standaard logische apps in Azure Logic Apps met één tenant voor meer informatie.

  • U kunt de volgende acties gebruiken voor Liquid Operations en XML-bewerkingen zonder integratieaccount. Deze bewerkingen omvatten de volgende acties:

    • XML: XML- en XML-validatie transformeren

    • Liquid: JSON transformeren naar JSON, JSON transformeren naar TEKST, XML transformeren naar JSON en XML naar tekst transformeren

    Notitie

    Als u deze acties in standaardwerkstromen wilt gebruiken, moet u Liquid-toewijzingen, XML-toewijzingen of XML-schema's hebben. U kunt deze artefacten uploaden in Azure Portal vanuit het resourcemenu van uw logische app, onder Artefacten, waaronder de secties Schema's en Kaarten. U kunt deze artefacten ook toevoegen aan de map Artifacts van uw Visual Studio Code-project met behulp van de respectieve mappen Kaarten en Schema's. U kunt deze artefacten vervolgens gebruiken in meerdere werkstromen binnen dezelfde logische app.

  • Standaardwerkstromen voor logische apps kunnen overal worden uitgevoerd omdat Azure Logic Apps SAS -verbindingsreeks s (Shared Access Signature) genereert die deze logische apps kunnen gebruiken voor het verzenden van aanvragen naar het runtime-eindpunt van de cloudverbinding. Azure Logic Apps slaat deze verbindingsreeks s op met andere toepassingsinstellingen, zodat u deze waarden eenvoudig kunt opslaan in Azure Key Vault wanneer u implementeert in Azure.

  • Standaardwerkstromen voor logische apps bieden ondersteuning voor het inschakelen van zowel de door het systeem toegewezen beheerde identiteit als meerdere door de gebruiker toegewezen beheerde identiteiten tegelijk, hoewel u slechts één identiteit tegelijk kunt selecteren. Hoewel ingebouwde, op serviceproviders gebaseerde connectors ondersteuning bieden voor het gebruik van de door het systeem toegewezen identiteit, bieden de meeste momenteel geen ondersteuning voor het selecteren van door de gebruiker toegewezen beheerde identiteiten voor verificatie, met uitzondering van SQL Server en de HTTP-connectors.

    Notitie

    Standaard is de door het systeem toegewezen identiteit al ingeschakeld voor het verifiëren van verbindingen tijdens runtime. Deze identiteit verschilt van de verificatiereferenties of verbindingsreeks die u gebruikt wanneer u een verbinding maakt. Als u deze identiteit uitschakelt, werken verbindingen niet tijdens runtime. Als u deze instelling wilt weergeven, selecteert u identiteit in het menu van uw logische app onder Instellingen.

• U kunt uw logische apps en hun werkstromen lokaal uitvoeren, testen en fouten opsporen in de ontwikkelomgeving van Visual Studio Code.

  Voordat u uw logische app uitvoert en test, kunt u foutopsporing eenvoudiger maken door onderbrekingspunten toe te voegen en te gebruiken in het workflow.json-bestand voor een werkstroom. Onderbrekingspunten worden echter alleen ondersteund voor acties op dit moment, niet voor triggers. Zie Werkstromen met één tenant maken in Visual Studio Code voor meer informatie.

• Publiceer of implementeer logische apps en hun werkstromen rechtstreeks vanuit Visual Studio Code in verschillende hostingomgevingen, zoals Azure en Azure Arc enabled Logic Apps.

• Schakel diagnostische logboekregistratie- en traceringsmogelijkheden voor uw logische app in met behulp van Application Insights wanneer deze wordt ondersteund door uw Azure-abonnement en instellingen voor logische apps.

• Toegang tot netwerkmogelijkheden, zoals privé verbinden en integreren met virtuele Azure-netwerken, vergelijkbaar met Azure Functions wanneer u logische apps maakt en implementeert met behulp van het Azure Functions Premium-abonnement. Raadpleeg de volgende documentatie voor meer informatie:

  • Netwerkopties van Azure Functions

  • Azure Logic Apps Running Anywhere - Netwerkmogelijkheden met Azure Logic Apps

• Genereer toegangssleutels opnieuw voor beheerde verbindingen die worden gebruikt door afzonderlijke werkstromen in een standaard logische app. Volg voor deze taak dezelfde stappen voor een logische app verbruik , maar niet op werkstroomniveau, niet op resourceniveau van de logische app.

Ingebouwde connectors voor Standard

Een standaardwerkstroom kan veel van dezelfde ingebouwde connectors gebruiken als een werkstroom verbruik, maar niet allemaal. Omgekeerd heeft een Standaardwerkstroom veel ingebouwde connectors die niet beschikbaar zijn in een werkstroom Verbruik.

Een standaardwerkstroom bevat bijvoorbeeld zowel beheerde connectors als ingebouwde connectors voor Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server en andere. Hoewel een verbruikswerkstroom niet dezelfde ingebouwde connectorversies heeft, zijn andere ingebouwde connectors zoals Azure API Management en Azure-app Services beschikbaar.

In Azure Logic Apps met één tenant worden ingebouwde connectors met specifieke kenmerken informeel ook wel serviceproviders genoemd. Sommige ingebouwde connectors ondersteunen slechts één manier om een verbinding met de onderliggende service te verifiëren. Andere ingebouwde connectors kunnen een keuze bieden, zoals het gebruik van een verbindingsreeks, Microsoft Entra-id of een beheerde identiteit. Alle ingebouwde connectors worden uitgevoerd in hetzelfde proces als de opnieuw ontworpen Azure Logic Apps-runtime. Raadpleeg de ingebouwde lijst met connectoren voor werkstromen van standaard logische apps voor meer informatie.

Belangrijk

Zorg ervoor dat u een trigger op basis van een serviceprovider correct instelt en test om een geslaagde bewerking te bevestigen. Een trigger op basis van een serviceprovider kan onnodig schalen maken, waardoor uw factureringskosten aanzienlijk kunnen worden verhoogd. Een veelvoorkomende fout is bijvoorbeeld het instellen van een trigger zonder uw logische app toestemming te geven of toegang te geven tot de bestemming, zoals een Service Bus-wachtrij, Azure Storage-blobcontainer, enzovoort. Zorg er ook voor dat u dergelijke triggers altijd bewaakt, zodat u onmiddellijk eventuele problemen kunt detecteren en oplossen.

Gewijzigde, beperkte, niet-beschikbare of niet-ondersteunde mogelijkheden

Voor de werkstroom van de standaard logische app zijn deze mogelijkheden gewijzigd of zijn deze momenteel beperkt, niet beschikbaar of niet ondersteund:

• Triggers en acties: ingebouwde triggers en acties worden systeemeigen uitgevoerd in Azure Logic Apps, terwijl beheerde connectors worden gehost en uitgevoerd met behulp van gedeelde resources in Azure. Voor standaardwerkstromen zijn sommige ingebouwde triggers en acties momenteel niet beschikbaar, zoals sliding window, Azure-app Service en Azure API Management. Als u een stateful of stateless werkstroom wilt starten, gebruikt u een ingebouwde trigger, zoals de trigger Aanvraag, Event Hubs of Service Bus. De trigger Terugkeerpatroon is beschikbaar voor stateful werkstromen, maar niet voor stateless werkstromen. In de ontwerpfunctie worden ingebouwde triggers en acties weergegeven met het label In-App , terwijl beheerde connectortriggers en acties worden weergegeven met het gedeelde label.

  Staatloze werkstromen kunnen alleen pushtriggers gebruiken waarbij u geen schema opgeeft voor uitvoering voor uw werkstroom. Deze webhook-triggers wachten tot er een gebeurtenis plaatsvindt of dat er gegevens beschikbaar zijn. De trigger Terugkeerpatroon is bijvoorbeeld alleen beschikbaar voor stateful werkstromen. Als u uw werkstroom wilt starten, selecteert u een push-trigger, zoals de aanvraag-, Event Hubs- of Service Bus-trigger. Hoewel u beheerde connectors voor staatloze werkstromen kunt inschakelen, worden in de connectorgalerie geen poll-triggers voor beheerde connectors weergegeven die u kunt toevoegen.

  Notitie

  Voor lokaal uitvoeren in Visual Studio Code moeten triggers en acties op basis van webhook extra instellingen hebben. Zie Werkstromen met één tenant maken in Visual Studio Code voor meer informatie.

  • De volgende triggers en acties zijn gewijzigd of zijn momenteel beperkt, niet ondersteund of niet beschikbaar:

    • De ingebouwde actie Azure Functions: een Azure-functie kiezen is nu Azure Functions-bewerkingen: een Azure-functie aanroepen. Deze actie werkt momenteel alleen voor functies die zijn gemaakt op basis van de HTTP-triggersjabloon .

      In Azure Portal kunt u een HTTP-triggerfunctie selecteren waartoe u toegang hebt door een verbinding te maken via de gebruikerservaring. Als u de JSON-definitie van de functieactie in de codeweergave of het workflow.json-bestand inspecteert met behulp van Visual Studio Code, verwijst de actie naar de functie met behulp van een connectionName verwijzing. Deze versie abstraheert de informatie van de functie als een verbinding, die u kunt vinden in het connections.json-bestand van uw logische app-project, dat beschikbaar is nadat u een verbinding in Visual Studio Code hebt gemaakt.

      Notitie

      In het model met één tenant ondersteunt de functieactie alleen verificatie van queryreeksen. Azure Logic Apps haalt de standaardsleutel van de functie op bij het maken van de verbinding, slaat die sleutel op in de instellingen van uw app en gebruikt de sleutel voor verificatie bij het aanroepen van de functie.

      Net als in het multitenant-model werkt de functieactie niet meer vanwege de ongeldige sleutel als u deze sleutel bijvoorbeeld vernieuwt via de Azure Functions-ervaring in de portal. Om dit probleem op te lossen, moet u de verbinding met de functie die u wilt aanroepen of bijwerken, de instellingen van uw app opnieuw maken met de nieuwe sleutel.

    • De ingebouwde actie, Inline Code, wordt hernoemd inlinecodebewerkingen, vereist geen integratieaccount meer en heeft bijgewerkte limieten.

    • De ingebouwde actie Azure Logic Apps : een werkstroom voor logische apps kiezen is nu werkstroombewerkingen. Roep een werkstroom aan in deze werkstroom-app.

    • De Gmail-connector wordt momenteel niet ondersteund.

    • Aangepaste beheerde connectors worden momenteel niet ondersteund. U kunt echter aangepaste ingebouwde bewerkingen maken wanneer u Visual Studio Code gebruikt. Raadpleeg Werkstromen op basis van één tenant maken met Visual Studio Code voor meer informatie.

    • Een werkstroom voor een standaard logische app kan slechts één trigger hebben en biedt geen ondersteuning voor meerdere triggers.

• Verificatie: de volgende verificatietypen zijn momenteel niet beschikbaar voor standaardwerkstromen :

  • Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) voor binnenkomende aanroepen naar op aanvragen gebaseerde triggers, zoals de aanvraagtrigger en http-webhooktrigger.

  • Verificatie van beheerde identiteit: ondersteuning voor zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteit is beschikbaar. De door het systeem toegewezen beheerde identiteit wordt standaard automatisch ingeschakeld. De meeste ingebouwde connectors op basis van serviceproviders bieden momenteel echter geen ondersteuning voor het selecteren van door de gebruiker toegewezen beheerde identiteiten voor verificatie.

• XML-transformatie: momenteel wordt alleen XSLT 1.0 ondersteund.

• Foutopsporing voor onderbrekingspunten in Visual Studio Code: hoewel u onderbrekingspunten in het workflow.json-bestand voor een werkstroom kunt toevoegen en gebruiken, worden onderbrekingspunten op dit moment alleen ondersteund voor acties, niet voor triggers. Zie Werkstromen met één tenant maken in Visual Studio Code voor meer informatie.

• Triggergeschiedenis en uitvoeringsgeschiedenis: Voor een standaard logische app wordt triggergeschiedenis en uitvoeringsgeschiedenis in Azure Portal weergegeven op werkstroomniveau, niet op resourceniveau van de logische app. Raadpleeg werkstromen op basis van één tenant maken met behulp van Azure Portal voor meer informatie.

• Back-up en herstel voor de uitvoeringsgeschiedenis van werkstromen: Standaard logische apps bieden momenteel geen ondersteuning voor back-up en herstel voor de uitvoeringsgeschiedenis van de werkstroom.

• Terraform-sjablonen: u kunt deze sjablonen niet gebruiken met een standaardresource voor logische apps voor volledige implementatie van de infrastructuur. Zie Wat is Terraform in Azure voor meer informatie?

• Azure API Management: u kunt momenteel geen Standard-resource voor logische apps importeren in Azure API Management. U kunt echter een logische app-resource voor verbruik importeren.

Strikte machtigingen voor netwerk- en firewallverkeer

Als uw omgeving strikte netwerkvereisten of firewalls heeft die het verkeer beperken, moet u toegang verlenen voor trigger- of actieverbindingen in uw werkstromen. U kunt eventueel verkeer van servicetags toestaan en hetzelfde niveau van beperkingen of beleidsregels gebruiken als Azure-app Service. U moet ook de FQDN's (Fully Qualified Domain Names) voor uw verbindingen zoeken en gebruiken. Raadpleeg de bijbehorende secties in de volgende documentatie voor meer informatie:

• Firewallmachtigingen voor logische apps met één tenant - Azure Portal
• Firewallmachtigingen voor logische apps met één tenant - Visual Studio Code

Volgende stappen

• Werkstromen op basis van één tenant maken in Azure Portal
• Op één tenant gebaseerde werkstromen maken in Visual Studio Code

We willen ook meer weten over uw ervaringen met Azure Logic Apps met één tenant.

• Voor bugs of problemen maakt u uw problemen in GitHub.
• Gebruik dit feedbackformulier voor vragen, aanvragen, opmerkingen en andere feedback.