Serviceomgeving met één tenant versus multi-tenant en integratieservice voor Azure Logic Apps

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). Als u een logische app wilt maken, gebruikt u het resourcetype Logische app (verbruik) of het resourcetype Logische app (Standaard). Het resourcetype Verbruik wordt uitgevoerd in de multi-tenant Azure Logic Apps of integratieserviceomgeving, terwijl het Standard-resourcetype wordt uitgevoerd in een omgeving met Azure Logic Apps tenant.

Voordat u kiest welk resourcetype u wilt gebruiken, lees dan dit artikel voor meer informatie over de manier waarop de resourcetypen en serviceomgevingen met elkaar in vergelijking zijn. Vervolgens kunt u bepalen welk type het beste kan worden gebruikt, op basis van de behoeften van uw scenario, de oplossingsvereisten en de omgeving waarin u uw werkstromen wilt implementeren, hosten en uitvoeren.

Als u geen tijd hebt Azure Logic Apps, bekijkt u de volgende documentatie:

• Wat is Azure Logic Apps?
• Wat is een werkstroom voor een logische app?

Resourcetypen en omgevingen

Als u werkstromen voor logische apps wilt maken, kiest u het resourcetype van de logische app op basis van uw scenario, de oplossingsvereisten, de mogelijkheden die u wilt en de omgeving waarin u uw werkstromen wilt uitvoeren.

In de volgende tabel worden de verschillen tussen het resourcetype Logische app (Standard) en het resourcetype Logische app (verbruik) kort samengevat. U leert ook hoe de omgeving met één tenant zich verhoudt tot de ISE (Multi-Tenant and Integration Service Environment) voor het implementeren, hosten en uitvoeren van uw werkstromen voor logische apps.

Resource voor logische app (standard)

Het resourcetype Logic App (Standard) is powered by opnieuw ontworpen runtime met één tenant Azure Logic Apps runtime. Deze runtime maakt gebruik van Azure Functions model voor uitbreiding en wordt gehost als een extensie op 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 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.

Het resourcetype Standard introduceert een resourcestructuur die meerdere werkstromen kan hosten, vergelijkbaar met de manier waarop een Azure-functie-app meerdere functies kan hosten. Met een 1-op-veel-toewijzing delen werkstromen in dezelfde logische app en tenant reken- en verwerkingsbronnen, wat zorgt voor betere prestaties vanwege hun nabijheid. Deze structuur verschilt van de resource logische app (verbruik) waar u een 1-op-1-toewijzing hebt tussen een logische app-resource en een werkstroom.

Ga verder met de volgende secties voor meer informatie over de draagbaarheid, flexibiliteit en prestatieverbeteringen. Of bekijk de volgende documentatie voor meer informatie Azure Logic Apps runtime en Azure Functions-extensibility voor één tenant:

• Azure Logic Apps Running Anywhere - Runtime Deep Dive
• Inleiding tot Azure Functions
• Azure Functions-triggers en -bindingen

Draagbaarheid en flexibiliteit

Wanneer u logische apps maakt met het resourcetype Logic App (Standard), kunt u uw werkstromen implementeren en uitvoeren in andere omgevingen, zoals Azure App Service Environment v3. Als u Visual Studio Code gebruikt met de extensie Azure Logic Apps (Standard), kunt u uw werkstromen lokaal ontwikkelen, bouwen en uitvoeren in uw ontwikkelomgeving zonder dat u deze in Azure moet implementeren. Als voor uw scenario containers zijn vereist, maakt u logische apps met één tenant met Azure Arc ingeschakeld Logic Apps. Voor meer informatie bekijkt u Wat is Azure Arc ingeschakeld Logic Apps?

Deze mogelijkheden bieden belangrijke verbeteringen en aanzienlijke voordelen ten opzichte van het model met meerdere tenants. Hiervoor moet u ontwikkelen op een bestaande resource die wordt uitgevoerd in Azure. Het multi-tenant model voor het automatiseren van resource-implementatie van logische apps (verbruik) is bovendien volledig gebaseerd op Azure Resource Manager-sjablonen (ARM-sjablonen), waarmee resource-inrichting voor zowel apps als infrastructuur wordt gecombineerd en verwerkt.

Met het resourcetype Logische app (Standard) wordt de implementatie eenvoudiger omdat u app-implementatie kunt scheiden van de implementatie van de infrastructuur. U kunt de single-tenant Azure Logic Apps runtime en werkstromen samen verpakken als onderdeel van uw logische app. U kunt algemene stappen of taken gebruiken om resources van uw logische app te bouwen, samen te stellen en in te zipten in kant-en-klaar artefacten. Als u uw infrastructuur wilt implementeren, kunt u arm-sjablonen nog steeds gebruiken om deze resources afzonderlijk in terichten, 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 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 gebruik te maken van standaardopties voor bouwen en implementeren, kunt u zich richten op het ontwikkelen van apps, los van de implementatie van de infrastructuur. Als gevolg hiervan krijgt u een algemener projectmodel waarin u veel vergelijkbare of dezelfde implementatieopties kunt toepassen die u voor een algemene app gebruikt. U profiteert ook van een consistentere ervaring voor het bouwen van implementatiepijplijnen rond uw app-projecten en voor het uitvoeren van de vereiste tests en validaties voordat u naar productie publiceert.

Prestaties

Met behulp van het resourcetype Logische app (Standard) kunt u meerdere werkstromen maken en uitvoeren in dezelfde logische app en tenant. Met deze 1-op-veel-toewijzing delen deze werkstromen resources, zoals rekenkracht, verwerking, opslag en het netwerk, en bieden ze betere prestaties vanwege hun nabijheid.

Het resourcetype Logic App (Standard) en de Azure Logic Apps-runtime voor één tenant bieden nog een aanzienlijke verbetering door de populairste beheerde connectors beschikbaar te maken als ingebouwde bewerkingen. U kunt bijvoorbeeld ingebouwde bewerkingen gebruiken voor Azure Service Bus, Azure Event Hubs, SQL en andere. Ondertussen zijn de versies van de beheerde connector nog steeds beschikbaar en blijven ze werken.

Wanneer u de nieuwe ingebouwde bewerkingen 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 hun verbindingen worden lokaal uitgevoerd in hetzelfde proces waarin uw werkstromen worden uitgevoerd. Beide worden gehost op de runtime met Azure Logic Apps 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.

Gegevenslocatie

Resources van logische apps die zijn gemaakt met het resourcetype Logische app (Standard) worden gehost in een Azure Logic Apps met één tenant. Hierbij worden geen gegevens opgeslagen,verwerkt of gerepliceerd buiten de regio waar u deze resources voor logische apps implementeert. Dit betekent dat gegevens in de werkstromen van uw logische app in dezelfde regio blijven waar u de bovenliggende resources maakt en implementeert.

Opties voor maken, bouwen en implementeren

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

Omgeving met één tenant

Omgeving met meerdere tenants

Integratieserviceomgeving

Hoewel uw ontwikkelingservaring verschilt afhankelijk van of u resources voor logische apps voor verbruik of standaard maakt, kunt u al uw geïmplementeerde logische apps onder uw Azure-abonnement vinden en openen.

Op de pagina Logische Azure Portal ziet u bijvoorbeeld resourcetypen voor zowel verbruik als standaardlogica. In Visual Studio Code worden geïmplementeerde logische apps weergegeven onder uw Azure-abonnement, maar ze worden gegroepeerd op de extensie die u hebt gebruikt, namelijk Azure: Logic Apps (Consumption) en Azure: Logic Apps (Standard).

Stateful en staatloze werkstromen

Met het resourcetype Logische app (Standard) kunt u deze werkstroomtypen binnen dezelfde logische app maken:

• Stateful

  Maak een stateful werkstroom wanneer u gegevens uit eerdere gebeurtenissen wilt bewaren, controleren of er naar wilt verwijzen. Met deze werkstromen worden alle invoer en uitvoer voor elke actie en hun staat opgeslagen en overdragen naar externe opslag, waardoor de details en geschiedenis van de run kunnen worden beoordeeld nadat elke run is voltooid. Stateful werkstromen bieden hoge tolerantie als er uitval is. Nadat services en systemen zijn hersteld, kunt u onderbroken uitvoeringen reconstrueren vanuit de opgeslagen status en de werkstromen opnieuw tot voltooiing voltooien. Stateful werkstromen kunnen veel langer actief blijven dan staatloze werkstromen.

  Standaard worden stateful werkstromen in zowel multiten tenants als Azure Logic Apps asynchroon uitgevoerd. Alle HTTP-acties volgen het standaard asynchrone bewerkingspatroon. Dit patroon geeft aan dat de ontvanger na een HTTP-actie een aanvraag naar een eindpunt, service, systeem of API aanroept of verzendt, onmiddellijk een antwoord '202 ACCEPTED' retourneert. Deze code bevestigt dat de ontvanger de aanvraag heeft geaccepteerd, maar de verwerking nog niet heeft voltooid. Het antwoord kan een header bevatten die de URI en een vernieuwings-id specificeert die de aanroeper kan gebruiken om de status van de asynchrone aanvraag te peilen of te controleren totdat de ontvanger stopt met verwerken en een location '200 OK'-antwoord of een ander niet-202-antwoord retourneert. De aanroeper hoeft echter niet te wachten tot de aanvraag is verwerkt en kan de volgende actie blijven uitvoeren. Zie Asynchrone microserviceintegratie dwingt microservice-autonomieaf voor meer informatie.

• Stateless

  Maak een staatloze werkstroom wanneer u geen gegevens van eerdere gebeurtenissen in de externe opslag hoeft te bewaren, te controleren of hier naar te verwijzen nadat elke run is uitgevoerd voor latere beoordeling. Met deze werkstromen worden alle invoer en uitvoer voor elke actie en hun staat alleen in het geheugen opgeslagen, niet in externe opslag. Als gevolg hiervan hebben staatloze werkstromen kortere uitvoeringen die doorgaans minder dan vijf minuten zijn, snellere prestaties met snellere reactietijden, hogere doorvoer en lagere uitvoeringskosten, omdat de details en geschiedenis van de uitvoering niet worden opgeslagen in externe opslag. Als er echter uitval is, worden onderbroken runs niet automatisch hersteld, zodat de aanroeper onderbroken runs handmatig opnieuw moet doen.

  Belangrijk

  Een staatloze werkstroom biedt de beste prestaties bij het verwerken van gegevens of inhoud, zoals een bestand, die niet groter is dan 64 kB in totaal. Grotere inhoudsgrootten, zoals meerdere grote bijlagen, kunnen de prestaties van uw werkstroom aanzienlijk vertragen of zelfs leiden tot een crash van uw werkstroom vanwege out-of-memory-uitzonderingen. Als uw werkstroom mogelijk grotere inhoudsgrootten moet verwerken, gebruikt u in plaats daarvan een stateful werkstroom.

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

  Voor eenvoudigere debugging kunt u de uitvoeringsgeschiedenis inschakelen voor een staatloze werkstroom, die enige invloed heeft op de prestaties, en vervolgens de uitvoeringsgeschiedenis uitschakelen wanneer u klaar bent. Zie Werkstromen op basis van één tenant maken in Visual Studio Code of Werkstromen op basis van één tenant maken in de Azure Portal.

  Notitie

  Staatloze werkstromen ondersteunen momenteel alleen acties voor beheerde connectors, die zijn geïmplementeerd in Azure, en niet voor triggers. Als u de werkstroom wilt starten, selecteert u de ingebouwde aanvraag, Event Hubs of Service Bus trigger. Deze triggers worden standaard uitgevoerd in de Azure Logic Apps runtime. Zie Gewijzigde, beperkte, niet-beschikbare of niet-ondersteunde mogelijkheden voor meer informatie over beperkte, niet-beschikbare of niet-ondersteunde triggers, acties en connectors.

Geneste gedragsverschillen tussen stateful en staatloze werkstromen

U kunt een werkstroom aanroepbaar maken vanuit andere werkstromen die bestaan in dezelfde Logic App-resource (Standard) met behulp van de aanvraagtrigger, HTTP Webhook-triggerof beheerde connectortriggers die het type ApiConnectionWebhook hebben en HTTPS-aanvragen kunnen ontvangen.

Dit zijn de gedragspatronen die geneste werkstromen kunnen volgen nadat een bovenliggende werkstroom een onderliggende werkstroom aanroept:

• Asynchrone polling-patroon

  De bovenliggende instantie wacht niet op een reactie op de eerste aanroep, maar controleert voortdurend de geschiedenis van de onderliggende run totdat het onderliggende wordt uitgevoerd. Stateful werkstromen volgen standaard dit patroon, wat ideaal is voor langlopende onderliggende werkstromen die de time-outlimieten voor aanvragen kunnen overschrijden.

• Synchroon patroon ('fire and forget')

  Het onderliggende antwoord bevestigt de aanroep door onmiddellijk een antwoord te retourneren en de bovenliggende actie gaat door met de volgende actie zonder te wachten op 202 ACCEPTED de resultaten van het onderliggende antwoord. In plaats daarvan ontvangt het bovenliggende resultaat wanneer het onderliggende wordt uitgevoerd. Onderliggende stateful werkstromen die geen antwoordactie bevatten, volgen altijd het synchrone patroon. Voor onderliggende stateful werkstromen is de run history beschikbaar die u kunt bekijken.

  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

  Voor een onderliggende staatloze werkstroom wacht de bovenliggende werkstroom op een antwoord dat de resultaten van het onderliggende antwoord retourneert. Dit patroon werkt vergelijkbaar met 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 antwoord, maar het bovenliggende antwoord wacht tot het onderliggende proces is voltooien voordat de volgende 202 ACCEPTED actie wordt voortgezet. Dit gedrag is alleen van toepassing op onderliggende staatloze werkstromen.

In deze tabel wordt het gedrag van de onderliggende werkstroom opgegeven op basis van of de bovenliggende en onderliggende werkstroom stateful, staatloos of gemengde werkstroomtypen zijn:

Andere modelmogelijkheden voor één tenant

Het model met één tenant en het resourcetype Logische app (Standard) bevatten veel huidige en nieuwe mogelijkheden, bijvoorbeeld:

• Logische apps en hun werkstromen maken op basis van meer dan 400 beheerde connectors voor SaaS-apps (Software-as-a-Service) en PaaS-apps en -services (Platform-as-a-Service), plus connectors voor on-premises systemen.

  • Meer beheerde connectors zijn nu beschikbaar als ingebouwde bewerkingen en worden op dezelfde manier uitgevoerd als andere ingebouwde bewerkingen, zoals Azure Functions. Ingebouwde bewerkingen worden standaard uitgevoerd op de single-tenant Azure Logic Apps runtime. Nieuwe ingebouwde bewerkingen zijn bijvoorbeeld Azure Service Bus, Azure Event Hubs, SQL Server, MQ, DB2 en IBM Host File.

    Notitie

    Voor de ingebouwde SQL Server kan alleen de actie Query uitvoeren rechtstreeks verbinding maken met virtuele Netwerken van Azure zonder de on-premises gegevensgateway te gebruiken.

  • U kunt uw eigen ingebouwde connectors maken voor elke service die u nodig hebt, met behulp van het framework voor Azure Logic Apps van één tenant. Net als bij ingebouwde bewerkingen zoals Azure Service Bus en SQL Server, maar in tegenstelling tot aangepaste beheerde connectors, die momenteel niet worden ondersteund, bieden aangepaste ingebouwde connectors een hogere doorvoer, lage latentie en lokale connectiviteit omdat ze worden uitgevoerd in hetzelfde proces als de runtime voor één tenant.

    De ontwerpmogelijkheid is momenteel alleen beschikbaar in Visual Studio Code, maar is niet standaard ingeschakeld. Als u deze connectors wilt maken, schakelt u uw project over van extensiebundels (Node.js) naar NuGet-pakketten (.NET). Zie Running Anywhere Azure Logic Apps - Ingebouwde connector-extensibility voor meer informatie.

  • U kunt de volgende acties gebruiken voor Liquid-bewerkingen en XML-bewerkingen zonder een 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 transformeren naar tekst

    Notitie

    Als u deze acties wilt gebruiken in Azure Logic Apps met één tenant (Standard), moet u Liquid-kaarten, XML-kaarten of XML-schema's hebben. U kunt deze artefacten in de Azure Portal uploaden vanuit het resourcemenu van uw logische app, onder Artefacten, dat de secties Schema's en Kaarten bevat. U kunt deze artefacten ook toevoegen aan de map Artifacts van uw Visual Studio Code-project met behulp van de respectievelijke mappen Kaarten en Schema's. U kunt deze artefacten vervolgens gebruiken voor meerdere werkstromen binnen dezelfde logische app-resource.

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

    Notitie

    Standaard is voor het resourcetype Logische app (Standard) de door het systeem toegewezen beheerde identiteit automatisch ingeschakeld om verbindingen tijdens run time te verifiëren. Deze identiteit wijkt af van de verificatiereferenties of connection string u gebruikt wanneer u een verbinding maakt. Als u deze identiteit uit schakelen, werken verbindingen niet tijdens run time. Als u deze instelling wilt weergeven, selecteert u in het menu van uw logische app onder Instellingen de optie Identiteit.

    De door de gebruiker toegewezen beheerde identiteit is momenteel niet beschikbaar in het resourcetype Logische app (Standaard).

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

  Voordat u uw logische app gaat uitvoeren en testen, kunt u debuggen eenvoudiger maken door onderbrekingspunten toe te voegen en te gebruiken in het bestand workflow.json voor een werkstroom. Onderbrekingspunten worden op dit moment echter alleen ondersteund voor acties, niet voor triggers. Zie Create single-tenant based workflows in Visual Studio Code (Werkstromenmet één tenant maken in Visual Studio Code) voor meer informatie.

• Logische apps en hun werkstromen rechtstreeks publiceren of implementeren vanuit Visual Studio Code naar verschillende hostingomgevingen, zoals Azure en Azure Arc ingeschakelde Logic Apps.

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

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

  • Netwerkopties van Azure Functions

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

• Toegangssleutels opnieuw maken voor beheerde verbindingen die worden gebruikt door afzonderlijke werkstromen in een Logic App-resource (Standard). Voor deze taak volgt u dezelfde stappen voor de resource Logic Apps (verbruik),maar op afzonderlijk werkstroomniveau, niet op het resourceniveau van de logische app.

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

Voor de resource van de logische app (Standard) zijn deze mogelijkheden gewijzigd of zijn ze momenteel beperkt, niet beschikbaar of niet ondersteund:

• Triggers en acties: ingebouwde triggers en acties worden standaard uitgevoerd in Azure Logic Apps, terwijl beheerde connectors worden gehost en uitgevoerd in Azure. Sommige ingebouwde triggers en acties zijn niet beschikbaar, zoals Sliding Window, Batch, Azure-app Services en Azure API Management. Gebruik de ingebouwde trigger Recurrence, Request, HTTP, HTTP Webhook, Event Hubsof Service Bus om een stateful of stateless werkstroom te starten. In de ontwerpfunctie worden ingebouwde triggers en acties weergegeven op het tabblad Ingebouwd.

  Voor stateful werkstromen worden triggers en acties van beheerde connectors weergegeven op het tabblad Azure, met uitzondering van de hieronder vermelde niet-beschikbare bewerkingen. Voor staatloze werkstromen wordt het Azure-tabblad niet weergegeven wanneer u een trigger wilt selecteren. U kunt alleen acties voor beheerde connectors selecteren, niet triggers. Hoewel u door Azure gehoste beheerde connectors kunt inschakelen voor staatloze werkstromen, toont de ontwerpfunctie geen triggers voor beheerde connectors die u kunt toevoegen.

  Notitie

  Als u lokaal wilt uitvoeren in Visual Studio Code, moeten op webhook gebaseerde triggers en acties extra worden ingesteld. Zie Create single-tenant based workflows in Visual Studio Code (Werkstromenmet één tenant maken in Visual Studio Code) voor meer informatie.

  • Deze triggers en acties zijn gewijzigd of zijn momenteel beperkt, niet-ondersteund of niet beschikbaar:

    • On-premises gegevensgatewaytriggers zijn niet beschikbaar, maar gatewayacties zijn wel beschikbaar.

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

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

      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 bij het model met meerdere tenants werkt de functieactie niet meer als u deze sleutel vernieuwt, bijvoorbeeld 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 opnieuw maken of de instellingen van uw app bijwerken met de nieuwe sleutel.

    • De ingebouwde actie, Inline Code,heeft de naam Inline Code Operations, heeft geen integratieaccount meer nodig en heeft bijgewerkte limieten.

    • De ingebouwde actie, Azure Logic Apps: een logic app-werkstroom kiezen is nu Werkstroombewerkingen - Een werkstroom aanroepen in deze werkstroom-app.

    • Sommige triggers en acties voor integratieaccounts zijn niet beschikbaar, bijvoorbeeld de ACTIES AS2 (V2) en RosettaNet.

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

• Verificatie: de volgende verificatietypen zijn momenteel niet beschikbaar voor het resourcetype Logische app (Standard) :

  • Azure Active Directory Open Verificatie (Azure AD OAuth) voor binnenkomende aanroepen naar triggers op basis van aanvragen, zoals de aanvraagtrigger en http-webhooktrigger.

  • Door de gebruiker toegewezen beheerde identiteit. Momenteel is alleen de door het systeem toegewezen beheerde identiteit beschikbaar en automatisch ingeschakeld.

• XML-transformatie: ondersteuning voor het verwijzen naar assemblies vanuit kaarten is momenteel niet beschikbaar. Bovendien wordt momenteel alleen XSLT 1.0 ondersteund.

• Onderbrekingspuntopsporing in Visual Studio Code: hoewel u onderbrekingspunten in het bestand workflow.json voor een werkstroom kunt toevoegen en gebruiken, worden onderbrekingspunten momenteel alleen ondersteund voor acties, niet voor triggers. Zie Create single-tenant based workflows in Visual Studio Code (Werkstromenmet één tenant maken in Visual Studio Code) voor meer informatie.

• Triggergeschiedenis en-run history: voor het resourcetype Logische app (Standard) worden de triggergeschiedenis en de run history in de Azure Portal weergegeven op werkstroomniveau, niet op het niveau van de logische app. Voor meer informatie bekijkt u Werkstromen met één tenant maken met behulp van de Azure Portal.

• Besturingselement voor zoomen: het zoombesturingselement is momenteel niet beschikbaar in de ontwerpfunctie.

• Implementatiedoelen: u kunt het resourcetype van de logische app (Standard) niet implementeren in een ISE (Integration Service Environment) en niet op Azure-implementatiesleuven.

• Azure API Management: u kunt het resourcetype logische app (Standard) momenteel niet importeren in Azure API Management. U kunt echter het resourcetype Logische app (verbruik) importeren.

Strikte netwerk- en firewallverkeersmachtigingen

Als uw omgeving strikte netwerkvereisten of firewalls heeft die het verkeer beperken, moet u toegang toestaan voor trigger- of actieverbindingen in uw logische app-werkstromen. Als u de FQDN's (Fully Qualified Domain Names) voor deze verbindingen wilt vinden, bekijkt u de bijbehorende secties in deze onderwerpen:

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

Volgende stappen

• Werkstromen op basis van één tenant maken in de Azure Portal
• Werkstromen op basis van één tenant maken in Visual Studio Code

We horen graag meer over uw ervaringen met een single-tenant Azure Logic Apps.

• Maak voor fouten of problemen uw problemen in GitHub.
• Gebruik dit feedbackformulier voor vragen, aanvragen, opmerkingen en andere feedback.