Si alguna vez necesitas consumir un servicio SOAP desde Dynamics 365 for Finance and Operations, lo primero que tienes que hacer es pedir a los responsables de ese servicio que creen una versión REST. Si eso no es posible, este post es para ti.

Voy a usar este web service que encontré por ahí en http://www.dneonline.com/calculator.asmx para el ejemplo, es una calculadora con las 4 operaciones básicas de suma, resta, división y multiplicación.

Consumir un servicio SOAP en .NET

Empecemos por lo más básico. ¿Cómo consumimos un servicio SOAP en Visual Studio? Muy fácil. Sólo hay que añadir una referencia de servicio en tu proyecto:

Apuntar al servicio web de tu elección:

Esto va a crear la referencia en Visual Studio:

Una vez hecho esto podemos crear una instancia del cliente del servicio y llamar a sus métodos:

3 + 6 = 9, parece que funciona.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations

Para consumir un servicio web en FnO crea un nuevo proyecto, haz click derecho en referencias y añade la referencia de servicio:

Emmm… no, no se puede, no hay referencias de servicio.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (espero…)

El problema es que en las máquinas de desarrollo de 365 no podemos añadir las referencias de servicio en Visual Studio.

¿Qué dice la documentación sobre esto? Bueno, igual que en AX2012 necesitamos crear una clase en .NET que consumira el servicio web y a través de la que accederemos a él desde 365. Muy bien!

Ya lo tenemos. Una referencia a nuestra librería y una runnable class que hará el trabajo:

A ejecutarlo:

¿Qué?

An exception of type ‘System.InvalidOperationException’ occurred in System.ServiceModel.dll but was not handled in user code

Additional information: Could not find default endpoint element that references contract ‘AASSOAPCalculatorService.CalculatorSoap’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

¿Contrato? ¿Qué contrato? No sé nada de un contrato. Nadie me ha dicho nada de un contrato! ¿Qué dice la Wikipedia del SOAP?

Soap is the term for a salt of a fatty acid or for a variety of cleansing and lubricating products produced from such a substance.

Creo que no es ese el SOAP que buscaba… (en inglés era más gracioso 🙁 )

SOAP provides the Messaging Protocol layer of a web services protocol stack for web services. It is an XML-based protocol consisting of three parts:

  • an envelope, which defines the message structure and how to process it

  • a set of encoding rules for expressing instances of application-defined datatypes

  • a convention for representing procedure calls and responses

El sobre es el contrato. Un contrato de datos es un acuerdo entre un servicio y un cliente que descibe qué datos se van a intercambiar. Ese contrato.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (esta es la buena)

Si vemos el proyecto que hemos creado para consumir el servicio hay un archivo que se llama app.config:

En este archivo tenemos el endpoint que usa la DLL. Este valor es fijo, y en caso de que tengamos un endpoint de pruebas y uno de producción tendríamos que crear una librería para cada uno de ellos. También vemos el contrato que usa, AASSOAPCalculatorService.CalculatorSoap. Como #MSDyn365FO es un ERP basado en web podríamos solucionar esto añadiendo el nodo de  system.serviceModel en el web.config del servidor, no? (app.config para apps de escritorui, web.config para apps web). Sí, pero sólo podríamos hacerlo en desarrollo porque en producción no tenemos acceso al servidor, y en cuanto los entornos Tier2+ se migren a self-service será imposible ahí también.

¿Qué hacemos entonces? Fácil, ChannelFactory<T> al rescate.! ChannelFactory<T> nos permite crear una instancia de la factory para nuestro contrato del servicio y después crear un canal entre el cliente y el servicio. El cliente sería nuestra clase en D365and y el servicio el endpoint (obviamente).

Hacemos lo siguiente:

El objeto BasicHttpBinding puede ser un BasicHttpsBinding si el servicio web corre sobre HTTPS. El objeto EndpointAddress es la URL del servicio. Instanciamos un contrato del servicio de nuestra clase con el binding y el endpoint y creamos el canal. Ahora podemos llamar al servicio web y sus métodos y…

Funciona! Y lo que es mejor, si hay distintos endpoints con este método podemos parametrizarlos y solo necesitamos una DLL para todos los endpoints!

Pero de verdad, evitad los servicios SOAP, tiremos todos de REST.

¡Suscríbete!

Recibe un correo cuando se publique un nuevo post
Author

Microsoft Dynamics 365 Finance & Operations technical architect and developer. Business Applications MVP since 2020.

1 Comment

  1. Pingback: GeekzSoltutions

Write A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

ariste.info