Creazione di un adattatore SOAP personalizzato per BizTalk ESB Toolkit 2.0

Question

Uso della BizTalk ESB Toolkit 2.0

Stiamo lavorando su un progetto in cui abbiamo bisogno di chiamare un proxy per un servizio Web che è una DLL. Non abbiamo problemi a fare questo attraverso un'orchestrazione dal momento che è possibile utilizzare una porta statica e configurarlo per utilizzare l'adattatore SOAP con l'impostazione del servizio Web che punta al montaggio nell'interfaccia BizTalk Admin. Nell'itinerario anche se non sembra essere un modo ovvio per fare questo in quanto le porte dinamiche non hanno la possibilità di utilizzare l'adattatore SOAP.

C'è una buona ragione per cui vogliamo fare questo, non ti preoccupare.

A seguito di questo, abbiamo implementato un fornitore di adattatore personalizzato ma stiamo avendo problemi a farlo funzionare.

seguiva una (vecchia) illustrato qui :

Il provider adattatore personalizzato eredita da BaseAdapterProvider e sostituisce il SetEndPoint (Dictionary, IBaseMessageContext) metodo.

Il metodo estrae il nome di montaggio, nome del tipo, e il nome del metodo che sono passati in via dizionario resolver e poi li scrive al contesto gasdotto:

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

e imposta il tipo di trasporto di sapone:

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

In altri casi, il provider di adattatore è quasi identico all'esempio illustrato nel link sopra, tranne per il cambiamento evidente da SMTP SOAP.

Il gruppo fornitore di adattatore è firmato, GACed, e aggiunto al esb.config.

Il provider adattatore viene chiamato da un itinerario che chiama solo il servizio e poi restituisce la risposta. Stiamo testando l'itinerario da parte del Cliente Itinerario test che viene fornito con il toolkit. La registrazione degli eventi all'interno del adattatore personalizzato mostra che il codice dell'adattatore viene chiamato. Il problema è che il messaggio non viene instradato al proxy del servizio. Il Visualizzatore eventi dà il seguente errore:

  

Il motore di messaggistica non è riuscito a elaborare   un messaggio inoltrato da adattatore: SOAP   fonte   URL: /ESB.ItineraryServices.Response/ProcessItinerary.asmx.   Dettagli: il messaggio pubblicato potrebbe   Non essere instradato perché nessun abbonati   furono trovati. Questo errore si verifica se il   la sottoscrizione di orchestrazione o porta di trasmissione   non è stato arruolato, o se alcuni di   le proprietà dei messaggi necessari per   la valutazione di sottoscrizione non sono stati   promosso. Si prega di utilizzare il Biztalk   Console di amministrazione per risolvere i problemi   questo fallimento.

Indagare le instamces servizio sospese in Panoramica del Gruppo mostra due cose: I valori per nome assembly, nome del tipo, e il nome del metodo sono stati impostati correttamente. Il corpo del messaggio è mancante. Abbiamo cercato di configurare l'invio e la ricezione condotte sulla porta di trasmissione per essere sia XMLTransmit / XMLReceive e ItinerarySendPassthrough / PassthroughReceive e non fa alcuna differenza.

C'è qualcosa di ovvio che potrebbe avere perso? Dovete passare esplicitamente il corpo del messaggio attraverso? Se sì, come?

EDIT:

A seguito di un richiesta dal forum Toolkit BizTalk ESB sto inviando schermate del percorso, il contesto e mando i filtri di porta.

Itinerario , Contesto , Port filtra .

Molte grazie, Nigel.

Answer 1

Prima di tutto devo dire che si sta tentando a più di progettare la soluzione. sviluppo adattatore non è banale e ci sono varie cose che dovete prendere in considerazione a. Sviluppo e la distribuzione adattatori sono classificati come i cambiamenti della piattaforma, i cui effetti tutto il vostro ambiente, quindi se non si ha familiarità allora il vostro non dovrebbe farlo. Ti consiglierei di prendere qualche altro percorso. A questo punto io personalmente non ho abbastanza comprensione interni ESB, quindi non sarà in grado di commentare su di esso. In caso peggiore potrebbe essere meglio utilizzare il proxy .NET DLL direttamente all'interno del vostro orchestrazione (espressione o forma un messaggio), piuttosto che costruire un adattatore. Anche se la sua non è raccomandato approccio, ancora mi sento la sua migliore di approccio adattatore personalizzato.

Answer 2

semantico, non vedo il motivo per cui una soluzione che prevede un adattatore WCF-BasicHtpp non avrebbe funzionato nel vostro scenario. In ogni caso, vorrei provare a vedere cosa succede con un adattatore WCF-BasicHttp, e una volta ho avuto una soluzione di lavoro, vorrei passare a un adattatore SOAP personalizzato se è veramente necessario.

Al momento, la soluzione è strano - nel senso che si dispone di una rampa d'accesso direttamente collegato ad un off-ramp. Non ho mai visto che in nessuna delle mie itinerari. Potrebbe essere necessario creare un messaggistica intermedio o orchestrazione dei servizi Itinerario in betweeen.

In caso contrario, il messaggio in modo efficace viene pubblicato per la finestra di messaggio e, ovviamente, non ci sono abbonati per essa, da cui l'errore si verifica.