Problemen met werkstromen in Azure Logic Apps vaststellen en oplossen

Van toepassing op: Azure Logic Apps (verbruik + standaard)

De werkstroom van de logische app genereert informatie die u kan helpen bij het diagnosticeren en opsporen van problemen in uw app. U kunt uw werkstroom diagnosticeren door de invoer, uitvoer en andere informatie voor elke stap in de werkstroom te controleren met behulp van de Azure Portal. U kunt ook enkele stappen toevoegen aan een werkstroom voor runtime-foutopsporing.

Triggergeschiedenis controleren

Elke werkstroomuitvoering begint met een trigger, die volgens een schema wordt geactiveerd of wacht op een binnenkomende aanvraag of gebeurtenis. De triggergeschiedenis bevat alle triggerpogingen die uw werkstroom heeft uitgevoerd en informatie over de invoer en uitvoer voor elke triggerpoging. Als de trigger niet wordt geactiveerd, probeert u de volgende stappen.

Verbruik

1. Als u de status van de trigger in uw logische app Verbruik wilt controleren, controleert u de triggergeschiedenis. Als u meer informatie over de triggerpoging wilt weergeven, selecteert u die trigger-gebeurtenis, bijvoorbeeld:

   

2. Controleer de invoer van de trigger om te bevestigen dat deze worden weergegeven zoals u verwacht. Selecteer in het deelvenster Geschiedenis onder de koppeling Invoer de koppeling, die het deelvenster Invoer weergeeft.

   Triggerinvoer bevat de gegevens die de trigger verwacht en nodig heeft om de werkstroom te starten. Als u deze invoer controleert, kunt u bepalen of de triggerinvoer juist is en of aan de voorwaarde is voldaan, zodat de werkstroom kan worden voortgezet.

   

3. Controleer de uitvoer van de triggers, indien van toepassing, om te bevestigen dat ze worden weergegeven zoals u verwacht. Selecteer in het deelvenster Geschiedenis onder de koppeling Uitvoer de koppeling, waarmee het deelvenster Uitvoer wordt weergegeven.

   Triggeruitvoer bevat de gegevens die de trigger doorgeeft aan de volgende stap in uw werkstroom. Als u deze uitvoer bekijkt, kunt u bepalen of de juiste of verwachte waarden worden doorgegeven aan de volgende stap in uw werkstroom.

   In een foutbericht wordt bijvoorbeeld aangegeven dat de RSS-feed niet is gevonden:

   

   Tip

   Als u inhoud vindt die u niet herkent, vindt u hier meer informatie over verschillende inhoudstypen in Azure Logic Apps.

Standard

1. Als u de status van de trigger wilt controleren in uw logische standaard-app, bekijkt u de triggergeschiedenis. Als u meer informatie over de triggerpoging wilt weergeven, selecteert u die trigger-gebeurtenis, bijvoorbeeld:

   

2. Controleer de invoer van de trigger om te bevestigen dat deze worden weergegeven zoals u verwacht. Selecteer in het deelvenster Geschiedenis onder de koppeling Invoer de koppeling, die het deelvenster Invoer weergeeft.

   Triggerinvoer bevat de gegevens die de trigger verwacht en nodig heeft om de werkstroom te starten. Als u deze invoer controleert, kunt u bepalen of de triggerinvoer juist is en of aan de voorwaarde is voldaan, zodat de werkstroom kan worden voortgezet.

   

3. Controleer de uitvoer van de triggers, indien van toepassing, om te bevestigen dat ze worden weergegeven zoals u verwacht. Selecteer in het deelvenster Geschiedenis onder de koppeling Uitvoer de koppeling, waarmee het deelvenster Uitvoer wordt weergegeven.

   Triggeruitvoer bevat de gegevens die de trigger doorgeeft aan de volgende stap in uw werkstroom. Als u deze uitvoer bekijkt, kunt u bepalen of de juiste of verwachte waarden worden doorgegeven aan de volgende stap in uw werkstroom.

   In een foutbericht wordt bijvoorbeeld aangegeven dat de RSS-feed niet is gevonden:

   

   Tip

   Als u inhoud vindt die u niet herkent, vindt u hier meer informatie over verschillende inhoudstypen in Azure Logic Apps.

Uitvoeringsgeschiedenis van werkstroom controleren

Telkens wanneer de trigger wordt geactiveerd, maakt Azure Logic Apps een werkstroomexemplaar en wordt dat exemplaar uitgevoerd. Als een uitvoering mislukt, voert u de volgende stappen uit, zodat u kunt controleren wat er tijdens die uitvoering is gebeurd. U kunt de status, invoer en uitvoer voor elke stap in de werkstroom bekijken.

Verbruik

1. Als u de uitvoeringsstatus van de werkstroom in uw logische app Verbruik wilt controleren, bekijkt u de uitvoeringsgeschiedenis. Als u meer informatie wilt weergeven over een mislukte uitvoering, inclusief alle stappen in die uitvoering in hun status, selecteert u de mislukte uitvoering.

   

2. Nadat alle stappen in de uitvoering zijn weergegeven, selecteert u elke stap om de shapes uit te vouwen.

   

3. Controleer de invoer, uitvoer en eventuele foutberichten voor de mislukte stap.

   

   In de volgende schermopname ziet u bijvoorbeeld de uitvoer van de mislukte RSS-actie.

   

Standard

1. Als u de uitvoeringsstatus van de werkstroom wilt controleren in uw logische Standaard-app, bekijkt u de uitvoeringsgeschiedenis. Als u meer informatie wilt weergeven over een mislukte uitvoering, inclusief alle stappen in die uitvoering in hun status, selecteert u de mislukte uitvoering.

   

2. Nadat alle stappen in de uitvoering zijn weergegeven, selecteert u elke stap om de details ervan te bekijken.

   

3. Controleer de invoer, uitvoer en eventuele foutberichten voor de mislukte stap.

   

   In de volgende schermopname ziet u bijvoorbeeld de uitvoer van de mislukte RSS-actie.

   

Fouten in runtime opsporen

Voor hulp bij foutopsporing kunt u diagnostische stappen toevoegen aan een werkstroom van een logische app, samen met het controleren van de trigger en de uitvoeringsgeschiedenis. U kunt bijvoorbeeld stappen toevoegen die gebruikmaken van de Webhook Tester-service , zodat u HTTP-aanvragen kunt inspecteren en de exacte grootte, vorm en indeling kunt bepalen.

1. Ga in een browser naar de Webhook Tester-site en kopieer de gegenereerde unieke URL.

2. Voeg in uw logische app een HTTP POST-actie toe met de hoofdtekstinhoud die u wilt testen, bijvoorbeeld een expressie of uitvoer van een andere stap.

3. Plak uw URL van Webhook Tester in de HTTP POST-actie.

4. Als u wilt controleren hoe Azure Logic Apps een aanvraag genereert en indient, voert u de werkstroom van de logische app uit. U kunt vervolgens teruggaan naar de Webhook Tester-site voor meer informatie.

Prestaties - veelgestelde vragen (FAQ)

Waarom is de duur van de werkstroomuitvoering langer dan de som van alle duur van de werkstroomactie?

Planningsoverhead bestaat bij het uitvoeren van acties, terwijl wachttijd tussen acties kan plaatsvinden vanwege de belasting van het back-endsysteem. De duur van een werkstroomuitvoering bevat deze planningstijden en wachttijden, samen met de som van alle actieduur.

Meestal wordt mijn werkstroom binnen 10 seconden voltooid. Maar soms kan voltooiing veel langer duren. Hoe kan ik ervoor zorgen dat de werkstroom altijd binnen 10 seconden is voltooid?

• Er bestaat geen SLA-garantie voor latentie.

• Verbruikswerkstromen worden uitgevoerd op Azure Logic Apps met meerdere tenants, zodat de workloads van andere klanten mogelijk een negatieve invloed hebben op de prestaties van uw werkstroom.

• Voor meer voorspelbare prestaties kunt u overwegen om standaardwerkstromen te maken, die worden uitgevoerd in Azure Logic Apps met één tenant. U hebt meer controle om omhoog of uit te schalen om de prestaties te verbeteren.

Na 2 minuten treedt er een time-out op voor mijn actie. Hoe kan ik de time-outwaarde verhogen?

De time-outwaarde van de actie kan niet worden gewijzigd en staat vast op 2 minuten. Als u de HTTP-actie gebruikt en u eigenaar bent van de service die wordt aangeroepen door de HTTP-actie, kunt u de service wijzigen om de time-out van twee minuten te voorkomen met behulp van het asynchrone patroon. Zie Langlopende taken uitvoeren met het actiepatroon polling voor meer informatie.

Veelvoorkomende problemen - Logische standaard-apps

Niet-toegankelijke artefacten in Azure Storage-account

Standaard logische apps slaan alle artefacten op in een Azure-opslagaccount. Mogelijk krijgt u de volgende fouten als deze artefacten niet toegankelijk zijn. Het opslagaccount zelf is bijvoorbeeld mogelijk niet toegankelijk of het opslagaccount bevindt zich achter een firewall, maar er is geen privé-eindpunt ingesteld voor het gebruik van de opslagservices.

Azure Portal locatie	Fout
Overzichtsdeelvenster	- System.private.corelib:Toegang tot het pad 'C:\home\site\wwwroot\hostj.son is geweigerd - Azure.Storage.Blobs: deze aanvraag is niet gemachtigd om deze bewerking uit te voeren
Deelvenster Werkstromen	- Kan de hostruntime niet bereiken. Foutdetails, code: 'BadRequest', bericht: 'Er is een fout opgetreden (InternalServerError) van de hostruntime.' - Kan de hostruntime niet bereiken. Foutdetails, code: 'BadRequest', bericht: 'Er is een fout opgetreden (ServiceUnavailable) van de hostruntime.' - Kan de hostruntime niet bereiken. Foutdetails, code: 'BadRequest', bericht: 'Er is een fout opgetreden (BadGateway) van hostruntime.'
Tijdens het maken en uitvoeren van de werkstroom	- Kan de werkstroom niet opslaan - Fout in de ontwerpfunctie: GetCallFailed. Kan de bewerkingen niet ophalen - ajaxExtended-aanroep is mislukt

Opties voor probleemoplossing

De volgende lijst bevat mogelijke oorzaken voor deze fouten en stappen voor hulp bij het oplossen van problemen.

• Voor een openbaar opslagaccount controleert u de toegang tot het opslagaccount op de volgende manieren:

  • Controleer de connectiviteit van het opslagaccount met behulp van Azure Storage Explorer.

  • Controleer in de app-instellingen van uw logische app-resource de connection string van het opslagaccount in de app-instellingen, AzureWebJobsStorage en WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Raadpleeg Host- en app-instellingen voor logische apps in Azure Logic Apps met één tenant voor meer informatie.

  Als de verbinding mislukt, controleert u of de SAS-sleutel (Shared Access Signature) in de connection string de meest recente is.

• Voor een opslagaccount dat zich achter een firewall bevindt, controleert u de toegang tot het opslagaccount op de volgende manieren:

  • Als firewallbeperkingen zijn ingeschakeld voor het opslagaccount, controleert u of privé-eindpunten zijn ingesteld voor blob-, bestands-, tabel- en wachtrijopslagservices.

  • Controleer de connectiviteit van het opslagaccount met behulp van Azure Storage Explorer.

  Als u verbindingsproblemen ondervindt, gaat u verder met de volgende stappen:

  1. Maak in hetzelfde virtuele netwerk dat is geïntegreerd met uw logische app een virtuele Azure-machine, die u in een ander subnet kunt plaatsen.

  2. Voer vanaf een opdrachtprompt nslookup uit om te controleren of de blob-, bestands-, tabel- en wachtrijopslagservices worden omgezet in de verwachte IP-adressen.

     Syntaxis: nslookup [StorageaccountHostName] [OptionalDNSServer]

     Blob: nslookup {StorageaccountName}.blob.core.windows.net

     Bestand: nslookup {StorageaccountName}.file.core.windows.net

     Tabel: nslookup {StorageaccountName}.table.core.windows.net

     Wachtrij: nslookup {StorageaccountName}.queue.core.windows.net

     • Als de opslagservice een service-eindpunt heeft, wordt de service omgezet in een openbaar IP-adres.

     • Als de opslagservice een privé-eindpunt heeft, wordt de service omgezet naar de respectieve privé-IP-adressen van de netwerkinterfacecontroller (NIC).

  3. Als de vorige DNS-query's (domain name server) worden opgelost, voert u de psping - of tcpping-opdrachten uit om de connectiviteit met het opslagaccount via poort 443 te controleren:

     Syntaxis: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

     Blob: psping {StorageaccountName}.blob.core.windows.net:443

     Bestand: psping {StorageaccountName}.file.core.windows.net:443

     Tabel: psping {StorageaccountName}.table.core.windows.net:443

     Wachtrij: psping {StorageaccountName}.queue.core.windows.net:443

  4. Als elke opslagservice kan worden omgezet vanaf uw virtuele Azure-machine, zoekt u de DNS die door de virtuele machine wordt gebruikt voor omzetting.

     1. Stel de instelling voor de WEBSITE_DNS_SERVER app van uw logische app in op de DNS en controleer of de DNS correct werkt.

     2. Controleer of VNet-integratie juist is ingesteld met het juiste virtuele netwerk en subnet in uw logische standaard-app.

  5. Als u privé-Azure DNS-zones gebruikt voor de privé-eindpuntservices van uw opslagaccount, controleert u of er een koppeling naar het virtuele netwerk van uw logische app is gemaakt.

Raadpleeg Logische standaard-app implementeren in een opslagaccount achter een firewall met behulp van service- of privé-eindpunten voor meer informatie.

Volgende stappen

• Uw logische app bewaken