Rundown Broker
Rundown Broker connects BCS rundowns to the ROAD playout engine.
This component is a Windows service, which connects to BCS service and ROAD service, both in a client role - see following picture.
Components Interaction
An instance of the Rundown Broker can handle several BCS rundowns, each to be executed by a ROAD playout job.
Installation
As a requirement a .NET 8.0 or later runtime prior to the Rundown Broker installation needs to be installed. Use the .NET Desktop runtime, which you can download from here: https://dotnet.microsoft.com/en-us/download/dotnet/8.0
Currently there is no setup procedure, so installing Rundown Broker means copying the whole RundownBroker folder to your local drive (recommended to \Program Files\ROAD\Rundown Broker). The RundownBroker.exe can be launched directly, then it will run showing up a console window with some log messages.
For basic configuration copy the appsettings_template.json from the provided doc folder to the installation folder, rename it to appsettings.json and edit it as needed (documentation below).
To run the Rundown Broker as a Windows service, it must be installed via CMD (elevated).
SC CREATE "Rundown Broker" binpath="C:\Program Files\ROAD\Rundown Broker\RundownBroker.exe"
or PowerShell (elevated)
New-Service -Name "Rundown Broker" -BinaryPathName "C:\Program Files\ROAD\Rundown Broker\RundownBroker.exe"
Uninstall the Rundown Broker Windows service via CMD (elevated)
sc.exe delete "Rundown Broker"
or PowerShell (elevated)
Remove-Service -Name "Rundown Broker"
To enable system logging to “Applications/Rundown Broker Startup”, it is recommended to start the RundownBroker.exe once with administrator privileges, so it can create this source in Windows system events. (This is needed only until there will be an installer for Rundown Broker.) See paragraph “Logging” below.
Setting Up Rundowns
One rundown configuration relates to one playout job on ROAD side. This job can be started by any mechanism provided to create ROAD jobs. For productive usage the system should assure the needed playout job is active, so it is recommended to create a standby schedule for each playout job. It is required to refer to a job template (because the scheduling client is limited in its configuration options), which must contain RundownPlayerFilter on output side. In any case it is required to define a job alias, because this is used to connect a rundown to the playout job.
Each rundown is defined by one ROAD config entry.
Rundown config
BCSS URL, BCSS socket URL, DPE token to access BCS
Program name (= Welle)
Show name (optional)
Track number (optional)
Protocol track number (optional)
Date to restrict execution to one day (optional)
ROAD job alias
When a rundown config is changed, affected Rundown Brokers will be informed by the ROAD backend and apply the change immediately. The detailed description of rundown configs is below.
Configuration
Rundown Broker’s appsettings.json
In the folder where RundownBroker.exe is started in (actually its working folder) there must be the local configuration file appsetting.json, which contains the following parameters:
Section | Parameter | Default Value | Description |
---|---|---|---|
Settings |
|
| This section contains all parameters for the Rundown Broker |
Settings.Logging |
|
| Configuration for logging via Logger.dll, which targets to .log files in the same format like ROAD does. |
| Path | “Logging\RundownBroker” | Absolute or relative path for the created log file. The log file name will be set in format “RundownBroker_YYYY-MM-DD_hh:mm:ss_<cnt>.log |
| ArchivePath | ““ | Path to move purged log files to. If not defined, purging will delete old log files. |
| MinimalSeverity | “I” | Minimal severity for log messages to appear in the log file Possible values in sequence of rising severity (use either the abbreviation character or the full name, case-insensitive): d=debug, i=info, s=success, w=warning, e=error, v=severe, f=fatal |
| RotationSize | 10000000 | After exceeding this file size (in bytes), the log file is being finished and a new file is created continuing logging. A note is added to the end of the prior and to the start of the next file. |
| PurgeInterval | 43200 | Time interval to run purging of Service and Workers' log files (in seconds). |
| PurgeByDays | 7 | Minimum age of Service's log files to be purged. See in https://davidsystems.atlassian.net/wiki/spaces/LRS/pages/13632388/Configuration+Parameters+of+ROAD+Service under Purging Log Files |
| PurgeByNumber | 100 | Minimum amount of Service's log files to purge the oldest ones. See in https://davidsystems.atlassian.net/wiki/spaces/LRS/pages/13632388/Configuration+Parameters+of+ROAD+Service under Purging Log Files |
Settings.Road |
|
| Configuration for connecting to the ROAD backend |
| RestAddress | URI to connect to ROAD Service via http or https | |
| DpeToken | ““ | Token for authorization to ROAD This is needed if the ROAD Service requests it. Otherwise the token will be sent, but ignored on ROAD side. This token is also applied as default for all BCS connections, if there is no different token configured in the respective parameters (see below). |
| BrokerInstanceAlias | ““ | Alias for this Broker instance’s program settings. If not set, the local computer name (in lowercase) will be used as alias. |
Example for appsettings.json file:
{
"Settings": {
"Logging": {
"Path": "Logging\\RundownBroker",
"ArchivePath": "",
"MinimalSeverity": "D",
"RotationSize": 10000000,
"PurgeInterval": 43200,
"PurgeByDays": 7,
"PurgeByNumber": 100
},
"Road": {
"RestAddress": "http://road-dpe:11003",
"DpeToken": "MjAyNDAxMzExNzE4MDk4NzI6V09SS1NUQVRJT04tQVA6eWF1OnRvcHNlY3JldHBhc3N3b3Jk",
"BrokerInstanceAlias": "road-server22"
}
}
}
ROAD Based Rundown Configurations
The actual configuration defining, which BCS shows the Rundown Broker should process, is placed inside ROAD configuration objects, which are stored in the ROAD database. A Rundown Broker instance accesses its responsible configuration by reading all ROAD configs in group “RDB/<broker instance>/Rundowns“.
For changing these configurations you can use the desktop tool “Rundown Configurator” or PowerShell scripts (example is provided as SetProgramConfig.ps1 in the doc folder. This is an example template to be edited for the actual settings).
Each config object consists of group, name, description and a value, which is a JSON structure, which contains the following parameters:
Section | Parameter | Default Value | Mandatory | Description |
---|---|---|---|---|
value |
|
|
| Contains a list of ProgramConfig entries, each having the following parameters |
| bcssHttpUrl | Mandatory to define the three BCSS parameters or refer to a BcsInstance set of them | URL to access BCS service via http / https | |
| bcssWsUrl | URL to access BCS service via ws / wss | ||
| dpeToken | Token for authorization to BCS service | ||
| bcsInstance | Name of a BcsInstance config object (see below) | ||
| program |
| Name of the program, which should be read by the Rundown Broker. | |
| show |
|
| Name of the show to be read by the Rundown Broker. Missing or empty: Read all shows in the program |
| date |
|
| Date to be considered (format YYYY-MM-DD) for rundowns of only one specific day. Missing or empty: Read data for the current date. |
| track | 0 |
| Track to be read by the Rundown Broker. Missing or empty: Track 0 is read. |
| protocolTrack |
|
| Number of the BCS Protocol Track, which receives the metadata of played-out elements. Protocol Track number are in the range 1000-1099. Missing or empty: No protocol track data is written. |
| jobAlias |
| JobAlias on ROAD side to process the playout of this rundown. |
Example JSON
{
"group": "RDB/notebook-nni/Rundowns",
"name": "Rundown Channel 4",
"value": {
"bcsInstance": "ROAD-BCS",
"jobAlias": "RundownPlayerTest-C4",
"program": "Channel4",
"protocolTrack": 0,
"show": "Morning show",
"track": 0
}
}
ROAD Based BCSS Instance Configurations
To avoid copying the full BCS service parameter set to many rundown configs, those can be maintained at one place and referred to by rundown configs. They then use the parameter BcsInstance instead of BcssHttpUrl, BcssWsUrl and DpeToken.
Each BcsInstance config must be in the group “RDB/BcsInstances“.
Section | Parameter | Value | Description |
---|---|---|---|
| group | “RDB/BcsIstances” |
|
| name | Arbitrary name, must be unique | This name is used for referring this BCS instance from rundown configs. It might also appear to users when configuring rundowns. |
value | bcssHttpUrl | mandatory | URL to access BCS service via http / https |
| bcssWsUrl | mandatory | URL to access BCS service via ws / wss |
| dpeToken | mandatory | Token for authorization to BCS service |
Example JSON
{
"group": "RDB/BcsInstances",
"name": "ROAD-BCS",
"value": {
"bcssHttpUrl": "http://road-bcs:8081",
"bcssWsUrl": "ws://road-bcs:8081",
"dpeToken": "MjAyNDAxMzExNzE4MDk4NzI6V09SS1NUQVRJT04tQVA6eWF1OnRvcHNlY3JldHBhc3N3b3Jk"
}
}
Logging
The first startup messages are always written to Windows system event messages, which can be viewed with the standard Event Viewer.
The preferred location there is under “Application and Service Logs/Rundown Broker Startup”. In case the Rundown Broker doesn’t have the required rights to write there, these event messages are written to “Windows Logs/Application” with source “.NET Runtime”.
To enable system logging to “Applications/Rundown Broker Startup”, it is recommended to start the RundownBroker.exe once with administrator privileges, so it can create this source in Windows system events. (This is needed only until there will be an installer for Rundown Broker.)
When the Rundown Broker service is running, it writes all events to a log file as configured in appsettings.json’s section “Settings/Logging” (see above).