SEVILLA Meetups29112022_sh.pptx

FRANCISCO JAVIER TOSCANO LOPEZ
29/11/2022
SEVILLA MuleSoft Meetup Group

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.

All contents © MuleSoft, LLC
Integración ¿Que es?

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

Protocolo de integración HTTP

9
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

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
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.

Protocolo de integración SOAP

13
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
SOAP-WS

14
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
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
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
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.

Protocolo de integración REST y
diferencias con SOAP

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
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
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.

Implementación de ejemplos con MuleSoft

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.

Ejemplo de Mule App, que consume un
Web Service SOAP

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.

Ejemplo de Mule App, que publica un
Servicio SOAP

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.

Despliegues de Mule Apps en CloudHub
1.0 con Maven

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>

Despliegues de Mule Apps en Runtime
Fabric con Maven

31
Publicación de Mule App en Runtime Fabric
<plugin>
<configuration>
<runtimeFabricDeployment>
<uri>https://anypoint.mulesoft.com</uri>
<applicationName>s-examplertf</applicationName>
<target>rtf-aks-sandbox</target>
<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>

Despliegues de Mule Apps en CloudHub
2.0 con Maven

33
Publicación de Mule App en CloudHub 2.0
<plugin>
<configuration>
<cloudhub2Deployment>
<uri>https://anypoint.mulesoft.com </uri>
<provider>MC</provider>
<target>Cloudhub-EU-West-2</target>
<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>

SEVILLA Meetups29112022_sh.pptx

Recomendados

Recomendados

Más contenido relacionado

Similar a SEVILLA Meetups29112022_sh.pptx

Similar a SEVILLA Meetups29112022_sh.pptx (20)

Último

Último (20)

SEVILLA Meetups29112022_sh.pptx