Sync - 1.0 - Manual de Usuario

Tabla de Contenidos

¿ Que es Napse Sync ?

Es una herramienta que permite replicar información de una base de datos MongoDB a otra base de datos MongoDB.
Dichas bases pueden encontrarse en diferentes servidores.
Adicionalmente, permite mantener en el servidor productivo transaccional un nivel de información controlado, sin acumular historia que eleva los costos y requiere de mayor nivel de recursos para funcionar.

¿ Cuales son sus beneficios ?

1. Ahorro de costos, ya que la información se puede guardar en medios de más bajo costo que los que usualmente se utilizan en servidores Cloud.
2. Acceso seguro con herramientas de reporting como Power BI o Tableau
3. Acceso desde otras soluciones con el fin de ejecutar procesos como conciliación o resguardo de información.

¿ Cómo sería un esquema tradicional de uso de Napse Sync ?

1. Replicar información transaccional de BRIDGE a MongoDB Atlas con el fin de, desde Power BI, construir informes a medida.
2. Replicar información generada por PROMO, en cuanto a movimientos de programas de fidelidad o cupones, para alimentar un CRM que realiza comunicación a los clientes.
3. Poder conectar otras soluciones propias de cada cliente, que utilicen la información para conciliar o cualquier otro proceso que resulte de utilidad al negocio.

¿ Cual es el público que podría utilizar Napse Sync ?

Los clientes que contratan nuestras soluciones en la nube, podrían querer tener la información en servidores propios y de ese modo, explotarla para armar reportes o participar de procesos internos.

Antes de comenzar: 

Instalar la solución, siguiendo el manual de instalación.

Primer paso: configuración de las cadenas de conexión a la base de datos.

Debemos configurar la base de datos origen, destino y el prefijo (opcional) con el que se crearán las colecciones en la base de datos destino.

Primero nos dirigimos al archivo de configuración, que se encuentra en el directorio de instalación de la solución, específicamente en la carpeta "config" y editamos el archivo config.json

{
  "app": {
    "db": {
      "source": "mongodb://admin:[email protected]:27017/bridgeOffline?authSource=admin",
      "destination": "mongodb://admin:[email protected]:27017/bridgeOfflineCopy?authSource=admin",
      "destinationPrefix": "bridge_"
    },
    "server": {
      "secret": "123888000",
      "port": 8080,
      "isSsl": false,
      "logMode": "debug",
      "cronEnabled": true,
      "version": "1.3.0"
    }
  }

Debemos configurar lo siguiente: 

1. source: es la base de datos Origen, por ejemplo, la base de datos de Bridge o Promo.
2. destination: es la base de datos en donde se copiará la información
3. destinationPrefix: es un prefijo que se le pondrá a las tablas que se creen en la base destino, por ejemplo, si copio la colección que en origen se llama TransactionRetail y le configuro como prefijo bridge_ , en destino, la colección se llamará "bridge_TransactionRetail"
4. port: es el puerto en donde ejecutará la solución.

El archivo entities.json

Este archivo, es clave para la solución, contiene las entidades que se replicarán y el modo de replicación (progresivo o reemplazo).

[
  {
    "entity": "TransactionRetail",
    "dateColumn": "businessDayDate",
    "mode": "progressive",
    "maxRecords": 1000,
	"idDataType": "ObjectId",
    "cron": "*/5 * * * *",
    "related": [
      {
        "entity": "TransactionRetailItem",
        "parent": "transactionObjectId",
        "child": "transactionObjectId"
      },
      {
        "entity": "TransactionRetailPayment",
        "parent": "transactionObjectId",
        "child": "transactionObjectId"
      },
      {
        "entity": "TransactionRetailDiscount",
        "parent": "transactionObjectId",
        "child": "transactionObjectId"
      }
    ]
  },
  {
    "entity": "Item",
    "dateColumn": "",
    "mode": "replace",
    "maxRecords": 20000,
    "cron": "0 0 * * *",
	"idDataType": "String",
  },
  {
    "entity": "Brand",
    "dateColumn": "",
    "mode": "replace",
    "maxRecords": 1000,
    "cron": "0 1 * * *",
	"idDataType": "Number",   
	},
  {
    "entity": "ItemInventoryJournalEntry",
    "dateColumn": "dateTimstamp",
    "mode": "progressive",
    "maxRecords": 1000,
    "cron": "*/2 * * * *",
	"idDataType": "Number",   
}
]

idDataType

Log con resultados

En la base de datos destino, existirá una nueva colección llamada SyncLog que contiene cada operación realizada, para poder realizar un seguimiento.

La estructura, es de la siguiente forma: 

1. entity: es la entidad que se replicó
2. records: son los registros replicados en la operación
3. result: es el resultado de la operación
4. destinationDeleted: indica si se borro primero la tabla destino
5. maxRecords: es la cantidad máxima configurada en el archivo entities.xml para replicar

Conciliación entre Origen y Destino

La solución puede conciliar la cantidad de registros por fecha, entre origen y destino, de cada entidad.
Para ello, en aquellas entidades que hayan sido marcadas para conciliar, arma un proceso que compara la cantidad de registros y los guarda en la colección SyncConciliation
Un ejemplo de registros en dicha tabla es: 

Sobre la performance

Las tablas transaccionales, suelen tener millones de registros, por eso debemos tener en cuenta las cantidades que manejamos ante cada operación de migración de datos.

1. Tener en cuenta la cantidad de registros generados por minuto, hora, día para que la operación tenga la flexibilidad de poder procesar un día operativo en un día de procesamiento.
2. Tener en cuenta si hay tablas relacionadas al momento de definir la cantidad.

Sobre los índices

Versiones posteriores 

1. La versión 1, permite pasar de una base con una única empresa a otra base, es decir, no se puede por ejemplo, tomar información de una base de PROMO multi empresa, esto se encontrará incluido en la próxima versión.
2. La versión 1, posee el log en tablas, en una versión posterior, esto se presentará por pantalla.
3. La versión 1, posee la conciliación en tablas, en una versión posterior, esto se presentará por pantalla.