Om anslutningsappar i Azure Logic Apps

När du skapar arbetsflöden med hjälp av Azure Logic Apps kan du använda anslutningsappar för att snabbt och enkelt komma åt data, händelser och resurser i andra appar, tjänster, system, protokoll och plattformar – ofta utan att behöva skriva någon kod. En anslutningsapp innehåller fördefinierade åtgärder som du kan använda som steg i dina arbetsflöden. Azure Logic Apps innehåller hundratals anslutningsappar som du kan använda. Om ingen anslutningsapp är tillgänglig för den resurs som du vill komma åt kan du använda den allmänna HTTP-åtgärden för att kommunicera med tjänsten, eller så kan du skapa en anpassad anslutningsapp.

Den här översikten ger en introduktion till anslutningsappar på hög nivå och hur de i allmänhet fungerar. Information om de mer populära och vanliga anslutningsprogrammen i Azure Logic Apps finns i följande dokumentation:

Vad är anslutningsappar?

Tekniskt sett är en anslutningsapp en proxy eller en adapter runt ett API som den underliggande tjänsten använder för att kommunicera med Azure Logic Apps. Den här anslutningsappen tillhandahåller åtgärder som du använder i dina arbetsflöden för att utföra uppgifter. En åtgärd är tillgänglig som en utlösare eller åtgärd med egenskaper som du kan konfigurera. Vissa utlösare och åtgärder kräver också att du först skapar och konfigurerar en anslutning till den underliggande tjänsten eller systemet, till exempel så att du kan autentisera åtkomsten till ett användarkonto. Mer översiktsinformation finns i Översikt över anslutningsappar för Azure Logic Apps, Microsoft Power Automate och Microsoft Power Apps.

Utlösare

En utlösare anger händelsen som startar arbetsflödet och är alltid det första steget i alla arbetsflöden. Varje utlösare följer också ett specifikt avfyrningsmönster som styr hur utlösaren övervakar och svarar på händelser. Vanligtvis följer en utlösare avsökningsmönstret eller push-mönstret , men ibland är en utlösare tillgänglig i båda versionerna.

  • Sökningsutlösare kontrollerar regelbundet en viss tjänst eller ett visst system enligt ett angivet schema för att söka efter nya data eller en specifik händelse. Om nya data är tillgängliga, eller om den specifika händelsen inträffar, skapar och kör dessa utlösare en ny instans av arbetsflödet. Den nya instansen kan sedan använda de data som skickas som indata.

  • Push-utlösare lyssnar efter nya data eller för att en händelse ska inträffa, utan avsökning. När nya data är tillgängliga, eller när händelsen inträffar, skapar och kör dessa utlösare en ny instans av arbetsflödet. Den nya instansen kan sedan använda de data som skickas som indata.

Du kanske till exempel vill skapa ett arbetsflöde som gör något när en fil laddas upp till FTP-servern. Som det första steget i arbetsflödet kan du använda FTP-utlösaren med namnet När en fil läggs till eller ändras, vilket följer avsökningsmönstret. Du kan sedan ange ett schema för att regelbundet söka efter uppladdningshändelser.

En utlösare skickar även alla indata och andra nödvändiga data till arbetsflödet där senare åtgärder kan referera till och använda dessa data i hela arbetsflödet. Anta till exempel att du vill använda Office 365 Outlook utlösare med namnet När ett nytt e-postmeddelande kommer för att starta ett arbetsflöde när du får ett nytt e-postmeddelande. Du kan konfigurera den här utlösaren så att den vidarebefordrar innehållet från varje nytt e-postmeddelande, till exempel avsändaren, ämnesraden, brödtexten, bifogade filer och så vidare. Arbetsflödet kan sedan bearbeta informationen med hjälp av andra åtgärder.

Åtgärder

En åtgärd är en åtgärd som följer utlösaren och utför någon typ av uppgift i arbetsflödet. Du kan använda flera åtgärder i arbetsflödet. Du kan till exempel starta arbetsflödet med en SQL utlösare som identifierar nya kunddata i en SQL databas. Efter utlösaren kan arbetsflödet ha en SQL åtgärd som hämtar kunddata. Efter den SQL åtgärden kan arbetsflödet ha en annan åtgärd, inte nödvändigtvis SQL, som bearbetar data.

Anslutningskategorier

I Azure Logic Apps är de flesta utlösare och åtgärder tillgängliga i antingen en inbyggd version eller i en hanterad anslutningsversion. Några utlösare och åtgärder är tillgängliga i båda versionerna. Vilka versioner som är tillgängliga beror på om du skapar en förbrukningslogikapp som körs i Azure Logic Apps för flera klientorganisationer eller en standardlogikapp som körs i Azure Logic Apps.

  • Inbyggda anslutningsappar körs internt på Azure Logic Apps-körning.

  • Hanterade anslutningsappar distribueras, hanteras och hanteras av Microsoft. Dessa anslutningsappar tillhandahåller utlösare och åtgärder för molntjänster, lokala system eller både och.

    I en standardlogikapp ordnas alla hanterade anslutningsappar som Azure-anslutningsappar . Men i en förbrukningslogikapp ordnas hanterade anslutningsappar som Standard eller Enterprise, baserat på prisnivå.

Mer information om logikapptyper finns i Resurstyper och skillnader i värdmiljö.

Anslutningskonfiguration

Innan du kan skapa eller hantera logikappar och deras anslutningar i Förbrukningslogikappar behöver du specifika behörigheter. Mer information om dessa behörigheter finns i Säkra åtgärder – Säker åtkomst och data i Azure Logic Apps.

Innan du kan använda utlösare eller åtgärder för en hanterad anslutningsapp i arbetsflödet kräver många anslutningsappar att du först skapar en anslutning till måltjänsten eller systemet. Om du vill skapa en anslutning inifrån logikappens arbetsflödesdesigner måste du autentisera din identitet med kontoautentiseringsuppgifter och ibland annan anslutningsinformation. Innan arbetsflödet till exempel kan komma åt och arbeta med ditt Office 365 Outlook e-postkonto måste du auktorisera en anslutning till det kontot. För vissa inbyggda anslutningsappar och hanterade anslutningsappar kan du konfigurera och använda en hanterad identitet för autentisering i stället för att ange dina autentiseringsuppgifter.

Även om du skapar anslutningar i ett arbetsflöde är dessa anslutningar i själva verket separata Azure-resurser med sina egna resursdefinitioner. Om du vill granska dessa definitioner för anslutningsresurser följer du dessa steg baserat på om du har en förbruknings- eller standardlogikapp:

Anslutningssäkerhet och kryptering

Information om anslutningskonfiguration, till exempel serveradress, användarnamn och lösenord, autentiseringsuppgifter och hemligheter krypteras och lagras i den skyddade Azure-miljön. Den här informationen kan endast användas i logikappresurser och av klienter som har behörighet för anslutningsresursen, som framtvingas med hjälp av länkade åtkomstkontroller. Anslutningar som använder Azure Active Directory öppen autentisering (Azure AD OAuth), till exempel Office 365, Salesforce och GitHub, kräver att du loggar in, men Azure Logic Apps lagrar endast åtkomst- och uppdateringstoken som hemligheter, inte inloggning Autentiseringsuppgifter.

Etablerade anslutningar kan komma åt måltjänsten eller systemet så länge tjänsten eller systemet tillåter det. För tjänster som använder Azure AD OAuth-anslutningar, till exempel Office 365 och Dynamics, uppdaterar Azure Logic Apps åtkomsttoken på obestämd tid. Andra tjänster kan ha gränser för hur länge Logic Apps kan använda en token utan att uppdatera. Vissa åtgärder, till exempel att ändra ditt lösenord, ogiltigförklarar alla åtkomsttoken.

Tips

Om din organisation inte tillåter dig att komma åt specifika resurser via anslutningsappar i Azure Logic Apps kan du blockera möjligheten att skapa sådana anslutningar med hjälp av Azure Policy.

Mer information om hur du skyddar logikappar och anslutningar finns i Säker åtkomst och data i Azure Logic Apps.

Brandväggsåtkomst för anslutningar

Om du använder en brandvägg som begränsar trafiken och dina logikappsarbetsflöden behöver kommunicera via brandväggen måste du konfigurera brandväggen för att tillåta åtkomst för både de inkommande och utgående IP-adresserna som används av Azure Logic Apps-plattformen eller körningen i Den Azure-region där logikappens arbetsflöden finns. Om dina arbetsflöden också använder hanterade anslutningsappar, till exempel Office 365 Outlook-anslutningsappen eller SQL-anslutningsappen, eller använder anpassade anslutningsappar, måste brandväggen även tillåta åtkomst för allautgående IP-adresser för hanterade anslutningsappar i logikappens Azure-region. Mer information finns i Brandväggskonfiguration.

Upprepningsbeteende

Återkommande inbyggda utlösare, till exempel upprepningsutlösaren, körs internt på Azure Logic Apps-körningen och skiljer sig från återkommande anslutningsbaserade utlösare, till exempel utlösaren för Office 365 Outlook-anslutningsappen där du måste skapa en anslutning först.

För båda typerna av utlösare, om en upprepning inte anger ett specifikt startdatum och en viss tid, körs den första upprepningen omedelbart när du sparar eller distribuerar logikappen, trots utlösarens upprepningskonfiguration. Undvik det här beteendet genom att ange ett startdatum och en tidpunkt för när du vill att den första upprepningen ska köras.

Vissa hanterade anslutningsappar har både upprepningsbaserade och webhookbaserade utlösare, så om du använder en upprepningsbaserad utlösare läser du översikten över upprepningsbeteende.

Upprepning för inbyggda utlösare

Återkommande inbyggda utlösare följer det schema som du anger, inklusive en angiven tidszon. Men om en upprepning inte anger andra avancerade schemaläggningsalternativ, till exempel specifika tider för att köra framtida upprepningar, baseras dessa upprepningar på den senaste utlösarkörningen. Därför kan starttiderna för dessa upprepningar påverkas på grund av faktorer som svarstid under lagringsanrop.

Mer information finns i följande dokumentation:

Upprepning för anslutningsbaserade utlösare

I återkommande anslutningsbaserade utlösare, till exempel Office 365 Outlook, är schemat inte den enda drivrutinen som styr körningen. Tidszonen avgör bara den första starttiden. Efterföljande körningar beror på upprepningsschemat, den senaste utlösarkörningen och andra faktorer som kan orsaka att körningstiderna driver eller ger oväntat beteende, till exempel:

  • Om utlösaren kommer åt en server som har mer data, som utlösaren omedelbart försöker hämta.
  • Eventuella fel eller återförsök som utlösaren medför.
  • Svarstid under lagringsanrop.
  • Inte upprätthålla det angivna schemat när sommartid (DST) startar och slutar.
  • Andra faktorer som kan påverka när nästa körningstid inträffar.

Mer information finns i följande dokumentation:

Felsöka återkommande problem

Prova följande lösningar för att se till att arbetsflödet körs vid den angivna starttiden och inte missar en upprepning, särskilt när frekvensen är i dagar eller längre:

  • När DST börjar gälla justerar du upprepningen manuellt så att arbetsflödet fortsätter att köras vid den förväntade tidpunkten. Annars flyttas starttiden en timme framåt när DST startar och en timme bakåt när DST slutar. Mer information och exempel finns i Upprepning för sommartid och standardtid.

  • Om du använder en upprepningsutlösare anger du en tidszon, ett startdatum och starttid. Konfigurera dessutom specifika tider för att köra efterföljande upprepningar i egenskaperna Vid dessa timmar och Vid dessa minuter, som endast är tillgängliga för frekvenserna Dag och Vecka . Vissa tidsfönster kan dock fortfarande orsaka problem när tiden skiftar.

  • Överväg att använda en skjutfönsterutlösare i stället för en upprepningsutlösare för att undvika missade upprepningar.

Anpassade anslutningsappar och API:er

I Förbrukningslogikappar som körs i Azure Logic Apps för flera klientorganisationer kan du anropa Swagger-baserade eller SOAP-baserade API:er som inte är tillgängliga som färdiga anslutningsappar. Du kan också köra anpassad kod genom att skapa anpassade API Apps. Mer information finns i följande dokumentation:

I Standard-logikappar som körs i Azure Logic Apps med en enda klientorganisation kan du skapa inbyggda tjänstleverantörsbaserade anpassade inbyggda anslutningsappar som är tillgängliga för alla standardlogikappar. Mer information finns i följande dokumentation:

ISE och anslutningsappar

För arbetsflöden som behöver direkt åtkomst till resurser i ett virtuellt Azure-nätverk kan du skapa en dedikerad integrationstjänstmiljö (ISE) där du kan skapa, distribuera och köra arbetsflöden på dedikerade resurser. Mer information om hur du skapar ISE:er finns i Anslut till virtuella Azure-nätverk från Azure Logic Apps.

Anpassade anslutningsappar som skapats i en ISE fungerar inte med den lokala datagatewayen. Dessa anslutningsappar kan dock direkt komma åt lokala datakällor som är anslutna till ett virtuellt Azure-nätverk som är värd för ISE. Därför behöver logikappar i en ISE troligen inte datagatewayen när de kommunicerar med dessa resurser. Om du har anpassade anslutningsappar som du har skapat utanför en ISE som kräver den lokala datagatewayen kan logikappar i en ISE använda dessa anslutningsappar.

När du bläddrar bland de inbyggda anslutningsappar eller hanterade anslutningsappar som du vill använda för logikappar i en ISE visas CORE-etiketten i inbyggda anslutningsappar i arbetsflödesdesignern, medan ISE-etiketten visas på hanterade anslutningsappar som är utformade för att fungera med en ISE.

Example CORE connector

CORE

Inbyggda anslutningsappar med den här etiketten körs i samma ISE som dina logikappar.

Example ISE connector

ISE

Hanterade anslutningsappar med den här etiketten körs i samma ISE som dina logikappar.

Om du har ett lokalt system som är anslutet till ett virtuellt Azure-nätverk låter en ISE dina arbetsflöden komma åt systemet direkt utan att använda den lokala datagatewayen. I stället kan du antingen använda systemets ISE-anslutningsprogram om det är tillgängligt, en HTTP-åtgärd eller en anpassad anslutningsapp.

För lokala system som inte har ISE-anslutningsappar använder du den lokala datagatewayen. Om du vill hitta tillgängliga ISE-anslutningsappar läser du ISE-anslutningsappar.

Example non-ISE connector

Ingen etikett

Alla andra anslutningsappar utan etikett, som du kan fortsätta att använda, körs i den globala Logic Apps-tjänsten för flera klientorganisationer.

Kända problem

Följande tabell innehåller kända problem för Logic Apps-anslutningsappar.

Felmeddelande Beskrivning Lösning
Error: BadGateway. Client request id: '{GUID}' Det här felet beror på att taggarna uppdateras i en logikapp där en eller flera anslutningar inte stöder Azure Active Directory (Azure AD) OAuth-autentisering, till exempel SFTP-annons SQL, vilket bryter dessa anslutningar. Undvik att uppdatera taggarna för att förhindra det här beteendet.

Nästa steg