Condividi tramite

Estensione di funzionalità di BizTalk ESB Toolkit con SOA Governance

  • Articolo

Microsoft BizTalk ESB Toolkit viene fornito con BizTalk Server ed è una raccolta di strumenti e librerie che estendono BizTalk Server funzionalità di supporto di un'architettura di messaggistica dinamica e ad accoppiamento libero. Funziona come middleware che fornisce strumenti per l'aggregazione rapida tra i servizi e i relativi consumer. Abilitando la massima flessibilità in fase di esecuzione, BizTalk ESB Toolkit semplifica la composizione ad accoppiamento libero degli endpoint di servizio e la gestione delle interazioni del servizio.

Sentinet BizTalk Server Extensions migliora le funzionalità di BizTalk ESB Toolkit integrandola con Sentinet, una soluzione software di governance e gestione API SOA per la piattaforma Microsoft. La prima versione di Sentinet BizTalk Server Extensions offre un resolver di repository SOA bizTalk ESB Toolkit che si integra con BizTalk Server 2013, BizTalk ESB Toolkit e Visual Studio 2012.

Questo white paper illustra come Sentinet SOA Resolver estende le funzionalità di BizTalk ESB Toolkit, come configurare il resolver SOA Sentinet e infine un esempio che illustra come usare il resolver SOA Sentinet.

Resolver SOA ESB Toolkit e Sentinet SOA

Tra le altre cose, un resolver ESB Toolkit deve fornire quanto segue:

  • Risoluzione di runtime degli endpoint di servizio e delle relative configurazioni

  • Soluzioni BizTalk ESB con messaggistica ad accoppiamento libero.

    Sentinet offre un repository SOA affidabile e completo che offre soluzioni di integrazione SOA con funzionalità avanzate di governance e gestione del runtime SOA. Insieme a Sentinet SOA Repository, Sentinet SOA Resolver offre architetture BizTalk Server ESB con configurazioni ESB avanzate e facili da usare, routing dinamico dei messaggi e funzionalità di implementazione della sicurezza dei messaggi.

    Un diagramma generale seguente mostra come il resolver SOA Sentinet si inserisce nell'architettura di BizTalk ESB Toolkit.

    Sentinet con BizTalk ESB Toolkit

    In fase di esecuzione, il componente Risoluzione e routing degli endpoint nell'illustrazione precedente (che fa parte di ESB Toolkit Resolver Framework) usa un documento di itinerario (creato in Visual Studio Itinerario Designer) per creare un'istanza di Resolver specifico e richiedere al resolver di fornire l'endpoint di servizio e la relativa configurazione. L'itinerario stesso deve essere configurato con il riferimento all'endpoint del servizio, in modo che il resolver possa usare questo riferimento per trovare l'endpoint richiesto nel Registro di sistema o nel repository. In fase di progettazione (quando viene creato l'itinerario), l'indirizzo fisico effettivo dell'endpoint di servizio non è noto e nessuno dei criteri di sicurezza richiesti dal servizio. Nelle fasi successive, il runtime di ESB Toolkit usa l'endpoint di servizio risolto per configurare Off-Ramp porta di trasmissione dinamica per inviare il messaggio all'indirizzo del servizio fisico effettivo con le impostazioni di sicurezza del servizio necessarie. Se l'indirizzo dell'endpoint di servizio, i protocolli di comunicazione o i requisiti di sicurezza cambiano solo la configurazione del Registro di sistema o del repository deve essere aggiornata. La configurazione di runtime degli artefatti ESB o BizTalk Server non richiede l'aggiornamento.

In che modo il resolver Sentinet aggiunge valore a un'applicazione ESB Toolkit?

I due vantaggi principali dell'uso del resolver Sentinet insieme al repository SOA sono:

  • Assegnazione di identità client all'endpoint di servizio esterno risolto: la maggior parte del tempo, l'endpoint ESB risolto richiede un'identità client specifica per chiamare il servizio esterno (ad esempio nome utente/password, credenziali specifiche dell'account di Windows o certificato X.509 specifico). Si tratta di un requisito di sicurezza molto comune che non viene gestito in modo appropriato da altri resolver/registri ESB.

  • Limitazione dell'accesso alle informazioni di sicurezza: per ovviare alla limitazione precedente, altri resolver potrebbero usare la configurazione manuale di tModel per includere CODICE XML complesso con le identità di sicurezza necessarie. Tuttavia, il salvataggio delle informazioni di sicurezza come parte di registri/repository non è l'approccio corretto. In questo modo, gli utenti del servizio possono accedere facilmente ai dettagli di sicurezza, ad esempio nome utente, password e così via, per accedere al servizio.

    Sentinet Resolver e Sentinet SOA Repository offrono funzionalità per assegnare in modo flessibile e sicuro qualsiasi identità client specifica all'endpoint ESB risolto tramite comportamenti di endpoint WCF standard o personalizzati. Sentinet ottiene questo risultato configurando il sistema di risoluzione Sentinet e non il repository SOA Sentinet con le informazioni di sicurezza. Tutte le credenziali client configurate con il sistema di risoluzione Sentinet vengono archiviate in un formato crittografato.

    Oltre a questo, di seguito sono riportati alcuni degli altri vantaggi dell'uso del resolver Sentinet e del repository SOA Sentinet.

  • Fornisce un repository SOA completo. Il repository fornisce l'accesso al contenuto dei metadati del servizio, alle identità e ai criteri del servizio, al supporto per le versioni del servizio e così via.

  • Facilità di registrazione dei servizi fisici nel registro Sentinet caricando il servizio WSDL.

  • Console di amministrazione Sentinet completa e facile da usare. La console fornisce l'accesso di gestione a tutti i metadati del servizio e agli artefatti associati, con una semplice interfaccia utente per accedere alle operazioni del servizio e ai relativi schemi di dati, endpoint di servizio, criteri di sicurezza e così via.

  • Gestione e configurazione di comportamenti personalizzati per gli endpoint risolti. Il sistema di risoluzione Sentinet offre comportamenti endpoint completamente personalizzabili e facilmente configurabili per gli endpoint risolti.

  • Opzione per configurare il sistema di risoluzione Sentinet con un'ampia gamma di criteri di ricerca. Gli itinerari possono definire qualsiasi parola chiave assegnata a un endpoint di servizio o usare un percorso del servizio che punta a un servizio nella gerarchia dei servizi repository.

  • Funzionalità avanzate di test del resolver. Le configurazioni del sistema di risoluzione Sentinet possono essere testate direttamente dall'Designer dell'itinerario di Visual Studio. Anche se altri resolver possono fornire informazioni solo sulle proprietà di base dell'endpoint, Sentinet Resolver fornisce informazioni estese sugli endpoint risolti. Oltre alle proprietà di base dell'endpoint, il resolver Sentinet rivela le proprietà che identificano il servizio risolto e la posizione dell'endpoint nel repository Sentinet. I progettisti di itinerari possono testare il modo in cui Il sistema di risoluzione Sentinet e i diversi criteri di ricerca influiscono sui risultati della risoluzione prima che l'itinerario stesso venga usato in fase di esecuzione.

Installazione delle estensioni BizTalk Server Sentinet

È possibile scaricare e installare le estensioni Sentinet BizTalk da qui. L'installazione dell'estensione installa il resolver Sentinet per ESB Toolkit, la documentazione e gli esempi su come usare l'estensione.

Un documento che illustra in dettaglio come installare e configurare l'estensione Sentinet BizTalk Server è disponibile come parte del download del prodotto.

Uso delle estensioni BizTalk Server Sentinet

In questa sezione viene illustrato come usare le estensioni sentinet BizTalk Server e presentare le funzionalità indicate in precedenza.

Prerequisiti

Le istruzioni in questo white paper presuppongono che siano state installate e configurate le operazioni seguenti:

Registrare un servizio Web

I servizi Web gestiti dall'infrastruttura Sentinet devono essere registrati nel repository. Questo white paper usa un servizio di esempio di Ricerca clienti WCF fornito con il pacchetto di installazione Sentinet.

  1. Avviare il servizio di esempio Ricerca clienti installato dal pacchetto di installazione Sentinet. Avviare l'esempio di Ricerca clienti come amministratore, selezionare un'associazione di criteri (ad esempio wsHttpBinding) e quindi fare clic su Start.

  2. Dopo aver eseguito il servizio, fare clic sul collegamento Visualizza Wsdl per aprire un browser con l'URL dei metadati del servizio e il servizio WSDL. Copiare l'URL dei metadati dalla barra degli indirizzi del browser.

  3. Aprire un browser e immettere l'URL (https://[computer-name]/sentinet) per avviare la Console di amministrazione di Sentinet. Accedere e selezionare l'elemento radice repository nel pannello Visualizzazione repository . Fare clic con il pulsante destro del mouse sull'elemento radice repository e scegliere l'opzione di menu Aggiungi >> servizio SOAP .

  4. Nella finestra di dialogo Aggiungi servizio , per l'opzione WSDL dall'URL , incollare l'URL dei metadati del servizio copiato in precedenza e quindi fare clic su Avanti.

    Aggiungere l'URL del servizio

  5. La procedura guidata avvia il download dei metadati del servizio. Al termine del download, la procedura guidata visualizza la struttura dell'albero del servizio Web. Specificare un nome per il servizio e fare clic su Fine per caricare i metadati del servizio nel repository Sentinet.

    Struttura del servizio Web

  6. Il servizio viene importato nel repository come versione 1. Selezionare la versione e quindi selezionare l'endpoint. Nel riquadro Dettagli endpoint nella parte inferiore fare clic sulla scheda Allegati e quindi fare clic su Modifica.

    Modificare l'endpoint di servizio

  7. Nella scheda Dettagli endpoint fare clic sul segno (+) su Parole chiave, immettere una parola chiave da associare all'endpoint ,ad esempio TestKeyword, quindi fare clic su Salva. La parola chiave viene usata come tag di endpoint (o identificatore) nel repository SOA.

    Specificare una parola chiave

    Ripetere i passaggi precedenti per aggiungere una nuova versione del servizio CustomerSearch , ma con un'associazione diversa, ad esempio basicHttpBinding. Più avanti in questo white paper verrà illustrato come il resolver Sentinet possa essere risolto in servizi diversi (o versioni diverse dello stesso servizio) associando semplicemente una parola chiave di ricerca all'endpoint del servizio.

Configurare il sistema di risoluzione Sentinet

Questa sezione illustra come configurare il sistema di risoluzione Sentinet in un semplice progetto di itinerario BizTalk ESB Designer e in particolare come usare parole chiave per risolvere in modo univoco un endpoint di servizio. Questa sezione illustra anche come testare il resolver da Visual Studio stesso, senza inviare messaggi ESB.

  1. Avviare Visual Studio e creare un progetto di itinerario BizTalk ESB Designer.

  2. Nella Esplora soluzioni fare doppio clic sull'itinerario per aprirlo nel Designer itinerario.

  3. Dalla casella degli strumenti trascinare e rilasciare la forma Servizio itinerario nell'area di progettazione.

  4. Selezionare la forma Servizio itinerario e modificare la proprietà Extender del servizio itinerario in Estensione messaggistica dall'elenco a discesa.

    Impostare la proprietà Message Extender

  5. Fare clic con il pulsante destro del mouse sull'elemento Resolver nella forma Servizio itinerario e scegliere Aggiungi nuovo sistema di risoluzione.

    Aggiungere un nuovo resolver

  6. Selezionare il nuovo elemento resolver, rinominarlo (ad esempio , MyResolver) e per la proprietà Resolver Implementation (Implementazione resolver ), selezionare Sentinet Resolver Extension (Estensione resolver Sentinet).

    Impostare l'implementazione del resolver

  7. Specificare le proprietà Action e Keywords per l'estensione del resolver Sentinet. Queste proprietà verranno usate per risolvere in modo univoco i servizi aggiunti in precedenza al repository Sentinet. Esistono anche altre proprietà che è possibile specificare per l'estensione del resolver Sentinet. Per altre informazioni su queste proprietà, vedere la Guida dell'utente delle estensioni BizTalk sentinet.

    Proprietà Descrizione
    Azione Intestazione Azione messaggio che identifica in modo univoco l'operazione del servizio chiamata. Questa intestazione dell'azione fa parte del WSDL del servizio e si trova nel WSDL del servizio o dall'interfaccia utente della console di amministrazione sentinet (nelle proprietà Del messaggio di richiesta dell'operazione.
    Parole chiave Specificare la parola chiave ,ad esempio TestKeyword, assegnata al servizio nella Console di amministrazione sentinet.

    Lo screenshot seguente mostra la proprietà Action e Keywords specificata per la configurazione di MyResolver .

    Configurazione di Resolvery sentinet

  8. Salvare le modifiche apportate alla configurazione.

Configurazione avanzata del resolver

L'applicazione Sentinet BizTalk Extensions Configuration modifica Sentinet.BizTalk.config file che si trova nella radice della cartella di installazione del pacchetto (il percorso predefinito è <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Sentinet.BizTalk.config). Il file può essere modificato all'esterno dell'applicazione di configurazione Sentinet BizTalk Extensions per fornire opzioni di configurazione avanzate. In molti scenari ESB pratici, ad esempio, gli endpoint risolti devono essere forniti non solo con gli indirizzi e le associazioni degli endpoint di servizio, ma anche con identità client specifiche (nome utente/password, credenziali specifiche dell'account di Windows o un certificato X.509 client). Senza l'identità client appropriata, ESB Off-Ramp porte di trasmissione non riesce a chiamare servizi esterni. Sentinet Resolver consente allo sviluppatore di itinerari di assegnare un comportamento di endpoint specifico che fornisce l'identità dell'endpoint client appropriata. È possibile preconfigurare più comportamenti endpoint come comportamenti endpoint WCF standard nel file diSentinet.BizTalk.config e quindi fare riferimento a un comportamento specifico dell'endpoint nell'itinerario dalla configurazione del resolver Sentinet specificando il nome del comportamento per la proprietà Resolved Endpoint Behavior .

Testare la configurazione del resolver

Dopo aver configurato il sistema di risoluzione Sentinet specificando i valori delle proprietà pertinenti, è possibile testare il sistema di risoluzione da Visual Studio stesso.

  1. Nell'area di progettazione fare clic con il pulsante destro del mouse sul sistema di risoluzione Sentinet aggiunto alla forma Servizio itinerario e quindi scegliere Test configurazione resolver.

    Il riquadro di output mostra i risultati del test, un estratto di cui è simile al seguente:

    ***** Resolved Service Endpoint *****  

Service Path and Name          : /CustomerSearch  
Service Id                     : 2b6d686a-cae1-4b7b-93da-99affef98478  
Service Version                : 1  
Endpoint Name                  : WSHttpBinding_ICustomerSearch  
Endpoint Address               : http://btscloudcar/CustomerSearch/1

    Si noti che il sistema di risoluzione ha restituito l'endpoint per il servizio CustomerSearchversione 1 a cui sono associati i criteri di ricerca (TestKeyword).

  2. Rimuovere testKeyword associato alla versione 1 del servizio CustomerSearch e associarlo all'endpoint della seconda versione del servizio.

    1. Aprire la Console di amministrazione di Sentinet, fare clic sulla versione 1 nel servizio CustomerSearch , fare clic sull'endpoint wsHttpBinding, quindi sulla scheda Allegati e quindi su Modifica.

      Rimuovere la parola chiave dal servizio CustomerSearch

    2. Fare clic sul pulsante sulla parola chiave immessa prima di eliminare la parola chiave, fare clic su Sì nella finestra di messaggio e quindi fare clic su Salva.

      Rimuovere la parola chiave dal servizio CustomerSearch

    3. Assegnare ora la stessa parola chiave (TestKeyword) all'endpoint basicHttpBinding nella versione 2 dello stesso servizio.

  3. Indietro a Visual Studio e testare di nuovo la configurazione del resolver. Fare clic con il pulsante destro del mouse sul sistema di risoluzione Sentinet aggiunto alla forma Servizio itinerario e quindi scegliere Test configurazione resolver.

    Il riquadro di output mostra i risultati del test, un estratto di cui è simile al seguente:

    ***** Resolved Service Endpoint *****  

Service Path and Name          : /CustomerSearch  
Service Id                     : 5b9e5878-7016-44ab-9f0e-5282a8c3e508  
Service Version                : 2  
Endpoint Name                  : BasicHttpBinding_ICustomerSearch  
Endpoint Address               : http://btscloudcar/CustomerSearch/2

  4. Si noti che il sistema di risoluzione ha ora restituito i dettagli per la versione 2 del servizio anche se non è stato modificato alcun elemento nell'applicazione itinerariO ESB.

    Assegnare di nuovo la parola chiave (TestKeyword) alla versione 1 del servizio (con l'endpoint WSHttpBinding ).

Usare le estensioni BizTalk Server Sentinet

In questa sezione si esaminerà in che modo l'estensione Sentinet BizTalk, insieme al resolver ESB, può essere usata per identificare in modo univoco un servizio e instradare il messaggio a tale servizio, con modifiche minime o nessuna modifica al servizio o al client che invia il messaggio. Verranno testata due scenari:

  • Inviare un messaggio di esempio a un servizio registrato nel repository Sentinet (con la parola chiave collegata). Modificare quindi l'associazione di criteri per il servizio usando la Console di amministrazione sentinet e inviare un altro messaggio di esempio. Questo scenario illustra come la modifica dei criteri di sicurezza del servizio non influisce né sull'applicazione client né sull'itinerario ESB.

  • Inviare un messaggio di esempio a un endpoint di servizio registrato nel repository Sentinet (con parola chiave collegata). Allegare quindi la stessa parola chiave a un'altra versione dello stesso servizio e inviare di nuovo il messaggio. Questo scenario illustra come l'associazione di una parola chiave a una versione diversa del servizio instrada automaticamente i messaggi a una nuova versione del servizio.

    Per testare questi scenari, verranno usati gli esempi seguenti:

  • Servizio di ricerca clienti fornito con il programma di installazione Sentinet. Questo servizio può essere avviato dal menu Start.

  • Soluzione Nevatech.Vsb.BizTalk.Samples fornita con il programma di installazione sentinet. Questo esempio è disponibile all'indirizzo <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples.

  • ESB. Esempio Di itinerario.Test fornito con Microsoft BizTalk ESB Toolkit. Questa opzione è disponibile all'indirizzo <install drive>:\Program Files (x86)\Microsoft BizTalk ESB Toolkit\ESBSource.zip\Source\Samples\Itinerary\Source\ESB.Itinerary.Test e viene usata per testare i messaggi di esempio al servizio di ricerca clienti.

Per testare il sistema di risoluzione Sentinet modificando l'associazione di criteri del servizio

  1. Assicurarsi che il servizio CustomerSearch distribuito con wsHttpBinding sia in esecuzione.

  2. Nell'esempio Nevatech.Vsb.BizTalk.Samples aprire CustomerSearch.Search.route, selezionare Risolvi endpoint servizio in Message Extender all'interno della forma Messaggio di route e per la proprietà Keywords specificare una parola chiave, ad esempio TestKeyword.

    SentinetWP_AssignKeywordAssegnare

  3. Salvare le modifiche apportate all'itinerario ed esportare il modello. Fare clic con il pulsante destro del mouse in un punto qualsiasi dell'area di progettazione dell'itinerario e toccare Esporta modello.

  4. Nella console di amministrazione di BizTalk Server fare clic con il pulsante destro del mouse sull'applicazione Microsoft.Practices.ESB, scegliere Importa e quindi fare clic su Associazioni. Passare al percorso di esempio del resolver ESB in <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolvere aprire il file BizTalk.Bindings.xml . In questo modo vengono create le porte di trasmissione Sentinet Solicit-Response e Sentinet One-Way necessarie per gli itinerari di esempio.

    Assicurarsi inoltre che tutte le porte di trasmissione e le posizioni di ricezione dell'applicazione BizTalk Microsoft.Practices.ESB siano inserite e avviate.

  5. Aprire ESB. L'applicazione Itinerary.Test , compilarla ed eseguirla. Nel client di test dell'itinerario avviato seguire questa procedura:

    1. Nel client di test dell'itinerario, in Opzioni servizio Webdeselezionare Usa servizio WCF e selezionare Servizio bidirezionale.

    2. Nell'elenco a discesa Tipo di servizio selezionare Messaggistica.

    3. Fare clic su Carica itinerario e passare al file CustomerSearch.Search.Itinerary.xml che si trova nella cartella ExportedItineraries del progetto di esempio all'indirizzo <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolver\ExportedItineraries.

    4. Fare clic sul pulsante con i puntini di sospensione (..) in Carica gruppo di messaggi e passare a CustomerSearch.Search.Request.xml che si trova nella cartella SampleMessages del progetto all'indirizzo <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolver\SampleMessages.

    5. Fare clic su Invia richiesta e verificare che la risposta sia stata ricevuta.

  6. Nella finestra di dialogo CustomerSearch notare che il contatore aumenta di uno.

  7. Nella Console di amministrazione di Sentinet aggiornare i dettagli dell'endpoint per usare basicHttpBinding anziché wsHttpBinding.

    1. Selezionare l'endpoint di servizio, fare clic sulla scheda Dettagli e quindi su Modifica.

    2. Nella scheda Dettagli fare clic sui puntini di sospensione (...) nella sezione Criteri per avviare la procedura guidata Modifica criteri .

      Avviare modifica guidata criteri

    3. Nella prima pagina mantenere il tipo di criterio privato e quindi fare clic su Avanti.

    4. Nella seconda pagina modificare l'elemento XML wsHttpBinding impostandolosu basicHttpBinding (con distinzione tra maiuscole e minuscole) e quindi su Fine.

      Aggiornamento del SentinetWP_ModifyPolicy_2 di associazione dei criteri

    5. Fare clic su Salva per salvare le modifiche apportate ai dettagli dell'endpoint.

  8. Arrestare il servizio CustomerSearch , modificare l'associazione da wsHttpBinding a basicHttpBinding e quindi riavviare il servizio.

    Riavviare il servizio con SentinetWP_RestartCustService di associazione diverse

  9. Dal client dell'itinerario di test inviare di nuovo un messaggio di test al servizio di ricerca del cliente. Si noti che il contatore nella finestra di dialogo Servizio di ricerca clienti viene incrementato di nuovo di 1.

    Dopo la ricezione del messaggio, dalla Console di amministrazione sentinet modificare i dettagli dei criteri in wsHttpBinding. Analogamente, arrestare il servizio Ricerca clienti , ripristinare il criterio in wsHttpBinding e avviare il servizio.

    Questo dimostra come i dettagli del servizio nel repository Sentinet possono essere aggiornati in tempo reale per puntare a un endpoint di servizio aggiornato senza modificare l'itinerario o il client.

Per testare il resolver Sentinet modificando le assegnazioni di parole chiave

  1. Assicurarsi che le due istanze del servizio CustomerSearch distribuite con wsHttpBinding e basicHttpBinding siano in esecuzione.

  2. Nell'esempio Nevatech.Vsb.BizTalk.Samples aprire CustomerSearch.Search.route, selezionare Risolvi endpoint servizio in Message Extender all'interno della forma Messaggio di route e per la proprietà Keywords specificare una parola chiave, ad esempio TestKeyword.

    SentinetWP_AssignKeywordAssegnare

  3. Salvare le modifiche apportate all'itinerario ed esportare il modello. Fare clic con il pulsante destro del mouse in un punto qualsiasi dell'area di progettazione dell'itinerario e toccare Esporta modello.

  4. Nella console di amministrazione di BizTalk Server fare clic con il pulsante destro del mouse sull'applicazione Microsoft.Practices.ESB, scegliere Importa e quindi fare clic su Associazioni. Passare al percorso di esempio del resolver ESB in <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolvere aprire il file BizTalk.Bindings.xml . In questo modo vengono create le porte di trasmissione Sentinet Solicit-Response e Sentinet One-Way necessarie per gli itinerari di esempio.

    Assicurarsi inoltre che tutte le porte di trasmissione e le posizioni di ricezione dell'applicazione BizTalk Microsoft.Practices.ESB siano inserite e avviate.

  5. Aprire ESB. L'applicazione Itinerary.Test , compilarla ed eseguirla. Nel client di test dell'itinerario avviato seguire questa procedura:

    1. Nel client di test dell'itinerario, in Opzioni servizio Webdeselezionare Usa servizio WCF e selezionare Servizio bidirezionale.

    2. Nell'elenco a discesa Tipo di servizio selezionare Messaggistica.

    3. Fare clic su Carica itinerario e passare al file CustomerSearch.Search.Itinerary.xml che si trova nella cartella Esportatinerary del progetto di esempio in <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolver\ExportedItineraries.

    4. Fare clic sul pulsante con i puntini di sospensione (..) nel gruppo Carica messaggio e passare a CustomerSearch.Search.Request.xml situato nella cartella SampleMessages del progetto in <installation drive>:\Program Files\Nevatech\Sentinet BizTalk Extensions\Samples\ESB Resolver\SampleMessages.

    5. Fare clic su Invia richiesta e verificare che la risposta sia stata ricevuta.

  6. Nella finestra di dialogo CustomerSearch si noti che il contatore aumenta di uno.

  7. Dalla console di amministrazione sentinet rimuovere TestKeyword associato alla versione 1 del servizio CustomerSearch e associarla alla versione 2 del servizio.

    1. Aprire la console amministrativa Sentinet, fare clic su Versione 1 nel servizio CustomerSearch , fare clic sull'endpoint wsHttpBinding e quindi fare clic sulla scheda Allegati e quindi su Modifica.

      Rimuovere la parola chiave dal servizio CustomerSearch

    2. Fare clic sul pulsante sulla parola chiave immessa prima di eliminare la parola chiave, fare clic su Sì nella finestra di messaggio e quindi fare clic su Salva.

      Rimuovere la parola chiave dal servizio CustomerSearch

    3. Assegnare ora la stessa parola chiave (TestKeyword) all'endpoint basicHttpBinding nella versione 2 dello stesso servizio.

  8. Inviare di nuovo un messaggio di test dal client itinerario di test e notare che questa volta il contatore viene incrementato nella finestra di dialogo che rappresenta la versione 2 del servizio, distribuita con basicHttpBinding.