SEVILLA Meetups29112022_sh.pptx
- 1. FRANCISCO JAVIER TOSCANO LOPEZ 29/11/2022 SEVILLA MuleSoft Meetup Group
- 2. 2 Agenda • Integración de sistemas ¿Qué es? • Protocolo de integración HTTP • Protocolo de integración SOAP y REST • Implementación de ejemplos con MuleSoft • Despliegues de Mule Apps en CloudHub y Runtime Fabric • Mesa redonda.
- 3. All contents © MuleSoft, LLC Integración ¿Que es?
- 4. 4 Integración de sistemas ¿Qué es? • Proceso encargado de hacer que varios sistemas se comuniquen entre ellos para entregar una funcionalidad global como sistema integrado • Para conseguir un sistema integrado nos basamos en unidades básicas de integración (INT-XX), encargadas de conectar únicamente dos sistemas Subsistema A Subsistema C Subsistema B Sistema integrado INT-AB
- 5. 5 Unidad básica de integración La unidad básica de integración, comunica dos sistemas utilizando cuatro aspectos tecnológicos básicos, con el objetivo de habilitar el intercambio de información entre ambos sistemas. • Protocolo • Seguridad • Mensaje • Comunicación Seguridad Mensaje Protocolo Subsistema A Subsistema B Comunicación Integración AB
- 6. 6 Unidad básica de integración Protocolo: Conjunto de reglas que definen el modo en la que se llevará a cabo la comunicación entre ambos sistemas. Seguridad: Condiciones que deben cumplir los sistemas para confiar el uno en el otro. Mensaje: Contiene la información intercambiada entre ambos sistemas. Comunicación: Define la dirección de la comunicación, qué puede ser bidireccional o unidireccional. Seguridad Mensaje Protocolo A B
- 7. 7 Ejemplos de tecnologías de integración Existen muchos tipos diferentes de tecnologías asociadas a cada aspecto de la unidad básica de integración. Aplicando diferentes combinaciones conforman la gran variedad de tipos de integración. Protocolo • HTTP • FTP • SMTP • SOAP • LDAP Mensaje • XML • XSD • JSON • JSON Schema • Base64 • Binary Seguridad • WSS • BASIC • OAUTH • SSL/TLS • JWT Comunicación • Unidirecciona l • Bidireccional • Síncrona • Asíncrona
- 8. All contents © MuleSoft, LLC Protocolo de integración HTTP
- 9. 9 Protocolo de integración HTTP Protocolo síncrono basado en TCP (Transmission Control Protocol) que permite la trasferencia de información entre sistemas de la WWW (World Wide Web) y que se apoya en los siguientes conceptos • URI • Método • Cabeceras • Parámetros • Cuerpo de mensaje • Códigos de error Subsistema A Subsistema B
- 10. Protocolo de integración HTTP 10 URI (Uniform Resource Identifier) Identifica la dirección del recurso HTTP: URI = URL + URN • URL (Uniform Resource Locator): http://www.domain.com • URN (Uniform Resource Name): /resource • URI: http://www.domain.com/resource Métodos (por convenio) • GET: Solicita obtener un recurso • POST: Solicita crear un nuevo recurso • PUT: Solicita reemplazar un recurso existente por completo • PATCH: Solicita reemplazar un recurso existente parcialmente • DELETE: Solicita eliminar un recurso Cabeceras Las cabeceras HTTP son metadatos que son enviados del (origen destino) en la solicitud y (destino origen) en la respuesta. Aunque se pueden usar cabeceras definidas por el usuario, existen muchas cabeceras reservadas por el propio protocolo HTTP. (Content-Type, Accept, Authorization, …) Parámetros Los parámetros son metadatos que son solo enviados en la solicitud (origen destino) como parte de la URI. Pueden ser de dos tipos pathParam o queryParam http://www.domain.com/{pathParam1}/{pathParam2}?query Param1=value1&queryParam2=value2
- 11. 11 Protocolo de integración HTTP Cuerpo del Mensaje (body/payload) Información trasmitida en cada dirección de la comunicación HTTP. Solo los métodos de creación y modificación permiten el envío de un mensaje en la solicitud, pero en todos los casos se permite recibir un mensaje como respuesta. • GET, DELETE: No envían mensaje en el cuerpo de la solicitud • POST, PUT, PATCH: Envían mensaje en el cuerpo de la solicitud La cabecera Content-Type define el tipo de contenido enviado en la solicitud • Content-Type: application/json La cabecera Accept define el tipo de contenido aceptado en la respuesta • Accept: text/plain Códigos de error El protocolo HTTP responde con un código informando el estado de procesamiento de las solicitud • 1xx: Respuestas informativas. Indica que la petición ha sido recibida y se está procesando. • 2xx: Respuestas correctas. Indica que la petición ha sido procesada correctamente. • 3xx: Respuestas de redirección. Indica que el cliente necesita realizar más acciones para finalizar la petición. • 4xx: Errores causados por el cliente. Indica que ha habido un error en el procesado de la petición a causa de que el cliente ha hecho algo mal. • 5xx: Errores causados por el servidor. Indica que ha habido un error en el procesado de la petición a causa de un fallo en el servidor.
- 12. All contents © MuleSoft, LLC Protocolo de integración SOAP
- 13. 13 Protocolo de integración SOAP SOAP (Simple Object Access Protocol) es un protocolo síncrono basado principalmente en HTTP cuyo objetivo es publicar una funcionalidad como un servicio web a través del intercambio de mensajes XML. Este protocolo aporta interoperabilidad entre sistemas al margen de la plataforma tecnológica, utilizando los siguientes conceptos: • HTTP • WSDL • XML • WSS • XSD Subsistema A Subsistema B SOAP-WS
- 14. 14 Protocolo de integración SOAP HTTP (Hypertext Transfer Protocol) El protocolo SOAP se basa en HTTP para trasmitir la información. • Método GET: Para obtener la descripción del servicio web (WSDL) • Método POST: Para operar con las operaciones del servicio web • Cabecera Content-Type: text/xml; application/soap+xml XSD XML que define el esquema de datos de los mensajes SOAP, especificando tanto la estructura como los posibles valores que puede contener cada elemento o atributo. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> </xsd:schema> XML (Extensible Markup Language) Lenguaje de etiquetas, usado por SOAP para representar la definición del servicio web, los esquemas de datos y los mensajes. • WSDL: XML de definición del servicio web, sirve como contrato en la comunicación. • XSD: XML de definición de los tipos de mensajes usados por el servicio web • XML-SOAP: XML que contiene el mensaje de solicitud y respuesta WSDL XML que define todos aspectos relativos el servicio web SOAP. Expone el nombre del servicio, Endpoint de consumo, operaciones y tipos de mensajes de solicitud y respuesta de cada operación <wsdl:definitions name="Service" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> </wsdl:definitions>
- 15. 15 Protocolo de integración SOAP - WSDL Elementos definición abstracta • Definition : es el elemento raíz de todos los documentos WSDL. Define el nombre del servicio web, declara múltiples espacios de nombres utilizados en el resto del documento y contiene todos los elementos de servicio descritos aquí. • Data types : los tipos de datos que se utilizarán en los mensajes. • Message : es una definición abstracta de los datos, en forma de un mensaje presentado como un documento completo o como argumentos para mapear a una invocación de método. • Port Type : es un conjunto abstracto de operaciones asignadas a uno o más endpoint, que definen la recopilación de operaciones para un enlace; La colección de operaciones, como es abstracta, se puede asignar a múltiples transportes a través de varios enlaces. • Operation : es la definición abstracta de la operación de un mensaje, como nombrar un método, una cola de mensajes o un proceso comercial, que aceptará y procesará el mensaje. Elementos definición concreta • Binding : es el protocolo concreto y los formatos de datos para las operaciones y los mensajes definidos para un tipo de puerto en particular. • Port : es una combinación de un enlace y una dirección de red, que proporciona la dirección de destino de la comunicación del servicio. • Service : es una colección de endpoint relacionados que abarca las definiciones de servicio en el archivo; los servicios asignan el enlace al puerto e incluyen cualquier definición de extensibilidad. Elementos opcionales • Documentation: este elemento se utiliza para proporcionar documentación legible para humanos y se puede incluir dentro de cualquier otro elemento WSDL. • Import: este elemento se usa para importar otros documentos WSDL o esquemas XML
- 16. 16 Protocolo de integración SOAP – Ejemplos Ejemplos • soap_arquitectura.xml: Este ejemplo tiene el esquema básico de un WSDL • soap_ejemplo.xml: Este ejemplo tiene un ejemplo sencillo de una operación Hola Mundo • s-soap-gdi.wsdl: Tiene un ejemplo real de un proyecto.
- 17. 17 Protocolo de integración SOAP - WSS Cabecera UserNameToken WSS mediante usuario y contraseña que serán trasmitidos en la cabecera del mensaje SOAP. <soap:Envelope xmlns:soap="..." xmlns:wsse="..."> <soap:Header> ... <wsse:Security> <wsse:UsernameToken> <wsse:Username>USER</wsse:Username> <wsse:Password Type="...">PASS</wsse:Password> <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> <wsu:Created> ... </wsu:Created> </wsse:UsernameToken> </wsse:Security> ... </soap:Header> ... </soap:Envelope> Formato de contraseña El método UsernameToken permite representar la contraseña de dos formas diferentes. • PasswordText: La contraseña como texto plano Password_Text = Contraseña • PasswordDigest: El resumen de la contraseña (SHA) y opcionalmente el Nonce y/o el sello de tiempo de creación del mensaje (Created). Password_Digest = Base64 (SHA-1(nonce + created + password)) El nonce es una contramedida usada para evitar ataques de repetición, de forma que el servidor SOAP debe implementar un control del mismo para que sea efectivo.
- 18. All contents © MuleSoft, LLC Protocolo de integración REST y diferencias con SOAP
- 19. 19 Protocolo de integración REST Definición • REST es una interfaz para conectar varios sistemas basados en el protocolo HTTP y nos sirve para obtener y generar datos y operaciones, devolviendo esos datos en formatos muy específicos, como XML y JSON. • El formato más usado en la actualidad es el formato JSON, ya que es más ligero y legible en comparación al formato XML. • REST se apoya en HTTP, los verbos que utiliza son exactamente los mismos, con ellos se puede hacer GET, POST, PUT y DELETE. De aquí surge una alternativa a SOAP. • REST llega a solucionar esa complejidad que añadía SOAP, haciendo mucho más fácil el desarrollo de una API. Características • En REST existen varios estándares para la descripción de interfaces, entre ellos OpenAPI, RAML • Tipos de seguridad: Basic Authentication, LDAP, Oauth 2.0, JWT,…
- 20. 20 SOAP vs REST SOAP REST SOAP es un protocolo. SOAP fue diseñado con una especificación. Incluye un archivo WSDL que tiene la información requerida sobre lo que hace el servicio web, además de la ubicación del servicio web. REST es un estilo arquitectónico en el que un servicio web solo puede ser tratado como un servicio HTTP RESTful. SOAP no puede hacer uso de REST ya que SOAP es un protocolo y REST es un patrón arquitectónico. REST puede hacer uso de SOAP como protocolo subyacente para los servicios web, porque al final es solo un patrón arquitectónico. SOAP utiliza interfaces de servicio para exponer su funcionalidad a las aplicaciones cliente. En SOAP, el archivo WSDL proporciona al cliente la información necesaria que se puede utilizar para entender qué servicios puede ofrecer el servicio web. REST utiliza localizadores de servicio uniforme para acceder a los componentes del dispositivo de hardware. Por ejemplo, si hay un objeto que representa los datos de un empleado alojado en una URL como http://demo.example, los siguientes son algunos de los URI que pueden existir para acceder a ellos. http://demo.example/empleado http://demo.example/empleado/1
- 21. 21 SOAP vs REST SOAP REST SOAP requiere más ancho de banda para su uso. Dado que los mensajes SOAP contienen mucha información dentro de ellos, la cantidad de transferencia de datos usando SOAP suele ser mucha. <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP- ENV ="http://www.w3.org/2001/12/soap-envelope" SOAP- ENV:encodingStyle =" http://www.w3.org/2001/12/soap- encoding"> <soap:Body> <Demo.guru99WebService xmlns="http://tempuri.org/"> <EmployeeID>int</EmployeeID> </Demo.guru99WebService> </soap:Body> </SOAP- ENV:Envelope> REST no necesita mucho ancho de banda cuando se envían solicitudes al servidor. Los mensajes REST consisten principalmente en mensajes JSON. A continuación se muestra un ejemplo de un mensaje JSON pasado a un servidor web. Puedes ver que el tamaño del mensaje es relativamente menor que el de SOAP. {"city":"Mumbai","state":"Maharastra"} SOAP solo puede funcionar con formato XML. Como se ve en los mensajes SOAP, todos los datos pasados están en formato XML. REST permite diferentes formatos de datos, como texto sin formato, HTML, XML, JSON, etc. Pero el formato más preferido para transferir datos es JSON.
- 22. All contents © MuleSoft, LLC Implementación de ejemplos con MuleSoft
- 23. 23 Ejemplo Mule App Definiciones • RAML: Definición del contrato de integración. • Scaffolding: Proceso de creación del esqueleto de la mule app a partir del RAML. • Operation: Diferentes servicios Rest definidos en el RAML e implementados en los Flow. • Global Element: Elementos de configuración que afecta a todos los flujos que lo utilicen. • Flow/Subflow: Componente de Mulesoft por el que fluye el mensaje cuando llega a la Mule App. • Component: Los diferentes componentes de Mulesoft que modifican el mensaje cuando viaja por el flujo. • Connector: Componente que simplifica el proceso de conexión con elementos externos. a Mulesoft, (BBDD, JMS, etc). • SOAP Route: Componente que construye los Flow a partir del WSDL. • ApiKit Route: Componente que construye los Flow a partir del RAML/OAS3.
- 24. All contents © MuleSoft, LLC Ejemplo de Mule App, que consume un Web Service SOAP
- 25. 25 Ejemplo Mule App – consume web service SOAP • Flujo 1 (consumer-service-api2Flow-local) : Este flujo llama a un WS Mock publicado en local con SoapUI, con el componente WS Consumer. • Flujo 2 (consumer-service-api2Flow-real): Este flujo llama a un WS real publicado por Postman y w3school con el componente WS Consumer. • Flujo 3 (consumer-service-api2-http-real): Este flujo llama al WS Real pero con el componente Http Request.
- 26. All contents © MuleSoft, LLC Ejemplo de Mule App, que publica un Servicio SOAP
- 27. 27 Ejemplo Mule App – publica web service SOAP • De donde partimos??, de un WSDL: para poder crear un WS SOAP con MuleSoft es necesario tener un contrato WSDL de donde partir. En el proceso de creación del proyecto al incluir el WSDL en el proceso de scaffolding se crea el esqueleto con el SOAP Route. • SOAP Route: es el componente encargado de enrutar el mensaje cuando llega a MuleSoft.
- 28. All contents © MuleSoft, LLC Despliegues de Mule Apps en CloudHub 1.0 con Maven
- 29. 29 Publicación de Mule App en CloudHub 1.0 <plugin> <groupId>org.mule.tools.maven</groupId> <artifactId>mule-maven-plugin</artifactId> <version>${mule.maven.plugin.version}</version> <extensions>true</extensions> <configuration> <classifier>mule-application</classifier> <cloudHubDeployment> <uri>https://anypoint.mulesoft.com</uri> <muleVersion>4.4.0</muleVersion> <businessGroup>everisSandbox</businessGroup> <businessGroupId>ed517fa0-dd83-4ea0-b12c- b68a2f170e25</businessGroupId> <username>${userPlatform}</username> <password>${passPlatform}</password> <applicationName>s-examplech1</applicationName> <environment>Dev</environment> <region>us-east-2</region> <workers>1</workers> <workerType>MICRO</workerType> <properties> <key>value</key> </properties> </cloudHubDeployment> </configuration> </plugin>
- 30. All contents © MuleSoft, LLC Despliegues de Mule Apps en Runtime Fabric con Maven
- 31. 31 Publicación de Mule App en Runtime Fabric <plugin> <groupId>org.mule.tools.maven</groupId> <artifactId>mule-maven-plugin</artifactId> <version>${mule.maven.plugin.version}</version> <extensions>true</extensions> <configuration> <classifier>mule-application</classifier> <runtimeFabricDeployment> <uri>https://anypoint.mulesoft.com</uri> <muleVersion>4.4.0</muleVersion> <username>${userPlatform}</username> <password>${passPlatform}</password> <applicationName>s-examplertf</applicationName> <businessGroup>everisSandbox</businessGroup> <businessGroupId>ed517fa0-dd83-4ea0-b12c- b68a2f170e25</businessGroupId> <target>rtf-aks-sandbox</target> <environment>Dev</environment> <provider>MC</provider> <replicas>1</replicas> <properties> <key>value</key> </properties> <deploymentSettings> <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAc rossNodes> <updateStrategy>recreate</updateStrategy> <clustered>false</clustered> <forwardSslSession>false</forwardSslSession> <lastMileSecurity>false</lastMileSecurity> <resources> <cpu> <reserved>70m</reserved> <limit>500m</limit> </cpu> <memory> <reserved>1000Mi</reserved> </memory> </resources> <http> <inbound> <publicUrl>http://rtfntt.example.com/s- examplertf</publicUrl> </inbound> </http> </deploymentSettings> </runtimeFabricDeployment> </configuration> </plugin>
- 32. All contents © MuleSoft, LLC Despliegues de Mule Apps en CloudHub 2.0 con Maven
- 33. 33 Publicación de Mule App en CloudHub 2.0 <plugin> <groupId>org.mule.tools.maven</groupId> <artifactId>mule-maven-plugin</artifactId> <version>${mule.maven.plugin.version}</version> <extensions>true</extensions> <configuration> <classifier>mule-application</classifier> <cloudhub2Deployment> <uri>https://anypoint.mulesoft.com </uri> <provider>MC</provider> <environment>Dev</environment> <target>Cloudhub-EU-West-2</target> <businessGroup>everisSandbox</businessGroup> <businessGroupId>ed517fa0-dd83-4ea0-b12c- b68a2f170e25</businessGroupId> <username>${userPlatform}</username> <password>${passPlatform}</password> <muleVersion>4.4.0</muleVersion> <server>anypoint-exchange-v3</server> <applicationName>${project.name}</applicationName> <replicas>1</replicas> <vCores>0.1</vCores> <deploymentSettings> <lastMileSecurity>false</lastMileSecurity> <forwardSslSession>false</forwardSslSession> <generateDefaultPublicUrl>true</generateDefaultPublicUrl> </deploymentSettings> </cloudhub2Deployment> </configuration> </plugin>
- 34. Thank you