WebSphere Enterprise Service Bus, Versión 6.2.0 Sistemas operativos: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Caso de uso: recuperación de datos de sucesos anómalos

Un caso de uso proporciona el contexto para un caso de ejemplo de recuperación. En este caso de uso, una empresa tiene una aplicación que recibe una solicitud para crear una cuenta nueva.

La solución está formada por diferentes módulos tal como se recomienda en las prácticas recomendadas de módulos.

El primer módulo media la solicitud y delega el trabajo a un proceso de Creación de cuenta. En el ejemplo siguiente hemos implementado la solución como módulos separados en los que la solicitud se pasa entre el módulo de mediación (AccountRouting) y el módulo de proceso (AccountCreation) a través de una importación/exportación de SCA. Consulte la captura de pantalla siguiente para obtener una ilustración de los dos módulos.

Figura 1. Diagrama de ensamblaje del proceso de direccionamiento de cuenta
Se pasa una solicitud entre el módulo de mediación (AccountRouting) y el módulo de proceso (AccountCreation) de la importación de SCA a la exportación de SCA.

A partir del diagrama de ensamblaje que se muestra en Figura 1, puede empezar a ver en qué ubicaciones del flujo pueden producirse anomalías. Cualquiera de los puntos de invocación del diagrama de ensamblaje puede propagar o implicar una transacción. Existen unas cuantas áreas del flujo donde se recopilarán datos como resultado de anomalías de la aplicación o del sistema.

En general, la interacción (síncrona y asíncrona) crea y gestiona los límites de las transacciones entre componentes y los enlaces de importación/exportación y sus calificadores asociados. Los datos empresariales se acumulan en ubicaciones de recuperación específicas a menudo a causa de anomalías en la transacción, puntos muertos o retrotracciones.

Las posibilidades de transacción dentro de WebSphere Application Server ayudan a WebSphere ESB a enumerar las transacciones con los proveedores de servicios. Estas interacciones listadas son especialmente importantes para comprender los enlaces de importación y exportación. El hecho de comprender cómo se utilizan las importaciones y las exportaciones dentro de los casos empresariales específicos es importante para determinar donde se acumulan los sucesos que requieren recuperación.

Una estrategia de manejo de errores debe definir los patrones de interacción, las transacciones utilizadas y el uso de la importación y exportación antes de desarrollar la aplicación. El arquitecto de soluciones debe identificar las preferencias de uso, las directrices y, a continuación, utilizarlas al crear la aplicación. Por ejemplo, el arquitecto tiene que entender cuándo utilizar llamadas síncronas o asíncronas, cuándo utilizar el manejo de errores BPEL, etc. El arquitecto tiene que saber si todos los servicios pueden participar en transacciones o no, y para aquellos servicios que no pueden participar, cómo manejar la compensación si se encuentran problemas.

Además, la aplicación que se muestra en el diagrama de ensamblaje en Figura 1 aprovecha los grupos de conectividad y las prácticas recomendadas de desarrollo de módulos. Aprovechando este patrón tenemos la capacidad de detener el flujo de entrada de nuevos sucesos deteniendo el módulo AccountRouting .

En las secciones siguientes se comenta la ubicación de datos empresariales en caso de anomalía y recuperación.

Business Flow Manager o Human Task Manager

En nuestro caso empresarial, aprovechamos un proceso de BPEL para el proceso AccountCreation.

Respecto a la recuperación, a continuación se indican algunas cuestiones que debe preguntarse en referencia a la gestión de BPEL y de la tarea humana:
  1. ¿Qué tipo de proceso se está ejecutando (larga o corta duración, máquina de estado de empresa, tarea de usuario)?

    Los procesos de ejecución corta se conocen como microflujos.

  2. ¿Se ha desarrollado correctamente el proceso, utilizando la gestión de errores para promover la integridad de datos?
  3. ¿Cómo se han configurado los patrones de invocación y las propiedades de las unidades de trabajo para predecir y controlar los límites de transacción?

El hecho de conocer las respuestas a estas preguntas afectará a su estrategia de recuperación para las invocaciones 7 y 8 que se muestran en el diagrama de ensamblaje, tal como se destaca en la captura de pantalla siguiente:

Figura 2. Diagrama de ensamblaje del proceso de direccionamiento de cuenta - invocaciones 7 y 8
La captura de pantalla muestra el diagrama de ensamblaje con las invocaciones 7 y 8 resaltadas.

Los componentes con estado, como los procesos de larga duración de BPEL y de máquinas de estado de empresa, implican muchas transacciones de base de datos donde los cambios de actividad de procesos y los cambios de estado se comprometen en la base de datos. El trabajo progresa con la actualización de la base de datos y colocando un mensaje en una cola interna que describe qué debe efectuarse a continuación.

Si se producen problemas para procesar los mensajes internos de Business Flow Manager, estos mensajes se desplazan a una Cola de retención. El sistema intenta continuar procesando los mensajes. Si un mensaje posterior se procesa correctamente, los mensajes de la Cola de retención se vuelven a enviar para ser procesados. Si el mismo mensaje se coloca en la cola de retención cinco veces, se envía a la cola de almacenamiento. .

Encontrará información adicional acerca de la visualización del número de mensajes y la reproducción de mensajes en la sección Reproducción de mensajes de Cola de retención/Cola de almacenamiento.

Gestor de sucesos con error

El Gestor de sucesos con error (FEM) se utiliza para volver a reproducir los sucesos o las solicitudes de invocación de servicio que se realizan de forma asíncrona entre la mayoría de tipos de componente.

Los sucesos anómalos se crean si el componente AccountRouting efectúa una llamada asíncrona al enlace de importación de SCA AccountCreationSCAImport y se devuelve una ServiceRuntimeException.

Es importante tener en cuenta que los sucesos anómalos no se generan en la mayoría de casos donde BPEL es el cliente de la interacción de servicio. Esto significa que la invocación para 7 y 8 (tal como se muestra en Figura 2) no producirá habitualmente un suceso anómalo. BPEL proporciona manejadores de errores y otros modos de modelar la anomalía. Por este motivo, si una anomalía ServiceRuntimeException (SRE) llama a "JDBCOutboundInterface", se devuelve SRE a BPEL para el proceso. La estrategia de manejo de errores para el proyecto debe definir como se gestionan de forma coherente las excepciones de tiempo de ejecución en BPEL.

Sin embargo, hay que tener en cuenta que los sucesos anómalos se crean para los mensajes de respuesta asíncronos para el cliente BPEL si estos mensajes no se pueden entregar a la instancia de proceso a causa de una anomalía de la infraestructura.

En el diagrama siguiente se ilustra como funciona el componente gestor de sucesos con error. Las descripciones del proceso asociado con cada paso numerado se proporcionan según el diagrama.

Figura 3. Proceso del gestor de sucesos con error
Diagrama de proceso de un gestor de sucesos con error. El diagrama está numerado y los pasos numerados se proporcionan en una lista a continuación del diagrama.
Proceso del gestor de sucesos con error
  1. El componente de origen realiza una llamada mediante un patrón de invocación asíncrono
  2. El MDB de SCA recoge el mensaje del destino de SCA
  3. El MDB de SCA realiza la llamada al componente de destino correcto
  4. El componente de destino lanza una ServiceRuntimeException
  5. La transacción de MDB de SCA se retrotrae al destino de SCA
  6. La información de excepción se almacena en la base de datos del gestor de sucesos con error con un estado de no confirmado
  7. SIBus vuelve a intentar la invocación un número n de veces

    El valor por omisión de límite de reintentos es 5 - un original y 4 reintentos. Puede cambiar el valor por omisión en la consola administrativa. Por ejemplo, con un módulo M de SCA determinado, puede ir a Buses > SCA.SYSTEM.<CELL>.BUS > Destinos > sca/M y cambiar el valor del campo Entregas máximas con error.

  8. Cuando el número de reintentos alcanza el límite especificado, el mensaje se mueve al destino FEM.
  9. La base de datos del gestor de sucesos con error recoge el mensaje
  10. La base de datos del gestor de sucesos con error actualiza el suceso anómalo en la base de datos y el estado se establece en anómalo.

¿Cuándo se crean los "sucesos anómalos"?

Como se ha indicado, no se crean sucesos anómalos para invocaciones síncronas ni suelen crearse para interacciones de proceso empresarial de dos direcciones.

Los sucesos anómalos suelen crearse cuando los clientes utilizan un patrón de invocación asíncrona y el proveedor de servicios lanza una excepción ServiceRuntimeException.

Si todo se realiza de forma síncrona y en la misma transacción, los datos no se recopilan en ningún sitio, sino que todo se retrotrae al cliente que realizó la llamada. Siempre que se produce un compromiso, se recopilan datos. Si todas las llamadas son síncronas, pero hay varios compromisos, entonces esos compromisos se convierten en un problema.

En general, debe utilizar llamadas de proceso asíncrono o BPEL de larga duración si se necesitan varias transacciones. Así, cada llamada ASYNC es una posibilidad de recopilar datos. Los procesos BPEL de larga duración son un punto de colección.

Tabla 1. Patrones de invocación y relación con la creación de sucesos anómalos: Excepciones empresariales de servicio
Patrón de invocación Suceso anómalo creado ¿S/N? Notas
Síncrona No No se crean sucesos anómalos para las excepciones empresariales de servicio o cuando se utiliza un patrón síncrono
Asíncrona - Una dirección No Por definición, las invocaciones de una dirección no pueden declarar anomalías, es decir, es imposible generar una excepción ServiceBusinessException.
Asíncrona - Respuesta diferida No Los sucesos anómalos no se crean para las excepciones empresariales de servicio
Asíncrona - Devolución de llamada No Los sucesos anómalos no se crean para las excepciones empresariales de servicio
Tabla 2. Patrones de invocación y relación con la creación de sucesos anómalos: Excepciones de tiempo de ejecución de servicio
Patrón de invocación Suceso anómalo creado ¿S/N? Notas
Síncrona No No se crean sucesos anómalos para las excepciones de tiempo de ejecución de servicio o cuando se utiliza un patrón síncrono.
Asíncrona - Una dirección  
Asíncrona - Respuesta diferida  
Asíncrona - Devolución de llamada  
BPEL - Dos direcciones No
No se crean sucesos anómalos cuando el componente de origen es un proceso empresarial.
Nota: Para una llamada asíncrona, si la respuesta no puede devolverse a BPEL, se crea un suceso anómalo.
BPEL - Una dirección  
Para obtener más información, consulte el tema del centro de información titulado Gestión de sucesos con error.

Encontrará información adicional acerca de la visualización y el reenvío de sucesos con error en la sección Reenvío de sucesos con error.

Destinos bus de integración de servicios

Los mensajes que esperan para ser procesados pueden acumularse en algunos destinos del bus de integración de servicios (SIBus). La mayor parte de estos destinos son del "sistema". Los mensajes que se encuentran dentro de estos destinos suelen ser de los tres tipos que se indican a continuación:
  • Solicitudes asíncronas para procesar
  • Respuestas asíncronas a las solicitudes
  • Mensajes asíncronos que no se han podido deserializar o cuyo selector de función no se ha podido resolver
    Nota: Las respuestas asíncronas pueden ser objetos de empresa válidos o anomalías devueltos como resultado de una solicitud.

Módulo de destino de SCA

Una vez más, se hace referencia al caso empresarial.

Existirían dos "Módulos SCA" en la solución:
  • sca/AccountRouting
  • sca/AccountCreation

Estos destinos se crean cuando se despliega el módulo en un servidor de aplicaciones o en un clúster.

Existen pocas oportunidades de que los mensajes se acumulen en estos destinos. La acumulación de mensajes en estas ubicaciones es una indicación clara de que puede existir un problema de rendimiento o un defecto en una aplicación. Investíguelo inmediatamente. Es importante supervisar la profundidad de los destinos de los módulos (con la solución de supervisión de TI que elija) porque la copia de seguridad de los mensajes podría provocar una parada del sistema o un tiempo de reciclaje prolongado.

Se los denomina destinos de "Módulo SCA" porque el nombre generado es el mismo que el nombre del módulo con el “sca/” adicional. Estos destinos son esenciales en el funcionamiento de las invocaciones asíncronas de SCA (en la intermediación de solicitudes y respuestas). Existen diferentes números de destinos adicionales que se generan durante la instalación de la aplicación en el bus SCA.SYSTEM, pero para esta explicación destacaremos la importancia del destino "Módulo SCA".

Reintento del bus de integración del sistema

Como hemos aprendido anteriormente, FEM integra un mecanismo de reintento con el bean controlado por mensajes SCA (MDB). Este comportamiento de reintento se puede controlar modificando el atributo "Entregas máximas con error" en el destino del módulo.
Nota: Habitualmente, no existe ningún motivo para ajustar esta posibilidad de reintento. Esta información se proporciona por exhaustividad.

En nuestro caso de ejemplo, existen diferentes destinos Bus SI creados por SCA para dar soporte a la comunicación asíncrona.

Como hemos visto, uno de estos destinos se denomina "sca/AccountRouting". Puede ajustar el número de reintentos que se producen durante una excepción ServiceRuntimeException de una invocación de servicio asíncrona cambiando el valor de la propiedad "Entregas máximas con error" a través de la consola administrativa. Sin embargo, no puede definir un valor inferior a 2 en módulos con un proceso BPEL. La segunda entrega es necesaria para devolver ServiceRuntimeExceptions a BPEL para su proceso.

Destinos de excepciones del sistema

Podemos administrar las anomalías en el gestor de sucesos con error. Cuando se traten importaciones y exportaciones basadas en JMS o EIS, debemos tener en cuenta otra ubicación importante.

Los destinos del bus SCA.Application se configuran para direccionar los mensajes con error al destino de excepción del sistema SIB de ese bus. Por lo tanto, si una exportación de JMS recoge un mensaje del bus de la aplicación SCA y lo ejecuta en una situación de retrotracción, el mensaje con error se direccionará al destino de excepción del sistema SIB en lugar del destino de excepción de recuperación de WBI. Este caso de ejemplo difiere de la discusión de suceso anómalo anterior en que un error al deserializar un mensaje del bus SCA.Application no producirá un suceso anómalo. Existe un destino de excepción del sistema en cada bus de la solución. Estos destinos deben supervisarse y administrarse como la "cola de mensajes no entregados" común en las infraestructuras MQ.

Considere el caso de ejemplo siguiente.

Diagrama que muestra cómo se procesan las excepciones del sistema.
Un cliente JMS externo coloca un mensaje en una cola de entrada expuesta a través de una exportación de JMS. El MDB de enlace de exportación de JMS recoge el mensaje para procesarlo. Desde ahí, sucederá una de estas dos cosas:
  1. La exportación de JMS analiza correctamente el mensaje y determina qué operación de la interfaz debe invocar y en qué punto se envía el mensaje al tiempo de ejecución de SCA para su proceso.
  2. La exportación de JMS no puede reconocer el cuerpo del mensaje como objeto de negocio válido o bien el enlace de exportación de JMS deserializa el cuerpo del mensaje pero no puede determinar la operación apropiada que debe invocar en la interfaz. En este punto, el mensaje se coloca en el destino de excepción del sistema para el bus.

Puede producirse este tipo de anomalía cuando se intenta recibir solicitudes de AccountRoutingJMSExport (1). Esta es una exportación de JMS y existe la posibilidad de que los sucesos se acumulen en el destino de excepción del sistema en SCA.Application.Bus. Utilice la solución de supervisión de TI seleccionada para observar la profundidad de este destino.

Gestor de sucesos con error y destinos SIB

Para WebSphere ESB, el destino de excepción se establece en la cola de destino de excepción de WebSphere ESB. Esta cola sigue la convención de denominación siguiente:
Node name: WESBNode
Server name: server1
Destino de excepciones de recuperación: WBI.FailedEvent.WESBNode.server1
En general, todos los destinos creados en el bus SCA.System se configurarán para direccionar los mensajes con error al destino de excepción de recuperación.

Cuando se produce una anomalía del sistema, además de capturar el mensaje con error en este destino de excepción, la característica de recuperación de WebSphere ESB también genera un suceso anómalo que representa el error del sistema y lo almacena en la base de datos de recuperación tal como se describe en la sección Gestor de sucesos con error de este documento de caso de uso.

Resumen

En resumen, WebSphere ESB proporciona prestaciones administrativas superiores a la plataforma WebSphere Application Server subyacente. Deben adoptarse las medidas adecuadas para comprender y utilizar estas prestaciones, además de seguir la orientación que se proporciona en la sección sobre la planificación de la prevención de errores de Planificación de la prevención y la recuperación de errores.

Tabla 3. Prestaciones administrativas para ayudar a gestionar anomalías
Posibilidad administrativa Empaquetado con WebSphere ESB ¿S/N? Resumen
Gestor de sucesos con error Acceso de lectura/edición/supresión. Este es el lugar principal para administrar excepciones de tiempo de ejecución de servicio y otras formas de errores de infraestructura.

Navegador del bus de integración de servicios

Lectura/supresión. Utilice el navegador del bus de integración de servicios en la consola administrativa para examinar y realizar tareas operativas diarias en buses de integración de servicios.

Nota: El número de sucesos o registros que pueden administrarse de forma simultánea con estas herramientas depende de factores externos como la asignación de memoria, los conjuntos de resultados y los ajustes de la base de datos y el tiempo de espera de la conexión. Ejecute estas pruebas y defina los umbrales apropiados para evitar excepciones (OOM, TransactionTimeOut).

concept Tema de concepto

Condiciones de uso | Comentarios


Icono de indicación de la hora Última actualización: 05 julio 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. Reservados todos los derechos.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org).