Bueno, vamos a detallarlo un poco más, a ver si me sale
Tenemos por un lado el almacén central y por otro las tiendas
Con este método, no hace falta que los 2 estén con el mismo motor, ya que los programas de recogida y envío de datos, pueden hacer las transformaciones (de hecho, éste es mi caso, las tiendas están en FB y la central está en As400)
Estructura:
Central:
Programa -> recepciona colas (archivos de envío y/o recepción) de entrada y prepara colas de salida
Tenemos una carpeta por tienda y, dentro de cada una 2 carpetas, In y Out. En la carpeta In, la tienda dipositará las colas de entrada (tiquets, cierres de caja,....) y de la carpeta Out recogerá las colas de salida (Artículos nuevos, cambios de precio,.....)
Tiendas:
Programa -> recoge las colas de bajada actualizando las tablas y envía los datos de ventas, cierres de caja,....
Tenemos una carpeta para guardar las colas de entrada (In) y otra donde se prepara la cola de envío (out)
Recordemos que los ficheros XML generados, serán comprimidos en un sólo archivo (en mi caso con las ZLib poniendole extensión ZLB)
Bien, dicho esto general, vamos a detallar.
Triggers:
Las tablas que queremos que "bajen/suban" de/a las tiendas, tienen triggers asociados que actualizan unas tablas temporales. Ejemplo: la tabla de artículos tiene un trigger asociado en el Insert, Update y Delete. Al dispararse el trigger (como sabemos la operación que se está realizando -> Insert, Update, Delete), creamos un registro nuevo en la tabla temporal con el código del artículo y todos sus datos MAS un campo que nos indicará la acción a realizar (1=Insert, 2=Update, 3=Delete). ¿Por qué se graban todos los datos? Más que nada es por eso de más vale prevenir que curar
y de paso porque de esta manera, no se necesitan hacer joins para generar los XML y el proceso es más rápido.
Programa Central:
Tiene 2 Timers, uno para recepciones y otro para envíos. Para nosotros, lo más crítico son las recepciones, por lo que tenemos un timer vajo (15min). Los envíos de datos nuevos, no son tan críticos, por lo que tenemos un timer más alto (1h). Por supuesto, estos timers son configurables y se puede "forzar" un envío/recepción de datos.
¿Qué hace el programa? Bien, como queremos que sea lo más configurable posible, tenemos una tabla donde indicamos los SQL ha lanzar, es decir, las tablas a "bajar" a las tiendas. Un ejemplo de registro de esta tabla sería:
select campo1, campo2,..., campoN from tabla where condiciones
De esta manera, si en algún momento necesitamos añadir una tabla nueva a la tienda, sólo hay que añadir un registro a esta tabla y listos!!! No hay que modificar el programa nada en el programa.
Bien, una vez lanzado el SQL sobre esta tabla, lo que hacemos es generar un XML con la estructura y los datos de cada un de los resultados de lanzar los SQL contenidos en la tabla (no voy a entrar en temas de programación, sólo la teoría). Estos XML los ponemos en un directorio y, luego, sólo hay que recorrer todos los ficheros de ese directorio para hacer la compresión (recomiendo la librería ZLib ya que comprime más que el WinZip y, al no ser un compresor estándar, quizás es más seguro ya que los datos se mueven por internet). También seria posible utilizar un pgp para encriptar si se quiere hacer aún más seguro el envío de datos ya que hay una versión que funciona en linea de comandos.
El archivo resultante de la compresión, es el que se copiará en las distintas carpetas Out de cada tienda y, se borrarán los datos de las tablas temporales. Esto del borrado puede hacerse de muchas formas, pero nosotros lo hacemos de la siguente manera. Lanzamos el SQL pertinente y, mediante un bucle while not Query.Eof vamos generando el XML y, por cada registro generado (satisfactóriamente), lanzamos un SQL de Delelte. ¿Por qué esto? Imaginemos que estamos generando el XML de los artículos nuevos. Lanzamos el SQL sobre ArtiTMP y generamos el SQL. Mientras se ejecuta el proceso de generación, pueden haber nuevas inserciones en el maestros de Artículos, por lo que se generaría un registro nuevo en ArtiTMP. Si borramos con un delete general después del proceso... ese artículo se perdería. (no obstante, con este método algo más seguro.. también hemos tenido algún que otro problemilla de falta de algún código en las tiendas
)
Esto por lo que hace al envío de información.
Respecto a la recepción, es bastante más sencillo. Se tendría que recorrer los diferentes subdirectorios In de los directorios de las tiendas. Leer todos los ficheros, descomprimir, abrir los XML (con un TClientDataSet) y actualizar la tabla pertinente (también teniendo en cuenta el Insert, Delete o Update de la manera anteriormente mencionada). Nosotros, por cuestiones de seguridad (y de no compatibilidad al 100% de las tablas de FB y As400) tenemos tablas intermedias.
Programa Tiendas:
Cada X minutos (configurable, of course), generará los ficheros XML pertinentes (al estilo de lo que realiza el proceso de la Central, no creo que sea necesario repetirlo
), se conectará por FTP al ordenador de la Central y, en su directorio In pondrá el ZLB generado y, de su directorio Out se descargará las colas que tenga pendientes, las que serán descomprimidas y actualizará las tablas pertienentes de cada XML
Estos procesos de envío/recepción pueden ser servicios de Windows para no tener una pantallita allí abierta continuamente.
Recomiendo los commits después de cada proceso de una tabla y el cierre de la conexión a la BD despues de terminar (hemos tenido algún que otro conflictillo).
Bueno, creo que no me dejo nada.
PD: se aceptan sugerencias