Scrivere un listener per una soluzione Microsoft Azure

  • Articolo

 

Data di pubblicazione: novembre 2016

Si applica a: Dynamics CRM 2015

In questo argomento viene descritto come scrivere un listener che potrà leggere ed elaborare i messaggi di Microsoft Dynamics CRM 2015 che vengono pubblicati in Bus di servizio di Microsoft Azure. Come prerequisito, è necessario familiarizzare con la scrittura di un listener di Bus di servizio di Microsoft Azure prima di provare ad apprendere i dettagli sul listener di Microsoft Dynamics 365. Per ulteriori informazioni, vedere la documentazione del bus di servizio di Azure e il codice di esempio.

In questo argomento

Scrivere un listener coda

Scrivere un listener unidirezionale, bidirezionale o REST

Filtrare i messaggi

Scrivere un listener coda

Una coda di messaggi è un archivio di messaggi ricevuti agli endpoint del bus di servizio. Un listener coda è un'applicazione che legge ed elabora tali messaggi in coda. Poiché i messaggi del bus di servizio vengono archiviati in una coda, un listener non deve attivamente ascoltare, affinché i messaggi siano ricevuti nella coda. Un listener coda può essere avviato in seguito all'arrivo dei messaggi nella coda ed elaborare tali messaggi. Altri tipi di listener illustrati nella sezione successiva devono essere attivamente in ascolto o non colgono l'opportunità di leggere un messaggio. Tali messaggi possono essere originati da Microsoft Dynamics 365 o avere altre origini. Quando si scrive un listener coda, è importante verificare ogni azione dell'intestazione di messaggio per determinare se il messaggio è stato originato da Microsoft Dynamics 365.

È possibile effettuare una lettura distruttiva del messaggio utilizzando Ricevi in modalità ReceiveAndDelete, in cui il messaggio viene letto e rimosso dalla coda, o una lettura non distruttiva utilizzando la modalità PeekLock, in cui il messaggio viene letto ma rimane disponibile nella coda. Il codice di esempio di listener coda permanente fornito nel presente SDK esegue una lettura distruttiva. Per ulteriori informazioni sulla lettura di messaggi da una coda, vedere How to Receive Messages from a Queue (Come ricevere messaggi da una coda).

Un argomento è simile a una coda ma implementa un modello Pubblica/Sottoscrivi. Uno o più listener possono sottoscrivere il topic e ricevere messaggi dalla relativa coda.Ulteriori informazioni:Code, argomenti e sottoscrizioni

Importante

Le code persistenti e gli argomenti sono supportati, mentre le code del buffer dei messaggi non lo sono. Per utilizzare questi contratti, è necessario scrivere le applicazioni listener tramite Azure SDK versione 1.7 o 1.8.

Utilizzare code e argomenti della progettazione software multisistema può comportare il disaccoppiamento dei sistemi. Se l'applicazione listener dovesse non essere disponibile, la consegna dei messaggi da Microsoft Dynamics 365 riuscirà comunque e l'applicazione listener potrà continuare a elaborare i messaggi in coda quando tornerà online.Ulteriori informazioni:Code, argomenti e sottoscrizioni.

Aggiornare un listener di buffer messaggi per utilizzare le code permanenti

La procedura seguente elenca i passaggi generici da seguire per aggiornare un'applicazione listener che recupera il messaggio da un buffer dei messaggi a una che riceve il messaggio da una coda permanente.

  1. Nel portale Microsoft Azure e nella stessa soluzione, creare una coda nello stesso percorso utilizzato per il buffer dei messaggi.

  2. Installare Microsoft Azure SDK versioni 1,7 o 1,8 nel computer di sviluppo.

  3. Aggiornare il codice del listener rimuovere le classi e i metodi relativi al buffer messaggi e quindi sostituirli con QueueClient e Ricevi. Assicurarsi di utilizzare la modalità di lettura desiderata: RetrieveAndDelete o PeekLock. Per ulteriori informazioni sulla lettura di messaggi da una coda, vedere Code, argomenti e sottoscrizioni.

  4. Sviluppare l'applicazione listener.

Nessuna modifica di configurazione di Microsoft Dynamics 365 è necessaria, se l'endpoint coda utilizza lo stesso percorso della soluzione utilizzato dal buffer messaggi.

Scrivere un listener unidirezionale, bidirezionale o REST

Oltre al listener coda descritto in precedenza, è possibile scrivere un listener per altri tre contratti del bus di servizio che sono supportati da Microsoft Dynamics 365: unidirezionale bidirezionale, e REST. Un listener unidirezionale può leggere e elaborare un messaggio pubblicato nel bus di servizio. Un listener bidirezionale può fare lo stesso ma può anche restituire una stringa di alcune informazioni a Dynamics 365. Un listener REST è uguale al listener bidirezionale a eccezione del fatto che funziona con un endpoint REST. Si noti che questi listener devono essere attivamente in ascolto in un endpoint servizio per leggere un messaggio inviato attraverso il bus di servizio. Se il listener non è in ascolto quando Microsoft Dynamics 365 tenta di pubblicare un messaggio nel bus di servizio, il messaggio viene inviato.

La scrittura di u listener è strutturata intorno al cosiddetto ABC: indirizzo, binding e contratto (address, binding e contract). Le informazioni seguenti identificano gli ABC di un listener unidirezionale.

Dopo avere registrato il listener in un endpoint, il metodo Execute del listener è richiamato ogni volta che un messaggio viene pubblicato nel bus di servizio da Microsoft Dynamics 365. Il metodo Execute non restituisce alcun dato dalla chiamata al metodo. Per ulteriori informazioni, vedere l'esempio di listener unidirezionale, Esempio: listener unidirezionale.

Un listener bidirezionale è codificato in modo simile al listener unidirezionale. Gli ABC di un listener bidirezionale sono i seguenti:

Per il contratto bidirezionale, il metodo Esegui restituisce una stringa dalla chiamata al metodo. Per ulteriori informazioni, vedere l'esempio di listener bidirezionale, Esempio: listener bidirezionale.

Un listener REST è codificato in modo simile al listener bidirezionale. Gli ABC di un listener REST sono i seguenti:

Per il contratto REST, il metodo Execute restituisce una stringa dalla chiamata al metodo. Per ulteriori informazioni, vedere REST esempio di listener Esempio: listener REST. Si noti che nel listener REST nell'esempio, viene creata un'istanza di WebServiceHost e non di ServiceHost come nell'esempio bidirezionale.

Nota

Quando si utilizza il plug-in predefinito (ServiceBusPlugin) in un listener bidirezionale o REST, il plug-in non utilizza alcuna stringa di dati restituita dal listener. Tuttavia, un plug-in personalizzato in grado di rilevare Azure potrebbe utilizzare queste informazioni.

Quando si eseguono gli esempi di listener, il segreto dell'autorità emittente che viene richiesto è il codice gestione di Bus di servizio di Microsoft Azure. Il binding della federazione HTTP WS2007 utilizza la modalità "token" e il protocollo WS-Trust 1.3.

Filtrare i messaggi

Esiste un contenitore di proprietà con informazioni aggiuntive che viene aggiunto a ogni proprietà delle Proprietà dei messaggi negoziati inviata da Microsoft Dynamics CRM 2015 e CRM Online. Il contenitore di proprietà, disponibile per le code e gli endpoint del contratto di argomento permanenti, contiene le informazioni seguenti.

  • Organizzazione Url

  • ID utente chiamante

  • ID dell'utente di avvio

  • Nome logico entità

  • Nome richiesta

Tali informazioni identificano l'organizzazione, l'utente, l'entità e la richiesta di messaggio elaborati da Microsoft Dynamics 365 che hanno ottenuto come risultato la pubblicazione del messaggio del bus di servizio. Il codice del listener può scegliere di elaborare un messaggio che riceve in base a queste informazioni.Ulteriori informazioni:Esempio: Eseguire più richieste

Vedere anche

Estensioni Azure per Microsoft Dynamics CRM 2015
Scrivere un plug-in personalizzato che riconosce Azure
Esempio: listener di coda persistente
Esempio: listener unidirezionale
Esempio: listener bidirezionale
Esempio: listener REST
Inviare i dati di Microsoft Dynamics CRM 2015 tramite il bus di servizio di Azure

© 2017 Microsoft. Tutti i diritti sono riservati. Copyright