NVXRPL Replication

Manual

☰ Contents

General

• App Replication

Setup

• App Setup

Tasks

• Working with the app

Appendix

• Release notes

Docs  /  NVXRPL Replication  /  General
General

• Division of companies into master companies, operational companies, and other companies
• Detailed replication setup with different options down to the field level
• Ability to choose how the data is replicated
• Control and transparency are ensured
• Replication directly from specific records such as Customer, G/L Account, or Item, etc.
• Dependent tables are taken into account
• Transparency and control for making the correct decision before the final replication execution
• Replication can be automated through a job queue
• Replication between databases

Docs  /  NVXRPL Replication  /  Setup
Setup

RPL Setup

1. Replication General Setup
2. Replication Database Setup (if in use)
3. Replication Setup Companies
4. Replication Setup Tables
5. Transfer to Companies default values
6. Personal Accounts/Country codes Posting Groups

Replication General Setup

• The fields and field names are automatically filled in during app installation and cannot be changed. These fields are used to identify what is called master data by the system.
• Checking the "Database Replication" checkbox enables replication between different databases. Additional fields and the "Replication Setup Database" become visible and can be defined.
• Once "Database Replication" is set, you can decide whether the current database sends or receives data by checking the "Current Database Receiving" checkbox.
• "Ignore Customer Default Dimension on Project" is set when the customer default dimension needs to be overridden.
• "Working Language" - This setting is required to define the global language for table filters that function depending on the localization language.

Main Master Data

Main master data includes the following tables: G/L Account, Contact, Customer, Vendor, Item, Job and Resource Group. Only these master data have the fields "Transfer to Company" and "Replicate" , such as here:
• The "Transfer to Company" field determines per record where replication will be performed:
  • "None" - The record will not be replicated.
  • "All operational" - Data will be replicated to companies with the "Operational Company" flag in the "Replication Setup Companies",
  • "Some" - When this option is selected, the desired companies must be selected. To do this, click on the three dots to the right of the field.
  • "Entire Organisation" - Data will be replicated to companies that do not have a "Exclude from Replication" flag in the "Replication Setup Companies".
  The default values for this field come from the "Transfer to Companies default values" setup (see below).
• "Replicate" is a non-editable field that is automatically set after enabling replication (action "Activate Replication" - data transfers are created).

User setup - Replication with filter

If checked, the "Execute replication with filter" function is available for this user in the "Edit - RPL Replication" window.

Replication Setup Database

Once replication between databases is enabled (see "Replication General Setup"), the "Replication Setup Database" becomes visible. Multiple databases and multiple remote companies can be set up.
• The field "Database Name", specifies the database name from which data should be transferred.
• In the field "Database Server Name" must be entered the link to server including "https://".
• Port is the OData port from the BC Service - Configuration.
• The option "Tenant Database" determines whether the sending database is a cloud DB.
• The fields "Client ID Key", "App Company ID" as well as "Client Secret Key" are populated with the data from the Azure App Registry.
• Company Name is the name of the master data company from the sending databank.
• Once all the necessary information is entered, the Actions -> "Test Connection" action can be used to ensure the setup is correct for cross-database replication.

Replication Setup Companies

. At the beginning, all desired companies are defined as Replication Setup Companies.
• The "Master Data Company" identifier is used to mark the company in which the master data is managed. This identifier can only be set for one company.
• With the identifier "Operative Company" the companies are marked, which represent the operative business.
• With the identifier "Excluded from Replication" those companies are marked, which will never receive data from the master data company.
• Companies, which were entered in this table, but have no identifier, are further named as "other companies". They receive general master data such as payment terms from the master data company. "Main Master Data" (see above) they receive only those who have the entry "Entire Organisation" on the card in the field "Transfer to Company".
• For cross-database replication, two additional fields appear here: "Remote" - If you check this box, only companies from remote databases can be selected. "Database Name" - Select the database where the remote company is located.

Replication Setup Tables


• Use the "Insert Tables" action to add the desired table and the table's fields to the replication setup.
• Once a table has been added, the following fields should be noted:
  • Type The type differentiates between "Table", "Field" or "Dependent Table".
  • Table no. The number of the table is filled by the system if the entry was created with "Insert Tables". It can also be entered manually.
  • Table Name Name of the corresponding table, is filled by the system.
  • Field No. Number of the field, is filled by the system if the entry was created with "Insert Tables". But can also be entered manually.
  • Field name Name of the corresponding field, is filled by the system.
  • Tables Sequence Order in which the tables are processed. The lower the number, the earlier the processing.
  • Skip Field Validation If this flag is set, the field is transferred with the replication, but there is no validation of the field content. This flag may only be set in certain cases.
  • Ignore Field Basically, fields, which are present in the replication setup tables, may only be edited in the master data company. In other replicated companies it comes to an error message. If this flag is set, this field can be edited in the master data company as well as in all other companies and is not replicated. System fields, such as "Created by" or "Created on" should always receive this checkmark.
  • New Indicates rows which are newly added in the replication setup tables. When closing the "Replication Setup Tables" page, corresponding data transfer entries will be created in the master data company for all lines with this indicator checked. This flag can be removed manually if existing entries from the master data company are not to be transferred. However, this should only be done in special cases.
  • "Table filter" in "RPL Replication Setup Tables" The table filter is used to replicate only certain records of the table concerned. The table filter can only be used for setup data records with the type "Table" and "Dependent table". If a filter has been created, replication entries (data transfers) are only created for the data records selected according to the filter.
  Translated with DeepL.com (free version)
  • "Ignore for field"/"Ignore for field value". Sometimes you want to replicate only certain records of a table (depending on the value of a field) and not others. For this purpose, the "Ignore for field" and "Ignore for field value" fields in the "Replication Setup Tables" are used. These can be used only for the setup with the type "table": . For both fields, the values cannot be entered manually (except in "Ignore for field" if you want to delete the value completely). If you click on Lookup points, the selection list of fields for the selected table will appear: . Immediately after that, the corresponding page opens. For options, an option selection will pop-up and for other fields an input page: Thus, the setup is ready: IMPORTANT: You have to get out of the "Replication Setup Tables" in order for the changes to be saved. For the tables with such setup, replication is not enabled at all and they can be inserted/deleted/changed. Since the field value to be ignored comes into use immediately after record creation, it must be populated as soon as this field is created. In this example, we use the type of a resource. In this way the system should already know the value of the field when creating it. During the manual input, the input page for the defined field pops up: . IMPORTANT: In programmatically created records, the corresponding field value must be provided.

    Important

    This feature will be removed in the next version because the same function will be solved with TableFilter.
  • ""Ignore for Company" The "Ignore for Company" field is used in cases where you want to ignore specific tables or fields for certain companies. When replicating, the "Ignore for Company" setting can be considered at the table level. If "Yes" is selected, you can choose the company. When one or more companies are defined, data transfer for these companies is set to "Skip." The error message will be "The record could not be replicated because there is no definition for this table in the database." Creation, deletion, and changes in tables are allowed when "Ignore for Company" is set for this company. At the field level, "Ignore for Company" can also be considered. When set, the field content will not be transferred, as the field in the data transfer details is automatically set to "Skip." Furthermore, changes in fields are allowed when "Ignore for Company" is set for this field for this company.
  • "Write with "Insert"" When a new data record is created, this is done with an "Insert" entry and an "Update" entry. The "Insert" entry normally only writes the key fields and the "Update" entry writes all other values at a later time. However, if you also want to write certain values with the "Insert" entry, you can force this with this checkbox. Thus, the defined fields are already available before the "Update" entry: This can be very helpful in certain scenarios with dependent tables.

  Transfer to Companies default values

  This table lists all the so-called "main master data". Only in these tables can you select, for each record (during record creation), the target companies to which it should be replicated. You can define the default value for this function ("Transfer to Company") here.

  Personal Accounts/Country codes Posting Groups

  This setup is relevant for all customers which have companies with different country codes. Example: there is a company with Austrian legislature and a company with German legislature. In this case, for example, the business posting group cannot be filled from the master data company, because a customer in an Austrian company has the business posting group INLAND, but in the German company the same customer needs the business posting group EU. This setup has to be done in the receiving company. According to this setup the fields will be filled during the transfer to the target company. This setup must be done separately for the type "Customer" and "Vendor".

Docs  /  NVXRPL Replication  /  Tasks
Working with the App

Replication between companies in one Database

• Using the "Execute Replication" action initiates the processing of pending data transfers. This action can also be performed through a job queue.
• All processed entries are marked as "Assumed" along with the date and time of acceptance.
• If an error occurs during processing, the "Error" flag is set, and the date and time of the error are recorded. If an error occurs, the processing of all subsequent replication sets from the affected company is stopped. However, replication continues for all other companies. Once the error is resolved, replication for the affected company resumes at this point.
• The "Skip" flag allows skipping the processing of a data transfer to proceed with the processing of subsequent records. Removing the "Skip" flag will trigger another attempt to accept the skipped data transfer during replication.
• Within a company, the processing in replication is always based on the ascending order of the sequence number. However, for clarity, the data is displayed in descending order.
• Replication can also be performed within individual companies, considering only the data transfers for the respective company.

Replication of Main Master Data

Execute replication with filter

Replication between Databases

• During cross-database replication, data transfers from the base database are acquired using the "Transfer from Base-Database" action.
• If an error occurs during this process, the transfer is interrupted, and the corresponding data transfer is marked accordingly.
• To process records for the clients of this database, the "Execute Replication" action must be selected here as well.
• The master data company in the remote database is not strictly required. However, if you want to initiate data transfers for all companies with ONE execution of the "Execute Replication" function, you will need a master data cmpany in the remote database as well.
• When fetching replication setup tables, all definitions are always transferred. This occurs automatically during the transfer of data transfers. In a remote database, these definitions should not be altered anymore.
• The actions "Transfer from Base Database" and "Execute Replication" can be automated using a task queue (Report 61882 - RPLTransferRemoteDTNVX and Codeunit 61883 - RPLStartReplicationNVX).

Docs  /  NVXRPL Replication  /  Appendix
Release Notes

Build Overview in DevOps

NVXRPL 1.0.22.0

• Improvements

• • Field type RecordId is now being replicated.
  • System Fields are excluded from Insert Table action.

NVXRPL 1.0.21.0

• Improvements

• • Replication Setup: new Checkbox - "Replication Inactive"

NVXRPL 1.0.20.0

• Corrections

• • Setup for working language: Optimization
  • Vendors/Customers can be changed before replication activation without affecting replication.

NVXRPL 1.0.19.0

• Corrections

• • Setup for working language: Optimization

NVXRPL 1.0.18.0

• Corrections

• • New setup for working language

NVXRPL 1.0.17.0

• Corrections

• • Optimizing for Performance works now in Remote-Database.

NVXRPL 1.0.16.0

• Corrections

• • Log for all missing Insert-Records removed.

NVXRPL 1.0.15.0

• Corrections

• • Problem with missing Insert-Records corrected.

NVXRPL 1.0.14.0

• Improvements

• • Log will be written for all missing Insert-Records.

NVXRPL 1.0.13.0

• Corrections

• • Language error in the table filter has been fixed.

NVXRPL 1.0.12.0

• Corrections

• • The remote company with the same name is now ignored.

• Improvements

• • Setting in the "Replication Setup," the checkbox "Ignore Cust. Def. Dim. on Job."

NVXRPL 1.0.11.0

• Corrections

• • Order of the dep. Records corrected.

NVXRPL 1.0.10.0

• Corrections

• • Secure that a data record is not created if it already exists. This used to be possible in very rare cases where the primary key is automatically incremented.
  • Removing Company in "Ignore for Company" corrected.

• Improvements

• • "Assumed" has been renamed to "Replicated" in the data transfers
  • Renaming of existing data records with the same name is automatically skipped
  • Performance improvements.

NVXRPL 1.0.9.0

• Corrections

• • Table filter corrected in the remote database for Delete record.

NVXRPL 1.0.8.0

• Corrections

• • Correction regarding the formatting of decimal numbers
  • Table filter corrected in the remote database.

NVXRPL 1.0.7.0

• Corrections

• • Correction in relation to dependent table.
  • Filter of the parent table for dependent table is now also taken into account.

NVXRPL 1.0.6.0

• Corrections

• • Table filter Problem with default dimensions (as dependent table) has been fixed.

NVXRPL 1.0.5.0

• Improvements

• • New Function: "Execute Replication with Filter".
  • Tile with Replication entries (Datentransfers) with error was added to Admin Role.
  • Now it is possible, if necessary, to add certain non-primary key fields in the "Insert" entry.

• Corrections

• • Table filter for dependent Tables works now correctly.

NVXRPL 1.0.4.0

• Improvements

• • Table filter for replication of only certain records.

NVXRPL 1.0.3.0

• Corrections

• • Filter is cleared for non-filtered Action.

NVXRPL 1.0.2.0

• Replication entries can now be replicated in a filtered manner.

NVXRPL 1.0.1.0

• Renaming of records is possible now.

NVXRPL 1.0.0.0

• original version