Estrategias de Desarrollo

Conversin del acceso a Datos

Roadmap IBM

WDSC: Websphere WebProductores Developmet Cliente Studio Client interno

ObjetivoEs una generar una aplicacin Web orientada a la empresa, que permita tomar ventajas de la escalabilidad y flexibilidad que ofrecen las tecnologas modernas, tanto en hardware como en software. Adaptando el acceso a Base de datos y las practicas de desarrollo para que acompaen los cambios del negocio.

Mejores Herramientas (Better tools)Unificar y modernizar el Workbench de desarrollo para todo las tecnologas, RPG, COBOL, JAVA, SQL, etc.

Mejorar la interfaz de usuario (Better user interfase)IBM WebFacing Tool for iSeries WebSphere Host Access Transformation Services (HATS) iSeries Access for Web Las tres herramientas permiten modernizar y extender la vida util de las aplicaciones 5250.

Mejorar la arquitectura Better ArchitectureEs el primer paso para el rediseo de nuestras aplicacionesObjetivosModularizar Separar las reglas de negocio de la interfaz Aislar las funciones de acceso a la base de datos e impresin Trasladar lgica que historicamente fue escrita dentro de la aplicacin y que puede trasladarse a la base de datos (Reglas de integridad referencial, procedimientos almacenados, triggers, etc)

Modernizar usando SQLRazones del cambioEstandarizacin Performance Desarrolladores, mayor posibilidad de encontrar skills de desarrollo en SQL vs. RPG Funcionalidad Integridad de datos Acceso a herramientas de no-IBM

Conversin - Terminologa

Consideraciones

Metologa propuesta por IBMFASES1.

2. 3. 4.

Aplicar ingeniera inversa para convertir DDS a definiciones SQL (DDL) Crear mdulos de acceso a BD DB2 Mover las reglas de negocio a la base de datos Implementar funciones avanzadas de base de datos

CMO?

FASE I :Reemplazo de DDS por estructuras SQLPasos 1. Clasificar el ambiente existente 2. Establecer la lista de DDS a ser convertidas y medir esfuerzo 3. Establecer la convencin de nombres SQL a utilizar 4. Convertir las DDS a DDL SQL 5. Revisar las descripciones generadas con DDL 6. Crear un nuevo esquema DB2 (biblioteca) 7. Re-Crear todas los indices existente sobre las tablas SQL 8. Migrar los datos y testear las aplicaciones existentes

1.Clasificar el ambiente

2. Seleccionar DDSselect table_name, table_type, file_type from qsys2.SYSTABLES where table_schema = 'APILIB' and table_type = 'P' and file_type = 'D' order by table_name

Archivo fisico

Q lgicos

Q programas Inicio

Fin

Dias

3. Convencin de nombresEvite utilizar el tipo de objeto, como parte de el nombre del objeto. Por ejemplo, no use las palabras FILE, TABLE, INDEX o como parte del nombre. Utilice el nombre de tabla y un sufijo para SQL ndices. No se preocupe acerca de la longitud del nombre ya que los ndices no pueden ser especificados en una sentencia SQL. En el servidor iSeries, Proporcionar estadsticas de los ndices y se puede utilizar para ejecutar una consulta. Por ejemplo, CUSTMST_X001 es una indice radix de CUSTMST, o CUSTMST_V001 es un ndice de tipo Vector Encoded de CUSTMST. Usar los sufijos para los cdigos de aplicacin

4.Conversin DDS a DDL SQLiSeries Navigator- Generar SQL -- Generar SQL -- Versin: V5R4M0 060210 -- Versin: V5R4M0 060210 -- Generado en: 20/03/08 12:55:16 -- Generado en: 20/03/08 12:52:47 -- Base de datos relacional: LMA730 -- Base de datos relacional: LMA730 -- Opcin de estndares: DB2 UDB iSeries -- Opcin de estndares: DB2 UDB iSeries

API QSQGNDDL que puede ser llamada directamente desde un CL

CREATE TABLE COBDBF.COCAJAF ( CREATE VIEW COBDBF.COCAJAL1 ( -- SQL150B 10 REUSEDLT(*NO) en tabla COCAJAF de COBDBF ignorado. -- SQL1506 30 Clave o atributo para COCAJAL1 de COBDBF ignorado. CEMPRES NUMERIC(2, 0) NOT NULL DEFAULT 0 , CEMPRES , CSUCURS CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CSUCURS , CTCAJA CHAR(5) CCSID 284 NOT NULL DEFAULT '' , CTCAJA , NCAJA DECIMAL(8, 0) NOT NULL DEFAULT 0 , NCAJA , FCAJA DATE NOT NULL DEFAULT CURRENT_DATE , FCAJA , CCAJERO CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CCAJERO , FCIERRE DATE NOT NULL DEFAULT CURRENT_DATE , FCIERRE , NMINUTA DECIMAL(8, 0) NOT NULL DEFAULT 0 , NMINUTA , CEST_CA CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CEST_CA ) -- SQL150D 10 VALUES de columna CEST_CA ignorado. AS PRIMARY KEY( CEMPRES , CSUCURS , CTCAJA , NCAJA ) ) SELECT CEMPRES , RCDFMT COCAJAR ; CSUCURS , CTCAJA , LABEL ON TABLE COBDBF.COCAJAF NCAJA , IS 'Archivo de Cajas.' ; FCAJA , CCAJERO , LABEL ON COLUMN COBDBF.COCAJAF FCIERRE , ( CEMPRES IS 'Empresa Recaudadora' , NMINUTA , CSUCURS IS 'Cdigo de Sucursal' , CEST_CA CTCAJA IS 'Tipo de Caja' , -- SQL150D 10 VALUES de columna CEST_CA ignorado. NCAJA IS 'Nmero de Caja' , FROM COBDBF.COCAJAF FCAJA IS 'Fecha de Apertura de Caja' , CCAJERO IS 'Cdigo de Cajero' , RCDFMT COCAJAR ;

5. Revisin de DDLPalabras claves no soportadas Salvar Error de nivel (opciones)Recompilar con LVLCHK(*NO) OVRDBF LVLCHK(*NO) CHGPF LVLCHK(*NO) OJO!! Los resultados a futuro pueden ser impredecibles

Nombre de formato de registroSolucin para conservar el nombre de registro1. 2. 3.

CREATE TABLE COBDBF.COCAJAR ... RENAME TABLE COBDBF.CACAJFR TO CAJAS RENAME TABLE CAJAS TO SYSTEM NAME COCAJAF

Nombre de columnas

6.Crear un nuevo EsquemaCREATE SCHEMA crea los siguientes objetos AS/400:Biblioteca OS/400 journal and journal receiver DB2 views containing schema-wide catalog

7.Re-Crear todas los indices existente sobre las tablas SQLLuego de creado el nuevo esquema se deben usar los script SQL revisado para crear las nuevas tablas e ndices. Adicionalmente se deben crear los LF para que los programas existentes (HLL), asegurndose que todos los LF compartan la misma va de acceso que los ndices SQL.

CMO?

Pasos para recrear LFa)

b)

CREATE TABLE tabpf_sql (tabpf ser el nombre corto original) Modificar DDS de LF para referenciar al nuevo fsico.R Nombre_reg pfile(tabpf_sql) format(tabpf)

a)

Los pasos anteriores aseguran que labelchek es el mismo entre lgico y pgm, por lo tanto el programa no no necesita ser recompilado y tomar las ventajas de un acceso mas rpido en ndices muy grandes.

(Para detalles ver sg246393.pdf pgina 61).

8.Recrear los datos existentesSe debe armar un conjunto de aplicaciones para migrar los datos (CL, CPYF *MAP, SQL, etc) Validar datos Testear las aplicaciones Mover los nuevos esquemas del ambientes de Testing al ambiente productivoLo mejor es mover el esquema al ambiente produtivo y ejecutar todos los script de creacin nuevamente Si no es posible se puede salvar y restaurar el esquema desde el ambiente de Test al productivo.

SAV AND RESTORE SCHEMMA1. 2. 3. 4. 5.1.

En ambiente de Test SAVLIB TEST ACCPTH(*YES) En produccin CREATE SCHEMA PROD. RSTLIB TEST OPTION(*NEW) RSTLIB(PROD). Buscar en Test todos los objetos que se encuentran bajo Journal Asociar en produccin las tablas a los journalSTRJRNPF PROD/Tabla1 PROD/QSQJRN IMAGES(*BOTH) OMTJRNE(*OPNCLO) STRJRNPF PROD/Tabla2 PROD/QSQJRN IMAGES(*BOTH) OMTJRNE(*OPNCLO)

2.

DIFERENCIAS ENTRE PF, TABLAS SQLVentajasLas restricciones (constraint) estn incluidas en el objeto tabla SQL Lee mas rpido que comparado con la lecturas desde un lenguaje de alto nivel (HLL) Es posible colocar nombre mas descriptivos a los nombres de columnas El modelado de datos puede realizarse con herramientas que soporte SQL Se asocian automaticamente a journal las tablas creadas en un nuevo esquema

DesventajasLa escritura es mas lenta que con sentencias Write de HLL No hay soporte de DDM pero SQL can utilizarse distrubuido con SQL CONNECT Tablas SQL no soportan multi-miembros pero pueden usarse ALIAS.

DIFERENCIAS ENTRE LF E INDICESLa mayor diferencia es en la tecnologa que estn diseados los indices de bsquedas. Los ndices utilizan Encoded Vector Indexes (EVIs) con pginas de 64k mientras que los LF bitmap indexes DE 8k. VentajasMayor rendimiento en bsquedas con gran volumen de datos

DesventajasMayor requerimiento de memoria No tienen soporte de la clausula SELECT y OMIT

Vistas SQL vs LFLas vistas SQL son como LF sin claves.VentajasLas vistas son mas flexibles en trminos de seleccin y procesamiento de datos. Se permiten clusulas CASE y funciones DATE/TIME Las clusulas de agrupamiento y join que ofrecen las vistas son mas potentes que los LF Los programas nativos pueden abrir vistas como LF

DesventajasLas vistas SQL, no pueden ser con clave SQL no pueden reemplazar archivos lgicos con multiformato

Tipos de datos SQLEn las columnas de tablas SQL se soportan mas tipos de datos como LOB (large object), datalinks y tipos definido por el usuario. Las columnas soportan nombres hasta 30 caracteres de longitud y las tablas hasta 128. Es posible particionar por temas de performance tablas de datos de gran tamao.

MODERNIZANDO EL ACCESO A LOS DATOSCmo crear mdulos I/O para acceder a los nuevos objetos SQL? Cmo comenzar a mover las reglas de negocio a la base de datos? Cmo tomar ventaja de uso de SQL embebido para reemplazar sentencias tradicionales de I/O? Cmo aprovechar y explotar las ventajas de triggers, procedimientos almacenados y funciones de usuario?

Mdulos I/O para acceder a los nuevos objetos SQLESQUEMA OBJETIVO

Crear mdulo I/O de acceso a BDPasos requeridos1. Establecer reglas de nombrado 2. Crear vistas SQL basadas en requerimientos del negocio 3. Crear programas de servicio que accedan a los datos desde las vistas SQL 4. Convertir los programas legacy para que utilicen los programas de servicio.

3. Crear programas que accedan utilizando views

Imaginar la lgica solo con RPG...

4.Externalizar el acceso a base de datos I/ONo se necesitan convertir todos los programas Los candidatos son:Pgm que usen OPNQRYF (utilizan el viejo motor CQE en lugar del nuevo SQE) PGMs que hacen lecturas y escrituras masivas en batch. Programas que controlan existencia de registros Programas que podran beneficiarse con el uso de JOIN Programas que llenen un subfile con criterios complejos