HCL Domino · Replication · Field Protection · Security

Selective Domino Replication with Field Protection

Selecting which documents should be replicated is often only half of the problem. Sometimes the destination needs a document — but not every field contained in it.

This becomes particularly relevant when an internal Domino database is used as the master for a reduced or public version of the same information. Internal metadata, administrative information or encrypted fields may be required in the source database, while they should never become part of the target database.

The important question is no longer only “Which documents should be replicated?” but also “Which information inside those documents should be allowed to reach the target?”

From Document Selection to Field Selection

Sometimes Selecting the Right Documents Is Not Enough

In the previous replication example, a formula was used to control which documents participate in a Domino replication process. That solves an important problem: not every document in a source database necessarily belongs in the target database.

But even a document that should be replicated can contain information that belongs exclusively to one side.

Document Selection

Which documents?

A replication formula determines which documents are relevant for the replication process.

public vs. internal documents
status-based selections
document types or categories
application-specific selection rules

Field Protection

Which fields?

Field protection determines which values must remain local to one database and must not be overwritten by values from the other database.

internal metadata
administrative fields
local workflow information
encrypted internal fields

With @ReplicateWithFormulaWithFieldProtection, both decisions can be applied as part of the same replication operation.

Real-World Scenario

One Internal Master — One Reduced Public Help Database

A practical example is our own Domino API Engine Help environment.

The public Help database is derived from an internal Help database that acts as the master data source. The internal database contains additional information required for development, maintenance and internal processing that is not intended for publication.

Maintaining two independent sets of Help documents would create unnecessary duplication and make it much harder to keep the content synchronized.

Shared Content Titles, descriptions, syntax information, examples and other public Help content can be transferred to the public database.

Internal Information Administrative and internal processing fields remain exclusively in the internal master database.

Encrypted Fields Internal encrypted fields that are not required publicly do not need to become part of the public database at all.

Single Master Public documentation can still be derived from the same maintained source without maintaining a second independent content base.

Sensitive information that is not required in the target database does not need to be hidden there — it does not have to be transferred there in the first place.

Field Protection

Protected Fields Remain Local to Their Database

Field protection can be defined independently for both databases participating in the replication.

A field protected in database 1 is not overwritten by a field of the same name coming from database 2. The same principle applies in the opposite direction for fields protected in database 2.

Database 1

Fields listed for database 1 retain their local values. Values of fields with the same names from database 2 are not copied over them during replication.

Database 2

Fields listed for database 2 retain their local values. Corresponding values from database 1 are not transferred into those fields.

Important: Field protection is not a field-deletion mechanism. If a protected field already exists in the target database, its existing value remains untouched. If it does not exist there, the protected value from the other database is not introduced by the replication.

One Replication Operation

Selection, Protection and Replication in One Step

The useful part of this approach is that the application does not need to replicate documents first and clean up unwanted information afterwards.

The replication formula, replication rights and field-protection rules are applied directly as part of the controlled replication process.

Select A formula controls which documents participate in the replication.

Control Direction Separate replication rights control reading, writing, modifying and deleting for both databases.

Protect Fields Independent field lists define information that must remain local on either side.

Collect Results The operation returns statistics for created, updated and deleted documents and can additionally provide error statistics.

The two databases do not need to share the same Replica ID. This makes the mechanism useful for controlled synchronization between independently created Domino databases as well.

Security and Data Minimization

Do Not Transfer What the Target Does Not Need

Field protection is useful for more than reducing database size. It can also become part of a deliberate data-minimization strategy.

If internal information is not required in a public, external or otherwise reduced target database, there is often little benefit in transferring it and then relying on additional mechanisms to conceal it.

Reduced Data Exposure Information excluded from replication is not present in the target database simply because it existed in the source.

Smaller Target Databases Unnecessary internal fields do not consume storage in the reduced target database.

Clear Data Boundaries Application-specific field lists explicitly define which information belongs to which side of the replication.

Independent Local Information Each database can maintain fields that remain untouched by replication from the opposite side.

Beyond Public Documentation

The Same Pattern Applies to Many Domino Scenarios

An internal and public Help database is only one example. The same pattern can be useful whenever two Domino databases share part of their information but must keep other data separate.

External Portals Publish selected application data without transferring internal workflow or administration fields.

Archive Databases Transfer relevant business information while excluding temporary or environment-specific metadata.

Migration Staging Build reduced intermediate databases containing only the documents and fields required for the next processing step.

Distributed Applications Keep site-specific information local while synchronizing the shared part of application data.

Included Evaluation Example

Try Field-Protected Replication with the Test Databases

The real internal Help database is, of course, not part of the evaluation package. Instead, the existing Domino API Engine test databases are used to demonstrate the same principle with artificial data.

The test documents contain normal fields that participate in replication together with additional fields representing internal information. Selected fields are then protected during replication so that the resulting target documents contain only the intended information.

Evaluation Scenario

open the supplied Domino test databases
use a formula to select the documents that should participate
define the replication rights for both databases
define fields that must remain local to either database
execute the controlled replication in a single operation
compare the resulting documents in both databases
inspect the returned replication and error statistics

The test databases contain artificial data only. They demonstrate the same field-protection principle used for the public Help scenario without exposing any internal Help content.

Need more control over Domino replication? The Domino API Engine provides programmable replication functions for document selection, field protection, independently created databases and application-specific synchronization workflows.

Discuss Your Scenario Download Evaluation Function Documentation