Criando um adaptador SOAP personalizado para BizTalk ESB Toolkit 2.0

Question

Usando o BizTalk ESB Toolkit 2.0

Estamos trabalhando em um projeto onde nós precisamos chamar um proxy para um serviço web que é uma DLL. Não temos problemas ao fazer isso através de uma orquestração desde que você pode usar uma porta estática e configurá-lo para usar o adaptador SOAP com o cenário que aponta serviço web na assembléia na interface BizTalk administrador. No itinerário embora não parece ser uma maneira óbvia de fazer isso uma vez portos dinâmicos não tem a opção de usar o adaptador SOAP.

Há uma boa razão pela qual queremos fazer isso, não se preocupe.

Na sequência desta, implementamos um provedor adaptador personalizado, mas está tendo problemas para fazê-la funcionar.

seguido um exemplo (velho) mostrado aqui :

Os herda provedor adaptador personalizado de BaseAdapterProvider e substitui a SetEndPoint (Dictionary, IBaseMessageContext) método.

O método extrai o nome de montagem, nome do tipo, e o nome do método que é passado através do dicionário de resolução e, em seguida, as grava no contexto gasoduto:

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 define o tipo de transporte para sabão:

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

Em todos os outros aspectos, o prestador de adaptador é quase idêntico ao do exemplo mostrado na relação acima, com excepção para a alteração óbvia de SMTP para SOAP.

O fornecedor de adaptador de montagem é assinado, GACed, e adicionado ao esb.config.

O provedor adaptador é chamado de um itinerário que só chama o serviço e, em seguida, retorna a resposta. Estamos testando o itinerário a partir do Teste Cliente Itinerário que é fornecido com o kit de ferramentas. O registro de eventos dentro dos espectáculos adaptador personalizado que o código de adaptador está sendo chamado. O problema é que a mensagem não está sendo encaminhado para o proxy do serviço. O visualizador de eventos dá o seguinte erro:

O motor Messaging não conseguiu processo uma mensagem enviada por adaptador: SABÃO Fonte URL: /ESB.ItineraryServices.Response/ProcessItinerary.asmx. Detalhes: A mensagem publicada podia não ser encaminhado porque há assinantes foram achados. Este erro ocorre se o assinando orquestração ou porta de envio não tenha sido inscrito, ou se alguns dos as propriedades de mensagens necessárias para avaliação assinatura não ter sido promovido. Por favor use o Biztalk console de administração para solucionar problemas essa falha.

Investigando as instamces serviços suspensos no Grupo Overview mostra duas coisas: Os valores para o nome de montagem, o nome do tipo, e o nome do método estão a ser fixado correctamente. O corpo da mensagem está faltando. Temos tentado configurar a enviar e receber pipelines na porta de envio para ser tanto XMLTransmit / XMLReceive e ItinerarySendPassthrough / PassthroughReceive e não faz diferença.

Existe algo óbvio que poderia ter perdido? Você tem que passar explicitamente o corpo da mensagem através? Se sim, como?

EDIT:

Depois de uma pedido do fórum BizTalk ESB Toolkit estou postando capturas de tela dos filtros de porta itinerário, contexto e de envio.

Itinerário , Contexto , Porto filtra .

Muito obrigado, Nigel.

Answer 1

Primeiro de tudo eu vou dizer que você está tentando ao longo engenheiro a solução. Adaptador de desenvolvimento não é trivial e há várias coisas que você precisa levar em consideração. Desenvolvimento e adaptadores Implantando são categorizados como mudanças de plataforma, cujos efeitos seu ambiente todo, por isso, se você não está familiarizado, então o seu não deve fazê-lo. Eu recomendo que você tomar alguma outra rota. Nesse ponto, eu, pessoalmente, não tem discernimento suficiente para internos ESB, então não será capaz de comentar sobre ele. Na pior das hipóteses você pode ser melhor fora de usar o proxy DLL .NET diretamente dentro de sua orquestração (expressão ou forma de mensagem) ao invés de construir um adaptador. Mesmo que a sua não recomendado abordagem, ainda sinto a sua melhor que abordagem adaptador personalizado.

Answer 2

Semanticamente, eu não vejo por que uma solução que envolve um adaptador WCF-BasicHtpp não iria trabalhar em seu cenário. Em qualquer caso, eu definitivamente tentar ver o que acontece com um adaptador WCF-BasicHttp, e uma vez eu tenho uma solução de trabalho, gostaria de mudar para um adaptador SOAP personalizado se que é realmente necessário.

Atualmente, sua solução é estranho - no sentido de que você tem uma rampa de acesso directamente ligado a uma rampa de saída. Eu nunca vi isso em qualquer um dos meus itinerários. Talvez seja necessário criar um mensagens intermediário ou orquestração de serviços Itinerário em betweeen.

Caso contrário, a mensagem de forma eficaz é publicado para a caixa de mensagem e, obviamente, não há assinantes para isso, daí o erro que você encontrar.