Distributed transfers
A distributed transfer sends information from a source form on one server to a target form on another server or on the same server. You configure a distributed transfer by defining a distributed mapping (see Distributed-mapping) and by creating workflow to perform the transfer (see Creating-workflow-to-perform-DSO-operations). Then, when a request is created or modified in the source form, that action can trigger the workflow to create a copy of the request and transfer it to the target form. The transfer can include all or some of the data in the request.
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:
Stages of a distributed transfer
The other types of distributed operations — updates, returns, and deletes — use a subset of these stages.
To track these stages, use the DSO logs (see Configuring-BMC-Remedy-Distributed-Server-Option-logging).
Request ownership chains
To modify a request, users must own it. Typically, ownership is transferred with a request.
When ownership is transferred with a request, 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.
Types of distributed transfers
DSO 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.