The information in this topic is applicable only for on-premises deployments.

You can set up a distributed environment involving more than two locations. In this environment, one server "broadcasts" copies of a request to multiple recipients. 

Broadcast distributions are typically used to propagate forms, such as remote knowledge bases, from a central source. Ownership does not transfer with the requests, and when the distributed copies are modified, the original request is not updated.

For example, if you define a mapping on the sanfrancisco server that sends a data-only copy of a request to the chicago server, you must also define a mapping on the sanfrancisco server that sends another data-only copy of the same request to the toronto server.

If you try to broadcast copies of requests with ownership, the system successfully executes the transfer specified by the first filter action. All remaining transfers to other servers, specified by subsequent filter actions, result in error messages because ownership was transferred off the From server during the first filter action.

This section explains how to set up a broadcast distributed transfer that sends requests created in the Acme Product Info Archive form on the sanfrancisco server to the Acme Product Info Archive forms on the chicago and toronto servers. The following figure illustrates the flow of this example broadcast distributed transfer.

Broadcast distributed transfer example

To set up a broadcast distributed transfer

1. Create a distributed mapping named Acme ProdInfoArch W to E between the Acme Product Info Archive forms on the sanfrancisco and chicago servers.
   In the Distributed Mapping editor, use these values in the Options tab:

   The [confluence_table-plus] macro is a standalone macro and it cannot be used inline. Click on this message for details.
   This macro generates standalone content. As a consequence you need to make sure to use a syntax that separates your macro from the content before and after it so that it's on a line by itself. For example in XWiki Syntax 2.0+ this means having 2 newline characters (a.k.a line breaks) separating your macro from the content before and after it.
   See Creating-distributed-mappings and Distributed-transfer-scenario.

2. Create a distributed mapping named Acme ProdInfoArch W to T between the Acme Product Info Archive forms on the sanfrancisco and toronto servers.
   In the Distributed Mapping editor, use these values in the Options tab:

   The [confluence_table-plus] macro is a standalone macro and it cannot be used inline. Click on this message for details.
   This macro generates standalone content. As a consequence you need to make sure to use a syntax that separates your macro from the content before and after it so that it's on a line by itself. For example in XWiki Syntax 2.0+ this means having 2 newline characters (a.k.a line breaks) separating your macro from the content before and after it.
   See Creating-distributed-mappings and Distributed-transfer-scenario.

3. Create a filter with two DSO Transfer actions.
   Both actions should execute on Submit and Modify. Use the following action names. No qualification is necessary.

   The [confluence_table-plus] macro is a standalone macro and it cannot be used inline. Click on this message for details.
   This macro generates standalone content. As a consequence you need to make sure to use a syntax that separates your macro from the content before and after it so that it's on a line by itself. For example in XWiki Syntax 2.0+ this means having 2 newline characters (a.k.a line breaks) separating your macro from the content before and after it.
   Use the same filter to transfer requests from the sanfrancisco server to the chicago server and from the sanfrancisco server to the toronto server. Define the transfers as separate filter actions, which execute in order when the criteria on sanfrancisco is met.
   See Creating-workflow-to-perform-DSO-operations.

4. Test the broadcast by creating some requests in the Acme Product Info Archive form on the sanfrancisco server.
   Data-only copies of the requests should appear in the Acme Product Info Archive forms on the chicago and toronto servers.

Broadcasting distributed mappings and pools

To manage your  implementation from a central location, you can broadcast distributed mappings and pools to other AR System servers that participate in distributed transfers and returns. This helps ensure that the appropriate mappings are available where and when they need to be. For example, on the sanfrancisco server, you can create distributed mappings for the Distributed Mapping and Distributed Pool forms. Then, you can broadcast those mappings to the chicago and toronto servers.

To broadcast distributed mappings

1. On the sanfrancisco server, create a distributed mapping named Distributed Mapping: sanfrancisco to chicago between the Distributed Mapping forms on the sanfrancisco and chicago servers. In the Distributed Mapping editor, use these values:

   Panel	Item	Value
   Basic	From Server Name field	sanfrancisco
   	From Form Name field	Distributed Mapping
   	To Server Name field	chicago
   	To Form Name field	Distributed Mapping
   Options	When to Update field	Immediately
   	Transfer Mode field	Data Only
   Transfer to Target	Auto Map dialog box	Match Names
   Return from Target	Auto Map dialog box	Match Names

   See Creating-distributed-mappings and Distributed-transfer-scenario.

2. On the sanfrancisco server, create a distributed mapping named Distributed Mapping: sanfrancisco to toronto between the Distributed Mapping forms on the sanfrancisco and toronto servers. In the Distributed Mapping editor, use these values:

   Panel	Item	Value
   Basic	From Server Name field	sanfrancisco
   	From Form Name field	Distributed Mapping
   	To Server Name field	toronto
   	To Form Name field	Distributed Mapping
   Options	When to Update field	Immediately
   	Transfer Mode field	Data Only
   Transfer to Target	Auto Map dialog box	Match IDs
   Return from target	Auto Map dialog box	Match IDs

   See Creating-distributed-mappings and Distributed-transfer-scenario.

3. Create a filter with two DSO Transfer actions.
   Both actions should execute on Submit and Modify. Use the following action names. No qualification is necessary.

   The [confluence_table-plus] macro is a standalone macro and it cannot be used inline. Click on this message for details.
   This macro generates standalone content. As a consequence you need to make sure to use a syntax that separates your macro from the content before and after it so that it's on a line by itself. For example in XWiki Syntax 2.0+ this means having 2 newline characters (a.k.a line breaks) separating your macro from the content before and after it.
   Use the same filter to transfer requests from the sanfrancisco server to the chicago server and from the sanfrancisco server to the toronto server. Define the transfers as separate filter actions, which execute in order when the criteria on the sanfrancisco server is met.
   See Creating-workflow-to-perform-DSO-operations.

4. Test the broadcast by creating or modifying a distributed mapping on the sanfrancisco server. 
   Data-only copies of the requests should appear in the Distributed Mapping forms on the chicago and toronto servers.
5. To broadcast distributed mappings for the Distributed Pool form from the sanfrancisco server to the chicago and toronto servers, repeat these steps for the Distributed Pool form.