Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

Friday, August 17, 2012

Procesos de Búsqueda en Desarrollos Caóticos
















Las bases de datos, para almacenar direcciones de clientes, han sido diseñadas, tradicionalmente, con los siguientes campos básicos: dirección, ciudad, estado y país. Eventualmente se incluye el código postal y algún punto de referencia que facilita la ubicación del inmueble.

En Venezuela, con la nueva disposición gubernamental que ordena especificar en las direcciones de los clientes, la información relacionada con municipio, parroquia, sector/urbanización, casi todas las empresas se han visto en la necesidad de reorganizar las bases de datos, fragmentando o compactando información y creando nuevos archivos de datos y programas.

Esta reingeniería requiere el diseño de mejores buscadores de información. No es lo mismo cargar el pedido de un banco que contiene 300 sucursales (y además sucursales que pueden estar en la misma ciudad y avenida y que se pueden diferenciar solamente por el detalle de la ubicación) que cargar el pedido de un cliente que tiene dos sucursales. Los procesos de búsqueda de direcciones deben ser ágiles y parecidos a los buscadores de Google en cuanto a la localización rápida de los datos de un cliente. Estos cambios requieren más archivos, y más pantallas de navegación en cascada o listas desplegables que permiten seleccionar los datos faltantes de las direcciones.

Para aquellas empresas que trabajan con herramientas más actualizados como el SQLRPGLE, es sencillo generar buscadores:

Select * from librería/archivo where campo1 like ‘%Altamira%’ or campo2 like ‘%Altamira’

Si la información no está en un solo archivo es suficiente con hacer join con los archivos involucrados y aplicar la misma lógica.

Cabe destacar que, cuando un cliente tiene múltiples direcciones, es necesario asignar un campo clave de código de dirección (que puede ser un numero consecutivo) que permita diferenciar con éste código cada dirección registrada.

Aunque con el uso del SQL parecería sencillo este proceso, hay organizaciones que tienen sistemas caducos programados en Rpg 3 y quizás con algunos programas en rpg4 y cuya lógica engorrosa de programación de infinitos lazos anidados e indicadores, acumuladores y totalizadores de montos hacen de esta tarea un verdadero desafío.

¿Qué hacer en estos casos?

1.-Desarrollar programas para realizar cargas masivas de direcciones por cliente.

Independiente de los procesos que ya existen en la empresa, es necesario cargar manualmente o por procesos en batch de trasmisión remota las direcciones únicas o múltiples de cada cliente. Esto último aplica si las empresas logran establecer acuerdos con los clientes grandes y con corporaciones que envíen en un formato digital predeterminado, la información de sus direcciones bien sea en Excel o desde un iseries hacia otro iseries.

2.-Realizar programas de búsquedas o módulos que puedan ser invocados por los programas viejos y que devuelvan: o bien un arreglo con los códigos de direcciones que cumplen la condición de búsqueda o una lista desplegable interactiva donde el usuario seleccione la dirección que le interesa.

3.-Realizar la búsqueda en los subfiles y no en el archivo directamente.

Este último punto aplica principalmente a las instalaciones desactualizadas cuyo nivel de programación o experticia es insuficiente o cuando el despliegue del subfile se realiza luego de varios lazos anidados de lectura de archivos y no se desea cambiar la lógica del programa por la falta de tiempo, por el riesgo de errores o por la falta de recursos.

Mientras cargas el subfile puedes construir, en un campo oculto tipo caracter, el resultado de la concatenación de los campos del archivo donde deseas realizar la búsqueda. Cuando el usuario coloque un texto para buscar información, recorres el subfile haciendo %scan (o scan)por este campo “largo” y reposicionas el cursor en el tope del subfile con el rrs de la línea donde se consiguió la data. (con la keyword: cursor *top del sda)

4.-Como el dicho reza: “cuando veas las barbas de tu vecino arder pon las tuyas a remojar”, de la experiencia de otros puede sacarse provecho. Los desarrolladores que van a diseñar bases de datos de direcciones de cliente o de direcciones en general, o con campos de textos ( o el caso de empresas de geocodificación cuyo negocio es la localización de direcciones en mapas o en otro medios digitales) es preferible hacer un diseño de base de datos de direcciones “fragmentado”, es decir, generar un campo para cada detalle de la dirección de un cliente: País, Estado/Provincia, Municipio, Parroquia, Sector, Avenida/calle, edificio/casa, Piso, Punto de referencia, código postal, etc.

Separando los campos se tiene una mayor ventaja y flexibilidad en los procesos de búsqueda y además en los procesos de validación.

Este mismo tipo de criterio debe aplicarse a empresas de seguro y centros de salud que deben describir el estado de un paciente en campos de texto. Jerarquizar la data creando campos que actúen como índices de enlace y acceso en la base de datos es más recomendable que aquellos campos largos que tienen mucho texto y terminan haciendo engorroso el acceso a la información.




Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.


Autor: Ing. Liliana Suárez