Cómo notificar por correo electrónico en BPEL 10.1.3.3

Este artículo explica cómo funciona el correo electrónico de notificación en BPEL 10.1.3.3

Es un paso de procesamiento asíncrono con el motor BPEL dos asas de la actividad de correo electrónico de notificación.

• Creación de notificación y persistencia - BPEL Process Manager primero crear un aviso de un objeto, incluso NotificationID única, notificación y otras propiedades de carga del mensaje, e insertar los detalles de notificación a la tienda de deshidratación BPEL, a continuación, se enviará un vacío de mensajes JMS con la notificación a la propiedad ID una cola interna para notificar que el mensaje esté listo para la entrega.
  
  
• Notificación de entrega - Cuando el mensaje llega JMS en la cola, un hilo de MDB se asignarán y consume el mensaje. En el OnMessage () de los bancos multilaterales de desarrollo, se tratará de consulta de la tienda deshidratación habida cuenta de la notificación de identificación, a continuación, enviar los datos de notificación a través del correo electrónico de canal configurado previamente. Tenga en cuenta que la entrega de mensajes que ocurre en un subproceso independiente que el hilo de ejecución BPEL.
  

Por lo tanto, hay dos temas diferentes que se encargan de la persistencia de la notificación y entrega de correo electrónico, respectivamente. motor BPEL tiene que resolver la manera de coordinar los hilos de ejecución, de lo contrario la condición de carrera podrían ocurrir. Por ejemplo, cuando llega el mensaje del sistema anterior a la confirmación de la transacción para la inserción de notificación en la base de datos, el hilo MDB se iniciará en primer lugar, ya que los datos no fueron aprobadas, sin embargo, el identificador de notificación no puede ser recuperada mientras buscaba las tablas de Notificación de la MDB hilo. En este caso, la notificación por correo electrónico se producirá un error.

El escenario anterior puede funcionar muy bien en la situación normal, pero si hay algún fallo de la debida notificación al servidor de correo electrónico abajo, o problemas de red, etc BPEL lo puede hacer al respecto?

Un planificador de cuarzo se utiliza en BPEL 10.1.3.3 para manejar esta situación. Un planificador de cuarzo se iniciará un hilo que se ejecutará cada 15 minutos por defecto para enviar un lote de envases vacíos de mensajes JMS con identificadores únicos a la cola de JMS. Pero esta vez, no hay persistencia de mensajes, en cambio, los identificadores de la notificación se obtienen mediante la consulta el almacén de la deshidratación en el estado es o reintentar o SEND. En otras palabras, si hay registros en la base de datos donde el Estado es reintentar o SEND, estos registros se convertirán en candidatos a entregar. hilo MDB entonces buscará detalles de la tienda de deshidratación mensajes y entregarlos a través de correos electrónicos. En la fase de entrega, será comprobar cómo muchas veces el servidor ha intentado entregar el mensaje, el intento máxima es de 3 por defecto. Si todos estos intentos fallan, se actualizará el estado de esta notificación en el almacén de la deshidratación a error

las siguientes dos propiedades pueden ser configuradas en SOA_Oracle_Home/ BPEL / system / servicios / config / wf_config.xml.

• oracle.bpel.services.notification.maxattempt - valor por defecto es 3. La propiedad es el uso para controlar los intentos de un máximo de MDB se expedirá un aviso de notificación identificado por el ID. Si los intentos máxima se alcanza, el estado de notificación se ha cambiado a "ERROR", de lo contrario, el estado será cambiado a "Intentar de nuevo.
  
  

  Si la notificación es "ERROR" de estado, la única manera de volver a intentar la entrega de mensajes, es ejecutar el siguiente script para actualizar el BPELNotificationestado de tabla para RETRY. Por ejemplo:

  UPDATE BPELNotification
  de SET status = 'RETRY',
  ATTEMPTEDNUMBER = 0
  WHERE ID = <>
  

  
  

• oracle.bpel.services.notification.publisher_interval - el valor por defecto es 15 (minutos). Esta propiedad se utiliza para indicar la frecuencia con un trabajo de programador de cuarzo se llevará a cabo la búsqueda de la notificación a entregar y enviar mensaje de notificación a través de JMS vacío. El valor por defecto debería ser suficiente en casos más. Si hay un montón de errores en la entrega de mensajes o desea que el programador para empezar con más frecuencia, entonces usted puede reducir este valor.
  
  Pero si la propiedad es un valor muy pequeño, por ejemplo, 1 (minuto), entonces hay una posibilidad de que usted conseguirá duplicar los mensajes enviados al servidor de correo electrónico. Aquí hay un escenario que podría suceder en el mundo real.
  
  BPEL PM Cuando los procesos de la actividad de notificación, se deshidrata los detalles de notificación y que la notificación se convierte en un candidato a MDB para entregar. Supongamos que la entrega no ha terminado de procesar, con lo que el registro de notificación todavía reside en el almacén de la deshidratación con el estado "SEND". Si el trabajo de programador de cuarzo se ejecuta al mismo tiempo, también se recogerá la misma notificación como candidata a entregar, causando así la duplicación de mensajes enviados por bancos multilaterales de desarrollo
  

Esperemos que este artículo puede ayudarle a entender cómo el servicio de notificación trabaja en BPEL. Si tiene alguna duda, por favor, puesto que aquí, voy a intentar mi mejor esfuerzo para responder. Si tiene algún problema con el correo electrónico de notificación, los errores, es muy recomendable para ir a la consola de BPEL y establecer registrador collaxa.cube.services de depurar, a continuación, comprobar el ORACLE_HOME / OPMN / logs / para más información