Replication Engine Help

Niccoweb · Business Central

NCW Replication Engine · Guía de configuración· Configuration Guide

Configuración paso a paso de la replicación directa entre Business Central (BC a BC), desde la instalación hasta comprobar que un cambio llega al destino.Step-by-step configuration of direct Business Central to Business Central replication, from installation to a verified change arriving at the destination.

ProductoProduct SoporteSupport

Esta guía explica cómo configurar NCW Replication Engine para replicar datos directamente de una instalación de Business Central a otra por HTTP (BC a BC directa), desde la instalación hasta comprobar que un cambio incremental llega al destino.

Todos los pasos y capturas proceden de una ejecución real entre dos servidores de Business Central 29 on-premises, con la interfaz en español:

Papel	Servidor	Empresa
Origen	`bc29es`	CRONUS España S.A.
Destino	`bc29mx`	CRONUS Mexico S.A.

El ejemplo replica la tabla Cliente (18). Los pasos son los mismos para cualquier otra tabla.

Los valores de algunos campos de opción (Import, Export, NavUserPassword, Connected…) aparecen en inglés también con la interfaz en español.

1. Cómo funciona

 ORIGEN (bc29es)                                         DESTINO (bc29mx)
 ┌───────────────────────────────┐   HTTPS/HTTP POST    ┌───────────────────────────────┐
 │ Paquete CUST-ES-MX (Export)   │  ──────────────────▶ │ API nwr/replication/v1.0      │
 │  Detectar cambios → Bandeja   │   Basic auth, JSON   │  Lote entrante (Accepted)     │
 │  Enviar pendientes / export.  │                      │  Procesar pendientes → Cliente│
 │ Endpoint BC29MX               │                      │ Paquete CUST-ES-MX (Import)   │
 └───────────────────────────────┘                      └───────────────────────────────┘

Un paquete define qué se replica: tablas, campos, filtros y relaciones padre/hijo. El origen y el destino tienen cada uno un paquete con el mismo código. El destino solo escribe en las tablas configuradas en su propio paquete.
Un endpoint (solo en el origen) define a dónde se envía: la URL del destino, las credenciales y la empresa.
La exportación completa envía todos los registros de las tablas del paquete. La replicación incremental envía solo los registros insertados, modificados o eliminados desde la última ejecución, que se detectan mediante la bandeja de salida.
El destino guarda lo que recibe como lote entrante y lo importa de forma asíncrona, con Procesar pendientes o desde la cola de proyectos.

2. Requisitos previos

2.1 Instalar la app en los dos servidores

Instale NCW Replication Engine en el origen y en el destino, con la release que corresponda a la versión de Business Central de cada servidor. Cada release incluye el .app normal y un .runtime.app para on-premises:

Publish-NAVApp -ServerInstance BC -Path '.\niccoweb_NCW Replication Engine_29.0.3.runtime.app' -SkipVerification
Sync-NAVApp    -ServerInstance BC -Name 'NCW Replication Engine' -Version 29.0.3.x
Install-NAVApp -ServerInstance BC -Name 'NCW Replication Engine' -Version 29.0.3.x

Use la misma versión, o posterior, en el origen y en el destino. Desde la 29.0.3 / 28.0.3 / 14.0.3 los valores viajan en un formato independiente del idioma y de la configuración regional de cada usuario (sección 10).

2.2 Usuarios y permisos

Asigne el conjunto de permisos NCW REPLICATION a los usuarios que configuran o ejecutan la replicación.
En el destino, cree o reutilice un usuario con el que se autenticará el origen. Necesita el conjunto NCW REPLICATION y permisos de escritura en las tablas de negocio replicadas. La prueba se hizo con autenticación NavUserPassword.
Opcional: cambie al perfil Administrador de replicación NCW (Mi configuración → Rol). Tendrá un área de trabajo con las pilas de actividad de BC a BC directa.

2.3 La API del destino debe estar accesible

El origen llama a la página de API nwr/replication/v1.0 del destino:

http://<servidor-destino>:7048/<instancia>/api/nwr/replication/v1.0

Los servicios de API deben estar habilitados en el servidor de destino (ApiServicesEnabled = true; puerto 7048 por defecto).
Use HTTPS en producción. Con autenticación Basic sobre HTTP las credenciales viajan sin cifrar.

Comprobación rápida desde el servidor de origen:

Invoke-RestMethod 'http://bc29mx:7048/BC/api/nwr/replication/v1.0/companies' -Credential (Get-Credential)

2.4 Permitir la IP privada del destino (anti-SSRF, BC 26.11 / 27.2 / 28.0 y posteriores)

Importante. Las versiones recientes de Business Central bloquean las llamadas HttpClient desde AL a direcciones privadas o de loopback (10.x, 172.16–31.x, 192.168.x, 127.x). Dos servidores on-premises de la misma red se comunican con direcciones privadas, así que sin este paso Probar conexión falla con "Endpoint unreachable: … the connecting endpoint violates security requirements …".

En el servidor de origen, permita la IP del destino y reinicie el servicio:

Set-NAVServerConfiguration -ServerInstance BC -KeyName NavHttpClientAntiSSRFAllowedAddresses -KeyValue '["172.28.69.211"]'
Restart-NAVServerInstance  -ServerInstance BC

El valor es una matriz JSON de direcciones IP concretas; no admite rangos, así que use una IP fija para el destino.
Si la replicación es en los dos sentidos, configure cada servidor con la IP del otro.
NavHttpClientAntiSSRFEnabled = false desactiva la protección por completo. No se recomienda.
En Business Central online esta protección no se puede cambiar: el destino debe ser accesible por una dirección pública.
El registro de eventos del servidor muestra la causa: SSRF violation detected: non routable network address.

2.5 Configuración de replicación

Configuración de replicación NCW contiene los ajustes por empresa. Tipo de autenticación de la API local es informativo y lo rellena la app (desde 29.0.14 / 14.0.14 no se puede editar): indica a otros servidores cómo autenticarse en este, OAuth2 en Business Central online y NavUserPassword on-premises, y las definiciones de paquete exportadas lo incluyen. La autenticación real la decide Business Central; si un servidor on-premises usa otra, cambie el endpoint que apunta a él. Los lotes con error los reintentan los propios trabajos de replicación (vea Reintentos en la sección de programación).

Configurar ruta de replicación (desde 29.0.27 / 14.0.27, en el Role Center y en la búsqueda) configura una ruta desde el origen en cuatro pasos: el servidor de destino (un endpoint existente, o la dirección de su API, el usuario y la contraseña, probando la conexión), la empresa de destino (elegida de la lista del servidor), el paquete (código, descripción, los números de tabla y si envían las dos empresas) y qué hacer al final: preparar el paquete receptor en el destino a través de su API (el destino necesita 29.0.27 / 14.0.27 o posterior; un paquete que ya exista allí nunca se sustituye), programar el envío cada 5 minutos y, en un paquete en el que envían las dos, partir de los datos actuales. Las relaciones entre tablas, los filtros y las notificaciones se añaden después en la ficha del paquete, y en el destino se establece el secreto del endpoint que apunta de vuelta al origen.

Limpieza (desde 29.0.24 / 14.0.24): una vez al día los trabajos de replicación vacían el contenido de los lotes terminados (Completed, Acknowledged, DeadLetter) y borran los cambios ya enviados pasados los Días de conservación del contenido de lotes (0 = 30), y borran los movimientos del registro y los errores de replicación pasados los Días de conservación del registro (0 = 90). Los lotes en sí, los lotes con error o en espera y el seguimiento de cambios no se tocan nunca. Limpiar ahora lo hace en el momento.

3. Destino: crear el paquete receptor

En el destino (bc29mx), abra Paquetes de replicación y elija Nuevo:

Campo	Valor	Notas
Código	`CUST-ES-MX`	Debe ser idéntico al código del paquete de origen.
Descripción	Customers from CRONUS España	Texto libre.
Habilitado	Activado
Dirección	`Import`

En la sección Tablas, añada una línea con Id. tabla 18. Nombre tabla se rellena con Customer.

Al añadir una tabla, sus campos se generan automáticamente: se incluyen todos y la clave principal siempre queda incluida. Use Campos para excluir campos o marcar Validar campo, que ejecuta la validación del campo al importar. Include All Fields en la línea de la tabla lo hace para todos a la vez (desde 29.0.22 / 14.0.22): desactivado, solo queda la clave principal, para marcar los pocos campos que se quieren replicar; activado, vuelven a incluirse todos (excepto los FlowFields y los obsoletos). Sigue a la lista de campos: desmarcar un campo lo desactiva, e incluirlos todos lo activa. La Estrategia de importación de la línea controla cuánta lógica de negocio se ejecuta al importar (consulte 3.1).

Las tablas que vengan en la carga del origen pero no estén en este paquete se ignoran. El destino nunca escribe en una tabla que no se haya configurado expresamente para aceptarla.

Rellene en el paquete receptor Endpoint origen (un endpoint de este servidor que apunte al origen) y Empresa origen. Con ellos, el destino avisa al origen de cómo ha terminado cada lote en cuanto lo importa (sección 7.1). Sin ellos, el origen se entera igualmente en su siguiente ejecución programada.

Más rápido: créelo a partir de la definición del emisor (29.0.9 / 28.0.9 / 14.0.9). Cuando ya exista el paquete emisor (sección 5), elija Exportar definición en él y Importar definición → Como paquete receptor en la lista de paquetes del destino. Consulte 3.2.

3.1 Estrategia de importación

La Estrategia de importación de cada línea de tabla decide cómo se escriben los registros recibidos de esa tabla. Solo se aplica al importar.

Estrategia	Qué pasa con un registro recibido	Cuándo usarla
`Direct`	Se copian los valores tal cual. No se ejecuta el `OnValidate` de los campos ni los triggers `OnInsert`/`OnModify`/`OnDelete` de la tabla.	La opción normal. Es la más rápida y el destino queda exactamente igual que el origen.
`Validate`	Se ejecutan los triggers de la tabla al insertar, modificar y borrar. Los campos marcados con Validar campo (en Campos) ejecutan además su `OnValidate`; el resto se copia tal cual. Los campos de la clave principal nunca se validan.	Cuando el destino debe ejecutar su propia lógica de negocio, por ejemplo para recalcular importes o rellenar campos dependientes. Los valores pueden acabar distintos del origen, la importación es más lenta y falla si falta algo que esa lógica necesita.
`Handler`	El motor no escribe nada. El evento `OnBeforeReplicationRecordApply` permite que una extensión propia escriba el registro y marque `IsHandled`. Si ningún suscriptor lo gestiona, el registro falla.	Casos especiales que necesitan código: transformar valores, convertir códigos que difieren entre empresas o escribir en otra tabla.
`ReadOnly`	La tabla se ignora al importar: no se inserta, modifica ni borra nada.	Tablas que este lado envía pero no debe recibir, por ejemplo en un paquete Bidirectional en el que una empresa es la dueña de una tabla. También sirve para pausar la entrada de una tabla sin quitarla del paquete.

Para documentos como Cab. venta y Líneas venta use Direct. Validar campos de las líneas (N.º, Cantidad, Precio venta…) hace que Business Central recalcule precios, descuentos, IVA, dimensiones o reservas, y la línea puede quedar distinta del origen o fallar.

3.2 Copiar un paquete entre servidores: Exportar e Importar definición

En lugar de volver a crear a mano el paquete receptor, cópielo del emisor:

En el origen, abra el paquete emisor y elija Exportar definición. Se descarga un fichero <código>.ncwpackage.json. Contiene las tablas, los campos incluidos, Validar campo, las relaciones, los filtros (con Al salir del filtro) y los límites de lote y de reintento. También contiene la dirección de la API del origen, su empresa y su tipo de autenticación. Nunca contiene contraseñas ni secretos.
En el destino, abra Paquetes de replicación y elija Importar definición, y después el modo:
- Como paquete receptor (espejo del remitente): el mismo código con la dirección invertida (Export ↔ Import; Bidirectional se mantiene). La estrategia de importación es Direct. Endpoint origen y Empresa origen apuntan de vuelta al emisor: se reutiliza un endpoint existente con la misma URL de API o, si no hay ninguno, se crea uno con el nombre del host del emisor.
- Como copia idéntica: el paquete tal cual, para preparar otra instalación emisora (por ejemplo, de pruebas a producción). Los endpoints solo se mantienen si existe uno con el mismo código.
Si el paquete ya existe, se pregunta si se sustituye. Se vuelven a crear sus tablas, campos, relaciones, filtros y seguimiento de cambios.
Si se ha creado un endpoint nuevo, establezca su secreto de autenticación y ejecute Probar conexión.

Desde 29.0.15 / 14.0.15 se respeta la Dirección. Un paquete Import nunca envía: Programar..., Enviar cambios pendientes y Enviar exportación completa lo rechazan, y una entrada de la cola de proyectos creada antes para él no hace nada. Un paquete Export rechaza los lotes que le llegan. Use Bidirectional solo cuando las dos empresas deban enviarse cambios entre sí (vea a continuación).

Paquetes bidireccionales

Un paquete Bidirectional envía los cambios de esta empresa e importa los de la otra, con el mismo código de paquete en los dos lados: créelo en una empresa e importe su definición en la otra Como paquete receptor. Casos típicos son datos maestros que se mantienen en las dos empresas (clientes o productos que se crean en cualquiera de ellas), o tablas con distinto dueño en un mismo paquete, con la estrategia de importación ReadOnly en el lado que no debe recibir una tabla.

Desde 29.0.16 / 14.0.16:

Sin eco. Lo que una empresa recibe queda como ya replicado, así que no se devuelve.
Conflictos. Cada cambio lleva cómo era la copia del emisor antes del cambio. Si la copia receptora ya no es así, las dos empresas han cambiado el registro: Ganador de conflictos en el paquete decide qué versión se queda (Cambio recibido o Esta empresa), y el conflicto se anota en Errores de replicación (Conflicto: …). Las dos empresas necesitan valores opuestos: al hacer un paquete Bidirectional se pone Esta empresa, y su espejo recibe Cambio recibido. Mientras los dos lados tengan el mismo valor, el envío se rechaza. Las tablas con la estrategia Handler quedan en manos de su suscriptor.
Punto de partida. El primer envío de un paquete Bidirectional manda todos los registros que cubre. En la empresa que importó la definición suelen ser sus propios datos, así que Programar... y Enviar cambios pendientes ofrecen antes tomar los datos actuales como punto de partida; Tomar los datos actuales como punto de partida en el paquete lo hace en cualquier momento. Solo se envían los cambios posteriores.

Los registros que las dos empresas ya tenían antes de replicar, con la misma clave y valores distintos, cuentan como conflicto la primera vez que cambian, y decide el ganador de conflictos.

Las tablas que no existan en el destino detienen la importación indicando cuáles son. Los campos que no existan allí se omiten y se cuentan en el mensaje final.

4. Origen: crear el endpoint

En el origen (bc29es), abra Endpoints de replicación y elija Nuevo:

Campo	Valor (prueba)
Código	`BC29MX`
Descripción	CRONUS Mexico on bc29mx
Habilitado	Activado
Tipo de entorno	`OnPrem`
Dirección del servidor / Instancia del servidor / Tenant	`bc29mx` / `BC` / `default`
URL HTTP	`http://bc29mx:7048/BC/api/nwr/replication/v1.0`
Tipo de autenticación	`NavUserPassword`
Usuario HTTP	Usuario del destino (sección 2.2)

4.1 Establecer la contraseña

Elija Acciones → Establecer/cambiar secreto de autenticación e introduzca la contraseña del usuario de destino. El valor se enmascara y nunca se puede volver a ver, solo sustituir.

Secreto de autenticación pasa a mostrar Configurado. Si pone Configurado (sin cifrar…), el secreto está guardado pero el cifrado de la base de datos no está habilitado en este servidor. Habilítelo (Administración de cifrado de datos) para cifrar los secretos. Los secretos cifrados admiten como máximo 215 caracteres.

4.2 Probar la conexión

Elija Acciones → Probar conexión. Estado de la conexión debe mostrar Connected. Si falla, Último error indica el motivo: consulte Solución de problemas.

Desde 29.0.7 / 28.0.7 / 14.0.7, Probar conexión también pregunta al destino si puede importar lo que recibe. Si NCW Replication Engine no tiene licencia allí, el estado sigue en Connected y Último error indica "Conectado, pero el destino no puede importar: …".

4.3 Seleccionar la empresa de destino

En la sección Empresas, use la búsqueda … de Código empresa. La lista se lee en directo de la API del destino. Seleccione la empresa y elija Aceptar.

4.4 Tipos de autenticación

El Tipo de autenticación debe coincidir con cómo autentica el servidor de destino las llamadas a servicios web (ClientServicesCredentialType de su instancia de servicio).

Tipo	Qué se envía	Destino
`NavUserPassword`	HTTP Basic con Usuario HTTP y el secreto	Business Central on-premises con credenciales `NavUserPassword`. El secreto puede ser la contraseña del usuario o, mejor, su clave de acceso a servicios web. Use un usuario de integración dedicado con el conjunto de permisos NCW REPLICATION.
`UserName`	HTTP Basic con Usuario HTTP y el secreto	Servidores on-premises configurados con credenciales `UserName` (usuario y contraseña de Windows). Es poco habitual.
`OAuth2 (Microsoft Entra ID)`	Un token Bearer de Microsoft Entra ID (client credentials)	Business Central online, que no admite otra cosa, o servidores on-premises que usan Entra ID. Consulte 4.5.

Business Central on-premises sigue admitiendo NavUserPassword con clave de acceso a servicios web. Business Central online dejó de admitirlo en octubre de 2022.

4.5 Business Central online (OAuth2)

En Azure portal → Microsoft Entra ID → Registros de aplicaciones, registre una aplicación y cree un secreto de cliente (Certificados y secretos). Anote el Id. de aplicación (cliente) y el Id. de directorio (inquilino).
En Permisos de API, añada Dynamics 365 Business Central → Permisos de aplicación → API.ReadWrite.All y elija Conceder consentimiento de administrador.
En el Business Central online de destino, abra Aplicaciones de Microsoft Entra, añada el id. de cliente, póngalo en estado Habilitado, asígnele el conjunto de permisos NCW REPLICATION y permisos de escritura en las tablas replicadas, y elija Conceder consentimiento.
En el endpoint del origen:

Campo	Valor
URL HTTP	`https://api.businesscentral.dynamics.com/v2.0/<inquilino>/<entorno>/api/nwr/replication/v1.0`
Tipo de autenticación	`OAuth2 (Microsoft Entra ID)`
Id. de inquilino OAuth	Id. del inquilino (GUID) o dominio, por ejemplo `contoso.onmicrosoft.com`
Id. de cliente OAuth	Id. de aplicación (cliente) del paso 1
Ámbito OAuth	Mantenga `https://api.businesscentral.dynamics.com/.default`

Elija Establecer/cambiar secreto de autenticación e introduzca el secreto de cliente. Usuario HTTP no se usa.
Elija Probar conexión. Siempre pide un token nuevo; si Entra ID lo rechaza, Último error muestra el motivo que da Entra (por ejemplo, un secreto incorrecto o falta de consentimiento).

El motor pide el token por su cuenta antes de enviar y lo renueva poco antes de que caduque. Los tokens solo se guardan en memoria, nunca en la base de datos. Los secretos de cliente caducan (como máximo a los 24 meses), así que renueve el secreto en Entra ID y en el endpoint antes de esa fecha.

5. Origen: crear el paquete emisor

En el origen, abra Paquetes de replicación y elija Nuevo:

Campo	Valor
Código	`CUST-ES-MX` (el mismo que en el destino)
Descripción	Customers to CRONUS Mexico
Habilitado	Activado
Dirección	`Export`
Endpoint destino	`BC29MX`
Empresa destino	`CRONUS Mexico S.A.` (solo se aceptan las empresas añadidas en el endpoint)
Formato de exportación	`Json`

El Formato de exportación solo decide cómo exporta este servidor una exportación completa. Los cambios se envían siempre en JSON y, desde 29.0.13 / 14.0.13, quien recibe lee la exportación completa en el formato en que llegue, así que origen y destino no necesitan el mismo ajuste.

Añada Id. tabla 18 en Tablas, igual que en el destino.

Ajustes opcionales:

División en lotes: máximo de documentos, registros o tamaño por lote. 0 significa sin límite.
Reintentar: número de reintentos y espera para los envíos con error.
Relaciones / Filtros en una línea de tabla: anidamiento padre/hijo (por ejemplo Cab. venta → Líneas venta) y filtros por campo.

Replicar solo algunos registros (filtros)

Para replicar solo los registros que cumplen una condición, por ejemplo un campo booleano Replicar a Sí, seleccione la línea de tabla, elija Filtros y añada el campo con su valor de filtro (por ejemplo Sí, <>'' o 10000..20000). Filtro habilitado en la línea se activa solo con el primer filtro y se desactiva al borrar el último (desde 29.0.23 / 14.0.23; antes había que activarlo a mano, y sin él los filtros se ignoraban). Desactívelo a mano para pausar los filtros sin borrarlos. Los filtros se aplican a la exportación completa y a los cambios incrementales. Una tabla hija solo replica las líneas de registros padre que cumplen los filtros del padre.

Al salir del filtro decide qué ocurre con un registro ya enviado al destino que deja de cumplir los filtros:

Dejar de replicar (por defecto): deja de enviarse y el destino conserva su copia tal cual. Si vuelve a cumplir los filtros, solo se envía si ha cambiado entretanto.
Eliminar en destino: se envía un Delete, de modo que el destino solo tiene los registros que cumplen los filtros en cada momento. Si vuelve a cumplir los filtros, se envía como registro nuevo.

6. Carga inicial (exportación completa)

En el paquete de origen elija Acciones → Enviar exportación completa (HTTP). Se envían todos los registros de las tablas del paquete en un lote.

En el destino, abra Lotes entrantes de replicación. El lote llega con estado Accepted, con su número de registros y su suma de comprobación SHA-256. Elija Acciones → Procesar pendientes para importarlo. El estado pasa a Completed.

Un lote recibido que no se debe importar (Accepted, Failed o DeadLetter) se puede quitar con Acciones → Eliminar (desde 29.0.15 / 14.0.15). No se avisa al origen; su lote conserva el último estado.

En la prueba se recibieron, procesaron e importaron 68 clientes sin errores.

7. Replicación incremental (solo cambios)

Después de la carga inicial, solo hace falta enviar los cambios.

Los usuarios modifican los datos en el origen de forma normal. En la prueba se cambió el nombre del cliente 01121212.

Cliente modificado
En el paquete de origen elija Acciones → Detectar cambios.
- La primera ejecución sobre una tabla guarda una línea base y no crea entradas.
- Las siguientes crean una entrada en la bandeja de salida por cada registro insertado, modificado o eliminado.
- Si se ejecuta otra vez sin cambios en los datos, no crea nada.
Bandeja de salida
Elija Acciones → Enviar cambios pendientes (HTTP). Ejecuta Detectar cambios y envía todo lo pendiente, en tantos lotes como requieran los límites de troceo. El envío programado (sección 8) hace exactamente lo mismo.
- El paso 2 solo hace falta para revisar la bandeja de salida antes de enviar.
- Si no hay nada pendiente, indica "No hay cambios que enviar" y no envía nada.
- Primero pregunta al destino si puede importar. No se envía nada, y los cambios siguen pendientes, si la app no tiene licencia allí, si el destino no tiene un paquete con el mismo código o si su paquete no importa ninguna de las tablas de este. Desde 29.0.12 / 14.0.12 la comprobación del paquete necesita esa versión en origen y destino; a un destino anterior solo se le pregunta por la licencia.
- Las tablas de este paquete que el paquete del destino no incluye se omiten allí (el destino decide qué acepta). El mensaje tras el envío las indica.
- Si hay muchísimo pendiente (miles de documentos), mejor el envío programado que esperar en la página.
- Hasta 29.0.11 / 14.0.11 esta acción se llamaba Enviar todos los lotes pendientes (HTTP). Enviar lote (HTTP), que enviaba solo el siguiente lote de los cambios pendientes, y Procesar bandeja de salida, que los descargaba como fichero, se quitaron en 29.0.12 / 14.0.12.
Enviar lotes pendientes

Lotes
En el destino, Procesar pendientes importa el nuevo lote.

Cambio procesado

7.1 ¿Ha llegado el lote y se ha importado?

El origen lo sabe en dos pasos, porque en el destino recibir e importar son cosas distintas.

Momento	Estado del lote en el origen	Significado
Al enviar	Sent	El destino recibió el lote, comprobó su suma de control y lo guardó. Aún no está importado.
	Failed / Corrupted	No se pudo entregar (destino caído, credenciales, anti-SSRF…) o la suma de control no coincidía. Último error indica el motivo; se aplica el reintento automático.
Cuando el destino lo importa	Completed	Importado entero.
	Partial / Failed / DeadLetter	Fallaron algunos o todos los registros. Último error muestra el error del destino.
Aún pendiente	Accepted / Processing	Recibido, todavía sin importar. Si el destino no puede importar (app sin licencia), Último error lo indica.

Cómo recibe el origen el resultado de la importación:

Al momento (29.0.8 / 28.0.8 / 14.0.8): cuando el destino termina un lote avisa al origen, usando el Endpoint origen y la Empresa origen de su paquete receptor.
En cada ejecución programada del paquete (29.0.6 / 28.0.6 / 14.0.6): después de enviar, el origen pregunta al destino por todos sus lotes que siguen en Sent, Accepted o Processing. Es la vía de respaldo cuando el aviso no ha podido hacerse.
A petición: Actualizar estado remoto en la ficha de un lote, o en la lista de Lotes para todos los pendientes a la vez.

8. Automatizar con la cola de proyectos

Origen. En el paquete, elija Acciones → Programar.... Crea (o abre, si ya existe) una entrada de la cola de proyectos estándar que ejecuta el codeunit 73712294 NCW Repl. Outbound Processing con Cadena de parámetros = código del paquete. Cada ejecución hace Detectar cambios y después envía los cambios pendientes de ese paquete, como Enviar cambios pendientes (HTTP), de modo que la replicación incremental funciona sin intervención. Desde 29.0.14 / 14.0.14 la entrada se crea ya programada, cada 5 minutos todos los días; para cambiar el intervalo use Poner en espera en su ficha, modifíquela y Establecer estado en Preparado. Una entrada creada por una versión anterior que no es recurrente (nunca se ejecuta) se sustituye. Con la cadena de parámetros en blanco se procesan todos los paquetes habilitados.

Además, cada ejecución:

Comprueba que el destino puede importar (29.0.7 / 28.0.7 / 14.0.7). Si la app no tiene licencia allí, no se envía nada. La ejecución queda registrada como aviso en el Registro del paquete y termina sin error, para que la entrada periódica siga ejecutándose. La primera ejecución después de licenciar el destino envía todo lo pendiente.
Actualiza el estado de los lotes anteriores (29.0.6 / 28.0.6 / 14.0.6), como se explica en la sección 7.1.

Para enviar los mismos datos a varios destinos, o a horas distintas, cree un paquete por destino y programe cada uno por separado.

Las versiones anteriores a la 29.0.1 / 28.0.1 / 14.0.1 solo enviaban lo que ya estaba pendiente en la bandeja de salida. En esas versiones, ejecute Detectar cambios antes de cada envío programado.

Destino. En Lotes entrantes de replicación, elija Acciones → Programar procesamiento.... Crea (o abre) la entrada de la cola de proyectos que ejecuta el codeunit 73712289 NCW Repl. Inbound Processing, que importa todos los lotes entrantes pendientes. Desde 29.0.14 / 14.0.14 se crea ya programada, cada 5 minutos, como la del origen. Sin ella, los lotes recibidos esperan en Accepted hasta que alguien use Procesar pendientes. Desde 29.0.17 / 14.0.17, cuando llega un lote y la empresa no tiene ninguna entrada de este tipo, se crea automáticamente y se anota en Movimientos del registro de replicación. Se ejecuta con el usuario con el que se conecta el origen; cambie Id. usuario en la entrada si es necesario. Una entrada que ya existe, aunque esté en espera, no se toca.

El acceso Replicaciones programadas (cola de proyectos) del área de trabajo muestra los dos tipos de entradas.

Leer solo lo que ha cambiado (BC29, desde 29.0.27): el envío programado compara solo los registros escritos desde la penúltima ejecución (su SystemRowVersion), en vez de todos los registros de todas las tablas. Cada tabla se sigue leyendo entera como mucho cada hora, que es cuando se detectan los borrados, siempre que ella o una tabla padre tenga filtros, y en sus primeras ejecuciones. Detectar cambios a mano sigue haciendo la lectura completa. En BC14 cada ejecución lee las tablas enteras.

Reintentos. Desde 29.0.19 / 14.0.19 las dos entradas reintentan los lotes con error de su lado, siempre y en orden: en el origen, el envío programado reintenta los lotes Failed o Corrupted del paquete antes de enviar nada nuevo, y en el destino, el procesamiento de entrada (y Procesar pendientes) reintenta los lotes Failed y Partial antes de importar los posteriores. Mientras un lote anterior se sigue reintentando, los posteriores esperan, así que los lotes nunca llegan ni se importan desordenados. El número máximo de reintentos (0 = 5) y el retraso de reintento (segundos, que se duplican tras cada intento; 0 = en cada ejecución) de cada paquete marcan el ritmo; un lote que agota sus reintentos pasa a DeadLetter, se notifica y deja de retener a los demás. Reintentar en un lote hace lo mismo a mano, y Descartar (desde 29.0.21 / 14.0.21) pasa a DeadLetter un lote Failed o Corrupted que nunca va a pasar, para que se envíen los posteriores; sus cambios no llegan, así que use en él Reenviar registros (desde 29.0.26 / 14.0.26), que vuelve a poner sus registros en cola con sus valores actuales para el siguiente envío, o Enviar exportación completa. Un reintento envía el contenido guardado del lote completo (antes de 29.0.21 / 14.0.21 solo su primera línea, que el destino rechazaba como CHECKSUM_MISMATCH). La opción Reintento automático y su entrada de la cola de proyectos de versiones anteriores desaparecen; al actualizar se borra la entrada.

Las entradas siguen funcionando solas (desde 29.0.11 / 14.0.11). Business Central detiene para siempre una entrada periódica cuando una ejecución termina con error. Para evitarlo:

Un proyecto de replicación nunca falla porque la app no tenga licencia: la ejecución no hace nada, anota un aviso en Movimientos del registro de replicación (una vez al día) y la primera ejecución con la licencia activa hace el trabajo.
Una ejecución que termina con error la vuelve a lanzar la cola de proyectos cada 5 minutos, durante días (desde 29.0.21 / 14.0.21; antes, 3 intentos con 60 segundos entre ellos y después la entrada se paraba). Al actualizar se aplica a las entradas existentes.
Las ejecuciones con error se avisan por correo, una vez al día por paquete, a los destinatarios del paquete (Ejecuciones del proyecto de replicación han terminado con error). El aviso sale al inicio de la siguiente ejecución, así que llega aunque el trabajo siga fallando.
Cada ejecución de un proyecto de replicación, y Procesar pendientes, reinicia las entradas de replicación que se hayan quedado en Error y anota un aviso en Movimientos del registro de replicación. También las creadas a mano.

8.1 Notificaciones por correo

Desde 29.0.10 / 28.0.10 / 14.0.10 cada paquete puede avisar por correo de cómo ha terminado la replicación en este servidor, usando el correo de Business Central. Por defecto no se envía nada.

Requisitos

BC28 / BC29: una cuenta de correo en Cuentas de correo electrónico (SMTP, Microsoft 365…). Para usar una concreta con estos correos, asígnela al escenario NCW Replication en Escenarios de correo electrónico; si no, se usa la cuenta predeterminada. Business Central envía los correos encolados con el programador de tareas del servidor, así que EnableTaskScheduler debe ser true en la instancia de servicio (lo es por defecto).
BC14: Configuración de correo SMTP con el servidor y el remitente (Enviar como o Id. de usuario).

Configuración. En la ficha del paquete, sección Notificaciones:

Campo	Significado
Notificar	`Ninguno` (por defecto), `Fallos` o `Fallos y éxitos`.
Destinatarios de las notificaciones	Direcciones separadas por `;`. Cada una se comprueba al escribirla.
Modo de notificación de éxitos	`Resumen diario` (por defecto): un correo al día con los lotes completados desde el último. `Cada lote`: un correo por cada lote completado. Los fallos se envían siempre al momento.
Correo de Business Central	Indica si Business Central tiene una cuenta disponible (Configurado / No configurado).

Use Acciones → Enviar correo de prueba para comprobar toda la cadena.

Qué se notifica. Cada instalación avisa de lo que ocurre en su lado, según su propia copia del paquete, de modo que origen y destino pueden avisar a personas distintas:

Lado	Evento	Tipo
Origen	Un lote no se ha podido entregar (Failed, Corrupted)	Fallo
Origen	El destino informa de un lote Partial, Failed o DeadLetter	Fallo
Origen	El destino informa de un lote Completed	Éxito
Origen	Una ejecución programada no ha enviado porque el destino no puede importar (una vez al día)	Fallo
Destino	Un lote recibido termina Partial, Failed o DeadLetter	Fallo
Destino	Un lote recibido se importa (Completed)	Éxito

El resumen diario lo envía la primera ejecución programada (origen) o de procesamiento de entrada (destino) de cada día. Cada correo indica la empresa y el servidor, el paquete, el lote con su estado y sus cifras, y el error si lo hay. Nunca incluye datos de los registros.

Nunca afecta a la replicación. Si no hay cuenta de correo disponible o el mensaje se rechaza, la replicación sigue y el problema se anota en Errores de replicación (etapa Notification), como máximo una vez al día por paquete. Un lote se notifica una sola vez por resultado: volver a comprobar el mismo estado no reenvía el correo.

9. Supervisión

Dónde	Qué muestra
Pilas del área de trabajo	BC a BC directa: pendientes de exportar, de transferir y de importar, e importaciones con error
Paquete → Bandeja de salida	Cambios detectados y si ya se han procesado
Paquete → Lotes (origen)	Lotes salientes: destino, estado (Sent → Completed / Partial / Failed, ver 7.1), número de documentos, último error
Lotes entrantes de replicación (destino)	Lotes recibidos: estado (Accepted → Completed / Partial / Failed), recuentos, mensaje de error
Paquete → Errores / Errores de replicación	Errores de importación o envío por registro
Endpoint → Estado de la conexión	Última comprobación, última conexión correcta, último error

10. Solución de problemas

Empiece por Comprobar ruta en el paquete (desde 29.0.24 / 14.0.24). Revisa la licencia, las tablas, la conexión y el paquete en el destino, las entradas de la cola de proyectos y los lotes que han fallado o esperan, en el lado donde se ejecuta, e indica en cada línea qué hacer. Ejecútela en el origen y en el destino.

Síntoma	Causa	Solución
Probar conexión — Último error: `Endpoint unreachable: … the connecting endpoint violates security requirements …`	El anti-SSRF bloquea la IP privada del destino (BC 26.11/27.2/28+). El registro de eventos del servidor muestra `SSRF violation detected: non routable network address`.	Añada la IP a `NavHttpClientAntiSSRFAllowedAddresses` y reinicie el servicio (sección 2.4).
Probar conexión — Último error: `Endpoint unreachable: There was an error while executing the HTTP request …`	El nombre DNS no se resuelve, cortafuegos, puerto o URL incorrectos, o servicios de API deshabilitados	Pruebe la URL desde el servidor de origen con `Invoke-RestMethod` (sección 2.3).
Probar conexión — Último error: `Endpoint unreachable.` sin más texto	Versión anterior a la 29.0.2 / 28.0.2 / 14.0.2, que no guardaba el motivo	Revise el registro de eventos del servidor o actualice.
`401 Unauthorized.`	Usuario o contraseña incorrectos, o tipo de autenticación incorrecto	Vuelva a usar Establecer/cambiar secreto de autenticación y revise el usuario del destino.
Empresa destino rechazada	La empresa no está en la lista Empresas del endpoint	Añádala antes en el endpoint (sección 4.3).
Lote enviado pero sin datos en el destino	El lote sigue en Accepted	Ejecute Procesar pendientes, o Programar procesamiento... en la lista de lotes entrantes.
Una entrada de la cola de proyectos de replicación está en Error	Una ejecución falló, por ejemplo antes de activar la licencia (versiones anteriores a 29.0.11 / 14.0.11)	Elija Reiniciar en la entrada. Desde 29.0.11 / 14.0.11 la reinicia el siguiente proyecto de replicación o Procesar pendientes.
"No se ha enviado nada del paquete …: NCW Replication Engine no tiene licencia en la empresa …"	La app no tiene licencia en el destino	Licénciela allí. Los cambios siguen pendientes y se envían en la siguiente ejecución.
"No hay cambios que enviar en el paquete …"	No ha cambiado nada desde el último envío	No hay que hacer nada. Si esperaba un cambio, revise las tablas y los filtros del paquete.
No llegan correos de notificación	El Correo de Business Central del paquete dice No configurado, faltan destinatarios o el programador de tareas del servidor está desactivado	Configure una cuenta de correo (o la configuración SMTP en BC14), revise los destinatarios, use Enviar correo de prueba y mire Bandeja de salida de correo / Correos enviados en Business Central. Mire en Errores de replicación si hay No se ha enviado el correo de notificación.
El paquete … no está configurado en la empresa … del destino	Falta el paquete de recepción en el destino (sus lotes no importarían nada)	Créelo en el destino, por ejemplo con Exportar definición en el origen e Importar definición → Como paquete receptor en el destino. Los cambios pendientes se envían en el siguiente envío.
El paquete … tiene Dirección = Import: recibe datos en esta empresa y no envía	Se ha usado Programar... o un envío en el paquete receptor	Envíe desde el origen. Cambie la dirección solo si esta empresa también debe enviar (Bidirectional).
El paquete … tiene Dirección = Export en la empresa … del destino	El paquete del destino es emisor, por ejemplo los dos lados en Export	Póngalo en Import en el destino, o importe allí la definición Como paquete receptor.
El paquete … es Bidirectional en las dos empresas con el mismo ganador de conflictos	Los dos lados de un paquete Bidirectional se quedan con la misma versión en un conflicto, así que un registro cambiado en ambas podría acabar distinto en cada una	Ponga Ganador de conflictos = Esta empresa en una empresa y Cambio recibido en la otra.
Conflicto: … en Errores de replicación	Un registro se cambió en las dos empresas antes de que llegara ninguno de los cambios	Informativo: el ganador de conflictos decidió qué versión se queda. Revise el registro si la otra versión importaba.
El paquete … está deshabilitado en la empresa … del destino	El paquete receptor está deshabilitado (desde 29.0.18 / 14.0.18 esto pausa la ruta)	Habilítelo en el destino cuando la ruta deba volver a funcionar. El origen conserva los cambios pendientes y los envía en la siguiente ejecución; los lotes ya recibidos esperan en Accepted hasta entonces. El origen avisa por correo de la ejecución omitida una vez al día si su paquete notifica fallos.
Llegan al origen lotes con los datos del destino	Antes de 29.0.15 / 14.0.15 un espejo Bidirectional (o uno al que se cambió la dirección) se podía programar en el destino y enviaba todo lo que tenía	Ponga el paquete del origen en Export y el del destino en Import. Elimine los lotes que no se deban importar con Eliminar en la lista de lotes entrantes, antes de que se procesen.
No se ha podido informar al origen de cómo terminó el lote … (Errores de replicación, etapa ACK, en el destino)	El paquete del destino indica un endpoint o una empresa de origen a los que no llega, o que no existen allí	Use Probar conexión en ese endpoint: indica las empresas que no existen allí. Corrija la empresa de origen del paquete y las empresas del endpoint, y después use Actualizar estado remoto en el origen para los lotes ya importados.
Conectado, pero estas empresas del endpoint no existen allí	Un nombre de empresa del endpoint está mal, por ejemplo con un carácter estropeado al importar una definición de paquete antes de 29.0.13 / 14.0.13	Corrija el nombre en las empresas del endpoint y en los paquetes que lo usan.
El lote del origen se queda mucho tiempo en Sent	El destino nunca lo recibió (se perdió la respuesta del envío)	Desde 29.0.24 / 14.0.24 la consulta de estado lo detecta: pasados 15 minutos el lote se vuelve a enviar o, si ya llegaron lotes posteriores del paquete, se descarta (DeadLetter) y se avisa, porque reenviarlo pondría valores antiguos encima de otros más nuevos. Envíe sus registros con Enviar exportación completa si hacen falta.
El lote del origen se queda en Accepted sin error	El destino aún no lo ha importado: no tiene cola de proyectos de entrada o no se está ejecutando	Use Programar procesamiento... en la lista de lotes entrantes del destino. Desde 29.0.17 / 14.0.17 el siguiente lote la crea si falta; si no ha podido, Movimientos del registro de replicación indica por qué.
Importar definición: "Estas tablas del paquete no existen en esta instalación"	El emisor usa tablas de una app que no está instalada en el destino	Instale esa app, o quite esas tablas del paquete antes de exportarlo.
Tabla no importada	El paquete de destino no tiene esa tabla, o los códigos no coinciden	Configure el mismo código de paquete y las mismas tablas en el destino.
Lote entrante Failed con "El valor '3.871,94' del campo … no es válido"	El origen tiene una versión anterior a la 29.0.3 / 28.0.3 / 14.0.3 y sus usuarios tienen otro formato regional (decimales, fechas) que el destino	Actualice el origen. Desde esas versiones los valores viajan en formato independiente del idioma.
`Los secretos cifrados pueden tener como máximo 215 caracteres.`	Límite de cifrado de BC	Use un secreto más corto o guárdelo sin cifrado de base de datos.

Comprobado en Business Central 29.0 (on-premises, Docker) con NCW Replication Engine 29.0.3 e interfaz en español (es-ES en origen, es-MX en destino), octubre de 2026.

This guide walks through configuring NCW Replication Engine to replicate data directly from one Business Central installation to another over HTTP (Direct BC-to-BC), from installation to a verified incremental change arriving at the destination.

Every step and screenshot was captured from a real end-to-end run between two Business Central 29 on-premises servers:

Role	Server	Company
Source	`bc29es`	CRONUS España S.A.
Destination	`bc29mx`	CRONUS Mexico S.A.

The example replicates the Customer table (18). The same steps apply to any table.

How it works
Prerequisites
Destination: create the receiving package
Source: create the endpoint
Source: create the sending package
Initial load (full export)
Incremental replication (changes only)
Automate with the Job Queue
Monitoring
Troubleshooting

1. How it works

 SOURCE (bc29es)                                        DESTINATION (bc29mx)
 ┌──────────────────────────────┐   HTTPS/HTTP POST     ┌──────────────────────────────┐
 │ Package CUST-ES-MX (Export)  │  ───────────────────▶ │ API nwr/replication/v1.0     │
 │  Detect Changes → Outbox     │   Basic auth, JSON    │  Inbound Batch (Accepted)    │
 │  Send Pending / Full Export  │                       │  Process Pending → Customer  │
 │ Endpoint BC29MX              │                       │ Package CUST-ES-MX (Import)  │
 └──────────────────────────────┘                       └──────────────────────────────┘

A package defines what is replicated: tables, fields, filters and parent/child relations. The source and destination each have a package with the same Code. The destination only writes to tables configured in its own package.
An endpoint (source side only) defines where to send: the destination's URL, credentials and company.
Full export sends every record of the package's tables. Incremental replication sends only records inserted, modified or deleted since the last run, detected through the Outbox.
The destination stores what it receives as an inbound batch and imports it asynchronously, either with Process Pending or from the Job Queue.

2. Prerequisites

2.1 Install the app on both servers

Install NCW Replication Engine on the source and on the destination, using the release that matches each server's Business Central version. Releases contain the normal .app and an on-premises .runtime.app:

Publish-NAVApp -ServerInstance BC -Path '.\niccoweb_NCW Replication Engine_29.0.0.17.runtime.app' -SkipVerification
Sync-NAVApp    -ServerInstance BC -Name 'NCW Replication Engine' -Version 29.0.0.17
Install-NAVApp -ServerInstance BC -Name 'NCW Replication Engine' -Version 29.0.0.17

Use the same version, or later, on source and destination. From 29.0.3 / 28.0.3 / 14.0.3 values travel in a format that does not depend on each user's language or regional settings (see Troubleshooting).

2.2 Users and permissions

Assign the NCW REPLICATION permission set to users who configure or run replication. In BC14 the equivalent is the NCW REPLICATION role imported from the extension's permission set.
On the destination, create (or reuse) a user for the source to authenticate with. It needs the NCW REPLICATION permission set plus write permissions on the replicated business tables. The test run used NavUserPassword authentication.
Optional: switch to the NCW Replication Admin profile (My Settings → Role) to get the replication Role Center with the Direct BC-to-BC activity tiles.

2.3 Destination API must be reachable

The source calls the destination's API page nwr/replication/v1.0:

http://<destination-server>:7048/<instance>/api/nwr/replication/v1.0

API services must be enabled on the destination server (ApiServicesEnabled = true; port 7048 by default).
Use HTTPS in production. Basic authentication over plain HTTP sends credentials in clear text.

Quick check from the source server:

Invoke-RestMethod 'http://bc29mx:7048/BC/api/nwr/replication/v1.0/companies' -Credential (Get-Credential)

2.4 Allow the destination's private IP (anti-SSRF, BC 26.11 / 27.2 / 28.0 and later)

Important. Recent Business Central versions block HttpClient calls from AL code to private or loopback addresses (10.x, 172.16–31.x, 192.168.x, 127.x). Two on-premises servers on the same LAN talk over private addresses, so without this step Test Connection fails with Endpoint unreachable.

On the source server, allow the destination's IP address, then restart the service:

Set-NAVServerConfiguration -ServerInstance BC -KeyName NavHttpClientAntiSSRFAllowedAddresses -KeyValue '["172.28.69.211"]'
Restart-NAVServerInstance  -ServerInstance BC

The value is a JSON array of individual IP addresses. Ranges are not supported, so use the destination's fixed IP.
If replication runs in both directions, configure each server with the other's IP.
Alternatively, NavHttpClientAntiSSRFEnabled = false disables the protection completely. This is not recommended.
In Business Central online the protection cannot be changed, so the destination must be reachable on a public address.
The server event log shows the cause as SSRF violation detected: non routable network address.

2.5 Replication Setup

NCW Replication Setup holds the per-company settings. Local API Authentication Type is informative and filled in by the app (from 29.0.14 / 14.0.14 it cannot be edited): it tells other servers how to authenticate against this one, OAuth2 on Business Central online and NavUserPassword on premises, and exported package definitions carry it. Business Central decides the real authentication; if a server on premises uses another one, change the endpoint that points to it. Failed batches are retried by the replication jobs themselves (see Retries in the scheduling section).

Set Up Replication Route (from 29.0.27 / 14.0.27, on the Role Center and in search) sets up a route from the source in four steps: the destination server (an existing endpoint, or its API address, user and password, with the connection tested), the destination company (chosen from the server's list), the package (code, description, the table numbers, and whether both companies send), and what to do at the end: set up the receiving package on the destination through its API (the destination needs 29.0.27 / 14.0.27 or later; an existing package there is never replaced), schedule the send every 5 minutes and, for a package where both send, start from the current data. Relations between tables, filters and notifications are then added on the package card, and on the destination the secret of the endpoint that points back to the source is set.

Clean-up (from 29.0.24 / 14.0.24): once a day the replication jobs clear the content of batches that ended (Completed, Acknowledged, DeadLetter) and delete the changes already sent, after Batch Content Retention Days (0 = 30), and delete log entries and replication errors after Log Retention Days (0 = 90). The batches themselves, failed or waiting batches and the change tracking are never touched. Clean Up Now does it at once.

3. Destination: create the receiving package

On the destination (bc29mx), open NCW Replication Packages and choose New:

Field	Value	Notes
Code	`CUST-ES-MX`	Must be identical to the source package code.
Description	Customers from CRONUS España	Free text.
Enabled	On
Direction	`Import`

In the Tables section, add a line with Table ID 18. Table Name resolves to Customer.

When a table is added, its fields are generated automatically: all fields are included and the primary key is forced on. Use Fields to exclude fields or to set Validate Field, which runs the field's validation logic on import. Include All Fields on the table line does it for all of them at once (from 29.0.22 / 14.0.22): turned off, only the primary key remains, to tick the few fields to replicate; turned on, every field is included again (except FlowFields and obsolete fields). It follows the field list: clearing a field turns it off, including them all turns it on. Import Strategy on the table line controls how much business logic runs on import (see 3.1).

Tables that exist in the sender's payload but not in this package are ignored. The destination never writes to a table it was not explicitly configured to accept.

Set Source Endpoint (an endpoint on this server that points to the source) and Source Company on the receiving package. With them, the destination tells the source how each batch ended as soon as it is imported (section 7.1). Without them, the source still finds out at its next scheduled run.

Faster: create it from the sender's definition (29.0.9 / 28.0.9 / 14.0.9). Once the sending package exists (section 5), choose Export Definition on it and Import Definition → As receiving package on the destination's package list. See 3.2.

3.1 Import Strategy

Import Strategy on each table line decides how the records received for that table are written. It only applies on import.

Strategy	What happens to a received record	When to use it
`Direct`	Values are copied as they are. No field `OnValidate` and no table `OnInsert`/`OnModify`/`OnDelete` triggers run.	The normal choice. Fastest, and the destination ends up exactly like the source.
`Validate`	Table triggers run on insert, modify and delete. Fields marked Validate Field (see Fields) also run their `OnValidate`; the rest are copied as they are. Primary key fields are never validated.	When the destination must run its own business logic, for example to recalculate amounts or fill dependent fields. Values can then differ from the source, and the import is slower and fails if something the logic needs is missing.
`Handler`	Nothing is written by the engine. The `OnBeforeReplicationRecordApply` event lets your own extension write the record and set `IsHandled`. If no subscriber handles it, the record fails.	Special cases that need code: transforming values, mapping codes that differ between companies, writing to another table.
`ReadOnly`	The table is skipped on import: nothing is inserted, modified or deleted.	Tables this side sends but must not receive, for example in a Bidirectional package where one company owns a table. Also to pause incoming changes for a table without removing it.

For documents such as Sales Header and Sales Line, use Direct. Validating line fields (No., Quantity, Unit Price…) makes Business Central recalculate prices, discounts, VAT, dimensions or reservations, so the line can end up different from the source or fail.

3.2 Copy a package between servers: Export and Import Definition

Instead of rebuilding the receiving package by hand, copy it from the sender:

On the source, open the sending package and choose Export Definition. A file <code>.ncwpackage.json is downloaded. It holds the tables, included fields, Validate Field, relations, filters (with When Record Leaves Filter) and batch and retry limits. It also holds the source's API address, company and authentication type. It never contains passwords or secrets.
On the destination, open NCW Replication Packages and choose Import Definition, then pick the mode:
- As receiving package (mirror of the sender): the same code, with the direction inverted (Export ↔ Import; Bidirectional stays). The import strategy is Direct. Source Endpoint and Source Company point back to the sender: an existing endpoint with the same API URL is reused, otherwise one is created and named after the sender's host.
- As identical copy: the package as it is, to set up another sending installation (for example test → production). Endpoints are kept only when one with the same code exists.
If the package already exists, you are asked whether to replace it. Its tables, fields, relations, filters and change tracking are recreated.
When a new endpoint was created, set its authentication secret and run Test Connection.

From 29.0.15 / 14.0.15 the Direction is enforced. An Import package never sends: Schedule…, Send Pending Changes and Send Full Export refuse it, and a Job Queue Entry created for it earlier does nothing. An Export package refuses incoming batches. Use Bidirectional only when both companies must send changes to each other (see below).

Bidirectional packages

A Bidirectional package sends the changes of this company and imports those of the other one, with the same package code on both sides: create it in one company and import its definition in the other As receiving package. Typical cases are master data maintained in both companies (customers or items created in either), or tables with different owners in one package, using the ReadOnly import strategy on the side that must not receive a table.

From 29.0.16 / 14.0.16:

No echo. What a company receives is recorded as already replicated, so it is not sent back.
Conflicts. Each change carries how the sender's copy looked before it. When the receiving copy no longer looks like that, both companies changed the record: Conflict Winner on the package decides which version stays (Incoming Change or This Company), and the conflict is logged in Replication Errors (Conflict: …). The two companies need opposite values: making a package Bidirectional sets This Company, and its mirror gets Incoming Change. A send is refused while both sides have the same value. Tables with the Handler strategy are left to their subscriber.
Starting point. The first send of a Bidirectional package sends every record it covers. In the company that imported the definition those are usually its own data, so Schedule… and Send Pending Changes offer to take the current data as the starting point first; Take Current Data as Starting Point on the package does it at any time. Only later changes are sent.

Records that both companies already had before replicating, with the same key and different values, count as a conflict the first time they change, and the Conflict Winner decides.

Tables that do not exist on the destination stop the import with their list. Fields that do not exist there are left out and counted in the final message.

4. Source: create the endpoint

On the source (bc29es), open NCW Replication Endpoints and choose New:

Field	Value (test run)
Code	`BC29MX`
Description	CRONUS Mexico on bc29mx
Enabled	On
Environment Type	`OnPrem`
Server Address / Server Instance / Tenant	`bc29mx` / `BC` / `default`
HTTP URL	`http://bc29mx:7048/BC/api/nwr/replication/v1.0`
Authentication Type	`NavUserPassword`
HTTP Username	User on the destination (section 2.2)

4.1 Set the password

Choose Actions → Set/Change Authentication Secret and enter the destination user's password. The value is masked and can never be displayed again, only replaced.

Authentication Secret then shows Configured. If it says Configured (not encrypted…), the secret is stored but database encryption is not enabled on this server. Enable it (Data Encryption Management) to encrypt secrets at rest. Encrypted secrets are limited to 215 characters.

4.2 Test the connection

Choose Actions → Test Connection. Connection Status must show Connected. If it fails, Last Error explains why: see Troubleshooting.

From 29.0.7 / 28.0.7 / 14.0.7, Test Connection also asks the destination whether it can import what it receives. If NCW Replication Engine is not licensed there, the status stays Connected and Last Error says "Connected, but the destination cannot import: …".

4.3 Select the destination company

In the Companies section, use the … lookup in Company Code. The list is read live from the destination's API. Select the company and choose OK.

4.4 Authentication types

Authentication Type must match how the destination server authenticates web service calls (ClientServicesCredentialType on its server instance).

Type	What is sent	Destination
`NavUserPassword`	HTTP Basic with HTTP Username and the secret	Business Central on-premises with `NavUserPassword` credentials. The secret can be the user's password or, better, its web service access key. Use a dedicated integration user with the NCW REPLICATION permission set.
`UserName`	HTTP Basic with HTTP Username and the secret	On-premises servers configured with `UserName` credentials (Windows user name and password). Rare.
`OAuth2 (Microsoft Entra ID)`	A Bearer token from Microsoft Entra ID (client credentials)	Business Central online, which accepts nothing else, or on-premises servers that use Entra ID. See 4.5.

Business Central on-premises still accepts NavUserPassword with a web service access key. Business Central online stopped accepting it in October 2022.

4.5 Business Central online (OAuth2)

In the Azure portal → Microsoft Entra ID → App registrations, register an application and create a client secret (Certificates & secrets). Note the Application (client) ID and the Directory (tenant) ID.
In API permissions, add Dynamics 365 Business Central → Application permissions → API.ReadWrite.All and choose Grant admin consent.
On the destination Business Central online, open Microsoft Entra Applications, add the client ID, set its state to Enabled, assign the NCW REPLICATION permission set plus write permissions on the replicated tables, and choose Grant Consent.
On the source endpoint:

Field	Value
HTTP URL	`https://api.businesscentral.dynamics.com/v2.0/<tenant>/<environment>/api/nwr/replication/v1.0`
Authentication Type	`OAuth2 (Microsoft Entra ID)`
OAuth Tenant ID	Tenant ID (GUID) or domain, for example `contoso.onmicrosoft.com`
OAuth Client ID	Application (client) ID from step 1
OAuth Scope	Keep `https://api.businesscentral.dynamics.com/.default`

Choose Set/Change Authentication Secret and enter the client secret. HTTP Username is not used.
Choose Test Connection. It always requests a new token; if Entra ID refuses it, Last Error shows Entra's reason (for example an invalid secret or missing consent).

The engine requests the token itself before sending and renews it shortly before it expires. Tokens are kept in memory only, never in the database. Client secrets expire (up to 24 months), so renew the secret in Entra ID and on the endpoint before that date.

5. Source: create the sending package

On the source, open NCW Replication Packages and choose New:

Field	Value
Code	`CUST-ES-MX` (same as the destination)
Description	Customers to CRONUS Mexico
Enabled	On
Direction	`Export`
Destination Endpoint	`BC29MX`
Destination Company	`CRONUS Mexico S.A.` (only companies added on the endpoint are accepted)
Export Format	`Json`

Export Format only decides how this server exports a full export. The changes are always sent in JSON, and from 29.0.13 / 14.0.13 the receiver reads a full export in whatever format it comes in, so source and destination do not need the same setting.

Add Table ID 18 in Tables, exactly as on the destination.

Optional settings:

Batch Chunking: maximum documents, records or size per batch. 0 means no limit.
Retry: retry count and delay for failed sends.
Relations / Filters on a table line: parent/child nesting (for example Sales Header → Sales Line) and per-field filters.

Replicating only some records (filters)

To replicate only the records that meet a condition, such as a Replicate Boolean field set to Yes, select the table line, choose Filters and add the field with its filter value (for example Yes, <>'' or 10000..20000). Filter Enabled on the line turns on by itself with the first filter and off when the last one is deleted (from 29.0.23 / 14.0.23; before, it had to be turned on by hand, and filters without it were ignored). Turn it off by hand to pause the filters without deleting them. The filters apply to the full export and to the incremental changes. A child table only replicates the lines of parent records that pass the parent's filters.

When Record Leaves Filter decides what happens to a record already sent to the destination that no longer passes the filters:

Stop Replicating (default): it is no longer sent, and the destination keeps its copy as it is. If it passes the filters again, it is sent only if it changed in the meantime.
Delete in Destination: a Delete is sent, so the destination only holds the records that currently pass the filters. If it passes the filters again, it is sent as a new record.

6. Initial load (full export)

On the source package choose Actions → Send Full Export (HTTP). All records of the package's tables are sent in one batch.

On the destination, open NCW Repl. Inbound Batches. The batch arrives with status Accepted, with its record count and SHA-256 checksum. Choose Actions → Process Pending to import it. The status becomes Completed.

A received batch that must not be imported (Accepted, Failed or DeadLetter) can be removed with Actions → Delete (from 29.0.15 / 14.0.15). The source is not told; its batch keeps its last status.

In the test run, 68 customers were received, processed and imported with 0 failures.

7. Incremental replication (changes only)

After the initial load, only changes need to be sent.

Business users change data in the source as usual. In the test run, customer 01121212 was renamed.

Customer changed
On the source package choose Actions → Detect Changes.
- The first run on a table records a silent baseline and creates no entries.
- Subsequent runs log one Outbox entry for each inserted, modified or deleted record.
- Running it again with no data changes creates nothing.
Outbox
Choose Actions → Send Pending Changes (HTTP). It runs Detect Changes and sends everything pending, in as many batches as the chunking limits require. The scheduled send (section 8) does exactly the same.
- Step 2 is only needed to review the Outbox before sending.
- With nothing pending it says "There are no changes to send" and sends nothing.
- It first asks the destination whether it can import. Nothing is sent, and the changes stay pending, when the app is not licensed there, when the destination has no package with the same Code, or when its package imports none of this package's tables. From 29.0.12 / 14.0.12 both destination and source must be on that version for the package check; an older destination is only asked about its license.
- Tables of this package that the destination's package does not include are left out there (the destination decides what it accepts). The message after sending lists them.
- For a very large backlog (thousands of documents), prefer the scheduled send to waiting on the page.
- Up to 29.0.11 / 14.0.11 this action was called Send All Pending Batches (HTTP). Send Batch (HTTP), which sent only the next batch of the pending changes, and Process Outbox, which downloaded them as a file, were removed in 29.0.12 / 14.0.12.
Send pending batches

Batches
On the destination, Process Pending imports the new batch.

Delta processed

7.1 Did the batch arrive, and was it imported?

The source learns this in two steps, because receiving and importing are separate on the destination.

Moment	Source batch status	Meaning
When sending	Sent	The destination received the batch, checked its checksum and stored it. Not imported yet.
	Failed / Corrupted	It could not be delivered (destination down, credentials, anti-SSRF…) or the checksum did not match. Last Error has the reason; automatic retry applies.
After the destination imports it	Completed	Imported in full.
	Partial / Failed / DeadLetter	Some or all records failed. Last Error has the destination's error.
Still waiting	Accepted / Processing	Received, not imported yet. If the destination cannot import (app not licensed), Last Error says so.

How the source gets the import result:

At once (29.0.8 / 28.0.8 / 14.0.8): when the destination finishes a batch, it notifies the source, using the Source Endpoint and Source Company of its receiving package.
At every scheduled run of the package (29.0.6 / 28.0.6 / 14.0.6): after sending, the source asks the destination about all its batches still Sent, Accepted or Processing. This is the fallback when the notification could not be made.
On demand: Refresh Remote Status on a batch card, or on the Batches list for all pending batches at once.

8. Automate with the Job Queue

Source. On the package, choose Actions → Schedule…. This creates (or opens, if it already exists) a standard Job Queue Entry that runs codeunit 73712294 NCW Repl. Outbound Processing with Parameter String = the package code. Each run executes Detect Changes and then sends the pending changes for that package, like Send Pending Changes (HTTP), so incremental replication runs unattended. From 29.0.14 / 14.0.14 the entry is created already scheduled, every 5 minutes on all days; to change the interval use Set On Hold on its card, edit it and Set Status to Ready. An entry created by an earlier version that is not recurring (it never runs) is replaced. A blank Parameter String processes every enabled package.

Each run also:

Checks that the destination can import (29.0.7 / 28.0.7 / 14.0.7). If the app is not licensed there, nothing is sent. The run is logged as a warning in the package Log and ends without an error, so the recurring entry keeps running. The first run after the destination is licensed sends everything still pending.
Updates the status of earlier batches (29.0.6 / 28.0.6 / 14.0.6), as described in section 7.1.

To send the same data to several destinations, or at different times, create one package per destination and schedule each one separately.

Versions before 29.0.1 / 28.0.1 / 14.0.1 only sent what was already pending in the Outbox. On those versions, run Detect Changes before each scheduled send.

Destination. On NCW Repl. Inbound Batches, choose Actions → Schedule Processing…. This creates (or opens) the Job Queue Entry that runs codeunit 73712289 NCW Repl. Inbound Processing, which imports all pending inbound batches. From 29.0.14 / 14.0.14 it is created already scheduled, every 5 minutes, like the source one. Without it, received batches wait in Accepted until someone uses Process Pending. From 29.0.17 / 14.0.17, when a batch arrives and the company has no such entry at all, it is created automatically and noted in Replication Log Entries. It runs as the user the source connects with; change User ID on the entry if needed. An entry that exists, even on hold, is left as it is.

The Role Center's Scheduled Replications (Job Queue) shortcut lists both kinds of entries.

Reading only what changed (BC29, from 29.0.27): the scheduled send compares only the records written since the run before last (their SystemRowVersion), instead of every record of every table. A table is still read in full at most an hour apart, which is when deletions are found, always when it or a parent table has filters, and on its first runs. Detect Changes by hand keeps the full read. On BC14 every run reads the tables in full.

Retries. From 29.0.19 / 14.0.19 both entries retry the failed batches of their side, always and in order: on the source the scheduled send retries the package's Failed or Corrupted batches before it sends anything new, and on the destination inbound processing (and Process Pending) retries Failed and Partial batches before it imports later ones. While an earlier batch is still being retried, later ones wait, so batches never arrive or import out of order. Each package's Max Retry Count (0 = 5) and Retry Delay (seconds, doubled after each attempt; 0 = every run) set the pace; a batch that used up its retries goes to DeadLetter, is notified, and no longer holds the others back. Retry on a batch does the same by hand, and Give Up (from 29.0.21 / 14.0.21) moves a Failed or Corrupted batch that will never go through to DeadLetter, so the later ones are sent; its changes do not arrive, so use Resend Records on it (from 29.0.26 / 14.0.26), which queues its records again with their current values for the next send, or Send Full Export. A retry sends the batch's stored content in full (before 29.0.21 / 14.0.21 only its first line, which the destination rejected as CHECKSUM_MISMATCH). The separate Automatic Retry setting and its Job Queue Entry of earlier versions are gone; upgrading removes the entry.

The entries keep running on their own (from 29.0.11 / 14.0.11). Business Central stops a recurring entry for good when a run ends in an error. To avoid that:

A replication job never fails because the app is not licensed: the run does nothing, writes a warning in Replication Log Entries (once a day), and the first run after the license is active does the work.
A run that ends in an error is run again by the Job Queue every 5 minutes, for days (from 29.0.21 / 14.0.21; before, 3 attempts 60 seconds apart and then the entry stopped). Upgrading applies this to the existing entries.
Failed runs are reported by email, once a day per package, to the package's recipients (Runs of the replication job ended in an error). The report goes out at the start of the next run, so it arrives even while the job keeps failing.
Every replication job run, and Process Pending, restarts the replication entries left in Error, and writes a warning in Replication Log Entries. Entries created by hand get it too.

8.1 Email notifications

From 29.0.10 / 28.0.10 / 14.0.10 each package can report by email how its replication ended on this server, using Business Central's own email. Nothing is sent by default.

Requirements

BC28 / BC29: an email account in Email Accounts (SMTP, Microsoft 365…). To use a specific one for these emails, assign it to the NCW Replication scenario in Email Scenarios; otherwise the default account is used. Business Central sends queued emails with the server's task scheduler, so EnableTaskScheduler must be true on the service instance (it is by default).
BC14: SMTP Mail Setup with the server and the sender (Send As or User ID).

Configuration. On the package card, section Notifications:

Field	Meaning
Notify On	`None` (default), `Failures`, or `Failures and Successes`.
Notification Recipients	Email addresses separated by `;`. Each one is checked when you type it.
Success Notification Mode	`Daily Summary` (default): one email a day with the batches completed since the last one. `Each Batch`: one email per completed batch. Failures are always sent at once.
Business Central Email	Shows whether Business Central has an account available (Configured / Not configured).

Use Actions → Send Test Email to check the whole chain.

What is reported. Each installation reports what happens on its own side, according to its own copy of the package, so source and destination can notify different people:

Side	Event	Type
Source	A batch could not be delivered (Failed, Corrupted)	Failure
Source	The destination reports a batch Partial, Failed or DeadLetter	Failure
Source	The destination reports a batch Completed	Success
Source	A scheduled run was not sent because the destination cannot import (once a day)	Failure
Destination	A received batch ends Partial, Failed or DeadLetter	Failure
Destination	A received batch is imported (Completed)	Success

The daily summary is sent by the first scheduled run (source) or inbound processing run (destination) of each day. Each email has the company and server, the package, the batch with its status and counts, and the error when there is one. It never contains record data.

It never affects the replication. If no email account is available, or the message is rejected, the replication goes on and the problem is logged in Replication Errors (stage Notification), at most once a day per package. A batch is reported once per outcome: checking the same status again does not send the email again.

9. Monitoring

Where	What it shows
Role Center tiles	Direct BC-to-BC records pending export, transfer and import, and failed imports
Package → Outbox	Detected changes and whether they were processed
Package → Batches (source)	Outbound batches: destination, status (Sent → Completed / Partial / Failed, see 7.1), document count, last error
Inbound Batches (destination)	Received batches: status (Accepted → Completed / Partial / Failed), counts, error message
Package → Errors / NCW Replication Errors	Record-level import or send errors
Endpoint → Connection Status	Last check, last successful connection, last error

10. Troubleshooting

Start with Check Route on the package (from 29.0.24 / 14.0.24). It checks the license, the tables, the connection and the package on the destination, the Job Queue Entries, and the batches that failed or wait, on the side where it is run, and says for each line what to do. Run it on the source and on the destination.

Symptom	Cause	Fix
Test Connection — Last Error: `Endpoint unreachable: … the connecting endpoint violates security requirements …`	Anti-SSRF blocks the destination's private IP (BC 26.11/27.2/28+). The server event log shows `SSRF violation detected: non routable network address`.	Add the IP to `NavHttpClientAntiSSRFAllowedAddresses` and restart the service (section 2.4).
Test Connection — Last Error: `Endpoint unreachable: There was an error while executing the HTTP request …`	DNS name not resolvable, firewall, wrong port or URL, or API services disabled	Test the URL from the source server with `Invoke-RestMethod` (section 2.3).
Test Connection — Last Error: `Endpoint unreachable.` with no further text	Version before 29.0.2 / 28.0.2 / 14.0.2, which did not keep the reason	Check the server event log, or upgrade.
`401 Unauthorized.`	Wrong username or password, or wrong Authentication Type	Run Set/Change Authentication Secret again and check the destination user.
Destination Company rejected	The company is not in the endpoint's Companies list	Add it on the endpoint first (section 4.3).
Batch sent but no data at destination	Batch is still Accepted	Run Process Pending, or Schedule Processing… on the Inbound Batches list.
A replication Job Queue Entry is in Error	A run failed, for example before the license was active (versions before 29.0.11 / 14.0.11)	Choose Restart on the entry. From 29.0.11 / 14.0.11 the next replication job or Process Pending restarts it.
"Nothing was sent for package …: NCW Replication Engine is not licensed in company …"	The app is not licensed on the destination	License it there. The changes stay pending and are sent by the next run.
"There are no changes to send for package …"	Nothing changed since the last send	Nothing to do. Check the package's tables and filters if a change was expected.
No notification emails arrive	Package Business Central Email says Not configured, no recipients, or the server task scheduler is off	Set up an email account (or SMTP Mail Setup on BC14), check recipients, use Send Test Email, and look at Email Outbox / Sent Emails in Business Central. Check Replication Errors for Notification email not sent.
Package … is not set up in company … of the destination	The receiving package is missing on the destination (its batches would import nothing)	Create it on the destination, for example with Export Definition on the source and Import Definition → As receiving package on the destination. The pending changes are sent with the next send.
Package … has Direction = Import: it receives data into this company and does not send	Schedule… or a send was used on the receiving package	Send from the source. Change the Direction only if this company must also send (Bidirectional).
Package … has Direction = Export in company … of the destination	The destination's package is a sending one, for example both sides set to Export	Set it to Import on the destination, or import the definition there As receiving package.
Package … is Bidirectional in both companies with the same Conflict Winner	Both sides of a Bidirectional package keep the same version in a conflict, so a record changed in both could end different in each	Set Conflict Winner to This Company in one company and to Incoming Change in the other.
Conflict: … in Replication Errors	A record was changed in both companies before either change arrived	Informative: the Conflict Winner decided which version stays. Check the record if the other version mattered.
Package … is disabled in company … of the destination	The receiving package is disabled (from 29.0.18 / 14.0.18 this pauses the route)	Enable it on the destination when the route should run again. The source keeps the changes pending and sends them with the next run; batches already received wait as Accepted until then. The source reports the skipped run by email once a day if its package notifies failures.
Batches with the destination's data arrive at the source	Before 29.0.15 / 14.0.15 a Bidirectional mirror (or one whose direction was changed) could be scheduled on the destination and sent everything it had	Set the source package to Export and the destination's to Import. Delete the batches that must not be imported with Delete on the Inbound Batches list, before they are processed.
The source could not be told how batch … ended (Replication Errors, stage ACK, on the destination)	The destination's package names a Source Endpoint or Source Company it cannot reach, or that does not exist there	Run Test Connection on that endpoint: it names any company that does not exist there. Correct the package's Source Company and the endpoint's companies, then use Refresh Remote Status on the source for the batches already imported.
Connected, but these companies of the endpoint do not exist there	A company name in the endpoint's companies is wrong, for example a character damaged by importing a package definition before 29.0.13 / 14.0.13	Correct the name in the endpoint's companies and in the packages that use it.
Source batch stays Sent for a long time	The destination never got it (the answer to the send was lost)	From 29.0.24 / 14.0.24 the status check finds out: after 15 minutes the batch is sent again, or, when later batches of the package already arrived, given up (DeadLetter) and reported, because resending it would put older values over newer ones. Send its records with Send Full Export if they are needed.
Source batch stays Accepted with no error	The destination has not imported it yet: no inbound Job Queue Entry, or it is not running	Use Schedule Processing… on the destination's Inbound Batches list. From 29.0.17 / 14.0.17 the next batch creates it when it is missing; if it could not, Replication Log Entries says why.
Import Definition: "These tables of the package do not exist in this installation"	The sender uses tables from an app that is not installed on the destination	Install that app, or remove those tables from the package before exporting.
Table not imported	The destination package does not contain that table, or the codes differ	Configure the same package code and tables on the destination.
Inbound batch Failed with "Value '3.871,94' for field … is not valid"	The source runs a version before 29.0.3 / 28.0.3 / 14.0.3 and its users have different regional settings (decimals, dates) than the destination	Upgrade the source. From those versions values travel in a language-independent format.
`Encrypted secrets can be at most 215 characters.`	BC encryption limit	Use a shorter secret, or store it without database encryption.

Verified on Business Central 29.0 (on-premises, Docker) with NCW Replication Engine 29.0.0.17. Unattended scheduling and the Test Connection messages were verified on 29.0.1 and 29.0.2, October 2026.

Replication Engine Help

Contenido

1. Cómo funciona

2. Requisitos previos

2.1 Instalar la app en los dos servidores

2.2 Usuarios y permisos

2.3 La API del destino debe estar accesible

2.4 Permitir la IP privada del destino (anti-SSRF, BC 26.11 / 27.2 / 28.0 y posteriores)

2.5 Configuración de replicación

3. Destino: crear el paquete receptor

3.1 Estrategia de importación

3.2 Copiar un paquete entre servidores: Exportar e Importar definición

Paquetes bidireccionales

4. Origen: crear el endpoint

4.1 Establecer la contraseña

4.2 Probar la conexión

4.3 Seleccionar la empresa de destino

4.4 Tipos de autenticación

4.5 Business Central online (OAuth2)

5. Origen: crear el paquete emisor

Replicar solo algunos registros (filtros)

6. Carga inicial (exportación completa)

7. Replicación incremental (solo cambios)

7.1 ¿Ha llegado el lote y se ha importado?

8. Automatizar con la cola de proyectos

8.1 Notificaciones por correo

9. Supervisión

10. Solución de problemas

Contents

1. How it works

2. Prerequisites

2.1 Install the app on both servers

2.2 Users and permissions

2.3 Destination API must be reachable

2.4 Allow the destination's private IP (anti-SSRF, BC 26.11 / 27.2 / 28.0 and later)

2.5 Replication Setup

3. Destination: create the receiving package

3.1 Import Strategy

3.2 Copy a package between servers: Export and Import Definition

Bidirectional packages

4. Source: create the endpoint

4.1 Set the password

4.2 Test the connection

4.3 Select the destination company

4.4 Authentication types

4.5 Business Central online (OAuth2)

5. Source: create the sending package

Replicating only some records (filters)

6. Initial load (full export)

7. Incremental replication (changes only)

7.1 Did the batch arrive, and was it imported?

8. Automate with the Job Queue

8.1 Email notifications

9. Monitoring

10. Troubleshooting

Comentarios

Publicar un comentario