The synchronization subsystem provides facilities for automatic synchronization between tables and corresponding records in some external system. Synchronization can be bidirectional or unidirectional in either direction.
Syncing can be used to transmit all the functionality that an external system has in common with . For example, it allows the user to define table and field mappings, handle the communication of the data and determine which records need to be updated between each system. Each external system type also needs an external system Adaptor (ESA) to handle its unique characteristics. The ESA is responsible for implementing functions such as "List the available tables" "List the fields in a given table", "Create, Replace, Update, Delete a record". It is also possible to plug in a fully custom, third party ESA implementation and to share ESAs that you create with a particular system type.
comes with a prebuilt ESAs for common systems and new ones can be created by customers in Java or their choice of language. If the customer develops the ESA in Java, it can be linked with the Remote Proxy that actually communicates with the Sync subsystem. If the customer develops the ESA in some other language, it communicates with the Remote Proxy using standard I/O streams.
To be synchronized with , an external system must have these properties:
A given table can be synced with multiple external system and it is not necessary for all fields to be mapped. Existing ESAs provide support for synchronization with the File Directory, Microsoft Exchange, QuickBooks, Excel and other systems. The synchronization process is based on comparing record timestamps in the KB with record timestamps in the external system. For example, if a synchronization was run on Wednesday and is next run on Friday, it looks for all the records changed in one or both systems since Wednesday and propagates those updates to the other system. At the end of a synchronization process, both systems have matching data. Creation of new records or deletions may also be carried over to the other system if configured to do so.
The term sync is also used to refer to syncing entity sets between KBs. With entity sets, rather than syncing record data to an external system from the KB, you can instead sync KBs so that they contain the same tables, fields, and other structural elements. This is primarily useful when structural changes are made in a development KB, or testing KB, and those changes are moved to the production KB after thorough testing. For information about this type of sync, see Pushing Changes to Production. |
Inc/ Installation | |
Sync | Synchronization Sub-system |
XML | Extensible Markup Language. See http://www.w3.org/xml/ |
external system | external system - separate from |
STDIO | Standard Input/Output streams of console |
HTTPS | Secure Hypertext Transfer Protocol |
URL | Universal Resource Locator |
URL Encoding | Encoding as prescribed in http://www.w3schools.com/TAGS/ref_urlencode.asp |
NAT | Network Address Translation |
CL | Command Line |
ESA | external system Adapter |
ESA Proxy | Interface between the sync subsystem and the ESA. |
JDK | Java Development Kit |
REST | Representation State Transfer web service. See: http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html |
RPC | Remote Procedure Call |
supports several synchronization options. The choice of which method is most appropriate depends upon your particular needs.
The following table summarizes these options:
Sync Option | Description | Pros and Cons | |
---|---|---|---|
Web Services/REST | Used for general purpose, request-response integration with remote or local systems.
| Pros: The knowledgebase can be seen as an ordinary source, like a database; web services are now supported by virtually any platform. Cons:
| |
ESA | Best used to synchronize record copies between an KB and an external system. When a record is modified on one system, it is automatically updated in the peer system, either immediately, or on a schedule, or by a manual sync request. To achieve this functionality, the ESA must be able to connect to the sync subsystem, and support Create/Read/Update/Delete (CRUD) operations in the external system, which can be remote. | Pros:
Cons:
| |
Custom Scripts | Custom scripts can be run by upon some KB-defined conditions, such as when modifying a record. These scripts are executable and there is prebuilt support for Perl and Java scripts which are on the server. Run conditions can be quite complex and can be fully integrated with a workflow set up in the KB.
| Pros:
Cons:
|
The structure with which an table can be synchronized may be a table, a folder or anything else which logically groups records, and can be presented or derived by the ESA from the external system. All records within a single structure must have the same set of fields.
As well as records, it is also possible to synchronize relations between external records. Those are used to update Linked Fields in .
Sync also supports Collection fields, which are something in between normal data field, holding single value and a relation to other table. Collection fields hold multiple values, which might be complex objects, with multiple fields. These objects can be mapped to a separate table, just as related records for relations. But, unlike a relation, which treats all records independently, these records are treated as a part of their master record. If any of them is modified, a master record is considered to be modified.
In summary, the Sync Configuration Wizard creates a record in holding:
If a Sync Configuration is modified after it has been run, all previous peering of records with XS records is lost, and the next sync is treated as an entirely new synchronization.
For every record in an table or XS structure subject to a new sync, and for every such record created since the last sync, a corresponding record in the other system is determined, if it exists, by matching the Identifying fields - checked in the Field Mapping Wizard - from the two systems. If there's no such record, one is created. The two records are held by Sync in an ID - XS ID pair, thus peering the record with the external record. Logically, Sync treats the pair as a single data record, having and external views.
If a new record is created manually in both systems, the Identification process prevents Sync from duplicating them.
There are two algorithms for matching:
The algorithm is selected in the Field Mapping GUI - Use strict match for identification checkbox. The choice of exact matching may prevent matching if any identifying field has non-unique values.
After the pairing is established, it isn't cleared until either one of these conditions is met:
There are several similar options that control how the External Sync Wizard handles the direction of synchronization, and specify how the system should handle conflicts that arise when the same records are updated in both systems. For example, the General tab of the External Sync Wizard allows you to define the direction of the sync as two-way, or only updating or the external system.
Additionally, you can define how the synchronization handles record conflicts between the systems. If you need to map multiple entities from one system to a single entity in the other, you can enable multi-to-multi table mapping for the sync configuration, but this limits the sync to one-way. You can use multi-to-multi table mapping and sync in both directions by creating two separate one-way sync configurations, one syncing from to the external system, and one going in the other direction.
When there are two conflicting files, the system always chooses to keep one and discard the other. This can be based on the timestamps in the Last Updated Field for each record, or on the system which has been specified to take precedence. However, it is possible to specify the fields which should be overwritten in the Field Mapping Tab. Conflict handling in the General tab works in this way:
This system should take precedence: If both records have been changed to different values, the record is updated.
The sync is run at 07:52am. In this case, the record with values (Agiloft_1.doc) takes precedence. |
External System should take precedence: If both records have been changed since the last sync to different values, the external record is updated.
The sync is run at 07:52am. In this case, the record with external values (Agiloft_10.doc) takes precedence. |
Take the most recent record: If both records have been changed since the last sync to different values, the most recently modified record is updated.
The sync is run at 07:52am. In this case document Agiloft_10.doc takes precedence. |
Duplicate records: The system creates a duplicate of each record with both external system and values.
The sync is run at 07:52am. In this case both the Salesforce and systems has a duplicate of Agiloft_1 and Agiloft_10. |
In the Field Mapping wizard, the Table Update Type options define the sync direction for that specific table. The available options here are dependent on the sync direction. For example, if sync direction = Update Agiloft only, the available Table update type options are Synchronize and Import.
Export and Import do not attempt to synchronize the records by matching values and resolving conflicts. Instead, they simply overwrite all fields which are selected for mapping for the table.
The allowed operations restrict Create/Update/Delete operations for the tables in the internal or external systems. These options are dependent on the sync direction, and if the direction does not permit an operation, the option is disabled. For example, if Sync Direction = Update External System only, Agiloft Create, Agiloft Update, and Agiloft Delete are disabled here and shown in gray.
Within each table, each individual field also has the option to be updated in or the external system. As with the Allowed Operations, these options are dependent on the sync direction. Depending on the field selections here, the sync work in the following ways:
If two or more external systems are kept in sync with a given Table - which means using two or more different Sync Configurations - and if conflicts are resolved by preserving the most recent value, the results are affected by the order in which the synchronizations are run.
Suppose an updatable field in the 3 systems XS A, XS B and has the values and timestamps shown, and we synchronize A with , and then B with at 4p.m:
XS A p (3p.m) => p (4p.m) XS B q (2p.m) => p (4p.m) Agiloft r (1p.m) => p (4p.m) |
The first update changes because 3 p.m. > 1 p.m, and the second changes XS B because 4 p.m > 2 p.m
But if we synchronize B first, and then A, the effect is:
XS A p (3p.m) => q (4p.m) XS B q (2p.m) => q (4p.m) Agiloft r (1p.m) => q (4p.m) |
The first update changes because 2p.m > 1p.m, and the second changes XS A because 4p.m > 3p.m.
This is because there is only one timestamp on each value in a pair, whether it results from sync or user updating.
Related articles |