Cómo no romper los límites, cómo crear una buena arquitectura y cómo hacer un buen mantenimiento

Integración de sistemas con Microsoft Flow

Microsoft Flow es uno de los servicios disponibles en Office 365 por el que Microsoft está apostando como herramienta de integración transversal con casi prácticamente cualquier servicio en la nube. Hace un tiempo, nuestro compañero Sergio Hernández  ya presentó este servicio en este mismo blog. En esta ocasión vamos a ver un caso de uso real en el que en ENCAMINA hemos utilizado Flow para integrar correo de Office 365 con SAP CRM. 

Escenario

La necesidad de nuestro cliente era incorporar como actividad dentro de SAP CRM cualquier correo cruzado entre los Account Mangers y una serie de cuentas de clientes. Tanto los correos de entrada como los de salida.

Para ello, se ofrecía un API desde SAP en el que consultar si una cuenta de correo correspondía con uno de los clientes de interés o no. En caso afirmativo, otro método del servicio web de SAP permitía crear la actividad en SAP CRM con los datos del correo electrónico. La casuística era más o menos la misma, tanto para los correos de entrada como los de salida. Había que buscar cómo monitorizar los buzones de los Account Managers para comunicarse con el servicio web. 

La solución que encontramos fue utilizar Microsoft Flow para realizar esta monitorización puesto que ofrece un evento que dispara un flujo al enviar o recibir un correo en un buzón de correo.

Este mismo evento se puede lanzar para el correo de entrada o para el de salida, cambiando la carpeta que se monitoriza:

No obstante, para realizar las transformaciones necesarias antes de llamar al servicio web de SAP se generó un web api en Azure  al que se invocó desde el flujo en Microsoft Flow.

Requisitos técnicos

Para poder realizar está integración vamos a necesitar una cuenta de Microsoft Flow, capacidad para desarrollar una web API con autenticación en Azure, y los servicios expuestos de SAP, para poder generar los proxies correspondientes.

Implementación

 

La base fundamental de todo el desarrollo está compuesta por una serie de proxies generados mediante los wsdl extraídos de SAP. Para nuestro ejemplo han sido generados para C#, e integrados en un proyecto con visual studio 2017:

service.cs : Proxy wsdl generado para obtener si el remitente esta dado de alta en SAP.

serviceManager.cs : Proxy wsdl generado para crear acciones en SAP.

Una vez generados los ficheros proxy que nos permiten el acceso a SAP, generaremos una web api para hacer uso de ellos, y que nos permita generar la lógica necesaria para ello.

 

El fichero principal de nuestra web api “SAPController.cs”, expondrá los métodos necesarios para poder comunicar nuestro flujo con la web api, publicada en Azure

 

 

 

Para el ejemplo vamos a examinar el método GetBP, que nos permite saber si el remitente de un correo está dado de alta el SAP.

Como se puede ver en la captura, instanciamos el proxy para consultar si el usuario está vinculado a un cliente en SAP, para ello generamos una entidad NetworkCredential que nos permita almacenar las credenciales de acceso a SAP, que tendremos almacenadas en nuestro web.config.

El método a utilizar será “FindBusinessPartnerByEmailURI_Sync”, expuesto por SAP y accesible mediante nuestro proxy. Este método requiere un objeto de tipo data, que contenga el correo a consultar.

En caso afirmativo nuestro método nos devolverá el código asociado al cliente vinculado a esta cuenta de correo.

Por último, necesitaremos crear otro método más que nos permita crear acciones en SAP. Para ello utilizaremos el segundo proxy que expone los métodos necesarios para crear acciones:

Una vez creado el web api, será necesario publicarlo en Azure mediante un perfil de publicación, además de crear las dos aplicaciones empresariales en Azure Active Directory para poder realizar un acceso seguro a la web api.

Estas aplicaciones nos proveen de un token de autorización que nos permite realizar comunicaciones con el web api, estos datos serán necesarios para poder configurar las llamadas desde el Flow encargado de monitorizar una carpeta vinculada a nuestro correo de office 365.

Para finalizar este ejemplo, nos falta unir todas las piezas creadas hasta ahora, esto lo realizamos mediante Microsoft Flow.

Este flujo nos permite mediante las acciones básicas de Flow automatizar la monitorización de una cuenta de correo, como vemos la primera acción a utilizar es la de recepción de correo, esta acción está vinculada a una conexión que crearemos mediante la cuenta que queramos monitorizar.

Como vemos la cuenta a monitorizar es la que mediante la configuración indicamos como conexión a Office 365, una vez publicado el flujo, este se activará ante cada correo recibido.

Por último, vamos a ver cómo hacer uso del web api que hemos publicado en Azure, y cómo utilizar los métodos de autenticación para que las comunicaciones se realicen. Para ello utilizaremos la acción de conexión http:

Como vemos, esta acción tiene varios parámetros a configurar:

  • Método: En nuestro caso vamos a utilizar GET, ya que así lo hemos configurado en la web api.
  • URI: Url de acceso al método expuesto por la webapi, y el parámetro obtenido al monitorizar el correo entrante.
  • Autenticación: Active Directory OAuth, es el método de autenticación implementado mediante la aplicación cliente servidor creada en Azure.
  • Autoridad: Url de acceso al login de Microsoft
  • Inquilino: Identificador de la aplicación servidor creada en Azure active directory.
  • Audiencia: Url + Tenant Id.
  • idCliente: Identificador de la aplicación cliente creada en Azure active directory.
  • Secreto: Clave secreta proporcionada al crear la aplicación cliente en Azure active directory.

Conclusiones

Como hemos podido ver en este artículo, Flow es una herramienta que nos permite realizar integraciones entre servicios, no sólo dentro del ámbito de Office 365 sino también con otros aplicativos completamente al margen del mismo, como puede ser SAP CRM. Aprovechamos para aclarar que en Dynamics CRM esta integración del correo como actividad comercial se realiza de forma nativa utilizando Exchange Online, no hubiese sido necesario ningún desarrollo adicional ni integración con Flow 😊

¡Por cierto! Este artículo no hubiera sido posible sin la inestimable ayuda de mi compañero Paco Martí 🙂

 

mm

Sobre José Rafael García Rodrigo

Llevo unos catorce años trabajando en el negocio de IT, los últimos doce dedicados a tecnologías Microsoft, especialmente SharePoint y Office 365, BPM (Nintex y K2) y gestión de proyectos (Project Server). Durante todo este tiempo he realizado diferentes funciones (desarrollador, analista, arquitecto, consultor, Team Leader…) hasta llegar a mi puesto actual como Project Manager en ENCAMINA. No tengo muy claro el por qué, pero cuando nació mi hijo mayor nació también en mí la necesidad del emprendimiento. De repente, mi cabeza trataba de solucionar los problemas de negocio que iba advirtiendo tanto en mi vida profesional como personal, buscando oportunidades en los nuevos avances tecnológicos. Aprendí muchísimo durante el camino y creo que todo ese conocimiento me ayudará a hablar en este blog de cómo aprovechar la tecnología para descubrir propuestas disruptivas que ni siquiera nos hubiésemos planteado hace poco tiempo y que cambiarán nuestra organización y la relación con los clientes de manera inimaginable.
Esta entrada ha sido publicada en Azure, Flow, SharePoint. Enlace permanente.
ENCAMINA, piensa en colores