Condividi tramite

Connettori personalizzati in App per la logica di Azure

  • Articolo

Si applica a: App per la logica di Azure (a consumo e 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 per lavorare con dati nuovi ed esistenti.

I connettori in App per la logica di Azure sono incorporati o gestiti. Un connettore predefinito viene eseguito in modo nativo nel runtime di App per la logica di Azure, il che significa che sono ospitati nello stesso processo del runtime e offrono una velocità effettiva più elevata, una bassa latenza e la 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 comunicare 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 è in realtà una risorsa di Azure separata che fornisce l'accesso all'app, al servizio, al sistema, al protocollo o alla piattaforma di destinazione.

In alcuni casi, 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 dei connettori personalizzati per i flussi di lavoro delle app per la logica a consumo e i flussi di lavoro delle 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 SOAP fino a dei limiti specifici da usare nei flussi di lavoro delle app per la logica a consumo. La documentazione relativa ai connettori offre altre informazioni generali su come creare connettori personalizzati per le app per la logica a 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 a consumo:

App per la logica standard

In app per la logica di Azure a tenant singolo, il runtime riprogettato di App per la logica di Azure supporta i flussi di lavoro delle app per la logica Standard. Questo runtime è diverso dal runtime di App per la logica di Azure multi-tenant che supporta i flussi di lavoro delle app per la logica di consumo. Il runtime a tenant singolo usa il modello di estendibilità di Funzioni di Azure, che offre una funzionalità chiave per creare connettori predefiniti personalizzati per chiunque possa usare 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, nuovi connettori predefiniti includono 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 basati su provider di servizi nei flussi di lavoro Standard.

Connettori predefiniti basati su 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. Questi connettori, ad esempio, si basano sul modello di estendibilità funzioni di Azure, che offrono la possibilità di creare connettori personalizzati predefiniti 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à di 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 del provider di servizi 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à di Funzioni di Azure, il modello di estendibilità del connettore predefinito in App per la logica di Azure a tenant singolo include un'infrastruttura del provider di servizi che è possibile usare per creare, creare pacchetti, registrare e installare connettori predefiniti come estensioni di 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 e dal runtime di App per la logica di Azure per un connettore predefinito personalizzato con un trigger basato su Funzioni di Azure:

Diagramma concettuale che illustra 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 di 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 dell'operazione 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 all'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 necessarie sui parametri di connessione all'associazione di trigger di 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 azione di 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 di Funzioni di Azure del trigger del connettore gestito di Azure, implementare i metodi seguenti per fornire le informazioni di connessione e le associazioni di trigger in base alle esigenze di Funzioni di Azure.

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

  • GetFunctionTriggerDefinition() 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.

Metodi da implementare

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

Importante

Quando si dispone di informazioni sensibili, ad esempio stringhe di connessione che includono nomi utente e password, assicurarsi di usare il flusso di autenticazione più sicuro disponibile. Ad esempio, Microsoft consiglia di autenticare l'accesso alle risorse di Azure con un'identità gestita quando è disponibile il supporto e assegnare un ruolo con il privilegio minimo richiesto.

Se questa funzionalità non è disponibile, assicurarsi di proteggere le stringhe di connessione tramite altre misure, ad esempio Azure Key Vault, che è possibile usare con le impostazioni dell'app. È quindi possibile fare riferimento direttamente a stringhe sicure, ad esempio stringhe di connessione e chiavi. Analogamente ai modelli ARM, in cui è possibile definire le variabili di ambiente in fase di distribuzione, è possibile indicare le impostazioni dell'app all'interno della definizione del flusso di lavoro dell'app per la logica. È quindi possibile acquisire valori di infrastruttura generati dinamicamente, ad esempio endpoint di connessione, stringhe di archiviazione e altri. Per altre informazioni, vedere Tipi di applicazione per Microsoft Identity Platform.

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 della 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 Esempio di CosmosDbServiceOperationProvider.cs.

GetOperations()

La finestra di progettazione richiede questo metodo per ottenere le operazioni implementate dal servizio. L'elenco delle operazioni è basato 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 Esempio di CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Se si vuole usare il tipo di trigger basato su Funzioni di Azure, questo metodo fornisce le informazioni necessarie sui parametri di connessione per l'associazione di trigger di 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 Esempio di CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Se il connettore predefinito personalizzato ha solo un trigger, non è necessario implementare questo metodo. Tuttavia, se il connettore include azioni da implementare, è necessario implementare il metodo InvokeOperation(), che viene chiamato per ogni azione nel connettore eseguita durante l'esecuzione del flusso di lavoro. È possibile usare qualsiasi client, ad esempio FTPClient, HTTPClient e così via, come richiesto dalle azioni del connettore. Questo esempio usa 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 Esempio di CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Per usare un trigger basato su Funzioni di Azure come trigger nel connettore, è necessario restituire la stringa uguale al parametro di ipo nell'associazione di trigger di 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 Esempio di CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Questo metodo 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.

Passaggi successivi

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