Ford Country lo hace con Advantage

¿ Que haces si eres el distribuidor FORD No. 1 en ventas a nivel nacional ?
¿ Si tienes el departamento de refacciones mas grande y mejor surtido de todo el país ? (me consta porque encontré una pieza para mi coche que había estado buscando en un montón de refaccionarias y distribuidores)
¿ Si tu almacen de refacciones son de 2 plantas de mas de 1000 m2 con mas de 2 millones de dólares de valor de invenario ?
¿ Si vendes mas de 200 unidades nuevas cada mes ?
¿ Si tu bodega de coches mantiene un inventario promedio de 400 unidades mensuales ?
¿ Si tu departamento de servicio realiza 1,200 reparaciones al mes ?
Donde tus clientes son incluso otras agencias FORD que te compran refacciones y tus instalaciones ocupan una manzana completa en la ciudad de Guadalajara

y no contabas con Tecnología Cliente / Servidor.....

Este es el caso Country Motors, otra empresa que se ha beneficiado de las bondades de Advantage Database Server.

Country Motors o Ford Country, como se le conoce en el medio, posee ahora un servidor Advantage Database Server 7.1 para 250 usuarios, corriendo sobre un servidor Novell Netware 6.1, con TCP/IP en un Servidor Compaq Proliant, Xeon de 2.4 GHz, con 2 procesadores y 3 Gigas de memoria RAM, la red cuenta con mas de 120 estaciones de trabajo.

La empresa está en constante expansión, las instalaciones de Ford Country albergan a las 3 empresas del corporativo: Country Motors, Servicio Country y Servicios Administrativos Country, donde laboran mas de 200 empleados.

Country realiza toda la operación de sus tres empresa trabajando con el sistema SICOM (Sistema Integral COuntry Motors) una aplicación desarrollada por ellos mismos en xHarbour 0.99 y FWH 2.4. El servidor ADS se integró al SICOM en un proceso de migración donde tuve el gusto de participar junto con Héctor Garfias, director de Sistemas y Alejandro Frausto Acosta responsable del desarrollo de los sistemas.

ADS se integró en los 8 módulos que componen todo el sistema administrativo de la empresa y que además comparten información entre si :

Refacciones
Servicio
Ventas de autos nuevos y seminuevos
Contabilidad
Crédito y Cobranza
Bancos
Caja
Nómina

La empresa presta sus servicios desde las 7 am. hora en que abre el taller para recibir autos a servico, la atención al público se extiende hasta las 18:00 hrs normalmente, pero muchas veces se labora hasta las 10 u 11 de la noche en otras áreas, luego entonces, la operación del negocio la podríamos clasificar como de "misión crítica".

Cuando tu DBF mas grande tiene 500 mil registros, lo utilizan simultaneamente 15 usuarios, durante todo el día, esto ya te podrá ir dando una idea del volumen de información que se maneja en un mes en todos los departamente y por todos los sistemas.

Antes de la implementación de ADS, los errores de corrupción de índices, fallo en la integridad de la información lentitud en el tiempo de respuesta eran cosa de todos los días, y mantenían ocupados al todo el personal del área de informática solo para reparar archivos DBFs incompletos, regenerar índices y todas esas labores de emergencia que hay que hacer para mantener trabajando una empresa, sólo imagina, 120 usuarios atacando al mismo tiempo mas de 400 dbfs.... esto es una verdadera locura, no hay red que lo soporte.

El proceso de implementación siguió los siguientes pasos:

Instalación del servidor: El proceso de instalación del server fue bastante rápido, no cabe duda que los sistemas operativos de red han progresado un montón desde aquella versión 3.11 de Novell hasta la actual y de la versión 3.1 de ADS a la 7.1, de este punto no hay mucho que comentar.

Configuración de los parámetros básicos de trabajo: Como en toda implementación de ADS este es el proceso mas delicado porque de un correcto análisis de las bases de datos se deriva una buena puesta a punto del servidor, poner a punto un server ADS no es complicado pero requiere de una serie de análisis sobre las características de los archivos DBFs que integran el sistema, el número de usuarios que acceden a ellos, en fin, este punto requiere de una amplia colaboración por parte del usuario ADS y del consultor que realiza la implementación.

Migración de la aplicación: Este es el punto que mas tiempo nos llevó de todo el proceso de implementación, todos los programadores de Xbase tenemos ciertas deformaciones profesionales al programar que hemos usado de toda la vida para evitar los errores de corrupción de índices, entre ellos, el abrir y cerrar los archivos dbf cada vez que entras a un módulo de la aplicación, indexar en base a funciones definidas por el usuario, uso de filtros, y otras, estas cosas "matan" materialmente el desempeño del ADS, razón por la cual hubo que hacer una buena revisión del código fuente (mas de 30 mil líneas de código) para eliminar los cierres / aperturas de DBFs constantes. Por otro lado, hubo que revisar algunos índices que no eran de longitud fija (uso de la funcion TRIM(), en las llaves), o bien utilizaban funciones definidas para el usuario para generar una llave, en un par de casos, hubo incluso que modificar las estructuras de la base de datos para agregar un campo que contuviera la expresión de la UDF utilizada en un índice, esto por supuesto, llevo el tener que modificar varios programas. También se implementó el uso de AOFs (Advantage Optimized Filters) para sustituir los filtros Xbase que tenía el programa, este proceso nos llevo poco mas de 3 días.

Prueba de ácido: Una vez migrada la aplicación, llegó el momento de hacer la primera prueba en producción, para ello decidimos hacerla un sábado, que es un día en que se trabaja de manera normal, pero el flujo de datos no es mucho, así que a las 7 am comenzamos a montar la aplicación de Servicio ya que es la primera que comienza a funcionar todos los días, para las 9 de la mañana ya teniamos 5 de 8 aplicaciones en ejecución y constantes llamadas de los usuarios por problemas de conexión al sistema, se hizo una revisión de los parametros de trabajo del ADS y descubrimos que nos habíamos quedado muy cortos en un parámetro crítico al configurar el servidor, asi que de una manera u otra, había que modificarlo, dar de baja y levantar nuevamente el servicio para que los mas de 90 usuarios que atendía el sistema en ese momento pudieran continuar trabajando, optamos por "la solución violenta", es decir dar de baja el server sin importar quien estuviera conectado, asi que lo dimos de baja y lo volvimos a levantar, pero dada la presión de los usuarios por continuar trabajando, levantamos los servicios de ADS antes de que el server Novell se levantara completamente, y entonces tuvimos un problema doble, no había red, y tampoco había SICOM, asi las cosas, decidimos bajar nuevamente el server, esperar completamente a que se levantaran todos los servicios de Novell, y finalmente levantar el ADS con toda la calma que el caso requería, el server se mantuvo trabajando otras 3 horas y 40 minutos sin ningun problema ya, solo algunos detalles de programación, durante estas 3 horas de trabajo se atendió a 91 usuarios, se abrieron 781 tablas dbfs y se realizaron 10,748,669 operaciones en el servidor ADS sin ningún problema en ninguno de los departamentos.

La implementación está terminada, 3 días nos llevó y aún quedan algunos pendientes, detalles mínimos de programación, unos índices que no están bien hechos, pero son cosas que con un par de días revisando el código funcionarán perfectamente.

Los siguientes pasos serán la implementación de transacciones con ADS y quizá el cambio de formato de DBF a ADT, pero aún falta tiempo para eso.

ADS ha causado una grata impresión en la empresa, próximamente abrirán una nueva distribuidora, y por su puesto... habrá un ADS en su servidor.