Questa pagina è stata utile?
I suggerimenti relativi al contenuto di questa pagina sono importanti. Comunicaceli.
Altri suggerimenti?
1500 caratteri rimanenti
How to integrate BizTalk Server 2010 / 2013 with Service Bus for Windows Server

How to integrate BizTalk Server 2010 / 2013 with Service Bus for Windows Server

Aggiornamento: marzo 2014

Autore: Paolo Salvatori

Revisori: Mandi Ohlinger

Esempio da scaricare: Come integrare BizTalk Server 2010/2013 con Service Bus for Windows Server

Microsoft BizTalk Server consente alle organizzazioni di connettere ed estendere sistemi eterogenei all'interno dell'azienda e con partner commerciali. Service Bus fornisce le funzionalità di connettività, accodamento e routing ad applicazioni locali e cloud. Nel cloud Service Bus è disponibile nella piattaforma . In locale Service Bus per Windows Server è disponibile come set di servizi e componenti installabili.

In questo argomento è incluso un esempio più evoluto rispetto a quello riportato nell'articolo relativo alla procedura di integrazione di un'applicazione BizTalk Server 2010 con code e argomenti di Service Bus. In questo esempio viene mostrato come utilizzare WCF con NetMessagingBinding per integrare un'applicazione BizTalk Server 2010/2013 con Service Bus for Windows Server.

Nella soluzione vengono utilizzati i componenti seguenti per integrare BizTalk Server e Service Bus per Windows Server:

In questo articolo viene illustrato come utilizzare questi componenti in un'applicazione BizTalk e come configurare un'applicazione client WCF per implementare quanto segue:

  • Invio di messaggi a un'applicazione BizTalk Server 2010/2013 con una coda di Service Bus

  • Invio di messaggi a un'applicazione BizTalk Server 2010/2013 con un argomento di Service Bus

  • Ricezione di messaggi da un'applicazione BizTalk Server 2010/2013 con una coda di Service Bus

  • Ricezione di messaggi da un'applicazione BizTalk Server 2010/2013 con una sottoscrizione di Service Bus

Per inviare messaggi all'applicazione BizTalk è possibile utilizzare lo strumento Service Bus Explorer oppure l'applicazione client inclusa in questo esempio. Tale applicazione client utilizza Microsoft.ServiceBus.dll per scambiare messaggi con l'applicazione BizTalk mediante WCF.

Gli scenari sono due:

Scenario 1: l'applicazione utilizza porte di invio statiche.

Scenario 2: l'applicazione client specifica l'URL dell'argomento o della coda di risposta.

L'applicazione client Windows Forms simula un sistema LOB (Line-Of-Business) locale, il quale scambia messaggi con un'applicazione BizTalk Server che utilizza code, argomenti e sottoscrizioni forniti da Service Bus per Windows Server. In questo scenario l'applicazione BizTalk Server 2010/2013 utilizza porte di invio statiche e la stessa coda o lo stesso argomento per restituire la risposta al chiamante.

  1. L'applicazione client Windows Forms utilizza un proxy WCF per inviare un messaggio di richiesta a requestqueue o requesttopic.

  2. L'applicazione BizTalk Server utilizza una porta di ricezione unidirezionale per ricevere i messaggi di richiesta da Service Bus. Più specificamente, un percorso di ricezione WCF-Custom (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.ReceiveLocation) legge i messaggi di richiesta da requestqueue. Un secondo percorso di ricezione WCF-Custom (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Subscription.ReceiveLocation) riceve i messaggi di richiesta dalla sottoscrizione italyMilan di requesttopic. Entrambi i percorsi di ricezione utilizzano i componenti seguenti:

    • NetMessagingBinding riceve i messaggi da una coda o da una sottoscrizione.

    • In fase di runtime un controllo messaggio WCF personalizzato (ServiceBusMessageInspector) legge BrokeredMessageProperty dalla raccolta Properties dell'elemento Message WCF in ingresso. Il controllo messaggio WCF (ServiceBusMessageInspector) trasforma le relative proprietà standard (ad esempio, MessageId e ReplyTo) e le proprietà specifiche dell'applicazione (le coppie chiave/valore nella raccolta Properties di BrokeredMessageProperty) in proprietà di contesto nel messaggio BizTalk.

    • ListenUriEndpointBehavior viene utilizzato dal percorso di ricezione WCF-Custom che recupera i messaggi dalla sottoscrizione ItalyMilan definita in requesttopic. Questo componente personalizzato imposta il valore della proprietà ListenUri dell'endpoint del servizio. ListenUriEndpointBehavior è descritto più avanti in questo articolo.

    • Se un'applicazione recupera messaggi da una coda o sottoscrizione con sessione, è necessario aggiungere SessionChannelEndpointBehavior alla configurazione del percorso di ricezione WCF-Custom. Questo componente personalizzato assicura che, in fase di runtime, l'adapter WCF-Custom crei un IInputSessionChannel anziché un IInputChannel. L'aggiunta di SessionChannelEndpointBehavior è un requisito obbligatorio per ricevere messaggi da un'entità di messaggistica con sessione.

    • TokenProviderEndpointBehavior consente al percorso di ricezione di effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale utilizzato dallo spazio dei nomi di Service Bus mediante WindowsTokenProvider o OAuthTokenProvider. Quando è in uso WindowsTokenProvider, è possibile utilizzare l'account del servizio dell'istanza host che esegue il percorso di ricezione per effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale oppure è possibile specificare credenziali alternative. Quando è in uso OAuthTokenProvider, specificare sempre le credenziali come nome utente, password o dominio. Per accedere allo spazio dei nomi di Service Bus viene utilizzato LocalMachine\LocalUser o Domain\DomainUser. L'account utente utilizzato dal percorso di ricezione deve essere autorizzato ad accedere allo spazio dei nomi di Service Bus in cui è ospitata la coda o la sottoscrizione. Per autorizzare l'account utente ad accedere allo spazio dei nomi, è possibile utilizzare il cmdlet New-SBNamespace di Windows PowerShell quando si crea lo spazio dei nomi oppure il cmdlet Set-SBNamespace per aggiungere l'account utente al gruppo dei gestori dello spazio dei nomi.

  3. L'agente messaggi inoltra il messaggio di richiesta a MessageBox (BizTalkMsgBoxDb).

  4. La richiesta in ingresso avvia una nuova istanza di StaticSendPortOrchestration, che utilizza una porta diretta per ricevere i messaggi di richiesta che soddisfano l'espressione di filtro seguente:

    Microsoft.WindowsAzure.CAT.Samples.ServiceBusForWindowsServer.Schemas.Method == Static

    L'orchestrazione richiama un metodo esposto dal componente helper RequestManager per calcolare il messaggio di risposta. Copia le proprietà di contesto del messaggio di richiesta nel messaggio di risposta e assegna il valore della proprietà di contesto MessageId del messaggio di richiesta alla proprietà CorrelationId del messaggio di risposta. Verifica infine il valore stringa contenuto nella proprietà di contesto ReplyTo. Se il valore stringa contiene la parola "queue", l'orchestrazione restituisce il messaggio di risposta attraverso una porta logica associata a una porta di invio WCF-Custom configurata per inviare i messaggi a responsequeue. In caso contrario, pubblica la risposta in MessageBox utilizzando una porta di invio logica associata a una porta di invio WCF-Custom configurata per inviare i messaggi a responsetopic.

  5. L'agente messaggi inoltra il messaggio di richiesta a MessageBox (BizTalkMsgBoxDb).

  6. Il messaggio di risposta viene utilizzato da una delle porte di invio WCF-Custom seguenti:

    • ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.SendPort: scrive il messaggio di risposta in responsequeue.

    • ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Topic.SendPort: scrive il messaggio di risposta in responsetopic.

  7. Tramite la porta di invio selezionata il messaggio di risposta viene scritto in responsequeue o responsetopic. Entrambe le porte di invio sono configurate per utilizzare i componenti seguenti:

    • NetMessagingBinding invia i messaggi a Service Bus.

    • ServiceBusMessageInspector trasforma le proprietà di contesto del messaggio in proprietà BrokeredMessage.

    • TokenProviderEndpointBehavior consente alla porta di invio di effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale utilizzato dallo spazio dei nomi di Service Bus mediante WindowsTokenProvider o OAuthTokenProvider. Le stesse considerazioni si applicano anche alle porte di invio quando si utilizza questo componente in un percorso di ricezione.

  8. L'applicazione client utilizza un servizio WCF con due endpoint per recuperare il messaggio di risposta da responsequeue o responsetopic. In un ambiente con più applicazioni client ogni endpoint deve utilizzare una coda o una sottoscrizione distinta per ricevere messaggi di risposta da BizTalk Server.

L'applicazione client Windows Forms simula anche un sistema LOB (Line-Of-Business), il quale scambia messaggi con un'applicazione BizTalk Server che utilizza code, argomenti e sottoscrizioni forniti da Service Bus per Windows Server. In questo scenario l'applicazione client specifica l'URL della coda di risposta o dell'argomento nella proprietà ReplyTo. La definizione dell'URL consente ad applicazioni client diverse di inviare richieste attraverso la stessa coda o lo stesso argomento, ma per ricevere le risposte vengono utilizzati code e argomenti diversi. Questa architettura consente all'applicazione BizTalk di utilizzare un'unica porta di invio dinamica per trasmettere le risposte alle applicazioni client.

  1. L'applicazione client Windows Forms utilizza un proxy WCF per inviare un messaggio di richiesta a requestqueue o requesttopic.

  2. L'applicazione BizTalk Server utilizza una porta di ricezione unidirezionale per ricevere i messaggi di richiesta da Service Bus. Più specificamente, un percorso di ricezione WCF-Custom (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.ReceiveLocation) legge i messaggi di richiesta da requestqueue. Un secondo percorso di ricezione WCF-Custom (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Subscription.ReceiveLocation) riceve i messaggi di richiesta dalla sottoscrizione italyMilan di requesttopic. Entrambi i percorsi di ricezione sono configurati per utilizzare i componenti seguenti:

    • NetMessagingBinding riceve i messaggi da una coda o da una sottoscrizione.

    • In fase di runtime un controllo messaggio WCF personalizzato (ServiceBusMessageInspector) legge BrokeredMessageProperty dalla raccolta Properties dell'elemento Message WCF in ingresso. Il controllo messaggio WCF (ServiceBusMessageInspector) trasforma le relative proprietà standard (ad esempio, MessageId e ReplyTo) e le proprietà specifiche dell'applicazione (le coppie chiave/valore contenute nella raccolta Properties di BrokeredMessageProperty) in proprietà di contesto del messaggio BizTalk.

    • ListenUriEndpointBehavior viene utilizzato dal percorso di ricezione WCF-Custom che recupera i messaggi dalla sottoscrizione ItalyMilan definita in requesttopic. Questo componente personalizzato imposta il valore della proprietà ListenUri dell'endpoint del servizio. ListenUriEndpointBehavior è descritto più avanti in questo white paper in ListenUriEndpointBehavior.

    • Se un'applicazione recupera messaggi da una coda o sottoscrizione con sessione, è necessario aggiungere SessionChannelEndpointBehavior alla configurazione del percorso di ricezione WCF-Custom. SessionChannelEndpointBehavior assicura che, in fase di runtime, l'adapter WCF-Custom crei un IInputSessionChannel anziché un IInputChannel. L'aggiunta di SessionChannelEndpointBehavior è un requisito obbligatorio per ricevere messaggi da un'entità di messaggistica con sessione.

    • TokenProviderEndpointBehavior consente al percorso di ricezione di effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale utilizzato dallo spazio dei nomi di Service Bus mediante WindowsTokenProvider o OAuthTokenProvider. Quando è in uso WindowsTokenProvider, è possibile utilizzare l'account del servizio host che esegue il percorso di ricezione per effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale oppure è possibile specificare credenziali alternative. Quando è in uso OAuthTokenProvider, specificare sempre le credenziali come nome utente, password o dominio. Per accedere allo spazio dei nomi di Service Bus viene utilizzato LocalMachine\LocalUser o Domain\DomainUser. L'account utente utilizzato dal percorso di ricezione deve essere autorizzato ad accedere allo spazio dei nomi di Service Bus in cui è ospitata la coda o la sottoscrizione. Per autorizzare l'account utente ad accedere allo spazio dei nomi, è possibile utilizzare il cmdlet New-SBNamespace di Windows PowerShell quando si crea lo spazio dei nomi oppure il cmdlet Set-SBNamespace per aggiungere l'account utente al gruppo dei gestori dello spazio dei nomi.

  3. L'agente messaggi inoltra il messaggio di richiesta a MessageBox (BizTalkMsgBoxDb).

  4. La richiesta in ingresso avvia una nuova istanza di DynamicSendPortOrchestration, che utilizza una porta diretta per ricevere i messaggi di richiesta che soddisfano l'espressione di filtro seguente:

    Microsoft.WindowsAzure.CAT.Samples.ServiceBusForWindowsServer.Schemas.Method == Dynamic

    L'orchestrazione richiama un metodo esposto dal componente helper RequestManager per calcolare il messaggio di risposta. Copia le proprietà di contesto del messaggio di richiesta nel messaggio di risposta e quindi assegna il valore della proprietà di contesto MessageId del messaggio di richiesta alla proprietà CorrelationId del messaggio di risposta. Quindi legge l'indirizzo dell'entità di messaggistica (coda o argomento) a cui inviare la risposta dalla proprietà di contesto ReplyTo. L'orchestrazione infine configura le proprietà di contesto del messaggio di risposta e le proprietà della porta di invio dinamica per l'utilizzo dei componenti seguenti:

    • NetMessagingBinding invia i messaggi a Service Bus.

    • ServiceBusMessageInspector trasforma le proprietà di contesto del messaggio in proprietà BrokeredMessage.

    • TokenProviderEndpointBehavior consente al percorso di ricezione di effettuare l'autenticazione presso il servizio token di sicurezza (STS) locale utilizzato dallo spazio dei nomi di Service Bus mediante WindowsTokenProvider o OAuthTokenProvider.

  5. L'agente messaggi inoltra il messaggio di richiesta a MessageBox (BizTalkMsgBoxDb).

  6. La porta di invio unidirezionale dinamica ServiceBusForWindowsServer.Dynamic.SendPort utilizza il messaggio di risposta.

  7. La porta di invio dinamica utilizza l'adapter WCF-Custom e NetMessagingBinding come specificato dall'orchestrazione per restituire la risposta all'entità di messaggistica (in questo esempio, responsequeue o responsetopic) il cui indirizzo è specificato nell'applicazione client nella proprietà ReplyTo di BrokeredMessageProperty.

  8. L'applicazione client utilizza un servizio WCF con due endpoint per recuperare il messaggio di risposta da responsequeue o responsetopic. In un ambiente con più applicazioni client ogni endpoint deve utilizzare una coda o una sottoscrizione distinta per ricevere messaggi di risposta da BizTalk Server.

Vedere anche

Mostra:
© 2015 Microsoft