Distributed transfers
The following figure shows the basic flow of a distributed transfer. The request in the darker form has ownership after the operation is completed.
For an example of how to set up a distributed transfer, see Distributed-transfer-scenario.
Distributed transfer flow
Stages of a distributed transfer
The stages of a distributed transfer are listed in the following table:
Stage | DSO server action |
|---|---|
0 | Gets a list of pending items to process from the distributed pending queue. The list includes details about each operation. For information about the distributed pending queue, see Monitoring-and-managing-pending-distributed-operations. |
1 | Identifies the next pending item to process from the list obtained in stage 0. |
2 | Gets the definition of the source form associated with the pending item. |
3 | Gets detailed information about the request to transfer, which is identified by the request ID in the Source ID field of the pending item. |
4 | Gets the definition of the distributed mapping associated with the pending item. |
5 | Verifies that it can implement the mapping. |
6 | Gets the definition of the target form associated with the pending item. |
7 | Transfers the request from the source form to the target form. |
8 | After the transfer operation is complete, DSO updates information about the status of the operation in the request identified by the Source ID field of the pending item. |
The other types of distributed operations—updates, returns, and deletes—use a subset of these stages. To track these stages, use the Distributed Server Option logs, see Configuring-Distributed-Server-Option-logging.
Request ownership chains
To modify a request, users must own the request. Typically, ownership is transferred with a request, and an ownership chain is created. The ownership chain begins with the copy of the request that has ownership—also called the master copy (see the definition for Master Flag in Distributed-fields)—and extends back through all copies of the request from which ownership was transferred. For example, a request on the sanfrancisco server must be resolved on the chicago server. Therefore, you transfer the request with ownership to chicago so that chicago users can modify the request as necessary. Depending on your workflow configuration, sanfrancisco users might receive notice of changes made to the request on the chicago server through a distributed update operation. But sanfrancisco users cannot modify their copy of the request unless the request is returned with ownership through a distributed return operation. For information about mapping chains, see Setting-up-chained-distributed-transfers.
Types of distributed transfers
Distributed Server Option can perform the following types of distributed transfers:
Types of distributed transfers
Type of transfer | Copy of request in target form | Description | ||
|---|---|---|---|---|
Holds ownership? | Is in ownership chain? | Can be modified? | ||
Data Only | No | No | No | Typically used for archiving. Because data-only copies cannot hold ownership, they cannot start ownership chains. |
Data + Ownership | Yes | Yes | Yes | Considered the master copy. Modifications made to this copy can be automatically made to all other copies of the request in the ownership chain (see Distributed-updates). |
Independent Copy | Yes | No | Yes | Cannot receive updates from the master copy because independent copies are outside the ownership chain. Independent copies can start new ownership chains. |
Copy + Delete | Yes | No | Yes | Transfers an independent copy of a request to the target server and then deletes the original request. |
Dynamic data, such as an entry in a defect-tracking form, is often modified at the site to which it is transferred. Use a Data + Ownership operation to transfer this type of data.
Static data, such as customer biographical information, is typically not modified at the site to which it is transferred. Use a Data Only or Independent Copy operation to transfer this type of data.