Publish results
Configuration is complete, and we are now ready to upload results. Well, almost ready. Unless the event has already started, we have no results yet — and we are of course sensible enough to prepare our setup before event day. So, if we want to test the entire result publishing pipeline (and we do), we will need some fake results.
Creating fake results
Depending on the particular setup, there may be multiple ways to produce fake results for testing — some more convenient than others. Common for all of them, however, is that they should be kept separate from the real deal, be it via backups, duplicates, restore points, forks or whatever mechanism the setup provides.
Manual approach
Results are not magic, so regardless of setup, they can usually be constructed "by hand". Participants can be created, and their start and finish times can be assigned, providing fine-grained control over the mocked results. Timing programs often make this easy, if a bit tedious. Of course, it is also possible to craft results in IOF XML 3.0 format from scratch, though this is likely even more tedious.
Creating and assigning results to a handful of participants to run a basic test is feasible, but for larger scale testing, a more automatic approach is desirable.
Automatic approach
Some timing programs feature built-in result mocking capabilities, fascilitating easy production of fake results for more comprehensive testing. Depending on our result source, we may be able to take advantage of this.
MeOS + Divisionsmatchberegning
When using the MeOS + Divisionsmatchberegning result source, we can take advantage of one of MeOS' built-in services: Punching Test.
First, we need to ensure that our setup is ready. Since we are dealing with division matches, we need to be fairly strict here:
- One or more courses must be defined in MeOS. Importing the real courses may be easiest, though it is not required.
- Classes corresponding to the real division match classes must be defined in MeOS.
- Participants representing clubs from the relevant divisions must be defined in MeOS. Importing real signups may be easiest, though fake names can be used as long as the clubs are defined correctly.
In a copy of our MeOS competition, we navigate to the Services tab and choose Punching Test.
The service has a few parameters, but the defaults should be sufficient for our needs. Once we start the service, a steady stream of fake results will be produced. We should probably pause it until we are ready to upload division results, as we would quickly run out of new results otherwise.
Prepare publishing pipeline
To upload results, the entire result publishing pipeline must be available. Given our prior efforts, this should be not be an issue. Here is a quick checklist:
- Division Result Bridge is configured
- The Division Result Server is online
- Our result source is available
We have already covered these topics earlier in the guide, but particularly for the result sources, a slightly more detailed summary may be useful.
MeOS + Divisionsmatchberegning
As the name of this result source suggests, both MeOS and Divisionsmatchberegning need to be available.
From MeOS, Division Result Bridge only needs access to the information server, so we need to ensure that the information server is online. As previously mentioned, it does not matter which computer MeOS is running on, as long as the information server can be reached over the network.
Meanwhile, Divisionsmatchberegning needs to be installed on the same computer as Division Result Bridge. It does not need to be running, though it can be if other purposes (such as printing) require it — just keep the configuration files separate.
Divisionsmatchberegning
This result source only directly depends on Divisionsmatchberegning, though Divisionsmatchberegning of course depends on another program to feed it "raw" results. For every division, one instance of Divisionsmatchberegning must be running, and each instance must have its information server open on a unique network address. Division Result Bridge and the Divisionsmatchberegning instances can all running on the same computer, can each run on their own computer, or anything in between — as long as our network configuration allows it.
IOF XML file + Divisionsmatchberegning
For this result source, Division Result Bridge is concerned with Divisionsmatchberegning and the IOF XML 3.0 results file.
The IOF XML 3.0 results file needs to be available on the file system for Division Result Bridge to read. The origin of the file is irrelevant, but Division Result Bridge expects this file to be overwritten with new results regularly.
Divisionsmatchberegning must also be installed on the same computer as Division Result Bridge. It does not need to be running, though it can be if other purposes (such as printing) require it — we just need to keep the configuration files separate.
Upload results
We finally return to the Update Results pane. We have previous defined the Working Directory, so there is not much left to configure here. In fact, only the field Update interval (seconds) remains — and with the IOF XML file + Divisionsmatchberegning result source, that field is hidden. For now, we will ignore the update interval and focus on just a single upload.
Run once
Pressing the Run Once button triggers one run of the result publishing pipeline. Division Result Bridge reads fresh results from the result source, bundles them up alongside the competition and division metadata, and sends it all to the Division Result Server. The server first applies any changes to the metadata, and then updates the results for each division. This means that every result update is also an implicit metadata update.
The exact stages of the pipeline depend on the result source, but the result of each stage is printed to the log. If successful, the updated results can be viewed on the result page in the browser after a short moment.
Run continuously
Running the result publishing pipeline once is all well and good, but to offer anything resembling live results, we need to publish continously throughout the competition.
For this, we use the Start and Stop buttons. Pressing the Start button publishes fresh result immediately, and then continues to publish results indefinitely — or at least until we press the Stop button. The exact timing of the continous publication runs depends on the result source. Additionally, note that pressing the Stop button in the middle of a publishing run does not cancel that run, but merely avoids starting new runs.
Update interval
As mentioned earlier, using the IOF XML file + Divisionsmatchberegning result source causes the result publishing pipeline to be triggered automatically whenever the IOF XML 3.0 result file changes while running continuously. As such, the concept of an "update interval" does not apply — at least not within the confines of Division Result Bridge.
For the MeOS + Divisionsmatchberegning and Divisionsmatchberegning result sources, however, the value of the field Update interval (seconds) determines how frequently Division Result Bridge should poll the result source for new results. The default value of 60 seconds is likely okay, but depending on our setup, we may wish to adjust it.
The primary reason to decrease the update interval is quite simple: freshness of results. With a polling strategy, some amount of latency is added to the result publishing pipeline. In the best case, we happen to poll for results as soon as they are made available, incurring minimal delay. In the worst case, we poll just before new results come in, meaning they will have to wait out the entire duration of the update interval before being published. Over time, this added latency averages out to about half the update interval, so naturally, reducing the update interval also reduces the latency, thus providing fresher results.
Unfortunately, we cannot simply push the update interval down to 0, as there are a few limiting factors at play. For a start, the result publishing pipeline takes time to run (though this is much less of a factor with the Divisionsmatchberegning result source). An update interval shorter than this time is pointless, as new runs will not be started before an ongoing run is finished.
Additionally, we do not have unlimited resources. Frequently updating results may consume a significant chunk of the available bandwidth when using e.g. a mobile network in a remote location, as is not uncommon at orienteering events. This is less relevant with the MeOS + Divisionsmatchberegning result source, since it checks for changes before committing to an upload.
Furthermore, low-end setups may struggle to keep up with all the data flows of card readouts, signups, result exports and so on. These tasks usually have to be handled synchronously to avoid data corruption, so if our setup is spread across a network, and the network is slow or unreliable, each task may be accompanied by a sizeable amount of latency. In such an environment, running too many tasks too frequently can significantly reduce the responsiveness of the system, leading to stutters, freezes and similar issues.
Delete results
When we upload new results, the old results on the server are overwritten, so manually deleting results is usually not required. Still, we may wish to do so anyways. If we uploaded dummy results to test our setup, it would be a good idea to delete them before e.g. sharing the link to our results page in the bulletin.
Manually deleting our results is simple: Looking at the Online pane, we find the aptly-named Delete Results button. Upon pressing the button, we are prompted for confirmation, and, if confirmed, the results on the server will be deleted.
Rather than deleting the results, another option is to upload blank results instead. Uploading results from the real competition before it begins allows the result server to display a more meaningful page with an overview of the participating clubs as well as the current standings.