BPEL - Guía rápida

SOA o la Arquitectura Orientada a Servicios es un enfoque arquitectónico que hace uso de la tecnología para presentar los procesos comerciales como servicios reutilizables.

  • Está enfocado en el negocio y permite la transformación de procesos a nuevos niveles de integración, visualización, monitoreo y optimización.

  • No es una tecnología, es un concepto y una estrategia para usar tecnologías para construir soluciones de automatización empresarial.

Ahora veremos qué es BPEL y cómo ayuda en SOA.

¿Qué es BPEL?

Business Process Engineering Language es una tecnología que se utiliza para crear programas en arquitectura SOA.

Adición de un componente de servicio de proceso BPEL

Siga estos pasos para agregar un componente de servicio de proceso BPEL:

  • Desde el navegador de aplicaciones, seleccione Archivo> Nuevo> Aplicaciones> Aplicación SOA.

  • Esto inicia el asistente Crear aplicación SOA.

  • En el cuadro de diálogo Nombre de la aplicación, ingrese un nombre de la aplicación en el campo Nombre de la aplicación.

  • En el campo Directorio, ingrese una ruta de directorio en la que crear la aplicación y el proyecto compuestos SOA.

  • Haga clic en Siguiente.

  • En el cuadro de diálogo Nombre del proyecto, ingrese un nombre en el campo Nombre del proyecto.

  • Haga clic en Siguiente.

  • En el cuadro de diálogo Configuración de SOA del proyecto, seleccione Compuesto con el proceso BPEL.

  • Haga clic en Finalizar.

Archivos en el compuesto BPEL

El compuesto BPEL contiene los siguientes archivos:

  • composite.xml - Este archivo describe todo el conjunto compuesto de servicios, componentes de servicio, referencias y cables.

  • .bpel - Este archivo contiene el conjunto de actividades agregadas al proceso.

  • .componentType - Este archivo describe los servicios y referencias para el componente de servicio del proceso BPEL.

  • .wsdl - Este archivo define los mensajes de entrada y salida para este flujo de proceso BPEL, la interfaz y las operaciones de cliente admitidas, y otras características.

Conceptos utilizados en el proceso BPL

En esta sección, aprenderemos los diferentes conceptos involucrados en el proceso BPL.

Orquestación

    Suele utilizarse en procesos comerciales privados.
  • Un proceso central (que puede ser otro servicio web) toma el control de los servicios web involucrados.

  • Coordina la ejecución de diferentes operaciones en los servicios web involucrados en la operación.

  • Los servicios web involucrados no "saben" (y no necesitan saber) que están involucrados en un proceso de composición y que están participando en un proceso de negocios de nivel superior.
  • Solo el coordinador central de la orquestación conoce este objetivo, por lo que la orquestación se centraliza con definiciones explícitas de operaciones y el orden de invocación de los servicios web.

Coreografía

  • No depende de un coordinador central.

  • Cada servicio web involucrado en la coreografía sabe exactamente cuándo ejecutar sus operaciones y con quién interactuar.

  • Cada servicio web involucrado en la coreografía sabe exactamente cuándo ejecutar sus operaciones y con quién interactuar.

  • Todos los participantes en la coreografía deben conocer el proceso comercial, las operaciones a ejecutar, los mensajes a intercambiar y el momento en que se intercambian mensajes.

En este capítulo, aprenderemos sobre las diferentes actividades que componen los bloques de construcción Los bloques de construcción de un componente de servicio de proceso BPEL.

Oracle BPEL Designer incluye un conjunto de actividades que usted arrastra a un componente de servicio de proceso BPEL y hace doble clic en una actividad para definir sus atributos y valores de propiedad.

Asignar actividad

 Una actividad de asignación permite manipular datos, como copiar el contenido de una variable a otra.

Invocar actividad

 Una actividad de invocación le permite invocar un servicio (identificado por su enlace de socio) y especificar una operación para que este servicio la realice.

Recibir actividad

  Una actividad de recepción espera un mensaje de respuesta de devolución de llamada asincrónica de un servicio.

Aprendamos más sobre la actividad Invocar en la sección siguiente.

Invocar actividad

La actividad de invocación permite especificar una operación que se invocará para el servicio (identificada por su enlace de socio). La operación puede ser unidireccional o de solicitud-respuesta en un puerto proporcionado por el servicio. Las variables se pueden crear automáticamente en una actividad de invocación. Una actividad de invocación invoca un servicio sincrónico o inicia un servicio web asincrónico.

La actividad de invocación abre un puerto en el proceso para enviar y recibir datos. Este puerto se puede usar más para enviar los datos requeridos y recibir una respuesta. Para devoluciones de llamada sincrónicas, solo se necesita un puerto para las funciones de envío y recepción.

Los enlaces de socios se definen como intercambios de comunicación entre todas las partes con las que interactúa el proceso BPEL.

Son las referencias a las implementaciones reales, a través de las cuales el proceso BPEL interactúa con el mundo externo.

Vínculos de socios invocados

Estos son enlaces a servicios que son invocados por el proceso BPEL.

Enlaces de socios clientes

Estos son enlaces a servicios que pueden invocar un proceso BPEL.

Propiedades del enlace de socio

El editor de propiedades de enlaces de socios le permite establecer vínculos de socios para sus procesos BPEL. Con el Editor de propiedades de enlace de socio, puede especificar lo siguiente:

  • Name - Especifica el nombre del elemento Invoke.

  • WSDL File - Indica el archivo WSDL asociado con Partner Link.

  • Partner Link Type - Indica el tipo de enlace de socio definido en el WSDL.

  • My Role - Indica la función del proceso empresarial en sí.

  • Partner Pole - Indica el rol del socio.

  • Documentation - Accedido en la ventana Propiedades.

Los enlaces de socios se definen en el archivo .bpel.

Un BPEL puede interactuar con los servicios de las siguientes tres formas:

  • Servicios que invocan un proceso BPEL
  • Servicios que invoca el proceso BPEL
  • Servicios que actúan en ambos sentidos

En este capítulo, aprenderemos cómo crear un enlace de socio.

Siga los pasos que se muestran a continuación para crear un enlace de socio:

  • En SOA Composite Editor, haga doble clic en el componente de servicio de proceso BPEL.

  • Al hacer clic en el componente de servicio, se muestra Oracle BPEL Designer.

  • En la paleta de componentes, expanda Servicios BPEL.

  • Arrastre un enlace de socio al carril correspondiente de vínculos de socio.

  • Complete los campos de este cuadro de diálogo como se mencionó anteriormente en las Propiedades del enlace de socio.

Los adaptadores permiten integrar el componente de servicio de proceso BPEL con acceso a sistemas de archivos, servidores FTP, tablas de bases de datos, colas de bases de datos, sockets, Java Message Services (JMS), MQ y Oracle E-Business Suite. Este asistente permite configurar los tipos de adaptadores que se muestran en la siguiente figura para su uso con el componente de servicio de proceso BPEL:

Tipos de adaptadores

La siguiente imagen muestra los diferentes tipos de adaptadores:

Cola avanzada (AQ)

Para interactuar con una cola. AQ proporciona un mecanismo flexible para la comunicación asincrónica bidireccional entre las aplicaciones participantes.

Supervisión de la actividad empresarial de Oracle (BAM)

Para publicar datos en objetos de datos en un servidor Oracle BAM.

Base de datos

Para la interacción con bases de datos Oracle y no Oracle a través de JDBC y Oracle Business Intelligence (que es un tipo de fuente de datos especial).

FTP y archivo

Para el intercambio de archivos (lectura y escritura) en sistemas de archivos locales y sistemas de archivos remotos (mediante el uso del protocolo de transferencia de archivos (FTP)).

Servicio de mensajería Java (JMS)

Para interactuar con JMS. La arquitectura JMS utiliza una interfaz de un solo cliente para la arquitectura de muchos servidores de mensajería.

Cola de mensajes (MQ)

Para el intercambio de mensajes con los sistemas de cola de WebSphere MQ.

Aplicaciones de Oracle

Para la interacción con el conjunto de aplicaciones empresariales integradas de Oracle Application.

Oracle B2B

Para examinar metadatos B2B en el repositorio del servicio de metadatos (MDS) y seleccionar definiciones de documentos.

Enchufes

Para modelar protocolos estándar o no estándar para la comunicación a través de sockets TCP / IP.

Nombre del servicio del adaptador

La ventana Nombre del servicio solicita que ingrese un nombre, cuando se selecciona el tipo de adaptador de la paleta. Para este ejemplo,File Adapterfue seleccionado. Cuando se completa el asistente, aparece un archivo WSDL con este nombre de servicio en el navegador de aplicaciones para el componente de servicio de proceso BPEL (para este ejemplo, denominadoReadFile.wsdl). El nombre del servicio debe ser exclusivo dentro del proyecto. Este archivo de configuración incluye los valores de configuración del adaptador especificados con este asistente. También se crean otros archivos de configuración (como archivos de encabezado y archivos específicos del adaptador). Estos archivos se muestran en el Navegador de aplicaciones.

Los monitores de proceso BPEL en Oracle BPEL Designer se pueden configurar seleccionando Monitor en la parte superior de Oracle BPEL Designer.

En esta etapa, es necesario configurar el adaptador de Oracle BAM.

El proceso de BPEL del cliente envía un mensaje al proceso de BPEL de servicio y no se requiere que el proceso de BPEL de servicio responda como se muestra en la siguiente figura:

  • El proceso de cliente BPEL necesita un enlace de socio válido y una actividad de invocación.

  • El proceso de BPEL de servicio necesita una actividad de recepción.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción. El archivo WSDL se muestra a continuación.

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

El proceso BPEL del cliente envía una solicitud al proceso BPEL del servicio (d1 en la figura siguiente) y recibe una respuesta inmediata (d2 en la figura siguiente). Por ejemplo, un usuario solicita una suscripción a un formulario de solicitud en línea para la admisión a una universidad e inmediatamente recibe una confirmación por correo electrónico de que su solicitud ha sido aceptada.

  • El proceso de BPEL del cliente necesita una actividad de invocación. El puerto del lado del cliente envía la solicitud y recibe la respuesta.

  • El proceso BPEL de servicio necesita una actividad de recepción para aceptar la solicitud entrante y una actividad de respuesta para devolver la información solicitada o un mensaje de error (una falla; f1 en la figura siguiente) definido en el WSDL.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción. El archivo WSDL se muestra a continuación.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

El proceso BPEL del cliente envía una solicitud al proceso BPEL del servicio (d1 en la figura que se muestra a continuación) y espera hasta que el servicio responde (d2 en la figura que se muestra a continuación).

Por ejemplo, un usuario solicita una suscripción a un formulario de solicitud en línea para la admisión a una universidad y la solicitud no se puede confirmar a menos que sea aceptada en la oficina de admisiones.

  • El proceso de cliente BPEL necesita una actividad de invocación para enviar la solicitud y una actividad de recepción para recibir la respuesta.

  • El proceso de BPEL de servicio necesita una actividad de recepción para aceptar la solicitud entrante y una actividad de invocación para devolver la información solicitada o una falla.

    Note - La diferencia entre responder desde un proceso BPEL síncrono y asíncrono es que el servicio síncrono usa una actividad de respuesta para responder al cliente y un servicio asíncrono usa una actividad de invocación.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción. El archivo WSDL se muestra a continuación.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage"/>
   </wsdl:operation>
</wsdl:portType>

<wsdl:portType name = "BPELProcessCallback">
   <wsdl:operation name = "processResponse">
      <wsdl:input message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

El proceso de BPEL del cliente envía una solicitud al proceso de BPEL del servicio (d1 en la figura siguiente) y espera hasta que el servicio responde o hasta que se alcanza un cierto límite de tiempo, lo que ocurra primero. (d2 en la siguiente figura).

Por ejemplo, un usuario solicita una suscripción a un formulario de solicitud en línea para la admisión a una universidad y la solicitud se cancela si el usuario no recibe una respuesta de confirmación dentro de un período de tiempo específico.

El proceso del cliente BPEL necesita una actividad de invocación para enviar la solicitud y una actividad de selección con dos ramas: una onMessage rama y un onAlarmrama. Si la respuesta llega después de que expira el límite de tiempo, el mensaje pasa a la cola de mensajes no entregados.

El proceso de BPEL de servicio necesita una actividad de recepción para aceptar la solicitud entrante y una actividad de invocación para devolver la información solicitada o una falla.

Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

En este capítulo, aprenderemos sobre las interacciones asincrónicas con un temporizador de notificación. Considere los siguientes puntos relacionados con las interacciones asincrónicas:

  • El proceso de BPEL del cliente envía una solicitud al proceso de BPEL del servicio y espera una respuesta, aunque se envía una notificación después de que expira un temporizador.

  • El proceso de BPEL del cliente continúa esperando la respuesta del proceso de BPEL del servicio incluso después de que el temporizador ha expirado.

  • El proceso de BPEL del cliente necesita una actividad de alcance que contenga una actividad de invocación para enviar la solicitud y una actividad de recepción para aceptar la respuesta. losonAlarm El controlador de la actividad del alcance tiene un límite de tiempo e instrucciones sobre qué hacer cuando expira el temporizador.

  • Por ejemplo, espere 60 segundos y luego envíe una advertencia que indique que el proceso está tardando más de lo esperado.

  • El proceso de BPEL de servicio necesita una actividad de recepción para aceptar la solicitud entrante y una actividad de invocación para devolver la información solicitada o una falla.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

En este capítulo, aprenderemos sobre el concepto de una solicitud y respuestas múltiples.

  • El proceso de BPEL del cliente envía una solicitud única al proceso de BPEL del servicio y recibe múltiples respuestas a cambio.

    Por ejemplo, la solicitud puede ser pedir un producto en línea, y la primera respuesta puede ser el tiempo de entrega estimado, la segunda respuesta una confirmación de pago y la tercera respuesta una notificación de que el producto se ha enviado. En este ejemplo, se esperan el número y los tipos de respuestas.

  • El proceso de BPEL del cliente necesita una actividad de invocación para enviar la solicitud y una actividad de secuencia con tres actividades de recepción.

  • El proceso BPEL de servicio necesita una actividad de recepción para aceptar el mensaje del cliente, y un atributo de secuencia con tres actividades de invocación, una para cada respuesta.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

En este capítulo, aprenderemos sobre el concepto de una solicitud y una de dos posibles respuestas.

  • El proceso de BPEL del cliente envía una sola solicitud al proceso de BPEL del servicio y recibe una de dos posibles respuestas.

    Por ejemplo, la solicitud puede ser pedir un producto en línea y la primera respuesta puede ser un mensaje de stock o un mensaje de falta de stock.

  • El proceso del cliente BPEL necesita lo siguiente:

    • Una actividad de invocación para enviar la solicitud.

    • Una actividad de picking con dos ramas: una onMessage para la respuesta en stock e instrucciones sobre qué hacer si se recibe un mensaje en stock.

    • Un segundo mensaje onMessage para la respuesta de falta de stock e instrucciones sobre qué hacer si se recibe un mensaje de falta de stock.

  • El proceso BPEL de servicio necesita una actividad de recepción para aceptar el mensaje del cliente y una actividad de cambio con dos ramas, una con una actividad de invocación que envía el mensaje en stock si el artículo está disponible y una segunda rama con un envío de actividad de invocación el mensaje de agotado si el artículo no está disponible.

Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

En este capítulo, entenderemos el concepto de una solicitud, una respuesta obligatoria y una respuesta opcional.

  • El servicio BPEL del cliente envía una única solicitud al proceso BPEL del servicio y recibe una o dos respuestas.

  • Aquí, la solicitud es pedir un producto en línea. Si el producto se retrasa, el servicio envía un mensaje informándole al cliente. En cualquier caso, el servicio siempre envía una notificación cuando se envía el artículo.

  • El servicio de cliente BPEL necesita una actividad de alcance que contenga la actividad de invocación para enviar la solicitud y una actividad de recepción para aceptar la respuesta obligatoria. Para el mensaje opcional, elonMessageEl controlador de la actividad de alcance se establece junto con las instrucciones sobre qué hacer si se recibe el mensaje opcional (por ejemplo, notificarle que el producto se ha retrasado). El proceso del cliente BPEL espera recibir la respuesta obligatoria. Si la respuesta obligatoria se recibe primero, el proceso BPEL continúa sin esperar la respuesta opcional.

  • El proceso BPEL de servicio necesita una actividad de alcance que contenga la actividad de recepción y una actividad de invocación para enviar el mensaje de envío obligatorio, y el alcance onAlarm manipulador para enviar el mensaje retrasado opcional si un temporizador expira (por ejemplo, envíe el mensaje retrasado si el artículo no se envía en 24 horas).

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

Ahora, aprenderemos el concepto de procesamiento parcial en BPEL.

  • El proceso de BPEL del cliente envía una solicitud al proceso de BPEL del servicio y recibe una respuesta inmediata, pero el procesamiento continúa en el lado del servicio.

  • Este patrón también puede incluir devoluciones de llamada de múltiples disparos, seguidas de un procesamiento a más largo plazo.

  • Por ejemplo, el cliente envía una solicitud para comprar un paquete vacacional y el servicio envía una respuesta inmediata confirmando la compra, luego continúa reservando el hotel, el vuelo, el auto de alquiler, etc.

  • El proceso de cliente BPEL necesita una actividad de invocación para cada solicitud y una actividad de recepción para cada respuesta para transacciones asincrónicas, o simplemente una actividad de invocación para cada transacción sincrónica.

  • El proceso BPEL de servicio necesita una actividad de recepción para cada solicitud del cliente y una actividad de invocación para cada respuesta. Una vez finalizadas las respuestas, el Proceso BPEL del Servicio como el servicio puede continuar con su procesamiento, utilizando la información recopilada en la transacción para realizar las tareas necesarias sin ningún aporte adicional del cliente.

  • Como ocurre con todas las actividades de los socios, el archivo de lenguaje de descripción de servicios web (WSDL) define la interacción.

Aprenderemos sobre las múltiples interacciones de aplicaciones con BPEL en este capítulo.

  • Cuando hay más de dos aplicaciones involucradas en una transacción.

  • Este patrón de transacciones A-to-B-to-C-to-A puede manejar muchas transacciones al mismo tiempo. Por lo tanto, se requiere un mecanismo para realizar un seguimiento de qué mensaje va a dónde.

  • Esto se puede manejar usando WS-Addressing o conjuntos de correlación.

Hemos discutido en uno de los capítulos anteriores que Synchronous Web Service es uno, que proporciona una respuesta inmediata a una invocación.

En la captura de pantalla que se muestra a continuación, hemos creado un proceso BPEL síncrono que tiene una actividad de recepción para aceptar la solicitud del usuario. La actividad de respuesta envía simultáneamente la respuesta.

Como se mencionó anteriormente, el servicio web asíncrono es aquel que envía una solicitud a otro servicio web y espera la respuesta.

En la captura de pantalla que se muestra a continuación, hemos creado el proceso BPEL asíncrono que tiene una actividad de recepción para aceptar la solicitud del usuario. La actividad de asignación también asigna valores a los diferentes elementos de la solicitud.

A continuación, la actividad de invocación invoca la aplicación HelloWorld que envía la respuesta simultáneamente y que se captura en la actividad de recepción.

Además, tenemos la actividad de devolución de llamada que finalmente genera una salida y envía una respuesta de forma asincrónica.

Si hace doble clic en el receiveInput o callbackClient, verá que cada uno de ellos tiene una sola variable.

receiveInput → inputVariable
callbackClient → outputVariable

En este capítulo, entenderemos cómo funciona el flujo paralelo en BPEL.

¿Qué es la actividad de flujo?

Una actividad de flujo normalmente contiene muchas actividades de secuencia y cada secuencia se realiza en paralelo. Una actividad de flujo también puede contener otras actividades.

Por ejemplo, dos devoluciones de llamada asincrónicas se ejecutan en paralelo, por lo que una devolución de llamada no tiene que esperar a que la otra se complete primero. Cada respuesta se almacena en una variable global diferente.

En la actividad de flujo, el código BPEL determina el número de ramas paralelas. Sin embargo, a menudo el número de sucursales requeridas es diferente según la información disponible.

¿Qué es FlowN Activity?

La actividad flowN crea múltiples flujos iguales al valor de N, que se define en el tiempo de ejecución en función de los datos disponibles y la lógica dentro del proceso. Hay un incremento de la variable de índice cada vez que se crea una nueva rama, hasta que la variable de índice alcanza el valor de N.

La actividad flowN realiza actividades en un número arbitrario de elementos de datos. A medida que cambia el número de elementos, el proceso BPEL se ajusta en consecuencia.

Las ramas creadas por flowN realizan las mismas actividades, pero utilizan datos diferentes. Cada rama usa la variable de índice para buscar variables de entrada. La variable de índice se puede utilizar en la expresión XPath para adquirir los datos específicos de esa rama.

BPEL aplica la lógica para tomar decisiones mediante la ramificación condicional. Las dos acciones diferentes basadas en la ramificación condicional se muestran a continuación:

Cambiar actividad

En este método, configura dos o más ramas, con cada rama en forma de expresión XPath. Si la expresión es verdadera, entonces se ejecuta la rama. Si la expresión es falsa, entonces el proceso BPEL pasa a la siguiente condición de bifurcación, hasta que encuentra una condición de bifurcación válida, encuentra otra bifurcación o se queda sin bifurcaciones. Si más de una condición de bifurcación es verdadera, entonces BPEL ejecuta la primera bifurcación verdadera.

Mientras actividad

Puede utilizar una actividad while para crear un bucle while para seleccionar entre dos acciones.

Para comprender cómo utilizar el manejo de fallas, necesitamos aprender la arquitectura básica de un Service Composite en Oracle SOA Suite.

  • Service components- Procesos BPEL, Regla de Negocio, Tarea Humana, Mediador. Se utilizan para construir una aplicación compuesta SOA.

  • Binding components - Establecer conexión entre un compuesto SOA y el mundo externo.

  • Services - Proporciona un punto de entrada a la aplicación compuesta SOA.

  • Binding - Define los protocolos que se comunican con el servicio como SOAP / HTTP, adaptador JCA, etc.

  • WSDL - Define la definición de servicio de un servicio web.

  • References - Permite que una aplicación compuesta SOA envíe mensajes a servicios externos

  • Wires - Habilita la conexión entre los componentes del servicio.

Tipos de fallas

Veamos ahora los diferentes tipos de fallas.

Fallos comerciales

Ocurre cuando la aplicación ejecuta la actividad THROW o una INVOCACIÓN recibe una falla como respuesta. El nombre de la falla lo especifica el componente de servicio de proceso BPEL. El manejador de fallas que usa el nombre de falla y la variable de falla detecta esta falla.

Fallos en tiempo de ejecución

Esto es lanzado por el sistema. Estas fallas están asociadas conRunTimeFaultMessage y están incluidos en

http://schemas.oracle.com/bpel/extensionnamespace.

Maneras de manejo de fallas

En esta sección, aprenderemos sobre las diferentes formas de manejo de fallas.

Actividad de lanzamiento

Lanzar actividad arroja explícitamente la culpa. El bloque de captura detecta esta falla y las acciones correspondientes se ejecutan de ese modo.

  • Al utilizar la actividad de lanzamiento, puede lanzar fallas comerciales y, dentro del alcance creado, puede detectar esta falla y redirigir a la persona que llama (consumidor) para que tome medidas.

  • En lugar del enfoque anterior, arroja la misma falla atrapada en la actividad de captura del alcance creado. En el ámbito principal, puede detectar este error utilizando la actividad de captura.

Marco de manejo de errores (EHF)

Los 2 archivos principales utilizados en EHF son:

  • Fault-Policy.xml
  • Fault-Bindings.xml

Siempre que el proceso BPEL arroja un error, la EHF verificará si el error existe en los archivos Fault-Bindings.xml. Si es así, se llevará a cabo la acción en el archivo Fault-Policy.xml. Si no se encuentra la acción, la falla se lanzará y se manejará en el bloque de captura.

El marco de gestión de fallas (Fault-Policy.xml y Fault-Bindings.xml) se mantiene dentro de un compuesto SOA.

Los manejadores de fallas como catch y catchall están dentro de un BPEL para detectar todas las fallas, pero fault policies will only be executed when an invoke activity fails.

En este capítulo, veremos diferentes escenarios relacionados con el reenvío de un proceso fallado.

Escenario A

El código BPEL usa una política de falla y una falla se maneja usando la actividad "ora-intervención humana". A continuación, la falla se marca como Recuperable y el estado de la instancia se establece en "En ejecución".

Escenario B

El código BPEL usa una política de fallas y una falla se detecta y se vuelve a lanzar usando la acción "ora-rethrow-failure". Luego, la falla se marca como Recuperable y el estado de la instancia se establece en "Falla"; siempre que la falla sea recuperable (como si la URL no estuviera disponible).

Existen varios métodos para incorporar código Java y Java EE en procesos BPEL. A continuación se muestran algunos métodos importantes:

  • Envolver como un servicio de Protocolo simple de acceso a objetos (SOAP)

  • Incruste fragmentos de código de Java en un proceso BPEL con la etiqueta bpelx - exec

  • Utilice una fachada XML para simplificar la manipulación DOM

  • Utilice bpelx - métodos integrados de exec

  • Utilice código Java envuelto en una interfaz de servicio

La actividad de incrustación de Java nos permite agregar actividades en un proceso BPEL. Podemos escribir un fragmento de Java utilizando bibliotecas JDK estándar, las API de BPEL, clases Java personalizadas y de terceros incluidas en archivos JAR en compuestos SCA implementados (en el directorio SCA-INF / lib) y clases y bibliotecas Java disponibles en Classpath para SOA Tiempo de ejecución de la suite.

Java Embedding significa funcionalidad escondida en su interior, de una forma no muy desacoplada. El código Java es difícil de mantener. Al incrustar Java en BPEL (impulsado por XML), comenzamos a mezclar tecnología, que requiere diferentes habilidades, así como XML costoso para ordenar y deshacer el ordenamiento de objetos Java.

Los mejores casos de uso para la incrustación de Java parecen ser para el registro / seguimiento avanzado o para validaciones / transformaciones especiales. Sin embargo, no para reemplazar las capacidades integradas del motor BPEL, así como los otros componentes en SOA Suite 11g y los adaptadores que vienen con él.

XPath se utiliza principalmente para manipular XML en el proceso BPEL. Hay algunas funciones valiosas de Xpath que se pueden utilizar para manipular XML. Veamos las funciones a continuación.

bpel: getVaribleData (varName, partName, xpathStr)

Esto se puede usar para extraer un conjunto de elementos de una variable, usando una expresión XPath.

<bpel:copy>
   <bpel:from>
   <![CDATA[count(bpel:getVariableData(‘$Variable','$partName')/ns:return)]]>
   </bpel:from>
      <bpel:to variable = "itemNumber">
   </bpel:to>
</bpel:copy>

bpel: getLinkStatus ()

Esto se puede utilizar para evaluar y devolver un booleano si un enlace en particular está activo o inactivo.

: getVariableProperty (cadena, cadena)

Esto es útil para extraer propiedades en Variables.

: doXSLTTransform ()

Esto realiza las transformaciones XSLT.

cuerda ()

Esto se puede usar para extraer contenido de texto de elementos en lugar de usar / text ().

longitud de la cuerda()

Esta función se utiliza para calcular la longitud de la cadena. Pero el operador! = Parece no funcionar con la salida de esta función. ¡Entonces puedes usar> o <en lugar de usar! =.

Valores booleanos

Puede asignar valores booleanos con la función booleana XPath.

<assign>
   <!-- copy from boolean expression function to the variable -->
   <copy>
      <from expression = "true()"/>
      <to variable = "output" part = "payload" query="/result/approved"/>
   </copy>
</assign>

Asignar una fecha u hora

Puede asignar el valor actual de un campo de fecha u hora mediante la función de Oracle BPEL XPath getCurrentDate, getCurrentTime o getCurrentDateTime, respectivamente.

<!-- execute the XPath extension function getCurrentDate() -->
<assign>
   <copy>
      <from expression = "xpath20:getCurrentDate()"/>
      <to variable = "output" part = "payload"
      query = "/invoice/invoiceDate"/>
   </copy>
</assign>

Concatenación de cadenas

En lugar de copiar el valor de una variable de cadena (o parte de variable o campo) a otra, primero puede realizar la manipulación de cadenas, como concatenar varias cadenas.

<assign>
   <!-- copy from XPath expression to the variable -->
   <copy>
      <from expression = "concat('Hello ',
      bpws:getVariableData('input', 'payload', '/p:name'))"/>
      <to variable = "output" part = "payload" query = "/p:result/p:message"/>
   </copy>
</assign>

Asignar literales de cadena

Puede asignar cadenas literales a una variable en BPEL.

<assign>
   <!-- copy from string expression to the variable -->
   <copy>
      <from expression = "'GE'"/>
      <to variable = "output" part = "payload" query = "/p:result/p:symbol"/>
   </copy>
</assign>

Asignar valores numéricos

Puede asignar valores numéricos en expresiones XPath.

<assign>
   <!-- copy from integer expression to the variable -->
   <copy>
      <from expression = "100"/>
      <to variable = "output" part = "payload" query = "/p:result/p:quantity"/>
   </copy>
</assign>

Note - Se utilizaron algunas funciones XSLT para transformar un documento XML.

La correlación BPEL hace coincidir los mensajes entrantes con una instancia de proceso específica. Cuando necesita asociar datos específicos a una instancia específica de un proceso empresarial, utiliza la correlación.

Por ejemplo, al crear un proceso que verifica un número de cuenta y verifica el límite de crédito de la cuenta. Cuando se verifica, el proceso realiza una llamada a otro sistema para verificar el inventario y, si el artículo está en stock, genera una orden de compra. ¿Cómo sabe la orden de compra en qué cuenta se debitará? La respuesta a esta pregunta es la correlación.

Conjuntos de correlación

Los conjuntos de correlación se utilizan para identificar de forma exclusiva las instancias de proceso. Proporciona a cada conjunto de correlaciones un nombre exclusivo y luego lo define mediante una o más propiedades. Cada propiedad tiene un nombre y un tipo (por ejemplo, cadena o entero).

Alias ​​de propiedad

Es necesario definir el alias de propiedad para cada propiedad en el conjunto de correlación. Un alias de propiedad es una asignación que vincula la propiedad con los valores de entrada o salida.

Puntos importantes

Considere los siguientes puntos importantes relacionados con la Correlation Sets and Message Aggregation -

  • Un proceso que contiene más de una actividad de recepción o recogida debe tener un conjunto de correlaciones.

  • Los conjuntos de correlación se inicializan con valores del proceso de mensajes entrantes o salientes.

  • Si tiene grupos de mensajes que están asociados con un proceso específico, puede configurar uno o más conjuntos de correlación para manejar.

Los servicios web asincrónicos suelen tardar mucho en devolver una respuesta y, como tal, un componente de servicio de proceso BPEL debe poder agotar el tiempo de espera, o dejar de esperar, y continuar con el resto del flujo después de una cierta cantidad de tiempo. Puede utilizar la actividad de picking para configurar un flujo de BPEL para que espere durante un período de tiempo específico o para continuar desempeñando sus funciones. Para establecer un período de vencimiento para el tiempo, puede usar la actividad de espera. Para administrar los mensajes, los eventos se pueden utilizar especialmente cuando el proceso empresarial está esperando devoluciones de llamada de los servicios web de los socios.

Eventos

BPEL admite dos tipos de eventos:

Eventos de mensajes

Estos eventos son desencadenados por mensajes entrantes mediante la invocación de operaciones en tipos de puertos.

Eventos de alarma

Estos eventos están relacionados con el tiempo y se activan después de una determinada duración o en un momento específico.

  • Sin embargo, a menudo es más útil esperar más de un mensaje, de los cuales solo aparecerá uno.

  • Los eventos de alarma son útiles cuando desea que el proceso espere una devolución de llamada durante un cierto período de tiempo, como 15 minutos.

    • Si no se recibe ninguna devolución de llamada, el flujo del proceso continúa según lo diseñado.

    • Útil en arquitecturas orientadas a servicios poco acopladas, donde no puede confiar en que los servicios web estén disponibles todo el tiempo.

Elegir actividad

La actividad de picking tiene 2 ramas:

  • onMessage - el código en esta rama es igual al código para recibir una respuesta antes de que se agregue un tiempo de espera.

  • onAlarm - esta condición tiene código para un tiempo de espera de un minuto.

Actividad de espera

La actividad de espera permite que un proceso espere durante un período de tiempo determinado o hasta que se alcance un límite de tiempo. Debe especificarse exactamente uno de los criterios de caducidad.

El proceso BPEL se puede utilizar para el servicio de notificación. El proceso puede diseñarse para enviar lo siguiente:

  • email
  • mensaje de voz
  • mensajería instantánea (IM), o
  • notificaciones del servicio de mensajes cortos (SMS)

Para los servicios mencionados anteriormente, puede configurar el canal para el mensaje entrante y saliente.

Los sensores compuestos dentro de una aplicación SOA brindan la capacidad de definir campos rastreables en mensajes y le permite encontrar una instancia compuesta específica al buscar un campo o campos dentro de un mensaje. Por ejemplo, se podría definir un sensor para un número de pedido dentro de un mensaje, lo que nos permite encontrar la instancia donde se encuentra el número de pedido en cuestión.

Los sensores compuestos se pueden definir dentro de una aplicación SOA en varios componentes:

  • Componente de servicio (servicio expuesto)

  • Componente de referencia (referencia externa)

  • Mediador o componente BPEL que se haya suscrito a un evento empresarial (la publicación de un evento no puede tener un sensor)

Diferentes formas de definir el sensor compuesto

Hay diferentes formas de definir un sensor compuesto:

  • Especificando una variable existente como sensor.
  • Mediante una expresión con la ayuda del constructor de expresiones.
  • Mediante el uso de propiedades (por ejemplo, propiedades de encabezado de mensaje).

Sensores en Enterprise Manager

La definición de un sensor permite una búsqueda rápida de datos dentro de una instancia compuesta en EM Console.

En el panel de EM Console, un usuario puede buscar instancias por nombre y valor de sensor.

En la pestaña "Instancias de flujo", puede seleccionar sensores de los menús desplegables y puede utilizar valores de tipo comodín para el valor del sensor.

Se han agregado nuevas actividades en 2.0 que han reemplazado a las de 1.1.

<paraCada>

Esta actividad ayuda a repetir el conjunto de actividades. La actividad reemplaza la actividad FlowN en la versión BPEL 1.1.

<repeatUntil>

Esta actividad resulta útil si el cuerpo de una actividad debe realizarse al menos una vez. La condición de expresión XPath en la actividad repeatUntil se evalúa después de que se completa el cuerpo de la actividad.

<si> - <elseif> - <else>

Esta actividad reemplaza la actividad de cambio en BPEL 2.0. La actividad le permite definir un comportamiento condicional para actividades específicas para decidir entre dos o más ramas. Solo se selecciona una actividad para su ejecución de un conjunto de ramas.

<compensateScope>

Esta actividad ayuda a compensar el alcance secundario especificado.

<volver a lanzar>

Esta actividad se ha agregado a los controladores de errores. Le permite volver a generar una falla capturada originalmente por el manejador de fallas inmediatamente adjunto.