Synchronization architecture
The synchronization process compares your local Rule Designer workspace, the remote Decision Center database, and a reference that computes the state of the synchronization.
This reference state is created as a connection entry in your workspace when you connect to Decision Center.
The Synchronization tool in Rule Designer queries the Decision Center database remotely. To improve performance, the three–way comparison uses a checksum on both the remote and the local rules, and then compares them to the reference state.
- Incoming
Changes in Decision Center that you must update in Rule Designer.
- Outgoing
Changes that are made locally in Rule Designer that you must publish to the remote Decision Center.
- Conflict
Changes made to the local and remote versions.
If the Synchronization view advises any changes, you update or publish the changes as indicated, or override the proposed direction.
- If you rename a folder or subfolder in Rule Designer and synchronize, you obtain a new version in Decision Center for every artifact in that folder.
- The synchronization process is based on a user and a server. For example, if you synchronize between Rule Designer and Decision Center, then disconnect your project from Decision Center, and reconnect with another user credentials or connected to another server, then the synchronization can display conflicts even if no changes were made to your decision service or project.
Connection entries in synchronization
When you connect to Decision Center, a connection file (.syncEntries) is created in your workspace for the project.
The connection file tracks the state of the synchronization with one or more Decision Centers if you connect to more than one.
You must keep this entry to retain the three-way comparison that gives you the state of the synchronization.
When you close your Eclipse session, the connection file remains in your workspace, so you do not need to reconnect the next time you open Rule Designer.
When you disconnect from one Decision Center to connect to another one, you must keep the connection file of the first, unless you plan never to reconnect.
If you delete the connection entry and later reconnect and synchronize with the same project, the Synchronize view displays conflicts, even though the rules are the same on both sides, because you lost the checksum information when you deleted the entry. In this case, you can delete the project in Rule Designer and reimport it from Decision Center.
Only delete the connection entry if you do not need to reconnect, or if you want to clean the connection files, such as when you send a rule project (not the workspace) to another user.
UUIDs in synchronization
Synchronization uses Universal Unique Identifiers (UUIDs) to determine whether rules in Rule Designer and Decision Center are synchronized.
If you manually change the UUID of a rule in Decision Center, you get conflicts when you synchronize. For example, developers might change a UUID when they share rule projects through source code control (SCC) and want to work on different branches of a project in the same workspace. This approach breaks the synchronization. You must import different branches into separate workspaces to keep the synchronization.
When you copy a rule in Rule Designer as a starting point for another rule that you rename, copy it from the Rule Perspective to automatically change the UUID of the copied rule. Synchronization then detects the new rule on the Rule Designer side.
If you copy a rule in the Resource view or Windows Explorer, the copied rule has the same UUID as the original rule, and the copy process raises an error. To correct this error, right-click the copied rule in the Rule Explorer and click Update UUIDs.
If you
want to check the UUID of a rule, go to the .brl view
in Rule Designer.
To show the UUID in the Decision Center rule
tables, click Options in the top banner of
the Enterprise console.