SOA/ORACLE OSBcommitea.es/wp-content/uploads/2019/02/osb12_d1.pdfCONTENIDOS SOA/ORACLE OSB DEPURACIÓN Y CONTROL OSB Identificar y corregir los posibles errores dentro de un pipeline

SOA/ORACLE OSBM á l a g a – 0 2 / 2 0 1 9

A. Ramón MolinaJefe de ProyectoConexiones & IT

Axesor

0. Requisitos previosSOA/ORACLE OSB

Máquina virtual, Oracle OSB 12C

Descargada, instalada y funcionando correctamente

Acceso a los documentos y archivos del curso

http://commitea.es/osb120.2

0.1

Comunicación

@commitea

http://commitea.es

[email protected]

0.3

A. Ramón Molina Milla (commitea)

http://commitea.es/

http://commitea.es/osb12

http://commitea.es/

mailto:[email protected]


0.1 Máquina virtual Oracle OSB 12cRequisitos previos

Máquina virtual Oracle OSB 12.2.1

- Enlace de la descarga: link

- Instalación Oracle Virtual Box 6.0: link

- Configuración

- CPU: 2/4 Cores

- RAM: 8046/10924 MB

- Límite de ejecución 100%

- Red tipo bridge con el conector usado por la maquina host

- Reubicación de los discos duros virtuales

- Posibilidad de usar Jdeveloper de forma nativa: link

- SoapUI-5.5.0: link

- Notepad++: link

- XMLTools

http://commitea.es/

CONTENIDOSSOA/ORACLE OSB

DEPURACIÓN Y CONTROL OSB

Identificar y corregir los posibles errores dentro de

un pipeline.

ADAPTADORES Y TRANSPORTE EN OSB

Componentes que nos permiten el acceso a ciertos

orígenes y la comunicación entre origen y destino.

SEGURIDAD EN SOA/OSB

Métodos y aplicación de patrones definidos por

SOA y aplicados sobre Oracle OSB.5

6

4

FLUJO DE MENSAJES

Herramientas y funcionalidad que nos permite usar

la arquitectura SOA sobre la información tratada.

INTRODUCCIÓN ARQUITECTURA SOA

Comprender que es soa y las principales

herramientas y formatos que lo conforman.

INTRODUCCIÓN ORACLE OSB

Principios básicos de como funciona la herramienta

de Oracle para el intercambio de datos con SOA.2

3

1

L M X J V

18 19 20 21 22

25 26 27 28 29

4 5 6 7 8

PlanificaciónDía 18/02/2019

BienvenidaPresentacionesRevisión/Instalación de software en equipos

Introducción a Arquitectura SOA- ¿Qué es SOA?- SOA Governance- Niveles de abstracción- Patrones de diseño- ETL y ESB- SOAP- XML, XSD

- Ejercicios: - Diseño arquitectura integración real- Validación xml simple- Validación xml complejo.

Horario:09:00 – 14:00

Duración:25 horas

Lunes 18


http://commitea.es/

1. INTRODUCCIÓN SOASOA/ORACLE OSB

Patrones de diseño SOA

Patrones en el mundo real

¿Qué es SOA y que necesidades cubre?

Identificar la necesidad de implantar SOA dentro de un proyecto.

SOA Governance

monitorización y control de alto nivel para procesos de negocio 1.2

1.4

1.1

Niveles de abstracción SOA

Indicador de nivel madurez SOA1.3


http://commitea.es/


ESB

Enterprise Service Bus1.5

ETL

Extract, Transport and Loading1.6


XML y XSD

Extensible Markup Language / schema1.8

SOAP

1.7 Simple Object Access Protocol

http://commitea.es/


REST

Enterprise Service Bus1.9

ODATA

Extract, Transport and Loading1.10


http://commitea.es/

1.1 ¿Qué es SOA y que necesidades cubre?Introducción SOA


http://commitea.es/


“Una arquitectura orientada a servicios (SOA) es una arquitectura para

construir aplicaciones empresariales como un conjunto de componentes de caja negra, sin acoplar, orquestados

para ofrecer un nivel bien definido de servicio mediante la vinculación de los procesos de negocio.”

SOA es un paradigma software

- Busca crear o modificar sistemas con un enfoque en la escalabilidad y la flexibilidad

- La base para la escalabilidad/flexibilidad es la descentralización

SOA es un paradigma definido en el año 2000.

- No tiene un marco teórico totalmente establecido

- Muy flexible, si no se supervisa activamente puede terminar siendo difuso

CRM ERP


http://commitea.es/


“SOA es un estilo de arquitectura de TI que se apoya en la orientación a servicios”

- El cambio de paradigma que establece SOA respecto a la POO se basa en los mismo principios pero con la idea

de mejorarlos ampliando su aplicación a servicios.

- Ejemplo:

- Dentro de nuestra compañía tenemos dos servidores:

- El primero contiene un aplicativo encargado de gestionar los datos de nuestros clientes.

- El segundo servidor gestiona la facturación que hacemos a nuestros clientes.

- ¿Cómo podemos realizar una integración de los dos sistemas sin recurrir a ninguna herramienta

específica de SOA?


CRM ERP

http://commitea.es/


Posibles soluciones fuera de la arquitectura de SOA

- Generando una base de datos intermedia (stagin area)

- Intercambiando ficheros con datos en una carpeta de red compartida.

- Mediante la creación de un aplicativo que exponga y consuma los datos de cada uno de los sistemas

involucrados.

- Generando una herramienta intermedia que se encargue de leer los datos de cada uno de los sistemas

involucrados y haga de puente entre la comunicación.


CRM ERP

http://commitea.es/


Ejercicio: 0Diseño de arquitectura de integración real

http://commitea.es/

Ejercicio: 0Diseño de arquitectura de integración real.

Diseño de arquitectura de integración real.

Diseñar una arquitectura de integración real entre SAP y nuestro CRM:

- Usaremos SAP RFC para poder acceder a los datos.

- La RFC usada será RFC Read Table.

- Los datos han de viajar en un canal seguro.

- En caso de caída de uno de los dos servidores deberá de reintentarse la carga.


http://commitea.es/


- Para identificar el aporte de SOA, revisemos el ejemplo con las herramientas que proporciona SOA


http://commitea.es/


La importancia de la arquitectura SOA es que otorga la posibilidad de convertir las tecnologías en auténticos

habilitadores de negocio, aspecto que sin duda resulta fundamental para las empresas que buscan alcanzar el éxito en

un mercado cada vez más competitivo.

La arquitectura SOA permite alinear y acercar las áreas de tecnología y negocio

SOA permite el desarrollo de aplicaciones manejables y más seguras, ya que proporciona una infraestructura y

documentación común para desarrollar servicios con la posibilidad de añadir nuevas funcionalidades.

Gracias a SOA es posible minimizar la pérdida de datos, ya que ofrece seguridad y alta disponibilidad.

La arquitectura SOA permite el desarrollo de aplicación en menor tiempo y más económicas, gracias a la integración de

todos los datos de manera flexible.

SOA ayuda a mejorar la agilidad y flexibilidad de las organizaciones

CRM ERP

SOA Server


http://commitea.es/


Desde el punto de vista corporativo:

- Mejora los procesos de toma de decisiones, debido a que los directivos podrían disponen de mayor información en menor

tiempo.

- Aumenta la productividad de los empleados.

- Se potencian las relaciones con clientes y proveedores.

Desde el punto de vista de los departamentos de TI:

- Aplicaciones más productivas y flexibles.

- Aceleración en el desarrollo de aplicaciones.

- Disminución de costes de mantenimiento de aplicaciones.

- Aplicaciones más seguras y manejables.

- Minimización del riesgo de tiempo de inactividad o pérdidas de datos.

- Mejora de la capacidad para innovar y diferenciarse.

CRM ERP

SOA Server


http://commitea.es/

1.1 ¿Qué es SOA y que necesidades cubre?Simple Object Access Protocol

Procesos soportados: OnLine y Batch.

- Proceso Online:

Es un tipo de procesamiento que facilita y administra aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones.

Requiere un control de la transacción en curso para poder recuperar desde un punto de salvado.

Alta velocidad en la obtención de los datos.

No es recomendable usar este tipo de procesamiento si vamos a traspasar grandes cantidades de datos.

Ejemplo integración SAP mediante acceso RFC.

- Proceso Batch:

Batch processing («procesamiento por lotes»), la ejecución de una serie de programas en un computador sin la interacción humana.

Normalmente requiere desarrollo de software para instalar en la máquina origen.

Alta velocidad en el procesamiento de ficheros.

No es recomendable este tipo de procesamiento para datos en tiempo real.

Ejemplo integración SAP mediante desarrollo intermedio de generación de ficheros.


http://commitea.es/


1.2 SOA Governancemonitorización y control de alto nivel para procesos de negocio

http://commitea.es/


SOA Governance

- SOA Governance se compone de tres elementos indispensables:

- Registro: se trata de un catálogo con carácter evolutivo que recoge con detalle toda la información sobre los servicios disponibles en la implementación de SOA.

Este registro hace posible una mejor comunicación entre procesos de negocio y es la base para el descubrimiento de oportunidades.

- Política: más que una única norma, consiste en un conjunto de restricciones de comportamiento cuya función es garantizar que los servicios no pierden la

coherencia necesaria. Además otro de sus principales objetivos es el evitar que se produzcan conflictos entre ellos. Estas limitaciones también aseguran que se

siguen las mejores prácticas de ingeniería, se observa la normativa legal y se aplica el sentido común en las relaciones con los clientes. La aplicación de la

política que rige SOA governance ha de ser invariable, sin embargo, se pueden habilitar excepciones, cuando las circunstancias así lo requieran y se obtenga la

autorización para ello.

- Procedimiento de pruebas: su misión es garantizar la eficiencia, seguridad y rentabilidad de la solución SOA en conjunto. Para lograrlo, cuenta con un completo

programa que, desde una perspectiva integral, se ocupa de la planificación de auditorías y el diseño de técnicas para el control y seguimiento del desempeño en

base a procedimientos preestablecidos.


http://commitea.es/

Marco de trabajo:

- Sienta las bases para que cualquier empresa pueda definir e implementar su propio modelo de forma totalmente personalizada. Hay que tener en cuenta que

no debe plantearse como una acción, sino como un proceso gradual, ya que requiere un cambio en la cultura de empresa que se ha de planificar de forma

incremental.

- No existe un único modelo único de gobierno en el ámbito de la arquitectura orientada a servicios, ya que la combinación de política, registro y procedimiento

de pruebas responde a variables como la madurez, tamaño o características del entorno de la organización.

- En cualquier caso, las siguientes cuestiones pueden servir como guía para determinar los puntos fuertes de la definición de SOA Governance que aplicará en el

negocio:

- Qué es necesario para garantizar la eficacia de SOA en la organización.

- Quién o quiénes se harán responsables de la toma de decisiones relativas a la gobernabilidad de la arquitectura.

- Cómo se emplearán los medios para realizar las tareas de seguimiento de la evolución de las decisiones de gobierno de SOA tras su aplicación.



http://commitea.es/

SOA Governance

- Políticas (Qué):

Arquitectura de referencia

Metas y objetivos

Activos

Estándares

Administración de la configuración



http://commitea.es/

SOA Governance

- Decisiones (Quién):

Unidades organizativas.

Partes interesadas.

Funciones y responsabilidades.



http://commitea.es/

SOA Governance

- Procesos (Cómo):

Ciclo de vida del desarrollo de software

Diseño y tiempo de ejecución

Oracle SOA 12c

Subversion/Git/BitBucket

Sourcetree



http://commitea.es/


1.3 Niveles de abstracción SOAIndicador de nivel madurez SOA

http://commitea.es/


Servicios Iníciales

fase en la que aun no se ha producido un alineamiento con las necesidades de negocio, simplemente se introduce SOA para cubrir algunas necesidades puntuales.

Servicios con Arquitectura

Se definen los límites que evitan un crecimiento descontrolado de los servicios de negocio implementados en la fase anterior del modelo. En esta fase crecen la

consistencia, la fiabilidad y el control de los servicios.

Servicios de Negocio y Colaborativos

Se produce una consolidación de los procesos de negocio en forma de servicios, en esta fase la tecnología converge con las necesidades de negocio. Existen dos

tipos de servicios:

Servicios de negocio donde el mundo tecnológico se pone al servicio del negocio.

Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades compuestas colaboradores, partners o los mismos departamentos de

la organización.


http://commitea.es/

Medición de los Servicios de Negocio

Se analizan los resultados de los servicios mediante el uso de métricas definidas y analizadas por usuarios de negocio y tecnológicos.

Optimización de los Servicios de Negocio

Fase en la que los servicios son analizados para encontrar puntos de mejora continua. Esta fase se lleva a cabo dentro de un ciclo que tiene como final la retirada

del servicio de negocio analizado. Es importante considerar que los servicios no sólo se analizan de manera individual sino también de forma conjunta analizando

las interacciones entre ellos.



http://commitea.es/


1.4 Patrones de diseño SOAPatrones en el mundo real

http://commitea.es/

1.4 Patrones de diseño en SOAPatrones en el mundo real

Service Bus pattern

- Problema:

Entramos a trabajar en una nueva empresa sin ninguna tecnología definida y tras

analizar el proyecto nos decantamos por una solución basada en WS o API.

- Una vez todo está configurado de forma correcta y tenemos funcionando la

integración de todos nuestros servidores: CRM, ERP, Web, etc. Pero llega un día

donde tenemos que conectarnos con un cliente externo:

- Nuestro parque instalado se va complicando, nuevo servicios con nuevas

tecnologías, vulnerabilidades y el crecimiento de la complejidad de nuestro código

será muy alto.

json

MQ

Stagingarea

xml


http://commitea.es/

Service Bus pattern

- Opción 1:

Cada uno de los servicios tenga expuestas diferentes interfaces para conseguir que se

puedan utilizar desde otros servicios.

Pero no podríamos controlar todos los servicios y en el mejor de los casos solamente

solventaríamos la mitad del problema, tendríamos expuestos los servicios de

múltiples formas pero seguimos necesitando desarrollar o usar extensiones para

consumir los datos expuestos. Esto es lo que SOA debe evitar.

- Opción 2:

Usar un software central (ESB) que nos asegure obtener los datos en “real time” o en

su defecto en “near real time” e implementar una solución bajo el patrón de Service

Bus y usar una infraestructura de mensajería unificada.

Nos permitiría reducir complejidad y costes desde la arquitectura y definir una

herramienta adaptativa para futuras iteraciones de nuestra compañía.



http://commitea.es/

Service Bus pattern

El patrón nos brinda las siguientes herramientas:

- Message Bus: Encargado de conectar los diferentes servicios.

- Message Router: Determina que mensajes son hay que enviar y quién es su

destinatario.

- Channer adaptor: Convierte formatos y protocolos

- Service registration: El Bus debe saber dónde encontrar los servicios para saber

cómo realizar el descubrimiento de la información.

- Message handling: Proporciona la capacidad de invocar los servicios registrados.

Usando el endpoint además de transformar los mensajes para asegurar que el

destino puede consumir la información.

- Publish/subscribe: Permite que los servicios sean notificados de nuevos mensajes

sin necesidad de estar constantemente preguntado al emisor. Y cuando

generamos un nuevo mensaje no sea necesario informar de forma única a cada

uno de los destinos.



http://commitea.es/

Secured Message pattern

- Patrón orientado al componente más fundamental de SOA.

- Los sistemas SOA por definición son:

- Abiertos

- Distribuidos

- Conectado

- Esto significa que existen muchos mensajes viajando entre el origen y el destino.

Podemos mantener el control de los mensajes dentro de los servicios y algo sobre

los consumidores, pero qué pasa con el espacio entre medias o “tierra de nadie”.

- Esta zona es muy propensa a ciberataques y la mayoría son del tipo “man in the

middle”.

- Normalmente una empresa intenta:

- Proteger la privacidad

- Proteger la integridad

- Proteger la suplantación



http://commitea.es/


- Proteger la privacidad:

Proteger los detalles personales de los clientes cuando envía un mensaje de pedido a

un proveedor.

- Proteger la integridad:

Proteger el contenido de los mensajes para no se pueda modificar el contenido, por

ejemplo si indicamos que una factura tiene un importe de 20.000€ no se pueda

cambiar por 200€.

- Proteger la suplantación:

Proteger la identidad de la entidad que originó el mensaje, por ejemplo no queremos

que nadie pueda retirar dinero en nuestro nombre.



http://commitea.es/


- Patrón orientado al componente más fundamental de SOA.

- Los sistemas SOA por definición son:

- Abiertos

- Distribuidos

- Conectado

- Esto significa que existen muchos mensajes viajando entre el origen y el destino.

Podemos mantener el control de los mensajes dentro de los servicios y algo sobre

los consumidores, pero qué pasa con el espacio entre medias o “tierra de nadie”.

- Esta zona es muy propensa a ciberataques y la mayoría son del tipo “man in the

middle”.

- Normalmente una empresa intenta:

- Proteger la privacidad

- Proteger la integridad

- Proteger la suplantación



http://commitea.es/


1.5 ESBEnterprise Service Bus

http://commitea.es/



¿Qué es un ESB?

Un ESB se ocupa la capa de abstracción intermedia (middleware) entre los distintos

sistemas de una o varias organizaciones, proporcionando mecanismos de

comunicación y transformación a través de mensajería basada en estándares.

En definitiva, un ESB debe ser capaz de reemplazar todo el contacto directo entre

aplicaciones, consiguiendo que todas ellas se comuniquen a través del bus.

Los ESB transmiten y reciben mensajes basados en estándares, pero deben ser

capaces de transformar mensajes a formatos que sean reconocidos por las distintas

aplicaciones en el caso de que sea necesario, lo que se realiza a través de

adaptadores.

Además, el intercambio de mensajes debe ser independiente de la plataforma. Esto

permite al ESB integrar aplicaciones que se ejecutan en diversos sistemas operativos

o mainframes.

http://commitea.es/


Características de un ESB

- Independiente respecto a sistemas operativos y lenguajes de programación.

- Uso de formatos reconocidos (Xml, Json, csv) como lenguaje estándar de

comunicación.

- Soporte de estándares de Servicios Web.

- Adaptadores para realizar la integración con aplicaciones.

- Sap

- LifeRay

- Modelo de seguridad estándar para autorizar, autentificar y auditar el uso del ESB.

- Transformación de mensajes mediante códigos fuente reconocidos o propios:

- ESQL

- Java

- PHP

- Validación de mensajes.


http://commitea.es/


Características de un ESB

- Enrutamiento de mensajes aplicando reglas de negocio y en función del contenido

del mensaje.

- Manipulación de excepciones.

- Soporte a encolado y mantenimiento de mensajes, si las aplicaciones no están

disponibles.

- Monitorización del sistema y de la actividad de negocio (BAM).


http://commitea.es/


1.6 ETLExtract, Transform and Loading

http://commitea.es/


-


¿Qué es una ETL?

- Extraer, Transformar y Cargar y se refiere a los datos en una

empresa.

- ETL es el proceso que organiza el flujo de los datos entre diferentes

sistemas en una organización y aporta los métodos y herramientas

necesarias para mover datos desde múltiples fuentes a un almacén

de datos, estandarizarlos y cargarlos en otra base de datos.

- ETL forma parte de la Inteligencia Empresarial (Business

Intelligence), también llamado “Gestión de los Datos” (Data

Management).

- La idea es que una aplicación ETL lea los datos primarios de unas

bases de datos de sistemas principales, realice transformación,

validación, el proceso cualitativo, filtración y al final escriba datos en

el almacén y en este momento los datos son disponibles para

analizar por los usuarios.

http://commitea.es/

Características de una ETL

- Conectividad / capacidades de Adaptación (con soporte a orígenes y destinos de

datos):

- Capacidades de entrega de datos

- Capacidades de transformación de datos

- Capacidades de Metadatos y Modelado de Datos

- Capacidades de diseño y entorno de desarrollo

- Capacidades de gestión de datos

- Adaptación a las diferentes plataformas hardware y sistemas operativos existentes

- Las operaciones y capacidades de administración

- La arquitectura y la integración

- Capacidades SOA



http://commitea.es/


Ejercicio: 1Diseño de estructura estándar de mensaje.

http://commitea.es/

Ejercicio: 1Diseño de estructura estándar de mensaje.

Diseño de estructura estándar de mensaje.

Pensando en la reutilización y estandarización de mensajes dentro de nuestra compañía, realizar un diseño de estructura de mensaje que:

- Nos permita identificar rápidamente los datos asociados al mensaje.

- A la hora de recorrerlo pueda acceder rápido a los datos de origen.

- Pueda añadir datos relativos a la lógica de reintentos sin impactar en el contenido original del mensaje.


http://commitea.es/


1.7 SOAPSimple Object Access Protocol

http://commitea.es/


“SOAP es un formato de mensaje XML utilizado en interacciones de servicios web. Los mensajes SOAP habitualmente se envían sobre HTTP o JMS, pero se

pueden utilizar otros protocolos.”

- El uso de SOAP en un servicio web específico se describe mediante la definición WSDL.

- SOAP fue creado, entre otros, por: Microsoft, IBM Es uno de los protocolos utilizados en los servicios Web.

- Hay dos versiones de SOAP en uso común: SOAP 1.1 y SOAP 1.2.

Un mensaje SOAP DEBE codificarse utilizando XML

Un mensaje SOAP DEBE usar el namespace de SOAP Envelope

Un mensaje SOAP DEBE usar el namespace de codificación SOAP

Un mensaje SOAP NO debe contener una referencia DTD

Un mensaje SOAP NO debe contener instrucciones de procesamiento XML


http://commitea.es/


Estructura mensaje SOAP


http://commitea.es/


SOAP Envelope

Este envelope es requerido y define el documento XML como un mensaje SOAP.

- xmlns:soap Namespace

Siempre debe tener el valor de: "http://www.w3.org/2003/05/soap-envelope/".

Si se utiliza un espacio de nombres diferente, la aplicación genera un error y descarta el mensaje.


http://commitea.es/


SOAP Header

El elemento de header SOAP es opcional opcional.

Contiene información específica de la aplicación (como autenticación, pago, etc.)

sobre el mensaje SOAP.

Si el elemento Header está presente, debe ser el primer hijo del elemento Envelope.

Todos los elementos hijos del elemento de encabezado deben estar

calificados para el namespace.


http://commitea.es/


mustUnderstand

Si contiene los siguientes valores:

“0 - 1” (SOAP 1.1)

“true – false” (SOAP 1.2)

Indicará que que el receptor que procesa el Header debe reconocer el elemento.

Si el receptor no reconoce el elemento, fallará al procesar el encabezado.


http://commitea.es/


actor (SOAP 1.1)

role (SOAP 1.2)

no todas las partes de un mensaje SOAP pueden estar destinadas al punto final,

sino que pueden estar destinadas a uno o más de los puntos finales en la ruta del mensaje.

El atributo de actor/role se utiliza para dirigir el elemento de encabezado a

un punto final específico.

Los roles pueden ser definidos por la aplicación y son designados por un URI.

Por ejemplo, http://example.com/Log podría designar la función de un nodo que realiza el registro

La especificación SOAP 1.2 define tres roles estándar además de los definidos por la aplicación:

http://www.w3.org/2003/05/soap-envelope/none

Ninguno de los nodos SOAP en la ruta del mensaje procesará el bloque de encabezado directamente.

http://www.w3.org/2003/05/soap-envelope/next

Se espera que todos los nodos SOAP en la ruta del mensaje examinen el bloque de encabezado, siempre que un nodo no haya eliminado el encabezado en la ruta del mensaje.

http://www.w3.org/2003/05/soap-envelope/ultimateReceiver

Solo se espera que el nodo receptor final examine el bloque de encabezado.


http://commitea.es/


encodingStyle (SOAP 1.1 y SOAP 1.2)

Se utiliza para definir los tipos de datos utilizados en el documento.

Este atributo puede aparecer en cualquier elemento SOAP y se aplica al contenido

del elemento y a todos los elementos hijos.

Un mensaje SOAP no tiene codificación predeterminada.


http://commitea.es/


relay (SOAP 1.2)

Especifica si este encabezado será retransmitido a los nodos descendentes.


http://commitea.es/


SOAP Body

El elemento de cuerpo SOAP requerido contiene el mensaje SOAP real destinado

al punto final del mensaje.

Los elementos secundarios inmediatos del elemento Cuerpo de SOAP

pueden estar calificados para el espacio de nombres.


http://commitea.es/


SOAP Fault

El elemento SOAP Fault opcional se usa para indicar mensajes de error.

El elemento de falla SOAP contiene errores e información de estado para un mensaje SOAP.

Si un elemento Fault está presente, debe aparecer como un elemento hijo del elemento Body.

Un elemento de fallo solo puede aparecer una vez en un mensaje SOAP.

El elemento de falla SOAP tiene los siguientes subelementos:


<faultcode> Un Código para identificar el error.

<faultstring> Una explicación corta humanizable del error

<faultactor> Información del causante del error.

<detail> Contiene infomración específica del error de la aplicación

http://commitea.es/


SOAP ejemplo


http://commitea.es/

Documents

SOA/ORACLE OSBcommitea.es/wp-content/uploads/2019/02/osb12_d1.pdfCONTENIDOS SOA/ORACLE OSB DEPURACIÓN Y CONTROL OSB Identificar y corregir los posibles errores dentro de un pipeline