Creación de un adaptador SOAP personalizado para BizTalk ESB Toolkit 2.0

Question

Uso del kit de herramientas BizTalk ESB 2.0

Estamos trabajando en un proyecto en el que necesitamos llamar a un proxy a un servicio web que es una DLL.No tenemos problemas para hacer esto a través de una orquestación, ya que puede usar un puerto estático y configurarlo para usar el adaptador SOAP con la configuración del servicio web apuntando al ensamblado en la interfaz de administración de BizTalk.Sin embargo, en el itinerario no parece haber una forma obvia de hacer esto, ya que los puertos dinámicos no tienen la opción de usar el adaptador SOAP.

Hay una buena razón por la que queremos hacer esto, no te preocupes.

A partir de esto, implementamos un proveedor de adaptador personalizado, pero tenemos problemas para que funcione.

Seguimos un ejemplo (antiguo) mostrado aquí:

El proveedor de adaptador personalizado hereda de BaseAdapterProvider y anula el método SetEndPoint(Dictionary, IBaseMessageContext).

El método extrae el nombre del ensamblado, el nombre del tipo y el nombre del método que se pasan a través del diccionario de resolución y luego los escribe en el contexto de la canalización:

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);

y establece el tipo de transporte en jabón:

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

En todos los demás aspectos, el proveedor del adaptador es casi idéntico al ejemplo que se muestra en el enlace anterior, excepto por el cambio obvio de SMTP a SOAP.

El ensamblaje del proveedor del adaptador está firmado, GAC y agregado a esb.config.

Se llama al proveedor del adaptador desde un itinerario que solo llama al servicio y luego devuelve la respuesta.Estamos probando el itinerario desde el Cliente de prueba de itinerario que se incluye con el kit de herramientas.El registro de eventos dentro del adaptador personalizado muestra que se está llamando al código del adaptador.El problema es que el mensaje no se enruta al proxy del servicio.El visor de eventos da el siguiente error:

El motor de mensajería no pudo procesar un mensaje enviado por adaptador: URL de fuente SOAP: /esb.itineraryservices.response/processitinerary.asmx.Detalles: El mensaje publicado no se pudo enrutar porque no se encontraron suscriptores.Este error ocurre si la orquestación de suscripción o el puerto de envío no se han alistado, o si algunas de las propiedades del mensaje necesarias para la evaluación de suscripción no se han promovido.Utilice la consola de administración BizTalk para solucionar problemas de esta falla.

La investigación de las instancias de servicio suspendidas en Descripción general del grupo muestra dos cosas:Los valores para el nombre del ensamblado, el nombre del tipo y el nombre del método se están configurando correctamente.Falta el cuerpo del mensaje.Hemos intentado configurar las canalizaciones de envío y recepción en el puerto de envío para que sean XMLTransmit/XMLReceive e ItinerarySendPassthrough/PassthroughReceive y no hay diferencia.

¿Hay algo obvio que podríamos haber pasado por alto?¿Tiene que pasar explícitamente el cuerpo del mensaje?¿Si es así, cómo?

EDITAR:

Siguiendo un solicitud del foro BizTalk ESB Toolkit Estoy publicando capturas de pantalla del itinerario, el contexto y los filtros del puerto de envío.

Itinerario, Contexto, Filtros de puerto.

Muchas gracias Nigel.

Answer 1

en primer lugar voy a decir que usted está tratando de diseñar sobre la solución. desarrollo de adaptadores no es trivial y hay varias cosas que hay que tomar en consideración. Desarrollo y despliegue de adaptadores se clasifican como cambios de plataforma, que los efectos toda su entorno, por lo que si usted no está familiarizado entonces su no debe hacerlo. Yo recomendaría que tomar alguna otra ruta. En este punto, yo personalmente no tengo suficiente conocimiento de ESB internos, por lo que no voy a poder hacer comentarios al respecto. En el peor caso, puede ser mejor usar el proxy DLL de .NET directamente en el interior de su orquestación (expresión o forma de mensajes) en lugar de construir un adaptador. A pesar de que no es enfoque recomendado, todavía siento que es mejor que el enfoque de adaptador personalizado.

Answer 2

Semánticamente, no veo por qué una solución que involucra un adaptador WCF-BasicHtpp no ​​funcionaría en su escenario.En cualquier caso, definitivamente intentaría ver qué sucede con un adaptador WCF-BasicHttp y, una vez que tenga una solución que funcione, cambiaría a un adaptador SOAP personalizado si fuera realmente necesario.

Actualmente, su solución es extraña, en el sentido de que tiene una rampa de entrada conectada directamente a una rampa de salida.Nunca he visto eso en ninguno de mis itinerarios.Es posible que necesites crear un servicio de itinerario de mensajería u orquestación intermedio entretanto.

De lo contrario, el mensaje se publica efectivamente en el cuadro de mensaje y obviamente no hay suscriptores, de ahí el error que encuentra.