Hoy vamos con una entrada policiaca. Además vengo inspirado, este fin de semana aburridos de películas modernas con argumentos inverosímiles y llenas de efectos especiales… terminamos en casa viendo un par de películas antiguas de la señorita Marple divertida investigadora creada por Agatha Christie
Y el recordar a la investigadora pueblerina que le saca los colores a los Inspectores de Scotland Yard me ha recordado el tema de la entrada que estáis leyendo. Resulta que un programa de gestión de una empresa falla… y la culpa es de un PC vendido por la tienda del pueblo local.
Voy a poneros en antecedentes. Hace un año nos llama un empleado de esos que tienen trabajos duales (tengo otra entrada sobre eso) de contable-experto informático de la empresa. Resulta que han comprado una ampliación del ERP que tienen en su Pyme y van a instalar ordenadores en la planta de producción para gestionar tareas allí. Tienen que ser pequeños y táctiles, ya que la aplicación está pensada para usarse con las manos. Además la interacción de los usuarios con el software será mínima. Como trabajarán atacando al servidor de la empresa no hace falta que sean muy potentes.
Empezamos la búsqueda y les recomendamos unos portátiles con teclado desmontables de Asus que teníamos en stock en aquellos momentos y para sus prestaciones (incluía lápiz táctil con muy buena resolución) el precio era muy bueno (tanto que ya no los hemos vuelto a ver en stock…). Al final se decantan por un AIO de una marca conocida. Como no tiene claro si funcionarán, nos piden solo uno. Lo tienen un par de meses trabajando, mientras van depurando la aplicación. Al final nos piden una docena de AIOs iguales.
Los montamos y los dejamos funcionando. A las semanas se queja el contable de que en algunas pantallas les cuesta seleccionar datos a sus empleados. Vamos para allá y empiezo a no entender nada. Recordar que es una aplicación que esta en una cadena de montaje. Que los usuarios solo deben teclear a veces un código de orden de producción, una fecha y un código de calidad interno. Pues la aplicación está programada en Win32 con controles gráficos del siglo pasado. Esto si tienes un teclado y un ratón solo te hace parecer antiguo… pero si esperas que un usuario agobiado, con mascarilla y con guantes teclee algo en una pantalla táctil es un desastre. Sobre todo les era casi imposible seleccionar la fecha, ya que tenían un control donde estaba la fecha sin poder editarse, debían teclear en una teclita al lado muy pequeña, se abría una vista del mes, si la fecha era de otro mes, había que pasar de mes con teclas minúsculas a ambos lados, algo parecido a esta imagen, pero más pequeños los botones:
Como el contable no paraba de quejarse, les compramos unos lápices para ayudar a teclear en el AIO. Pero el AIO tenía una pantalla táctil de resolución normal. Vamos de la que tiene una resolución para usarse con aplicaciones desarrolladas pensando en que las van a usar solo con los dedos: botones grandes, campos grandes, pestañas… Aquí no quise hacer sangre con el contable, pero con los portátiles de Asus con lápiz de alta resolución táctil el problema no sería tan acuciante.
Al final decidí explicarle al contable como debían haber desarrollado las pantallas de la aplicación, así que monté una demo con las librerías de Winui 3. En el fondo es solo usar lo mismo que en las aplicaciones para móviles o tabletas, algo así:
Además el contable se quejaba de que había pedido ver más datos en la pantalla y le habían puesto tres datagrids. Para que entrasen todos los habían diseñado con unas filas realmente bajitas, no había manera de acertar con el lápiz para seleccionar un registro. Aquí le sugerí usar un sistema de pestañas para cambiar la vista en la misma pantalla y poner una filas de tamaño normal. Otro problema que tenía era que a veces necesitaban consultar datos que estaban en una columna que no era visible, asi que debían moverse en horizontal… y los botones de desplazamiento eran también pequeños.
Aquí repetí la jugada y monte nos datagrid en WinUI 3 con dos versiones. En una yo había modificado a mano el tamaño de las barras de scroll horizontal y vertical para que fuesen más grandes. En la otra versión ya me regodee… pues un + en la fila que al pulsarla mostraba todas las columnas de esa fila.
Pero también le comento que si querían seguir con un interface Win32, se podían comprar controles de terceros con esas prestaciones… Como dice mi mujer yo siempre buscándome amigos. Es lo malo de ser aprendiz de todo y maestro de nada.
Al final a base de practicar mucho con los lápices que les pusimos los trabajadores se acostumbraron y dejaron de quejarse. Total que problema había, una tarea que con un buen interfaz les llevaría 10 segundos ahora podían llevarles un minuto y medio. Y en ese tiempo la producción parada. Pero claro el diseño de las pantallas y la ergonomía no es algo de lo que deba saber un contable. Esto son algunos antecedentes para ir conociendo a la gente
Pero hace unos meses nos vuelven a llamar. Uno de los PCs muestra un error en el programa. Nos dicen que los programadores indican que es culpa de la tarjeta de red del AIO. Nos lo traemos a la tienda y lo tenemos tres días conectado pasando tests… no falla ni una sola vez el Wifi en los tres días. Por si acaso, reinstalamos Windows. Se lo llevan y están otros dos meses sin problemas.
En el interín nos llaman para que les hagamos un presupuesto a ver si pillan fondos del NextGeneration (esos que opinan que Linux es inseguro). Tenían tres proyectos: uno de hardware que querían que lo hiciésemos nosotros para cambiar el servidor (que todavía iba con Windows Server 2008) otro para mejorar la red local y un tercero de dos módulos nuevos para el ERP. Para le mejora de la red local viene su proveedor de red… que es un electricista del pueblo. El electricista les pasa un proyecto para tirar un cable RJ45 de 300 metros hacía la zona de producción y allí montar un Switch con dos puntos de acceso Wifi para dar cobertura a los 12 AIOs y a varios puestos nuevos que iban a instalarse si salía adelante el proyecto. Les recomendamos una infraestructura de fibra para esa tarea, para no perder velocidad en la conexión y no saturar el cable y saltar por lo menos a 10 GPBs. Aquí tenemos a otro conocido.
Se me ocurre preguntar (curioso que es uno) quién había montado los actuales punto de acceso de red. Nos dicen que se las vendieron los que les instalaron la primera versión el ERP y que las instaló (que no configuró) el electricista actual.
Pasan dos meses sin problemas y nos llama el contable exigiendo que le cambiemos el AIO, que otra vez daba problemas de red y los programadores le decían que la culpa era de la tarjeta de red del AIO. Tengo que explicarle que no puedo llamar al fabricante y enviarle un PC porque según unos programadores falla la tarjeta de red. Tenemos que ser capaces de reproducir el error e indicar al SAT del fabricante como hacerlo ellos. El AIO vuelve a nuestro taller. Por supuesto en una semana ni una caída de línea del Wifi, ni un paquete perdido. Se lo volvemos a instalar y nos dicen que sigue fallando, que el AIO hay que cambiarlo. En esas que tenemos un cliente que va a abrir un bar y nos pide un AIO de segunda mano. Entonces decidimos matar dos pájaros de un tiro. Se lo comentamos al contable de la empresa. Y le vendemos el AIO que según sus programadores no funcionaba al cliente del bar. Y por una diferencia de valoración nos compran un AIO nuevo igual. Pero no era igual, el fabricante le había puesto un micro más potente, más RAM, mejor disco duro y sobre todo una pantalla superior. Se lo llevamos y saltaba a la vista que era más sencillo de usar y corría más. Pensábamos que por fin habíamos terminado con el culebrón… no era así.
Dos días nos duró la tranquilidad al tercera fallaba otra vez la red y los programadores siguen insistiendo en la tarjeta Wifi. Me voy al armario del taller y sacó una Wifi USB que usamos para emergencias, que tiene 5 años y nunca ha fallado. Por si acaso otra Wifi USB nueva. Le instaló una, al día siguiente error. Instaló la nueva, en dos horas error del programa. Y entonces ya empiezo a recopilar las ventanas de los errores (u horrores). Ninguna era de Windows, todos eran avisos del propio programa. La mayoría de una librería de gestión de datos con SQL Server con mensajes genéricos del tipo: error de red general.
Le digo al contable que me pase el mapa de la red la empresa, que voy a ir revisando todos los puntos problemáticos… me mira con una cara de no saber de qué hablo. Para hacerlo corto, en el funcionamiento del programa del módulo que se ejecutaba en los AIOs intervenían:
- Un conocido programa de contabilidad español, vendido por una gran empresa
- Un módulo general de ERP de la misma empresa que la contabilidad
- Un servidor de hacía 15 años donde estaba instalado el programa de contabilidad y el ERP. Vendido por una empresa que ya no existía
- El SQL server de Microsoft instalado en el anterior servidor, pero con los datos en un NAS comercial vendido por los programadores de la primera ampliación del ERP.
- Un router y varios Switchs instalado por un electricista que ya no les trabajaba.
- Tres puntos de acceso de marca vendidos por la empresa que les estaba desarrollando el nuevo módulo del ERP
- El cableado y conexión de esos puntos de acceso a la red general que había hecho el electricista del pueblo.
- Nuestros AIOs.
- Un hardware específico conectado por USB al AIO que toma datos de las máquinas de la cadena de producción, comprado a una tercera empresa por los desarrolladores del módulo nuevo del ERP
Y con tantos candidatos, los culpables somos solo nosotros. Con las ventanas de error en mi poder inicio una pequeña búsqueda en la red. Encuentro que esas librerías de acceso a SQL tienen casi un cuarto de siglo. Y localizo en los foros de Microsoft (para no ir muy lejos) reportes de principios de siglo de problemas con aplicaciones de gestión son SQL Server y esas librerías que son idénticos a los que les pasan a ese cliente… y sin solución. Era divertido leer en el foro como indicaban que habían cambiado la tarjeta de red, los cables, los Switich, los routes… incluso instalado un PC nuevo y los errores seguían apareciendo de manera aleatoria. La respuesta de Microsoft era divertida, la culpa podía estar en cualquier sitio.
Al fina hice un refrito de las respuestas de Microsoft a ese error en esas librerías y he aplicado lo que yo puedo hacer en mi AIO. No tengo acceso al router, no tengo acceso a los puntos de red, no puedo ver el servidor, no puedo ver el código del programa… Con los cambios introducidos de momento llevamos una semana sin problemas, pero puede haber sido casualidad. Eso sí, le mostré al contable los logs del Wifi que Windows guarda de las últimas 72 horas en los momentos en que el programa fallaba. El wifi no se caía. Al final enseñé al trabajador a lanzar pings a Internet y cuando el programa mostraba error general de comunicaciones el AIO seguía enviando pings y recibiendo respuesta sin problemas. Incluso podían navegar por Internet. Creo que por lo menos tengo una buena coartada.
Ahora si alguien quiere hacer de detective y quiere decir quién cree que es el culpable, tenéis los comentarios para ello. Yo pienso que es una combinación de impericia de los programadores, junto con una saturación del viejo servidor que tarda en responder y no tienen una buena gestión de esas excepciones… pero no tengo medios para llegar a tener pruebas.
Yo apostaría a que el programa debe tener alguna conexión a SQL con un timeout que antes funcionaba siempre, y ahora algunas veces falla por no obtener la respuesta a tiempo, y no tienen bien controlada la gestión de esa excepción.
Habría que ver si el programa tiene en la configuración la posibilidad de crear algún log para ver exactamente dónde falla.
Me encanta cuando hablas de éstas historias (imagino que a tí, poca gracia 🙂 ).
Yo creo que, según el contable, la culpable es Miss Marple.
Con la cantidad de variables que tienes y con la poca accesibilidad a los equipos y programas… Madre mía! Prueba con la pitonisa Lola.
Disfruto con éstos relatos, Tendero.
Muchas gracias.
A mi según el día. Hay momentos en lo que me rio para mi mismo, ya que muchas veces te encuentras a gente de las grandes empresas que piensan que en un pueblo no hay conocimiento… pero me cabreo cuando nadie se pone a hacer el trabajo importante ni entiende que estos problemas son complejos y que se necesitas pensarlo muy bien antes de decir de quién es la culpa.
Como dicen arriba, un timeout demasiado corto podría ser parte del problema. Pero con acceso tan limitado al sistema… si consigues resolverlo te deberían nombrar Santo en el Vaticano. Porque vaya tela…
Hoy hemos podido centrar más el tema y veo el problema más en el servidor. El error aparece aleatoriamente, pero siempre cuando hacen una consolidación grande en el ERP. Es decir con operaciones simples contra el ERP nunca aparece. Pero de vez en cuando lanzan una actualización de grupos de datos de golpe al ERP y es cuando “aleatoriamente” se muestra el error general de red.