Dela via

Anpassade anslutningsappar i Azure Logic Apps

  • Artikel

Gäller för: Azure Logic Apps (Förbrukning + Standard)

Utan att skriva någon kod kan du snabbt skapa automatiserade integreringsarbetsflöden när du använder de fördefinierade anslutningsåtgärderna i Azure Logic Apps. En anslutningsapp hjälper dina arbetsflöden att ansluta och komma åt data, händelser och åtgärder i andra appar, tjänster, system, protokoll och plattformar. Varje anslutningsapp erbjuder åtgärder som utlösare, åtgärder eller båda som du kan lägga till i dina arbetsflöden. Genom att använda dessa åtgärder utökar du funktionerna för dina molnappar och lokala appar så att de fungerar med nya och befintliga data.

Anslutningsappar i Azure Logic Apps är antingen inbyggda eller hanterade. En inbyggd anslutningsapp körs internt på Azure Logic Apps-körningen, vilket innebär att de finns i samma process som körningen och ger högre dataflöde, låg svarstid och lokal anslutning. En hanterad anslutningsapp är en proxy eller en omslutning runt ett API, till exempel Office 365 eller Salesforce, som hjälper den underliggande tjänsten att prata med Azure Logic Apps. Hanterade anslutningsappar drivs av anslutningsinfrastrukturen i Azure och distribueras, hanteras, körs och hanteras av Microsoft. Du kan välja mellan hundratals hanterade anslutningsappar som ska användas med dina arbetsflöden i Azure Logic Apps.

När du använder en anslutningsåtgärd för första gången i ett arbetsflöde kräver vissa anslutningsappar inte att du skapar en anslutning först, men många andra anslutningsappar kräver det här steget. Varje anslutning som du skapar är i själva verket en separat Azure-resurs som ger åtkomst till målappen, tjänsten, systemet, protokollet eller plattformen.

Ibland kanske du vill anropa REST-API:er som inte är tillgängliga som fördefinierade anslutningsappar. För att stödja mer skräddarsydda scenarier kan du skapa egna anpassade anslutningsappar för att erbjuda utlösare och åtgärder som inte är tillgängliga som fördefinierade åtgärder.

Den här artikeln innehåller en översikt över anpassade anslutningsappar för arbetsflöden för förbrukningslogikappar och standardarbetsflöden för logikappar. Varje typ av logikapp drivs av en annan Azure Logic Apps-körning, som finns i Azure med flera klientorganisationer och Azure med en enda klientorganisation. Mer information om anslutningsappar i Azure Logic Apps finns i följande dokumentation:

Förbrukningslogikappar

I Azure Logic Apps med flera klientorganisationer kan du skapa anpassade anslutningsappar från Swagger-baserade eller SOAP-baserade API:er upp till specifika gränser för användning i arbetsflöden för förbrukningslogikapp. Dokumentationen om anslutningsappar innehåller mer översiktsinformation om hur du skapar anpassade anslutningsappar för förbrukningslogikappar, inklusive fullständiga grundläggande och avancerade självstudier. Följande lista innehåller även direkta länkar till information om anpassade anslutningsappar för förbrukningslogikappar:

Standardlogikappar

I Azure Logic Apps med en enda klientorganisation driver den omdesignade Azure Logic Apps-körningen arbetsflöden för standardlogikappar. Den här körningen skiljer sig från azure logic apps-körningen med flera klientorganisationer som driver arbetsflöden för förbrukningslogikappar. Körningen för en klientorganisation använder Utökningsmodellen för Azure Functions, som ger dig en viktig funktion för att skapa egna inbyggda anslutningsappar som alla kan använda i Standard-arbetsflöden. I de flesta fall ger den inbyggda versionen bättre prestanda, funktioner, priser och så vidare.

När Azure Logic Apps för en enda klientorganisation officiellt släpptes inkluderade nya inbyggda anslutningsappar Azure Blob Storage, Azure Event Hubs, Azure Service Bus och SQL Server. Med tiden fortsätter den här listan med inbyggda anslutningsappar att växa. Men om du behöver anslutningsappar som inte är tillgängliga i standardlogikappens arbetsflöden kan du skapa dina egna inbyggda anslutningsappar med samma utökningsmodell som används av tjänstleverantörsbaserade inbyggda anslutningsappar i Standard-arbetsflöden.

Tjänstleverantörsbaserade inbyggda anslutningsappar

I Azure Logic Apps med en enda klientorganisation kallas en inbyggd anslutningsapp med specifika attribut informellt för en tjänstleverantör. Dessa anslutningsappar baseras till exempel på Utökningsmodellen för Azure Functions, som ger dig möjlighet att skapa egna anpassade inbyggda anslutningsappar som ska användas i standardarbetsflöden för logikappar.

Däremot har inbyggda anslutningsappar som inte är en tjänstleverantör följande attribut:

  • Baseras inte på utökningsmodellen för Azure Functions.

  • Implementeras direkt som ett jobb inom Azure Logic Apps-körningen, till exempel schema-, HTTP-, begäran- och XML-åtgärder.

Det finns för närvarande ingen kapacitet för att skapa en inbyggd anslutningsapp som inte är en tjänstleverantör eller en ny jobbtyp som körs direkt i Azure Logic Apps-körningen. Du kan dock skapa egna inbyggda anslutningsappar med hjälp av tjänstleverantörens infrastruktur.

I följande avsnitt finns mer information om hur utökningsmodellen fungerar för anpassade inbyggda anslutningsappar.

Inbyggd utökningsmodell för anslutningsappar

Baserat på Utökningsmodellen för Azure Functions har den inbyggda utökningsmodellen för anslutningsappar i Azure Logic Apps med en enda klient en tjänstleverantörsinfrastruktur som du kan använda för att skapa, paketera, registrera och installera dina egna inbyggda anslutningsappar som Azure Functions-tillägg som vem som helst kan använda i sina Standard-arbetsflöden. Den här modellen innehåller anpassade inbyggda utlösarfunktioner som har stöd för att exponera en Azure Functions-utlösare eller åtgärd som en tjänstleverantörsutlösare i din anpassade inbyggda anslutningsapp.

Följande diagram visar de metodimplementeringar som Azure Logic Apps-designern och körningen förväntar sig för en anpassad inbyggd anslutningsapp med en Azure Functions-baserad utlösare:

Konceptdiagram som visar Azure Functions-baserad tjänstleverantörsinfrastruktur.

Följande avsnitt innehåller mer information om de gränssnitt som anslutningsappen behöver implementera.

IServiceOperationsProvider

Det här gränssnittet innehåller de metoder som tillhandahåller operationsmanifestet för din anpassade inbyggda anslutningsapp.

  • Operationsmanifest

    Operationsmanifestet innehåller metadata om de implementerade åtgärderna i din anpassade inbyggda anslutningsapp. Azure Logic Apps-designern använder främst dessa metadata för att driva redigerings- och övervakningsfunktionerna för anslutningsappens åtgärder. Designern använder till exempel åtgärdsmetadata för att förstå de indataparametrar som krävs av en specifik åtgärd och för att underlätta genereringen av utdatas egenskapstoken, baserat på schemat för åtgärdens utdata.

    Designern kräver och använder metoderna GetService() och GetOperations() för att köra frågor mot de åtgärder som anslutningsappen tillhandahåller och visar på designerytan. Metoden GetService() anger också anslutningens indataparametrar som krävs av designern.

    Mer information om dessa metoder och deras implementering finns i avsnittet Metoder att implementera senare i den här artikeln.

  • Åtgärdsanrop

    Åtgärdsanrop är de metodimplementeringar som används under arbetsflödeskörningen av Azure Logic Apps-körningen för att anropa de angivna åtgärderna i arbetsflödesdefinitionen.

Mer information om dessa metoder och deras implementering finns i avsnittet Metoder att implementera senare i den här artikeln.

IServiceOperationsTriggerProvider

Anpassade inbyggda utlösarfunktioner har stöd för att lägga till eller exponera en Azure Functions-utlösare eller åtgärd som en tjänstleverantörsutlösare i din anpassade inbyggda anslutningsapp. Om du vill använda den Azure Functions-baserade utlösartypen och samma Azure Functions-bindning som Azure Managed Connector-utlösaren implementerar du följande metoder för att tillhandahålla anslutningsinformation och utlösarbindningar som krävs av Azure Functions.

  • Metoden GetFunctionTriggerType() krävs för att returnera strängen som är samma som typparametern i Azure Functions-utlösarbindningen.

  • GetFunctionTriggerDefinition() har en standardimplementering, så du behöver inte uttryckligen implementera den här metoden. Men om du vill uppdatera utlösarens standardbeteende, till exempel ange extra parametrar som designern inte exponerar, kan du implementera den här metoden och åsidosätta standardbeteendet.

Metoder för att implementera

Följande avsnitt innehåller mer information om de metoder som anslutningsappen behöver implementera. Det fullständiga exemplet finns i Exempel CosmosDbServiceOperationProvider.cs och Skapa anpassade inbyggda anslutningsappar för standardlogikappar i Azure Logic Apps med en enda klientorganisation.

Viktigt!

När du har känslig information, till exempel niska veze som innehåller användarnamn och lösenord, bör du använda det säkraste tillgängliga autentiseringsflödet. Microsoft rekommenderar till exempel att du autentiserar åtkomst till Azure-resurser med en hanterad identitet när support är tillgänglig och tilldelar en roll som har minst behörighet.

Om den här funktionen inte är tillgänglig måste du skydda niska veze via andra mått, till exempel Azure Key Vault, som du kan använda med appinställningar. Du kan sedan direkt referera till säkra strängar, till exempel niska veze och nycklar. På samma sätt som ARM-mallar, där du kan definiera miljövariabler vid distributionen, kan du definiera appinställningar i logikappens arbetsflödesdefinition. Du kan sedan samla in dynamiskt genererade infrastrukturvärden, till exempel anslutningsslutpunkter, lagringssträngar med mera. Mer information finns i Programtyper för Microsoft platforma za identitete.

GetService()

Designern kräver den här metoden för att hämta metadata på hög nivå för din tjänst, inklusive tjänstbeskrivning, parametrar för anslutningsindata, funktioner, varumärkesfärg, ikon-URL och så vidare.

public ServiceOperationApi GetService()
{
   return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}

Mer information finns i Exempel på CosmosDbServiceOperationProvider.cs.

GetOperations()

Designern kräver den här metoden för att få de åtgärder som implementeras av din tjänst. Driftlistan baseras på Swagger-schema. Designern använder också åtgärdsmetadata för att förstå indataparametrarna för specifika åtgärder och generera utdata som egenskapstoken, baserat på schemat för utdata för en åtgärd.

public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
   return expandManifest ? serviceOperationsList : GetApiOperations();
}

Mer information finns i Exempel på CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Om du vill använda den Azure Functions-baserade utlösartypen tillhandahåller den här metoden nödvändig information om anslutningsparametrar till Azure Functions-utlösarbindningen.

public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
   return ServiceOperationsProviderUtilities
      .GetRequiredParameterValue(
         serviceId: ServiceId,
         operationId: operationID,
         parameterName: "connectionString",
         parameters: connectionParameters)?
      .ToValue<string>();
}

Mer information finns i Exempel på CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Om din anpassade inbyggda anslutningsapp bara har en utlösare behöver du inte implementera den här metoden. Men om anslutningsappen har åtgärder att implementera måste du implementera metoden InvokeOperation(), som anropas för varje åtgärd i anslutningsappen som körs under arbetsflödeskörningen. Du kan använda valfri klient, till exempel FTPClient, HTTPClient och så vidare, enligt vad som krävs av anslutningsappens åtgärder. I det här exemplet används HTTPClient.

public Task<ServiceOperationResponse> InvokeOperation(string operationId, InsensitiveDictionary<JToken> connectionParameters, ServiceOperationRequest serviceOperationRequest)
{
   using (var client = new HttpClient())
   {
      response = client.SendAsync(httpRequestMessage).ConfigureAwait(false).ToJObject();
   }
   return new ServiceOperationResponse(body: response);
}

Mer information finns i Exempel på CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Om du vill använda en Azure Functions-baserad utlösare som en utlösare i anslutningsappen måste du returnera strängen som är samma som typparametern i Azure Functions-utlösarbindningen.

I följande exempel returneras strängen för den färdiga inbyggda Azure Cosmos DB-utlösaren: "type": "cosmosDBTrigger"

public string GetFunctionTriggerType()
{
   return "CosmosDBTrigger";
}

Mer information finns i Exempel på CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Den här metoden har en standardimplementering, så du behöver inte uttryckligen implementera den här metoden. Men om du vill uppdatera utlösarens standardbeteende, till exempel ange extra parametrar som designern inte exponerar, kan du implementera den här metoden och åsidosätta standardbeteendet.

Nästa steg

När du är redo att starta implementeringsstegen fortsätter du till följande artikel: