Connettori personalizzati in App per la logica di Azure

  • Articolo

Si applica a: App per la logica di Azure (consumo + Standard)

Senza scrivere codice, è possibile creare rapidamente flussi di lavoro di integrazione automatizzati quando si usano le operazioni predefinite del connettore in App per la logica di Azure. Un connettore consente ai flussi di lavoro di connettersi e accedere a dati, eventi e azioni in altre app, servizi, sistemi, protocolli e piattaforme. Ogni connettore offre operazioni come trigger, azioni o entrambi che è possibile aggiungere ai flussi di lavoro. Usando queste operazioni, si espandono le funzionalità per le app cloud e le app locali in modo che funzionino con dati nuovi e esistenti.

I connettori in App per la logica di Azure sono compilati o gestiti. Un connettore predefinito viene eseguito in modo nativo nel runtime di App per la logica di Azure, che significa che sono ospitati nello stesso processo del runtime e forniscono una velocità effettiva maggiore, bassa latenza e connettività locale. Un connettore gestito è un proxy o un wrapper intorno a un'API, ad esempio Office 365 o Salesforce, che consente al servizio sottostante di parlare con App per la logica di Azure. I connettori gestiti sono basati sull'infrastruttura del connettore in Azure e vengono distribuiti, ospitati, eseguiti e gestiti da Microsoft. È possibile scegliere tra centinaia di connettori gestiti da usare con i flussi di lavoro in App per la logica di Azure.

Quando si usa un'operazione connettore per la prima volta in un flusso di lavoro, alcuni connettori non richiedono prima di tutto di creare una connessione, ma molti altri connettori richiedono questo passaggio. Ogni connessione creata è effettivamente una risorsa di Azure separata che fornisce l'accesso all'app di destinazione, al servizio, al sistema, al protocollo o alla piattaforma.

A volte, tuttavia, potrebbe essere necessario chiamare le API REST che non sono disponibili come connettori predefiniti. Per supportare scenari più personalizzati, è possibile creare connettori personalizzati per offrire trigger e azioni non disponibili come operazioni predefinite.

Questo articolo offre una panoramica sui connettori personalizzati per i flussi di lavoro delle app per la logica di consumo e sui flussi di lavoro dell'app per la logica Standard. Ogni tipo di app per la logica è basato su un runtime di App per la logica di Azure diverso, ospitato rispettivamente in Azure multi-tenant e in Azure a tenant singolo. Per altre informazioni sui connettori in App per la logica di Azure, vedere la documentazione seguente:

App per la logica di consumo

In App per la logica di Azure multi-tenant è possibile creare connettori personalizzati da API basate su Swagger o basate su SOAP fino a limiti specifici per l'uso nei flussi di lavoro dell'app per la logica di consumo. La documentazione sui connettori fornisce altre informazioni generali su come creare connettori personalizzati per le app per la logica di consumo, incluse esercitazioni di base e avanzate complete. L'elenco seguente fornisce anche collegamenti diretti alle informazioni sui connettori personalizzati per le app per la logica di consumo:

App per la logica standard

In App per la logica di Azure a tenant singolo, il runtime di App per la logica di Azure riprogettata supporta i flussi di lavoro dell'app per la logica Standard. Questo runtime differisce dal runtime di App per la logica di Azure multi-tenant che consente ai flussi di lavoro dell'app per la logica di consumo. Il runtime a tenant singolo usa il modello di estendibilità Funzioni di Azure, che offre una funzionalità chiave per creare connettori predefiniti per chiunque usi nei flussi di lavoro Standard. Nella maggior parte dei casi, la versione predefinita offre prestazioni, funzionalità, prezzi e così via migliori.

Quando App per la logica di Azure a tenant singolo è stata rilasciata ufficialmente, i nuovi connettori predefiniti includevano Archiviazione BLOB di Azure, Hub eventi di Azure, bus di servizio di Azure e SQL Server. Nel corso del tempo, questo elenco di connettori predefiniti continua a crescere. Tuttavia, se sono necessari connettori non disponibili nei flussi di lavoro dell'app per la logica Standard, è possibile creare connettori predefiniti usando lo stesso modello di estendibilità usato dai connettori predefiniti del provider di servizi nei flussi di lavoro Standard.

Connettori predefiniti basati sul provider di servizi

In App per la logica di Azure a tenant singolo, un connettore predefinito con attributi specifici è noto in modo informale come provider di servizi. Ad esempio, questi connettori si basano sul modello di estendibilità Funzioni di Azure, che offrono la possibilità di creare connettori predefiniti personalizzati da usare nei flussi di lavoro dell'app per la logica Standard.

Al contrario, i connettori predefiniti non del provider di servizi hanno gli attributi seguenti:

  • Non è basato sul modello di estendibilità Funzioni di Azure.

  • Viene implementato direttamente come processo all'interno del runtime di App per la logica di Azure, ad esempio Pianificazione, HTTP, Richiesta e operazioni XML.

Non è attualmente disponibile alcuna funzionalità per creare un connettore predefinito non di servizio o un nuovo tipo di processo eseguito direttamente nel runtime di App per la logica di Azure. È tuttavia possibile creare connettori predefiniti usando l'infrastruttura del provider di servizi.

Nella sezione seguente vengono fornite altre informazioni sul funzionamento del modello di estendibilità per i connettori predefiniti personalizzati.

Modello di estendibilità del connettore predefinito

In base al modello di estendibilità Funzioni di Azure, il modello di estendibilità del connettore predefinito in App per la logica di Azure a tenant singolo dispone di un'infrastruttura del provider di servizi che è possibile usare per creare, creare, registrare e installare connettori predefiniti come estensioni Funzioni di Azure che chiunque può usare nei flussi di lavoro Standard. Questo modello include funzionalità di trigger predefinite personalizzate che supportano l'esposizione di un trigger o un'azione di Funzioni di Azure come trigger del provider di servizi nel connettore predefinito personalizzato.

Il diagramma seguente illustra le implementazioni del metodo previste dalla finestra di progettazione di App per la logica di Azure e dal runtime per un connettore predefinito personalizzato con un trigger basato su Funzioni di Azure:

Diagramma concettuale che mostra l'infrastruttura del provider di servizi basata su Funzioni di Azure.

Le sezioni seguenti forniscono altre informazioni sulle interfacce che il connettore deve implementare.

IServiceOperationsProvider

Questa interfaccia include i metodi che forniscono il manifesto delle operazioni per il connettore predefinito personalizzato.

  • Manifesto delle operazioni

    Il manifesto delle operazioni include metadati sulle operazioni implementate nel connettore predefinito personalizzato. La finestra di progettazione app per la logica di Azure usa principalmente questi metadati per guidare le esperienze di creazione e monitoraggio per le operazioni del connettore. Ad esempio, la finestra di progettazione usa i metadati delle operazioni per comprendere i parametri di input richiesti da un'operazione specifica e per facilitare la generazione dei token di proprietà degli output, in base allo schema per gli output dell'operazione.

    La finestra di progettazione richiede e usa i metodi GetService() e GetOperations() per eseguire query sulle operazioni fornite dal connettore e visualizzate nell'area di progettazione. Il metodo GetService() specifica anche i parametri di input della connessione richiesti dalla finestra di progettazione.

    Per altre informazioni su questi metodi e sulla relativa implementazione, vedere la sezione Metodi da implementare più avanti in questo articolo.

  • Chiamate di operazione

    Le chiamate all'operazione sono le implementazioni del metodo usate durante l'esecuzione del flusso di lavoro dal runtime di App per la logica di Azure per chiamare le operazioni specificate nella definizione del flusso di lavoro.

    • Se il trigger è un tipo di trigger basato su Funzioni di Azure, il metodo GetBindingConnectionInformation() viene usato dal runtime in App per la logica di Azure per fornire le informazioni sui parametri di connessione necessari all'associazione di trigger Funzioni di Azure.

    • Se il connettore ha azioni, il metodo InvokeOperation() viene usato dal runtime per chiamare ogni azione nel connettore eseguita durante l'esecuzione del flusso di lavoro. In caso contrario, non è necessario implementare questo metodo.

Per altre informazioni su questi metodi e sulla relativa implementazione, vedere la sezione Metodi da implementare più avanti in questo articolo.

IServiceOperationsTriggerProvider

Le funzionalità di trigger predefinite personalizzate supportano l'aggiunta o l'esposizione di un trigger o un'azione Funzioni di Azure come trigger del provider di servizi nel connettore predefinito personalizzato. Per usare il tipo di trigger basato su Funzioni di Azure e lo stesso binding Funzioni di Azure del trigger del connettore gestito di Azure, implementare i metodi seguenti per fornire le informazioni di connessione e le associazioni trigger, come richiesto da Funzioni di Azure.

  • Il metodo GetFunctionTriggerType() è necessario per restituire la stringa uguale al parametro di tipo nell'associazione di trigger Funzioni di Azure.

  • GetFunctionTriggerDefinition() ha un'implementazione predefinita, quindi non è necessario implementare in modo esplicito questo metodo. Tuttavia, se si vuole aggiornare il comportamento predefinito del trigger, ad esempio fornire parametri aggiuntivi che la finestra di progettazione non espone, è possibile implementare questo metodo ed eseguire l'override del comportamento predefinito.

Metodi da implementare

Le sezioni seguenti forniscono altre informazioni sui metodi che il connettore deve implementare. Per l'esempio completo, vedere Sample CosmosDbServiceOperationProvider.cs e Creare connettori predefiniti personalizzati per le app per la logica Standard in App per la logica di Azure a tenant singolo.

GetService()

La finestra di progettazione richiede questo metodo per ottenere i metadati di alto livello per il servizio, tra cui la descrizione del servizio, i parametri di input di connessione, le funzionalità, il colore del marchio, l'URL dell'icona e così via.

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

Per altre informazioni, vedere Sample CosmosDbServiceOperationProvider.cs.

GetOperations()

La finestra di progettazione richiede questo metodo per ottenere le operazioni implementate dal servizio. L'elenco di operazioni si basa sullo schema Swagger. La finestra di progettazione usa anche i metadati dell'operazione per comprendere i parametri di input per operazioni specifiche e generare gli output come token di proprietà, in base allo schema dell'output per un'operazione.

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

Per altre informazioni, vedere Sample CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Se si vuole usare il tipo di trigger basato su Funzioni di Azure, questo metodo fornisce le informazioni sui parametri di connessione necessari per l'associazione di trigger Funzioni di Azure.

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

Per altre informazioni, vedere Sample CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Se il connettore predefinito personalizzato ha solo un trigger, non è necessario implementare questo metodo. Tuttavia, se il connettore ha azioni da implementare, è necessario implementare il metodo InvokeOperation(), che viene chiamato per ogni azione nel connettore in esecuzione durante l'esecuzione del flusso di lavoro. È possibile usare qualsiasi client, ad esempio FTPClient, HTTPClient e così via, in base alle azioni del connettore. In questo esempio viene usato 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);
}

Per altre informazioni, vedere Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Per usare un trigger basato su Funzioni di Azure come trigger nel connettore, è necessario restituire la stringa uguale al parametro di tipo nell'associazione di trigger Funzioni di Azure.

L'esempio seguente restituisce la stringa per il trigger predefinito di Azure Cosmos DB predefinito, "type": "cosmosDBTrigger":

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

Per altre informazioni, vedere Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Questo metodo ha un'implementazione predefinita, pertanto non è necessario implementare in modo esplicito questo metodo. Tuttavia, se si vuole aggiornare il comportamento predefinito del trigger, ad esempio fornire parametri aggiuntivi che la finestra di progettazione non espone, è possibile implementare questo metodo ed eseguire l'override del comportamento predefinito.

Passaggi successivi

Quando si è pronti per avviare i passaggi di implementazione, continuare con l'articolo seguente: