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 (Repository Creation Utility). 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:

1. Tener tantos puntos de deshidratación

2. Evitar Waits en medio del proceso

3. 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:

1. 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.

2. 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

3. 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.

4. 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.

5. 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.