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.
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.
En nuestro caso empresarial, aprovechamos un proceso de BPEL para el proceso AccountCreation.
Los procesos de ejecución corta se conocen como microflujos.
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:
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.
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.
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
y cambiar el valor del campo Entregas máximas con error.¿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.
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 |
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 | Sí | |
Asíncrona - Respuesta diferida | Sí | |
Asíncrona - Devolución de llamada | Sí | |
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 | Sí |
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.
Módulo de destino de SCA
Una vez más, se hace referencia al caso empresarial.
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
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.
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
Node name: WESBNode Server name: server1 Destino de excepciones de recuperación: WBI.FailedEvent.WESBNode.server1En 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.
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.
Posibilidad administrativa | Empaquetado con WebSphere ESB ¿S/N? | Resumen |
---|---|---|
Gestor de sucesos con error | Sí | 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 |
Sí |
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. |