A D3 broadcast occurs at the dataspace or snapshot level. For dataspace broadcasts, D3 first creates a snapshot to capture the current state, then broadcasts this newly created snapshot.
A broadcast performs one of the following procedures depending on the situation:
An update of the differences computed between the new broadcast snapshot and the current 'commit' one on the replica node.
A full synchronization containing all datasets, tables, records, and permissions. This is done on the first broadcast to a given replica node, if the previous replica node commit is not known to the primary node, or on demand using the user service in '[D3] Primary node configuration'.
The broadcast can be performed:
By the end-user, using the Broadcast action available in the dataspace or snapshot (this action is available only if the dataspace is registered as a delivery dataspace)
Using custom Java code that uses D3NodeAsMaster.
In order to be able to broadcast, the following conditions must be fulfilled:
The authenticated user profile has permission to broadcast.
The dataspace or snapshot to be broadcast has no validation errors.
Note: Although it is not recommended, it is possible to force a broadcast of a delivery dataspace that contains validation errors. In order to do this, set the maximum severity threshold allowed in a delivery dataspace validation report under '[D3] Primary node configuration' in the 'Administration' area.
The D3 primary node configuration has no validation errors on the following scope: the technical record of the concerned delivery dataspace and all its dependencies (dependent delivery mappings, delivery profiles and registered replica nodes).
There is an associated delivery profile.
If broadcasting a dataspace, the dataspace is not locked.
If broadcasting a snapshot, the snapshot belongs to a dataspace declared as delivery dataspace and is not already the current broadcast snapshot (though a rollback to a previously broadcast snapshot is possible).
The dataspace or snapshot contains differences compared to the last broadcast snapshot.
When a primary node shuts down, all waiting or in progress broadcast requests abort, then they will be persisted on a temporary file. On startup, all aborted broadcasts are restarted.
On the target replica or hub node side:
The ebx-d3-reference dataspace identifier is the common parent of all the delivery dataspaces.
The delivery dataspace has the same identifier in primary, replica or hub nodes.
If the delivery dataspace is missing, it will be created on the first or on the full synchronization broadcast.
If the delivery dataspace already exists on the first broadcast or full synchronization, it will be overridden.
If an existing dataspace with the same identifier as the delivery one is detected outside of the ebx-d3-reference, an error will be raised.
Broadcasts are performed asynchronously. Therefore, no information is displayed in the user interface about the success or failure of a broadcast. Nevertheless, it is possible to monitor the broadcast operations inside '[D3] Primary node configuration'. See Supervision.
An initialization occurs at the replica node level according to the delivery profiles registered in the TIBCO EBX® main configuration file of the replica node. When the primary node receives that initialization request, it creates or updates the replica node entry, then sends the last broadcast snapshot of all registered delivery dataspaces.
If the registered replica node repository ID or communication layer already exists, the replica node entry in the 'Registered replica nodes' technical table is updated, otherwise a new entry is created.
The initialization can be done:
Automatically at replica node server startup.
Manually when calling the replica node service 'Register replica node'.
To be able to register, the following conditions must be fulfilled:
The D3 mode must be 'hub' or 'slave'.
The primary and replica node authentication parameters must correspond to the primary node administrator and replica node administrator defined in their respective directories.
The delivery profiles defined on the replica node must exist in the primary node configuration.
All data models contained in the registered dataspaces must exist in the replica node. If embedded, the data model names must be the same. If packaged, they must be located at the same module name and the schema path in the module must be the same in both the primary and replica nodes.
The D3 primary node configuration has no validation error on the following scope: the technical record of the registered replica node and all its dependencies (dependent delivery profiles, delivery mappings and delivery dataspaces).
To set the parameters, see the replica or hub EBX® properties in Configuring primary, hub and replica nodes.
By default, when a data service accesses a delivery dataspace, it is redirected to the current snapshot, which is the last broadcast one. However, this default behavior can be modified either at the request level or in the global configuration.
On the primary node, a delivery dataspace can neither be merged nor closed. Other operations are available depending on permissions. For example, modifying a delivery dataspace directly, creating a snapshot independent from a broadcast, or creating and merging a child dataspace.
On the replica node, aside from the broadcast process, no modifications of any kind can be made to a delivery dataspace, whether by the end-user, data services, or a Java program. Furthermore, any dataspace-related operations, such as merge, close, etc., are forbidden on the replica node.
The last broadcast snapshot may change between two calls if a broadcast has taken place in the meantime. If a fully stable view is required for several successive calls, these calls need to specifically refer to the same snapshot.
To get the last broadcast snapshot, see D3Node.getBroadcastVersion.