Propietarios Múltiples de una Base de Datos Única

La Validación Siempre Usa Datos de Control de Producción

Cuando los procesos de lote de validación se ejecutan contra los datos de ubicación intermedia, validan los datos de ubicación intermedia contra las tablas de control de producción (e insertan errores en la tabla de error de ubicación intermedia). Esto significa que las sentencias SQL que acceden/actualizan entidades deben usar el propietario de ubicación intermedia, mientras que las sentencias SQL que acceden a tablas de control deben usar el propietario de producción. Pero observe que cuando estos mismos procesos de lote de validación se ejecutan contra producción, las sentencias SQL nunca accederán al propietario de ubicación intermedia. En cambio, todas apuntan al propietario de producción.

Esto se realiza de la siguiente manera:

• Debe existir un servidor de aplicación separado para cada propietario. Cada servidor de aplicación apunta a una ID de usuario de base de datos específica.
  Nota: En una instalación en la Nube, el servidor de aplicaciones solo puede apuntar a una ID de usuario de base de datos específica en cualquier momento. Para obtener más información sobre el cambio de propietarios, consulte “Soporte de Conversión de Datos para Implementaciones en la Nube”.
• La ID de usuario de base de datos asociada con el propietario de ubicación intermedia usa CISSTG como el propietario de la tabla principal y la tabla de transacción, pero usa CISADM como el propietario de las tablas de control de producción.
• La ID de usuario de base de datos asociada con el propietario de producción usa CISADM como el propietario de todas las tablas.

Es posible que se pregunte por qué tuvimos este problema. Existen varios motivos:

• Deseábamos reutilizar la lógica de validación que existe en los programas que validan los datos de producción. Para lograrlo, estos programas a veces apuntan al propietario de ubicación intermedia y otras veces deben apuntar al propietario de producción (y debe ser transparente para los programas, de lo contrario, se necesitarían dos juegos de SQL).
• Deseábamos permitir que usara la aplicación para mirar y corregir los datos de ubicación intermedia. Esto se puede lograr creando un servidor de aplicación que apunte a la base de datos de ubicación intermedia con las características de propiedad anteriormente descritas.
• Deseábamos que los programas de validación pudieran validar los datos de producción (además de los datos de ubicación intermedia). ¿Por qué desearía validar datos de producción si sólo se pueden agregar datos limpios a producción? ¿Por qué desea validar los datos de producción si sólo datos limpios se pueden agregar a producción? Se consideran los siguientes escenarios:
  • Después de una actualización, es posible que desee validar los datos de producción para asegurarse de que la lógica de salida de usuario preexistente todavía funciona.
  • Puede que desee llevar a cabo un experimento de las ramificaciones que puede tener el cambio de la lógica de validación. Para hacerlo, puede realizar un cambio temporario a la lógica de salida de usuario (en producción) y luego ejecutar los trabajados de validación de manera aleatoria de muestra.
  • Olvidó ejecutar un programa de validación antes de completar la producción y desea ver el daño. Si sigue las instrucciones de este documento, esto nunca debiera pasar. Sin embargo, ocurren accidentes. Y si pasan, al menos hay una forma de determinar las ramificaciones.

Solo la Validación puede Funcionar en Ambos Propietarios

Si bien el redireccionamiento de IDs de propietario es una técnica útil para los procesos de lote de validación, los procesos de lote de inserción en producción y asignación de claves no pueden usarlo. ¿Por qué? Porque estos procesos tienen que acceder al mismo tiempo a las mismas tablas, pero con diferentes propietarios. También deben hacer referencia a tablas específicas de conversión que no existen en producción. Por ejemplo, el proceso de lote que inserta filas en una tabla de producción debe seleccionar filas de la versión de ubicación intermedia de esa tabla, resolver claves desde las tablas de mapeo de conversión de clave anterior/clave nueva e insertar los registros resueltos en la versión de producción de esa misma tabla.

Esto se realiza de la siguiente manera:

• En la ubicación intermedia, existe una visualización de la producción para cada elemento elegible para una tabla de conversión. Estas visualizaciones han codificado el propietario de base de datos para apuntar a la producción. Por ejemplo, hay una visualización llamada CX_​PER que apunta a la tabla de persona en producción.
• Los programas de inserción y asignación de claves usan estas visualizaciones cada vez que necesitan acceder a datos de producción.