Recomendaciones de administración de Oracle SOA Suite 11G. Parte 2 de 2

Por Rolando Carasco
Publicado en Febrero 2014

En el artículo anterior se cubrieron temas de gestión de la Plataforma SOA Suite, tales como:

  • Levantar y detener Servicios. Diferentes técnicas para hacerlo
  • Despliegues importantes
  • Datasources clave
  • Topología de la Plataforma
  • Forma de distribuir los componentes

Ahora nos vamos a orientar a la administración pero del runtime de los compuestos y servicios que tengas construidos en tu organización.
Vamos a arrancar con el Tracking de Instancias adentro de la SOA-INFRA.

TRACKING DE INSTANCIAS DE SERVICIOS/COMPUESTOS
Básicamente son dos componentes que recibirán la mayor carga de Transacciones: Service Bus y la SOA Infra.
Pudiéramos agregar a esto el Balanceador de Cargas y posiblemente al OHS. Pero siendo estrictos, hablando de WL serían OSB y SOA-INFRA
Como hemos explicado, ambos corren en su propio WL y viven en dominios separados (también pueden vivir en un mismo dominio, pero en este documento se plantea que estén separados). Es posible hacer el rastreo desde que toca al Service Bus, y si esa transacción va hasta la SOA-INFRA, se puede llevar el tracking  hasta ella.
Hablando de Service Bus, lo realizamos con Service Bus Console, en el caso de la SOA-INFRA, con el Fusion Middleware Control - Enterprise Manager.
En el caso del Service Bus, siempre hablamos de transacciones cortas, por lo que lo que se espera monitorear es algo pequeño. Es decir: algún ID, el mensaje de entrada al Servicio, errores/excepciones; cosas de ese estilo. Regularmente guardarás los mensajes fallidos, pues  no te interesará que 5000 instancias de servicios exitosas, sean revisadas. En todo caso, te interesará saber por las que tuvieron algún fallo, para poder hacer  el tracking y tracing del problema.
En el caso de la SOA-INFRA, aquí sí hablamos de procesos más largos en su duración, y posiblemente nos interese saber por dónde pasó la ejecución y entender así, la actividad en dónde hubo algún error.      
En este último punto, lo que se puede ver son dos cosas:

  • Auditoría del Compuesto. Aquí simplemente aparece lo que ejecutó el compuesto, en términos de componentes, referencias
  • Auditoría del Proceso BPEL, en caso de haber usado dicho componente. Aquí se puede ver tal cual el proceso se ejecutó
  • Auditoría de Mediator: Qué decisión y ruta tomó el mensaje
  • Auditoría de Business Rules Engine: Se puede ver la regla que se ejecutó y cuál fue la decisión que tomó.

Un ejemplo de la Auditoría del Compuesto, se puede ver en la siguiente imagen:

Aquí vemos el rastreo completo del compuesto, desde que se originó un evento, cómo pasó por los diferentes componentes (Mediator, BPEL, etc) y a qué referencias a impactado. Igualmente vemos si dicha operación fue exitosa y si ya terminó o sigue en ejecución. También es posible tener el horario en el que se ejecutó, lo cual es muy valioso.
De esta vista, podemos llegar a la auditoría y rastreo de ejecución de un Flujo BPEL. Por ejemplo:

Aquí vemos la Pista de Auditoría, que es toda la ejecución de dicho Flujo, pero en modo texto. Podemos ver las asignaciones de variables, tomas de decisión, errores, valor de variables, tec.
Si queremos ver el Flujo gráfico, entonces damos click sobre la pestaña de Flujo:

De este diagrama, además de lo evidente con respecto al Flujo, podemos ver el identificador de Instancias, así como la fecha cuando el proceso inició. Igualmente podemos ver el Nivel de Auditoría con el cual el sistema está funcionando.
Otro punto relevante, es el relacionado con las Excepciones/Errores que sucedan en los Servicios. Estas Excepciones y Errores pueden también verse a nivel del Service Bus y de la SOA-INFRA.
En el caso del Service Bus,  el Servicio debe reportar dichos errores, de otra forma no se podrá conseguir esta información. Esto a través de las opciones de logging y reporting que provee el Service Bus.
En el caso de la SOA-INFRA, cualquier excepción/error que haya sido o no manejado por el compuesto, se reflejará en el Enterprise Manager.
De esta manera, si el reporte es un Error, se puede realizar relativamente fácil el rastreo de la Instancia en cuestión. 

En el caso de la SOA-INFRA, podemos tener la siguiente vista:

Esta pantalla del Enterprise Manager es muy valiosa pues te permite no solo listar los errores que han sucedido en el dominio en cuestión, pero te permite realizar búsquedas por: Mensaje de Error, Identificador de Fallo, Intervalo de Tiempo. Igualmente lo puedes hacer por Identificador de Instancia y Nombre de Compuesto.
En la tabla inferior de la pantalla, también tienes la capacidad de revisar aquellos errores/excepciones  de los cuales puedes realizar una Recuperación. Esto es, que es un error que puede ser reintentable, y que manualmente la consola del Enterprise Manager  te da la habilidad de hacerlo.
Algo que siempre recomiendo es hacer uso del Nombre de la Instancia, esta columnase encuentra en la tabla de la página Principal del Compuesto a monitorear. Por default esta columna está vacía. El desarrollador debe hacer lo propio para poder configurar lo que quiere que aparezca ahí. Normalmente se ocupa para poner algún identificador que sea útil para el negocio y que sirva para buscar instancias por algo realmente representativo. Por ejemplo: Algún número de Cliente, número de Teléfono, número de Factura, número de Producto, etc.
Como se ve en la pantalla la columna está representada por Name, o bien Nombre. Ahí es donde aparecerá el identificador que menciono.


Para colocarlo, una opción es usar la actividad de Java Embedded de BPEL PM, y utilizar la siguiente línea de código:
setCompositeInstanceTitle("ID Instancia " + (String) getVariableData("idInstancia"));
Con esto, la columna Name se poblará con dicho identificador.   Así, la búsqueda de una instancia en particular, puede ser con algún parámetro de negocio y no técnico, agilizando  el diagnóstico y resolución de problemas.
Algo que también recomiendo es que en tu búsqueda de instancias, si lo que estás buscando es algo particular de la ejecución de un Flujo BPEL, te vayas directo a este componente y abras la instancia particular. Esto te evitará ver toda la traza del compuesto. En ocasiones el compuesto es demasiado grande y su instancia o bien tarda en desplegarse en el navegador, o bien simplemente no se puede ver. Por eso es que, si tu interés es ver algo particular de un flujo BPEL, lo mejor es directamente la auditoría del componente.

ESTADO DE LOS COMPUESTOS
También, desde el Enterprise Manager, es factible controlar el estado de los compuestos. Esto es: poderlos Retirar, Frenar, Iniciar.

Primero vemos el estado de salud del compuesto. Señalado en la imagen con la flecha roja. Ahí vemos el nombre del Compuesto, y a su izquierda un señalamiento en Verde, que establece que el Compuesto está activo y ejecutándose.
Podemos retirarlo, lo cual hará que las instancias en ejecución sigan su camino, pero nuevas instancias no se generarán.
Luego vemos el botón de Cerrar, ese detiene todo lo que se esté ejecutando, obviamente nuevas instancias no se podrán ejecutar.
Y en medio de todo esto, podemos establecer como Default a esta versión. Esto es interesante, pues esto también nos haría ver que justamente esta versión NO es la default, y por eso la consola nos permite ponerla como tal.
Desde esta misma pantalla, podemos ver también una serie de opciones interesantes.
Por ejemplo, la supervisión:


También podemos anularlo, exportarlo, inspeccionar sus Políticas de Seguridad:      



RECOMENDACIÓN PARA TROUBLESHOOTING

Lo primero que hay que entender es que las transacciones, en su totalidad pasarán por el Service Bus.  Esto si es que tu arquitectura está fundamentada en exposición de Servicios a través de un elemento como OSB.
Esto hace que el primer punto de revisión, sea justamente el OSB .Si las transacciones no están en el OSB, seguramente estarán atoradas en el OHS, o bien en el Balanceador de Cargas. Pero eso no es parte de este documento. Se tendría que revisar en ellos, la forma de validar que hay problemas en esas capas.
Al llegar al Service Bus, lo primero que habría que hacer es mirar si la transacción reportó algo, esto lo veríamos en la sección de Operaciones del Bus.
Si la transacción la encontramos en el Bus, entonces el siguiente paso es ir a la SOA-INFRA. Esto, si es que el  Servicio tiene un componente del lado de la SOA-INFRA.
Estando ya del lado de la SOA-INFRA. Lo que debemos hacer es mirar el Enterprise Manager.Ir directamente a la sección de Fallas, o bien a la sección del compuesto en cuestión. Ahí saldrán las excepciones, o bien se buscará por algún identificador en particular.
Si el error es manejado, ahí fácilmente se identificará. Igualmente, si la instancia se encuentra en algún punto de deshidratación, también lo podremos saber
Si hubo algún error, pero el proceso no lo pudo manejar, y no se puede ubicar la causa, se tendrá que ir a los logs que se mencionaron en la primer parte de esta serie de artículos. En ese caso sí tendremos que ir hasta allá a buscar al error.
A nivel de los logs, además de buscar y tratar de identificar posibles causas de error, hay que estar pendientes que no se estén repitiendo excepciones.
Esto es, un compuesto en la soa-infra, por default si tuvo algún fallo, realizará una serie de reintentos. Si estos no fueron bien configurados, cada vez que se levante la infraestructura, estará reintentando esas instancias fallidas, lo cual provocará trabajo innecesario. Si al levantar la infra, nos damos cuenta de esto, tiene que ser reportado para poder revisar el compuesto en cuestión.
Otro escenario es que algún Datasource de los que usa el engine, esté teniendo algún problema. Esto se podrá validar desde el WeblogicConsole del componente en cuestión. Básicamente estaríamos hablando del OSB o bien de la SOA-INFRA.
Los datasources de la SOA-INFRA y del OSB, se enlistaron en la parte 1 de esta serie de artículos. Otro escenario es que los Weblogic estén respondiendo lento, o bien que los Servicios estén tardando en responder.  La causa de esto, puede ser la cantidad de Threads atorados, y esto también lo podríamos ver en el WeblogicConsole.
En el caso que la plataforma esté teniendo algún problema de lentitud o degradación del performance, que el mismo EM esté lento ,debemos de voltear a ver a la gente que administre la BD.
La BD de esta plataforma es una BD convencional, no hay nada en particular en ella. Pero al ser el repositorio  de metadatos, la soa-infra hace mucho uso de ella, por lo que también puede ser un punto a analizar, si es que la plataforma ya está demasiado lenta.
Sobre la BD habría que revisar el espacio libre en los tablespaces en cuestión, procesos, conexiones abiertas, etc. Realmente lo normal de cualquier BD.
Siempre hay que estar al pendiente del ambiente, pues el hecho de que sea Weblogic, Oracle, Base de datos, SOA, etc, no lo exime de tener que validar cuestiones de Sistema Operativo.
Hay que estar monitoreando espacio en disco, parámetros de Kernel, cantidad máximo de archivos que el SO puede abrir, permisos sobre los archivos, etc. Esto es muy importante, pues lo mas común es reportar que el Servicio no está disponible, y la verdadera causas del issue está a nivel de Sistema Operativo.
Igualmente no perder de vista que todo esto se ejecuta sobre una JVM, por lo que también hay que estar al pendiente de ella.
Desde nuestro punto de vista, los elementos a estar monitoreando, son:

  • La JVM
  • Memoria usada por los Managed Servers
  • Threads en ejecución
  • Datasources
  • Instancias de en la SOA-INFRA
  • Fallas y Excepciones en el Enterprise Manager
  • Revisión constante de los Logs.
  • Sistema Operativo en General
  • Validación en Base de Datos
  • Despliegues importantes en el Weblogic
  • Colas de JMS internas
  • Ejecución del RDA de Oracle https://blogs.oracle.com/soaproactive/entry/diagnose_soa_suite_11g_issues

ADMINISTRACION DE LA BASE DE DATOS DE MDS - SOA y OSB
El MDS es el repositorio de Base de Datos (Oracle) que ocupan todos los componentes de Fusion Middleware.
En el caso del OSB y la SOA SUITE, no es una excepción. Estos componentes hacen uso del MDS constantemente. Sobre todo la SOA SUITE, quizás el OSB no haga tanto uso de ella.
La SOA SUITE sí tiene constante uso del MDS, para:

  • Guardar artefactos, tales como: XSDs, WSDLs, XSLTs
  • Guardar el estado de las instancias de los compuestos
  • Guardar, de ser necesario, el payload de las instancias que están en ejecución, o ya se ejecutaron
  • Guardar el histórico de datos de Oracle BAM
  • Persistencia de colas JMS
  • Definiciones de Diccionario de Reglas, así como Rulesets.

Es por esto que es importante administrar esta BD. Pues contiene muchos elementos que son clave para la ejecución de la plataforma SOA. Esto no quiere decir que sea una BBDD especial, y que haya trucos o cuestiones especiales para administrarlas. Realmente es como cualquier BBDD
Los usuarios que utiliza la plataforma, son:  PROD_SOAINFRA, PROD_ORABAM, PROD_ORASDPM (el prefijo cambia de acuerdo a tu ambiente). Estos usuarios se generan como parte de ejecutar la utilería de Oracle llamada RCU (RepositoryCreationUtility). Y son parte de los esquemas de SOA.

El mantenimiento más crítico, desde mi punto de vista, está relacionado con la actividad que se genera durante la ejecución de los compuestos. Esta ejecución, sobre todo cuando se trata de compuestos que se comportan asincrónicamente,  hará un uso intensivo de la base de datos. Guardará prácticamente todo lo referente a la ejecución del compuesto, y dependiendo del nivel de auditoría que hayas configurado, estará guardando el payload completo que va viajando a lo largo de la ejecución.
Igualmente si el proceso (BPEL) tiene diferentes puntos de deshidratación, esto hará que constantemente esté yendo a la base de datos a recuperar su estado.
En ocasiones he leído que no se recomienda:

  • Tener tantos puntos de deshidratación
  • EvitarWaits en medio del proceso
  • Evitar Picks y Receives al medio del proceso

Es cierto, digamos que hacer un uso intensivo de ese tipo de actividades, lo que provocan es que en ambientes muy transaccionales, sean parte de la causa de fallos y de problemas  de rendimiento. Pero hay momentos en los que hay que ocuparlos, pues el diseño así lo exigirá.
Este tipo de actividades provocará una tarea constante de deshidratación en la Base de datos, por lo que, con mayor razón se debe poner atención a lo que  sucede adentro del manejador de base de datos.
Las actividades que debes tomar en cuenta, son las siguientes:

  • En  primera instancia, destina a un DBA que esté haciendo su trabajo sobre esta base de datos. Esto parece obvio, pero no pasa.  Me ha tocado estar muchas implementaciones , en donde no hay quien administre la base de datos de SOA, y éstas implementaciones son las que mas problemas tienen. Por lo que, sin lugar a dudas, debes de destinar a un DBA que se haga cargo de la base de datos.
  • Necesitas tener una reunión con el DBA en donde el equipo de SOA, explique el tipo de actividad que se tiene en esta Base de datos, para que en conjunto se llegue a conclusiones de cómo administrar al manejador
  • Tener claridad sobre el nivel de retención que quieras manejar sobre la información de las instancias. Hay clientes que no les interesa tener un histórico ni de un día anterior, pero hay aquellos que quieren guardar meses de histórico.  Esto depende totalmente del tipo de negocio e implementación. No es válido pensar que hay un estándar para decidir el nivel de retención, eso depende de tu negocio.
  • Tener una estrategia de purgado y de reclamo de espacio. Esto está totalmente ligado al punto anterior. El purgado se ejecutará y borrará la cantidad de información que tú decidas, pero eso es algo planeado, eso no es algo que decida el equipo de desarrollo SOA. Es una decisión en conjunto.
  • Entender el conjunto de tablas, y sobre todo , aquellas que son las propensas a crecer. Así como entender la razón por la cual esas tablas se llenan.

Aquí un extracto de un blog, referente a las Bases de Datos de Service Bus:
Major functionality of OSB is database independent. Most of the internal data-structures that are required by OSB are stored in-memory.Only reporting functionality of OSB requires DB tables be accessible. http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15017/before.htm#BABCJHDJ 

It should how ever be noted that we can still run OSB with out creating any tables on database.In such cases the reporting functionality cannot be used where as other functions in OSB will work just as fine.We also see few errors in the log file indicating the absence of these tables which we can ignore.  

If reporting function is required we will have to install few tables. http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15017/before.htm#BABBBEHD indicates running RCU recommended. OSB reporting tables are bundled along with SOA schema in RCU. 

Referencia: https://blogs.oracle.com/mneelapu/entry/does_osb_has_any_database_dependency

Como se puede entender, en el caso del Service Bus, no hay una dependencia tan grande con las Base de Datos. En realidad la dependencia es para cuestiones de reporteo y monitoreo.  Lo cual hace que si bien no es tan dependiente, sí sea importante. Pues sin la base de datos, no tendrás visibilidad, a través de los reportes que el OSB ofrece, de lo que está sucediendo durante la ejecución de Servicios.


Las Tabla mas relevantes para la SOA-INFRA, considerando la versión 11.1.1.6, son las siguientes:

  • AUDIT_TRAILCUBE_INSTANCE
  • CUBE_SCOPE
  • COMPOSITE_INSTANCE
  • COMPONENT_INSTANCE
  • MEDIATOR_CALLBACK
  • MEDIATOR_CORRELATION
  • BPEL_PROCESS_INSTANCES
  • BPEL_ACTIVITY_SENSOR_VALUES
  • BPEL_VARIABLE_SENSOR_VALUES
  • BPEL_FAULT_SENSOR_VALUES
  • AUDIT_DETAILSDLV_MESSAGE
  • DLV_SUBSCRIPTION
  • BPEL_FAULTS_VW
  • BPEL_VARIABLE_ANALYSIS_REPORT
  • JCA_NATIVE_CORRELATION
  • VERSIONREFERENCE_INSTANCE
  • FILEADAPTER_INX
  • REF_DATA

  
Aquí la descripción de algunas de ellas:
 

CUBE_INSTANCE This table contains the instance wise information for every instance that is being initiated. The CIKEY is the primary key of the table and this is the unique reference for a initiated instance. The DOMAIN_REF is used to refer the domain in which the initiated process belongs to. The PROCESS_ID gives the name of the process. The revision tag denotes the version of the process. The CREATION_DATE denotes the date in which the instance is created. The STATE denotes whether the instance is stale/completed successfully/error. The CONVERSATION_ID is an identifier that is used in correlation of instances in WS-Addressing. This can also be used in identifying an instance. The PARENT_ID is used to denote the CIKEY of the parent instance that initiated this process(if any).
CUBE_SCOPE The SCOPE_BIN column of this table is used to store the values of all variables declared in BPEL process and it values currently in runtime.
DLV_MESSAGE This table is an important part of correlation that occurs in BPEL. All incoming message’s metadata is stored in this table.
DLV_MESSAGE_BIN This table is an important part of correlation that occurs in BPEL. All incoming message’s payload is stored in this table.
INVOKE_MESSAGE This table is an important part of correlation that occurs in BPEL. All outgoing message’s metadata is stored in this table.
INVOKE_MESSAGE_BIN This table is an important part of correlation that occurs in BPEL. All outgoing message’s payload is stored in this table.
AUDIT_TRAIL This table is used to store information of the xml that is rendered in the BPEL Console. The LOG column has this xml.
TASK This table concerns with the human task that are created. Every task that is created is logged in this table. The ASSIGNEE denotes the user to whom the task is assigned.




























También aquí comparto la decripción de las tablas, sacado de la documentación oficial de Oracle:

TUNING DE PARAMETROS DE LA BASE DE DATOS DE LA SOA-INFRA
A continuación, una serie de parámetros a considerar para ser afinados, en base a un documento oficial de Oracle (http://www.oracle.com/technetwork/middleware/soasuite/learnmore/psrsoadbperformance-1919499.pdf):

 

PURGADO DE INSTANCIAS
A continuación, una serie de queries que servirán para conocer el estado de las instancias:

Para el purgado, te sugiero consultar las siguientes dos referencias:
Oracle Support:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=1384379.1

Oracle.com:
http://www.oracle.com/technetwork/database/features/availability/soa11gstrategy-1508335.pdf



Rolando Carraso (Oracle ACE) es Director de Oracle Fusion Middleware en S&P Solutions (México). Rolando tiene una carrera de mas de 13 años con tecnología Oracle. Toda su carrera profesional la ha dedicado a la ejecución e investigación de tecnologías que permita la integración de Aplicaciones. Especializándose en la Arquitectura Orientada a Servicios (SOA), tanto metodológicamente como técnicamente. Rolando es coordinador del Grupo de Usuarios de Tecnología en México (ORAMEX). Grupo fundado desde 2012, en conjunto con Plinio Arbizu (Oracle ACE Director).