Download AGILOFT REFERENCE MANUAL

Agiloft Reference Manual
Problem Areas
A few message or data types need special discussion.
Deletions
For many systems, tracking deleted records is problematic. The Agiloft HelperAPI can simplify this task. If
you can't easily track deletions in the external system you can either:


Enumerate all record IDs known by Agiloft and check whether those records actually
exist at the moment.
Or report "deletion events" to Agiloft when deletion happens in the external system.
The latter is usable if you can "hook in" into the external system to get deletion
notifications somehow.
A more sophisticated approach to ID enumeration, with better performance is possible if your system
uses never repeating, always increasing auto-incremented IDs. If this is the case, you may process the
countRange message and send a detectDeleted message to the Agiloft HelperApi. It will then apply a
dichotomy method (binary division) to find deleted IDs. This will be considerably faster than comparing
known and currently existing IDs one-by-one, especially if you can have a fast implement count(A < id <
B) operation and the number of deleted records is not large.
Transactions
Sync is transaction-less, because not all external systems support transactions or expose them over
integration APIs. If an external system requires transaction usage, the ESA should behave as it would
with "auto-commit on" in the SQL meaning, i.e. it should execute every operation in a separate
transaction.
Collections
Collection fields may hold complex objects, which can be mapped to Agiloft tables. For this reason,
getFields, getRelations and getCollections calls should accept both structure names and collection ids.
An ESA must ensure that structure names and any collection ids use different name spaces.
Locking (Clashing Modifications)
To deal with concurrent data modifications, Sync employs an "optimistic locking" strategy. When the
ESA is asked to modify or delete an external record, it is given a "last seen" timestamp. If the ESA detects
that the record was modified after that time, the ESA should respond with an OptimisticLockingFailure
exception and not modify or delete the record. If an external system uses the "pessimistic locking"
approach internally, the ESA should wait until the lock is granted first, or else report a record update
failure if waiting for the lock is not reasonable.
Currently, "delayed" updates due to locks are not supported, but this feature is likely to be added in the
upcoming releases because it may speed up syncn appreciably. It is a good idea to make your ESA ready
512