May 2025

• The Riot server listening for WindBot data now properly implements connection closing upon not having received device heartbeat messages for more than 30s.
• Fixed parsing of X-Forwarded-For header, now reporting the correct client IP in case of multiple proxies along the way.
• Improved logging in case operations received from replicas are being applied. The log entry now shows the name of the server where the operation originated from.

March 2025

• We included a new AI Agent, based on SAP AI Core, that helps commenting races, live and replay. To configure the agent, the administration console has a new "AI Agent" tab. It shows whether credentials for the underlying AI Core service have been provided, allows users to provide these, shows which language model is currently selected for producing the comments and displays the list of events, allowing the user to select for which of those the AI Agent shall be activated to produce comments. The comments will be produced when certain events in those races are discovered, such as a start or a certain share of competitors having rounded a mark. This also means that races already loaded will not have their existing data commented on. But (re-)loading races as well as live races into selected events will add those comments, visible in the "Tags" side bar in the race viewer.

  Two optional system properties can be used to control the AI Agent:

  • sap.aicore.credentials: if provided, its value is expected to be a JSON document with AI Core credentials, as you would get from viewing your credentials of you AI Core instance in SAP BTP Cockpit; if not provided, credentials may still be provided through the Admin Console later.
  • sap.sailing.aiagent.modelname: if provided, selected a language model name to use; a model deployment by that name must be available in the AI Core account for which the credentials are valid. If not provided, or if no model deployment by that name can be found, a default model is used (currently gpt-4o-mini). Note that the model you choose this way needs to comply with the openai API for chat-completions in order to be used in this context.
• The Administration Console now allows you to configure trusted origins / domains for using Cross-Origin Resource Sharing (CORS) and hence access, in particular, REST API resources from the server or replica set you are administering, as well as the possibility to embed pages from that server or replica set in some other page's <iframe> HTML element, controlled through the Content-Security-Policy header field and its frame-ancestors directive. Both, wildcard or explicit sets of origins in the form of https://www.example.org can be specified. CORS restrictions map to corresponding values of the Access-Control-Allow-Origin HTTP response header field. You can find these new options here in the Advanced / Local Server panel of the Administration Console.

  Note that the settings you make there are specific to the replica set / server name of the environment you're administering.

  Also note that with the introduction of these configuration options, there are new, secure defaults. CORS requests are now by default allowed only from the same origin as the REST request goes to, and frame embedding is by default disabled. Should you have a scenario in which you have embedded Sailing Analytics pages in your web site using an <iframe> and would like to continue doing this, please get in touch (support@sapsailing.com).

  Note that this additional configuration data changes the format of the Security Service's initial load for replication incompatibly. A synchronized roll-out approach is required, upgrading primary/master nodes before upgrading their replica(s).

• File uploads now not only require an authenticated user to have object creation permissions on the target server, but additionally the user's e-mail address now must have been validated successfully.
• New passwords now need to have a higher minimum complexity than before.
• There is a new system property geonames.org.usernames that can be used to provide one or more (comma-separated) user names for the geonames.org service that we use to map coordinates to venue names and to determine time zones for races as used, e.g., in data mining.

February 2025

• In the admin console's Smartphone Tracking panel, when importing data from files to create new device mappings there is now a "Vakaros" / "VAKAROS_EXTENDED" menu entry when using "Import fixes" or "Import additional sensor data," respectively. With these, files obtained from Vakaros devices can be imported with their time stamps, GPS information (lat/lon, COG, SOG) and, when available, from the "additional" sensor data heel, pitch, and the two special values load_GDF1 and load_GDF2, which we map to the forestay load and the kicker tension values, respectively.
• When upgrading an application replica set through the Landscape Management panel, other target groups such as those from an NLB will be considered correctly for adding and removing temporary upgrade replicas and the primary/master node.
• Added a result importer for the typical Sailwave HTML output, such as https://www.rhkyc.org.hk/storage/app/media/Sailing/result/HONG-KONG-RACE-WEEK/2025/ILCA4.htm. You can add these types of URLs now in the Result import URLs tab of the Connectors category in the administration console.

January 2025

• When exporting wind from the Admin Console's Tracked Races / Tracked Races panel, the wind data is represented as "fixes" where COG and SOG correspond to TWD and TWS, as usual. Now, however, not only the COMBINED wind track is exported, but all detailed tracks of type EXPEDITION, WEB, WINDFINDER, and RACECOMMITTEE. The respective object names are constructed from the wind source types and IDs, e.g., "EXPEDITION (DC-FE-AAHJ)" and can be imported again in the Tracked Races / Wind panel now (see "Routeconverter"-based wind import).
• Fixed wind import from ZIP files exported by the Sailing Analytics. So far, file extensions of the files wrapped in the ZIP file were checked to be ".txt" which therefore ignored the .gpx, .kml, etc. file types that we normally export ourselves.

December 2024

• The Igtimi WindBot connector has been re-designed. This became necessary because Riedel Communications GmbH deprecated and then stopped their "Riot" back-end which so far allowed WindBot and YachtBot devices to register, send their data to and provide client applications access to live and historic WindBot data.

  The new architecture features a built-in "Riot" server replacement in every Sailing Analytics server. It can be configured using the igtimi.riot.port system property, which is controlled through the IGTIMI_RIOT_PORT environment variable set for the start script. When left empty, the Riot server will listen on a random port unused so far. This port can be obtained using the /igtimi/api/v1/server REST GET method, found in the port attribute of the JSON document responded with. The built-in Riot server is replicated by default, and devices and data access windows are kept synchronized between primary and replicas. Dedicated instances may be set up with the only purpose of acting as a highly-available Riot server farm. Messages sent to one of the instances in the replica set will make it to all instances in the replica set and will eventually get stored persistently in the primary's database.

  Devices can be configured to send to that port, directly to the server's IP address with the specific port, or, e.g., through a network load balancer such as the Amazon Web Services (AWS) NLB, allowing for multiple servers such as a primary/master and one or more replicas to be registered for high availability. With an AWS NLB it is important to configure the target group such that the client IP address is preserved, so the server knows where to send responses and commands to.

  Instead of managing Igtimi "Accounts" there now is a system property igtimi.base.url that defines the base URL of the Riot service to which the Sailing Analytics server will connect for live and stored WindBot data. The new environment variable IGTIMI_BASE_URL is mapped to the igtimi.base.url property in the start scripts. The property defaults to https://wind.sapsailing.com. By default, authentication for the remote service is handled using the local user's bearer token of the user tracking or owning the race for which wind data is requested. The igtimi.bearer.token system property can be used as an override, e.g., in case the local Sailing Analytics server does not share the security service with the replica set running the Riot service. The corresponding environment variable is IGTIMI_BEARER_TOKEN. With this, the igtimi.client.id and igtimi.client.secret system properties, as well as their environment variable counterparts IGTIMI_CLIENT_ID and IGTIMI_CLIENT_SECRET, respectively, are no longer used.

  The new version of the Igtimi Devices panel in the Admin Console (see /gwt/AdminConsole.html#IgtimiDevicesPlace:) now shows the devices and their sharing to clients through so-called "Data Access Windows." The device entities are created automatically when messages are received. Data Access Windows (DAWs), however, need to be created manually in order to share the content delivered by the devices with authenticated users. You can use the DAWs' ownership and access control list (ACL) settings and grant users explicit permissions to individual DAWs. Click on the "Change Ownership" action icon to see the key of a DAW in case you want to use it in an individual permission that you grant to a user.

  There is a REST API that mimics the old Riot REST API to a certain degree. Sailing Analytics users and operators typically don't work with this API directly. Yet, the API is exposed under /igtimi/api/v1 and has end points for managing devices and DAWs, retrieving data recorded from the devices, as well as for finding out the web socket server end point for connecting to live data and connecting to it, and the above-mentioned method for finding out the Riot server socket's listening port.

  The protocol used for transmitting device data to REST API clients has changed in so far that the device message payloads are no longer sent as JSON objects; instead, the original Protocol Buffer (protobuf) binary messages are encoded using Base64 and transmitted as an array of such Base64 strings.

November 2024

• The system property for removing the SAP branding from the solution has changed its default. It used to default to false, meaning that by default the entire solution shows SAP's branding. Prior to publishing the repository under an open-source license we'd like to make clear that only SAP-reviewed versions such as from https://github.com/SAP/sailing-analytics are supposed to show this branding. Any other fork must not, and the regular rules for the use of the SAP trademark apply. See also brand.sap.com. Therefore, we change the default value of this property to true.

September 2024

• When removing the denotation for smartphone tracking from a race, tracking of that race will now be stopped and the tracked race will be removed. This ensures consistency when later the denotation should be added again.
• A file importer for the Queclink GL300 format (see, e.g., here) has been added. This way, you can now create a "smartphone-tracked" race and import a file that contains messages recorded from GL300 devices. Those messages look like this:

                    +BUFF:GTFRI,301201,860599002480051,,0,0,4,1,,,,-2.872803,52.161116,20240710154359,,,,,,1,,,,-2.872803,52.161116,20240710154404,,,,,,1,,,,-2.872803,52.161116,20240710154409,,,,,,1,,,,-2.872803,52.161116,20240710154414,,,,,,60,,21B0$
                  

  The importer naturally supports out of order delivery. The position-related data doesn't have to be ordered by increasing time stamps. This way, you can also activate buffering in your GL300 such that when the tracker comes online again, live data transmission takes precedence over transmitting the data buffered.

August 2024

• When importing race results for race columns with column factors different from 1.0, score difference highlighting now properly considers those column factors. This should help in particular when importing medal race scores which by default are doubled.
• Inserting wind data into the database on the importing side of a "Master Data Import" is now quicker, using mass insert instead of inserting the wind fixes one by one.
• Added Zoom8 as new pre-defined boat class.
• Switched from Launch Configurations to Launch Templates for AWS landscape automation. When this release is deployed, you will only be able to fully manage application replica sets based on Launch Templates. Those still based on Launch Configurations then need to be migrated manually in the AWS EC2 Console before you can manage those replica sets again with this release.

July 2024

• A regatta's end date is now considered for deciding whether to display the regatta as still "in progress." A regatta will be shown as "finished" now even if not all its races (as may occur particlarly in split-fleet scenarios) have been completed, as soon as the regatta's end date has passed.
• Upgraded TracAPI to version 3.15.13, resolving issues with deadlocks based on HTTP ports being blocked.

June 2024

• Upgraded to TracAPI 3.15.8, supporting more TracTrac invalid result markers (IRMs), in particular DCT, DNE, and RCT.
• For raw data output of wind sensor and object positions, where permitted, use seven instead of six decimal places in lat/lng output to increase resolution to approximately 1cm.
• Fixed concurrency issue with subscription webhook callbacks which in rare cases led expiring subscriptions or failing payments to not properly revoke user permissions.
• When archiving a replica set, any remote reference pointing to it from the archive running at www.sapsailing.com is being removed. Now, the same reference will also be removed from the failover archive at archive-failover.sapsailing.com to reduce inconsistency and a circular reference structure in case we need to switch to the failover.
• Upgraded to TracAPI 3.15.9, filtering mark positions by course area on the server side now and offering the client archived MTB files instead of live DB access where available.
• Upgraded to TracAPI 3.15.10, fixing a bug introduced by TracAPI 3.15.9 regarding locally overriding the so-called "stored data URI"
• Added class "Wingfoil"
• TracAPI 3.15.12 fixes the MTB file reader that was not releasing all the resources once the reading process was over.
• Added class "RS Vareo"
• Fixed Czech translation for the headerLogo of the web interface: 'Sailing Analytics' is now used instead of czech phrase.

May 2024

• Reading the wind estimation data from a server during start-up, using the windestimation.source.url system property, now requires authentication. The java/target/start script now reads the WINDESTIMATION_BEARER_TOKEN variable and passes it as the windestimation.source.bearertoken system property to the application. The user authenticated by that token must have the WIND_ESTIMATION_MODELS:READ permission for the server identified by the URL provided in the windestimation.source.url property, for example WIND_ESTIMATION_MODELS:READ:ARCHIVE if the URL is https://sapsailing.com
• Reading the polar data from a server during start-up, using the polardata.source.url system property, now requires authentication. The java/target/start script now reads the POLAR_DATA_BEARER_TOKEN variable and passes it as the polardata.source.bearertoken system property to the application. The user authenticated by that token must have the POLAR_DATA:READ permission for the server identified by the URL provided in the polardata.source.url property, for example POLAR_DATA:READ:ARCHIVE if the URL is https://sapsailing.com

April 2024

• The TracTrac connector now pools and re-uses event subscriber threads for live connections for the same event with equal stored and live URIs. This helps reduce the number of threads running in the system and is "friendlier" on the TracTrac infrastructure regarding the number of concurrent connections the system needs to manage.
• During live TracTrac connections, mark positions are now filtered by the race's course area if both, mark and race, specify one. This way, redundant and excessive mark fixes can be avoided, don't consume extra memory and don't waste replication bandwidth. See also bug 5919.
• Fixed file upload for Chrome browsers after Chrome made an incompatible change, appending a combination of <div> tags after the already <pre>-enclosed form submission completion payload.
• The TracTrac connector will no longer disconnect from a race when it is abandoned. It is now assumed the race will be re-sailed, and so the connector will keep tracking the race.
• Fixed handling of null values in "compareservers" end point.
• Upgraded to TracAPI 3.15.7, fixing an issue with static mark positions not transmitted during live races.
• The LOW_POINT_WITH_ELIMINATING_MEDAL_SERIES_PROMOTING_ONE_TO_FINAL_AND_TWO_TO_SEMIFINAL scoring scheme, as used typically for iQFOil formats with quarter/semi/grand finals, now does no longer require explicit column factors of 1.0 for those medal-series race columns. The medal series-based doubling is deactivated now for this scoring scheme. Should you have relied on this scheme doubling your medal series scores, you now have to adjust the column factors for those race columns to 2.0 explicitly.

March 2024

• Support the "AIN" IOC code for "ATHLÈTE INDIVIDUEL NEUTRE" with its special flag.
• Bug fix: in landscape automation, when moving all process instances away from a node to other nodes, in-place replica re-starts were erroneously performed using the "root" user instead of the "sailing" user. Not only were the processes running with the wrong user; this would also create folders with incorrect ownerships which then were no longer writeable for the "sailing" user which later led to problems with re-starting those processes, such as after a version upgrade.
• For new stand-alone instances, the new default type suggested is c5.2xlarge which is less expensive with similar characteristics as the previous default c4.2xlarge.

February 2024

• The TracTrac API now offers STP and SCP as new race competitor status values that we now map to our corresponding "IRM" / penalty codes.
• A bug in the way mark passing calculation results were stored persistently lead to some races "losing" their mark passings when the server was re-started. This bug is fixed now.
• Upgraded embedded Jetty web server from 9.4.44 to 9.4.54. See CVE-2024-22201 and Jetty issue #11256.

January 2024

• When launching a new application replica set in a region, the choice of the default RabbitMQ server now depends on the region: in our "default" region "eu-west-1", RabbitMQ is identified by the DNS-mapped host name "rabbit.internal.sapsailing.com". Elsewhere, the RabbitMQ server in the region is explored using the RabbitMQEndpoint tag. If not found, again "rabbit.internal.sapsailing.com" will be used, assuming there may be a VPC peering across regions.

October 2023

• TracTrac and YellowBrick passwords are no longer sent back to the client; there were ways to discover those passwords from the password fields by tweaking with the browser's debug tools. When leaving the password field empty during updating a connectivity record, the password will simply be left unchanged.
• The TracTrac "Update URI" is now discovered from the new field server_update_uri in the JSON document describing an event. This way, users don't need to enter it unless they want to override the default with some special value. It is therefore now usually sufficient to enter a user name and password combination in order to activate these updates that are sent back to the TracTrac server.

August 2023

• Added a new racing procedure SWC_4MIN for kites and windsurfers with a shortened four-minute start sequence with green flag for one minute after start.
• The layout regression in leaderboard configuration panels ("Leaderboards / Leaderboards" and "Connectors / Smartphone Tracking") has been fixed. The help text has moved above the two caption boxes, and action icon columns for the two bottom tables now resize in lock-step, letting the rows of the two adjacent tables typically have similar, if not the same, height.
• Course areas can now optionally be specified with a center point and radius for display on the map.
• Bug fix: when allowing for competitor updates in combination with the TracTrac connector, the updates were not applied properly to the Competitor records in case of a "league" setup where competitors can change their boats in the context of their regatta.
• Macao and Faroe three-letter IOC / Noational Paralympic Committee codes according to https://en.wikipedia.org/wiki/List_of_IOC_country_codes are now supported (MAC and FRO, respectively).
• Added "303" as alias name for the "Hansa 303" class
• Added "RS Venture" boat class with icon
• The race logs for leaderboards to which the logged-in user has READ permission are now visible under /gwt/AdminConsole.html#LeaderboardsPlace:.
• The TracTrac connector will now ignore mark positions from marks tagged with a course area that is different from the non-empty course area with which the race is tagged (if any). If either the mark or the race or neither are tagged with a course area on TracTrac's side the mark position will be processed.
• Auto-Scaling Groups created by landscape management now have monitoring enabled by default.
• Bug fix: selecting more than one shard for removal in the Landscape Management panel now works properly and removes all shards selected, not only the first.
• Tracked races without start time are now sorted towards the "later" end of the list.

July 2023

• Score updates received through the race log, e.g., from the SAP Sailing Race Manager app or from the SwissTiming tablets through a TracTrac race connection, will update a leaderboard's "last update" time point only if it is newer than the already existing latest score correction time point. This way, if updates are received out of order it will be the latest update defining the last score correction time point.
• Bugfix: when computing a leaderboard's live delay, not the last race with a valid start time but the "rightmost" race connected to a column in the leaderboard was considered. For example, when the current live race "R3" has a live delay of 2s and there is another race "R4" already connected to the leaderboard with a live delay of 30s then the live delay for the leaderboard will end up being considered to be 30s, not 2s. This is now fixed.
• The /sailingserver/windStatus page now also shows battery levels if received.
• Tolerate TracTrac competitor status and result updates for unknown competitors (e.g., hidden ones such as jury boats that are tracked). This avoid issues with making race results official, too.
• "IQF" is now an alias name for "iQFOil"
• Introduced "SCA" as a new invalid result marker (IRM). When used together with the scoring scheme "LowPointWithAutomaticRDG", a default score is computed based on average of the competitor's scores in all races prior to the one for which the SCA has been given. This implements RRS A9b.
• Introduced a new scoring scheme: "Low point system; Medal races as quarter final, semi final and grand final." It is well-suited for the iQFOil format as seen in the years 2022/2023. Model each of the Quarter Final, Semi Final, and Grand Final as a separate "Medal Series" with one race each. The scoring scheme understands that the best competitor of the opening series advances to the last medal series (e.g., "Grand Final"), and the second and third of the Opening Series advance straight to the Semi Final (last-but-one medal series).
• The invalid result markers (IRMs) SCP, STP, DPI, and RDG can now consider optional incremental score corrections which are added to the points determined based on the competitor's rank in the race and the scoring scheme that applied to the race. For example, a DPI penalty with +2.5 points may now be specified which applied during tracking the race. Absolute score corrections will be considered for these IRMs at the end of the race, regardless the incremental score correction. Note that the increments are subject to any column factors being applied; this may contradict an event's rules that may state that certain penalties, such as STP are not subject to doubling for a medal race. In such cases, specify half the penalty when editing the increment. Specifying and incremental penalties can be done on the /gwt/LeaderboardEdit.html reachable from the administration console's Leaderboards/Leaderboards tab (red dice symbol). They are displayed there in brackets behind the score and an optional IRM code, as in "17 DPI [+1.5]". Clearing the corresponding field in the editing popup dialog removes the incremental scoring offset, just like clearing the IRM code drop-down or the absolute score correction removes the values there, respectively.

June 2023

• When importing results, sorting of the result documents has been improved. The drop-down now puts those result documents at the top that have the relatively longest match of their class name with the regatta's class name, also now considering all alias names for the class known to the system. For equally likely matches the newer result document is preferred. The score importer used last is remembered in the user preferences now and suggested by default. The most likely result document from that "default" score provider is suggested for import if the boat class name has sufficient overlap with the leaderboard's boat class name.
• In the Admin Console Regattas section, the table now features a course area column. This was previously shown in the Leaderboards table only.
• Handling an error condition more "gracefully:" when in the "Low Point, First to Win Three Races in Final" a competitor was assigned a number of carried wins, but that competitor then did not compete in either of the semi-final fleets, an internal error would keep the entire leaderboard from displaying. This is now ameliorated by logging a warning and sorting such a competitor as "worse" than others with equal points/wins.
• When archiving a DNS-mapped replica set, the load balancer rules were removed only after even the master process was stopped. Furthermore, all replicas were stopped even if the master was not part of the public target group, before the load balancer rules were changed. This led to the unfortunate situation that the reverse-proxy rule that was already active would not get triggered until the load balancer rules for the replica set were finally removed, letting users receive error 500 status codes. Now, the master is first added to the public target group if it wasn't already a part of it, then all replicas are stopped, then the load balancer rules are removed, and then the master is stopped. This will increase availability, particularly during a replica set archiving process.
• In the landscape management panel it is now also possible to provide an already existing AWS session token together with access key and secret for logging in. This can help, e.g., when a corporate standard requires signing in with non-IAM roles or accounts where the typical IAM MFA login is not supported. See your ~/.aws/credentials file for a possible session token and see, for example, the aadawscli tool for producing such session credentials from an Azure Active Directory authentication scheme.
• Igtimi wind import now will trigger un-archiving of archived wind data. From the Igtimi web site: "All resources stored on the Igtimi servers will be archived if they are older than 6 months and have not been accessed for 4 months. When data is archived it is flagged as''“is_archived = true''". Note that when you hit archived data, while unarchiving is triggered, it will happen in the background and take up to a few minutes. You will then have to try again to actually receive the unarchived data.

May 2023

• When a user with landscape management permissions creates a new application replica set, e.g., for a new event and the user group created for the new server ("...-server") is also new then the user creating it will now automatically be assigned the role server_admin qualified for the new "...-server" group which will allow him / her to manage all technical aspects of the server. The role is assigned "transitively" so that the user may pass it on to other delegate users. This complements the transitive assignment of the user role qualified for the new "...-server" group which the user creating a group has always received, also before this update. See https://wiki.sapsailing.com/wiki/info/security/permission-concept for more details.
• When removing a replica set, now the selection in the table showing the MongoDB endpoints is honored: when a selection has been made there, after successfully removing the replica set, its master database will be moved to the MongoDB endpoint selected and will, after successful comparison with the original, be removed from its original location. Likewise, a new parameter is available for the corresponding REST API endpoint for removing replica sets.
• An STP or SCP scoring code ("Standard Penalty" / "Scoring Penalty") now by default adds 1.0 to the competitor's score as calculated based on the ranking. The STP / SCP code is shown already with the beginning of the race, but any official scoring result entered after the race will be used during replay only once the competitor has finished the race. For the medal stages of the new Formula Kite scoring (Low Point, First to Win Three Races, both, the A8.1 and A8.2 variants) an STP / SCP will add 1.1 to the competitor's score.
• The "Low Point, First to Win Three Races" scoring schemes, which rank competitors in the medal series based on the number of "races won" now count a win if the competitor has achieved the lowest score in that race. This changes the previous rule where the competitor needed to score 1.0 points in order to be called the "winner" of that race. In particular, with this change a competitor with, say, 2.0 points can be the "winner" of the race in case the competitor finishing first took a standard penalty (STP) or scoring penalty (SCP) which adds 1.1 points to the 1.0 point awarded for finishing first, so a total of 2.1 points, thus worse than the 2.0 points of the competitor finishing second. Should there still be a tie on points, the finishing order is used to break that tie.

April 2023

• Added boat classes "IMOCA", "VO65" and "VO60"
• Implemented a new scoring scheme that ignores A8.1 tie-breaking and only uses A8.2 (last race, second-to-last, etc.)
• Implemented a new scoring scheme that supports the Formula Kite medal series format but ignores A8.1 tie-breaking and only uses A8.2 (last race, second-to-last, etc.)

March 2023

• Users with administrative permissions on a server replica set will now be notified by e-mail about important events affecting the replica set, such as when the primary server instance is upgraded or moved and hence the replica set temporarily cannot accept write requests, or when the replica set is being archived and hence no other archiving should be run at the same time and the replica set being archived should not be modified during the archiving process. The SERVER permissions checked are CAN_IMPORT_MASTERDATA and CAN_EXPORT_MASTERDATA for the archiving process, and CONFIGURE_LOCAL_SERVER in case of the primary server becoming unavailable. E-Mail is sent only to addresses that were previously validated successfully.
• The landscape management panel in the administration console now offers a new action to move all application processes away from a server instance to a new one of which the user can determine the instance type. This is helpful, e.g., when a shared instance has an outdated image / installation, requires kernel updates or other things that at least would require a re-boot. Instead, moving to a new instance which is launched off the latest default image gives a fresh platform to launch the application processes on.
• The list of Amazon Machine Images in the landscape management panel now shows the AMI ID as a link that will open an AWS console, showing the instances launched off that AMI. This way it becomes easy to see which instances are using which of the managed AMIs.
• SSH keys produced with new versions of OpenSSH as well as the highly secure ED25519 keys are now supported for AWS landscape management. This removes the requirement to convert new OpenSSH keys to PEM format before starting to work with them.
• For the DNS name resulting from a new replica set name and an optional domain name or the default domain name (sapsailing.com) it is now checked that this name is not taken yet. An error message will be shown otherwise.
• Sorting of replica-set table by name is now case-insensitive.
• Bug fix: when working cross-region with the Landscape panel, temporary upgrade replicas were identified trying to obtain their host name from their IP address. When this is attempted, however, for an IP address identifying a host in one region and the host name is determined from within another region then the internal DNS name chosen is that of the other region and therefore incorrect. Instead, now the IP address's numeric representation is used instead.
• The scoring scheme "Low Point System, First with three wins in medals is winner" has been adjusted to meet the Olympic requirements; see official ORIS document OG2024_SAL_ORIS_R8_V1.2_20230330.pdf. It should be used as follows: An opening series, optionally split into qualification and final series in case the fleet is split, is followed by two medal series: one for the semi-final, and another for the grand final. Both of these medal series should start with a carry-forward which will be interpreted by the scoring scheme as the "number of wins carried forward." These carried wins need to be entered manually into the leaderboard (two wins for the best-seeded, one for the second-best seeded competitor for each fleet in those medal series). The semi-final series should consist of two fleets (A/B, equal rank 0) and will need seven race columns in addition to the carry-forward column because four competitors will race for the first to take three wins (defined as score 1.0 by the document), with a total of three carried wins may take six races at most, but due to a standard penalty (STP) no competitor may score a win in the first race of a semi-final fleet.

  The grand-finalists also race for the first to take three wins (including the carried-forward wins). They are ranked by wins, then by the last race rank, then by the second-to-last race rank and so on, up to the first grand-final race, and then by the opening series rank. Likewise, the semi-finalists will be ranked in their respective semi-final fleet. For their overall rank of the competitors ranking 2nd to 4th in their semi-final the two equally-ranked competitors from fleets A and B will be compared based on their opening series rank.

February 2023

• Added ability to upload multiple video or image files of an event at once. It also includes some optimizations and bug fixes.

January 2023

• Support for managing sharded replication in the "Landscape" panel of the "Advanced" category in the admin console), offered as a new icon in the "Action" column of the replica sets table: in the new dialog that pops up you can create and remove so-called "shards" to which you can assign zero or more leaderboards offered by that replica set. Each shard gets its own auto-scaling group and target group in addition to the regular auto-scaling group / target group pair used for the public target group. By default a minimum of two instances are required by each shard to ensure availability. They are created with the same launch template used by the replica set's regular public target group. When a shard's instances are healthy, rules are managed in the replica set's load balancer to route traffic regarding the leaderboards selected for the shard to the shard's target group. This reduces traffic on the default public target group, and the instances of the shard can focus on the sub-set of leaderboards configured instead of having to compute all leaderboards in parallel. This helps reduce the leaderboard re-calculation times for live events with parallel live races in several classes and tens of competitors per leaderboard.
• Introduced new permission EVENT:UPLOAD_MEDIA. With this special permission, a user who does not have the full EVENT:UPDATE permission can still add (not remove or edit) media to an event, in particular images and videos. In our production environment the role event_manager grants this permission now, too, so users having that role can grant EVENT:UPLOAD_MEDIA to other users or the general public at their likings.

December 2022

• Added Czech language support
• Imported magnetic declination tables for 2023 from NOAA

November 2022

• Bug fix: when archiving a replica set, waiting for the MongoDB hash computation to complete now will no longer fail with a CancellationException.
• The landscape management panel shows a more logical structure and validates the SSH key's passphrase before using it in interacting with systems.
• Column for auto-scaling group's AMI ID in landscape management panel is now searchable and sortable.
• New scoring scheme for the 2024 Olympic Kite format, called "Low Point System, First with three wins in medals is winner": it uses regular low point scoring for the opening series (anything up to and excluding any medal series race) with the usual RRS A8.1 tie breaking; for any subsequent sequence of medal series the scheme counts the wins, and a non-discardable carry column starting a medal series is taken to mean "wins carried into that series," not points. A competitor is said to have "won" a race if no other competitor scored better in that race, including any penalty points or other score corrections. Should this definition apply to more than one competitor, e.g., because all competitors got disqualified, were OCS or DNF, or because the first to cross the finish line received an STP of one point and hence scores equal to the competitor crossing the finish line in second position, then a winner is picked randomly. To decide a winner in this case, a manual score correction in favor of the desired winner is required.

  In the net points sum column, the leaderboard will show wins, not points, for competitors who sailed in the medal series. Tie breaking for medal series competitors is first by the index of the medal series competed in (finalists rank better than semi-finalists who did not sail in the final); second by the number of wins; third by the score obtained in the competitors last medal race; and fourth by the rank obtained in the opening series.

October 2022

• Bug fix: when moving replicas from dedicated to shared instances, now their memory configuration (absolute or relative) is propagated into their configuration correctly.
• User groups can now also be filtered by their ID.
• The user group and user owners in the "Local Server" tab are now clickable and navigate to the User Group Management and User Management tabs, respectively.
• Mostly transparent to the end user, we have introduced a new version of the protocol used to transmit data from the server to browser clients. With this new version, even large data sets will be streamed with constant memory footprint and with less CPU load, making a clogging of a server less likely even if several users make requests that solicit large responses.

September 2022

• Series within a regatta now support a configuration option that, regardless a race column factor, keeps the 1.0 score as 1.0, scaling the other scores accordingly. For example, the scores 1, 2, 3, ... with a column factor of 2 would then be mapped to 1, 3, 5, ... Use this, e.g., to model iQFOil slalom races with heat split where the general opening series does not use split fleets.
• A new leaderboard type is now available which can refer to another leaderboard for tie-breaking. An example could be the Formula Kite rules where the high-point medal stage leaderboard is required to use the low-point opening series leaderboard for tie-breaking under certain circumstances. New scoring schemes may follow that use this new construct.
• A new scoring scheme "High Point System, Match Racing, Tie-Break Based on other Leaderboard" is now available which uses the new type of leaderboard which can reference another leaderboard for tie-breaking. Note that when choosing this scoring scheme for any leaderboard but one that references a tie-breaking leaderboard, the tie-breaking leaderboard functionality will simply be ignored, making it equivalent in behavior to the simpler "High Point System, Match Racing" scoring scheme. It does not by default double scores in medal race columns. Instead of a regular RRS A8.1 score comparison based on sorting all scores, this scoring scheme uses the last race's finishing order for tie breaking before resorting to the other leaderboard referenced.
• Added boat classes "Beneteau First 35" and "Beneteau First 45" with their class logos.
• Setting a race's finishing/finished time now also updates a tracked race's "newest event" time point, helping with cache invalidation and getting used when determining a leaderboard's fall-back time point when requesting it for the "live" time point.

July 2022

• New load balancers that are created on demand now use the SSL policy "ELBSecurityPolicy-FS-1-2-Res-2019-08" to disable TLS 1.1 for new load balancers. It has already been disabled manually for all existing ones.
• In the Landscape management panel, replica set actions for the local ("active") replica set through which the action is triggered are disabled in case they could lead to the replica set's master process being stopped, moved, or re-started because this could interrupt the transaction while being processed, with undefined results.

June 2022

• Bug fix: when only the maximum number of discards of a series was changed, the leaderboard caches were not properly invalidated, hence results wouldn't have been recalculated up to the next "real" change.
• Replication performance has been updated. Less metadata overhead, parallel serialization for asynchronous operations on the master node, and a versioned, yet backward-compatible protocol help to avoid congestion situations when, e.g., re-loading races on a master node during live operations with several replicas attached.

May 2022

• To configure remote server references, instead of the SERVER:UPDATE permission users now need the more specific SERVER:CONFIGURE_REMOTE_INSTANCES permission.
• Running subscription updates is now avoided on replica servers.
• Added the penalty code (IRM) "NSC" to the XRR schema, e.g., for allowing it to be imported from XRR sources such as Manage2Sail.
• Bug fix: when renaming a series while adding/removing columns to/from it, the model, especially on a replica, could become inconsistent due to operations interleaving. This is now run in sequential order, avoiding the undesired interleaving.
• Added WASZP boat class

April 2022

• Note: the new "paywall" has been activated. There is a new role called "premium" that paying users can obtain. In case you have security super-powers you can add this role to an event's user group and imply it to all its users if you want to relieve this event from the restrictions of the paywall. Other than that we hope for your understanding regarding the introduction of this subscription-based model as it helps us to keep the SAP Sailing Analytics alive and available to you.
• The page used to edit leaderboard scores now shows the name or display name of the leaderboard in the header.
• Errors during reading the wind estimation and maneuver classification models now lead to an attempt to import them again from the URL specified for this purpose.
• Loading a race with replicas attached now achieves higher throughput on the replicas while inserting wind/mark/competitor fixes into the tracked race. This has been achieved by keying the replication operations based on their lock contention and parallelizing only those that do not compete for the same locks.
• A WindFinder spot collection "lago_maggiore" has been added.
• A competitor's e-mail address field can now contain a comma-separated list of e-mail addresses. Invitations will then be sent to all of those e-mail addresses. Note that if multiple devices accept such a single invitation that was sent to multiple addresses then users must make sure that no more than one device is actively tracking at any time. Otherwise, jumping tracks can be the result.
• Avoid a deadlock that could occur for ORC Performance Curve Scoring based on implied wind only (the pre-2015 rules).
• When denoting a split-fleet regatta for smartphone tracking, races in colunms with more than one fleet will now automatically be marked to define their own set of competitors.
• The leg data for ORC Performance Curve Scoring in the "constructed course" variant can now also be captured as TWD and leg direction, calculating the leg's TWA from these.

March 2022

• The REST API calls for /sailingserver/api/v1/regattas/{regatta}/races/{race}/... that export raw data now look for an HTTP request header field secondaryuserbearertoken and if present, use its value to authenticate a user that then must have the TRACKED_RACE:EXPORT permission for the race requested. Still, the regular ("primary") subject used to authenticate the request must have the REGATTA:READ and the TRACKED_RACE:READ permission for the respective entities.
• A new result importer for use with sailti.com has been added.

February 2022

• The policy for selecting replication instances can now be switched for running replica sets. Users now have the possibility to switch from a replica running on a shared instance to the use of dedicated replica instances, fully managed by the auto-scaling group. Conversely, a replica set using only fully-managed dedicated replica instances can be switched (back) to a more cost-efficient, yet still highly available replica running on a shared instance if workload does not require additional replicas launched by the auto-scaling group.
• A replica set's master process can now be moved to a different instance. Users can choose between moving to a shared or a dedicated instance. With this, a replica set that started out in an inexpensive shared set-up can me modified so that it uses a dedicated master instance. Furthermore, with this a scale-up and scale-down for the instance hosting the master process is now supported.
• Added a Remove button for application replica sets that is mutli-selection aware.
• The instance type of the replicas managed by a replica set's auto-scaling group can now be modified, and one by one, the replicas in the set managed by the auto-scaling group will be migrated to the new instance type, always keeping at least as many replicas available as there were when the action was started. Available as action icon and as multi selection-aware action button.

January 2022

• Landscape management now offers to upgrade auto-scaling groups after an AMI update.
• Replica sets can now also be managed on shared instances. This goes for new master processes which can be deployed into the instance hosting another replica set's master process, or into a new instance prepared for being shared. Alternatively to having the auto-scaling group provide a dedicated first replica to increase availability, users can now choose to have a replica be deployed to a shared instance that runs in an availability zone different from that of the one hosting the replica set's master process. If no such shared instance with the port required by the new replica set available, a new one is created in an availability zone other than the one hosting this replica set's master process, and the first replica is deployed onto that.

  With these steps, operators are now able to set up new replica sets using only shared instances when starting. While auto-scaling replicas will still be launched into new dedicated instances when the workload requires it, small-scale set-ups with low workloads can now be mapped very cost-effectively.

December 2021

• The import of data from another server ("Advanced - Master Data Import") now waits for tracked races to have finished loading when tracking the races imported has been requested. In this case, the sub-progress of that step is determined by the share of races that already have finished loading.

October 2021

• Added "Elan 350" boat class
• Added "IRC" as a class
• Fixed issue with mixed-up boat ID and competitor ID during competitor import
• A new experimental connector for YellowBrick is now provided. Provide a "race URL" such as "rmsr2021" to start tracking a race. It is advisable to import competitors up-front. A CSV file, as exported, e.g., from Excel, that has the column headers
  • Race Name
  • Sail Number
  • Model
  • loa
  • Entrant
  • Country
  • Skipper
  • cat-IRC
  • IRC
  • MOCRA
  • DH
  • ORC only
  • YellowBrick Name
  • Competitor ID
  will be parsed properly. The "YellowBrick Name" column must contain the name exactly as it appears in the YellowBrick API for the boat. The "Competitor ID" column must be constructed as "YB-{raceURL}-{YellowBrick Name}". For example, if your race URL is "rmsr2021" and a competitor has the YellowBrick Name "BAIT" then the "Competitor ID" must be "YB-rmsr2021-BAIT".

  The IRC column holds the handicap ToT / TMF / TCC value (e.g., 1.013) The "cat-IRC" is a category / classification, such as "Class 5" which will show in the competitor import as a suggestion for the fleet name. MOCRA, DH, and ORC only are columns which may be empty or have any non-empty string such as "x", indicating that the competitor is competing in the MOCRA, Double-Handed, and/or ORC class. If the "cat-IRC" is "undefined" then "ORC only" competitors will have "ORC" suggested as the race name and fleet name.

  The connector will ask for new positions every minute which is safely below the request quota of once every five seconds set by YellowBrick. If the newest fix is more than 24h old, the tracker stops requesting new positions automatically.

• It is now possible to copy course marks, course definitions and marks' tracking device associations from one regatta to another. Use the "Copy Course and Competitors" action icon in the "Connectors - Smartphone Tracking" race column list bottom left.

September 2021

• Let Igtimi connections that search devices while holding locks time out after 10s. This avoids rare deadlock issues in case the Igtimi servers may not deliver an answer.
• Landscape management now offers an implementation for archiving an application replica set.

August 2021

• Added boat classes iQFOil Men/Women/Youth

July 2021

• Creating and editing a Regatta object now uses the already loaded Events with their course areas to offer the event and course area selection in the Regatta dialog. This accelerates opening the dialog significantly, especially when used on a server with many events, such as the archive server or any public server such as my.sapsailing.com.
• Fixed a problem with Manage2Sail competitor import which had been introduced when the YachtScoring competitor import had been added.
• In order to restrict an overwhelming and uselessly long list of objects to select from, object lists are now reduced in several more places, based on permissions. For example, a user will only be offered those Leaderboard Groups for selection in the Event create/edit dialog that the user has the UPDATE permission for. Likewise, the events providing the course areas to select from are restricted when creating/editing a Regatta or a Flexible Leaderboard and when setting up a Race Manager App device configuration. The same applies to the list of events shown in the select box in the Manage2Sail Regatta Structure Import panel. Also, the leaderboards table in the "Leaderboards / Leaderboard groups" panel now has a filter checkbox that by default displays only those leaderboards that the user has the UPDATE permission for.
• A problem with uninitialized race timings may have led to endless loops trying to identify a valid time range for wind sampling. This has been fixed now.
• A Slovenian translation of the user interface has been added.
• The IOC code for "Russian Olympic Committee" is now available under the "ROC" abbreviation.
• Empty Igtimi WindBot messages, such as a COG message with no payload, no longer causes an uncaught exception but is now handled properly and logged accordingly. Other fixes in the same message now are processed as they should.
• After Igtimi changed their WebSocket implementation, we had to lower the heartbeat sending interval from 120s to 15s which now avoids connection interrupts.
• The /sailingserver/api/v2/leaderboards/{leaderboard-name} API now also delivers the currentSpeedOverGround-kts field if the competitor is not yet in the race.
• The /sailingserver/api/v1/regattas/{regattaName}/races/{raceName}/markpassings API method has been extended to also deliver the "raw" passing order (which can vary from the tracked rank, e.g., because a handicap ranking metric is in use), as well as a hypothetical score that one gets by passing the passing order through the scoring scheme and applying penalties or score corrections. Furthermore, the IRM/MaxPointsReason is output. See /sailingserver/webservices/api/v1/raceMarkPassingsGetDoc.html for more details.

June 2021

• Infer a tracking start/end time from race start/end time only if the regatta is marked accordingly.
• Bugfix in landscape management: when upgrading a replica set whose SERVER_NAME property does not equal the hostname used to address it, the temporary replica was trying to replicate from {SERVER_NAME}.sapsailing.com instead of {hostname}.sapsailing.com.
• GRIB file import in the "Tracked Races / Wind" panel now turns each position into a separate wind source, leading to better visual interpolation in streamlet display on map.
• The de-selection of wind sources for particular races in the tab "Tracked Races / Wind" is now stored persistently. This way, the de-selection survives re-loading of the race as well as re-starting or upgrading a server.

May 2021

• Added the RS21 boat class including logo, hull length and visualization type as a pre-defined boat class.
• Fixed an error regarding removing of non-transitive roles.
• Fixed problem with changing the ownership hierarchy of event series that have a leaderboard group with an overall leaderboard.
• Bugfix: When selecting "ORC Performance Curve (>>=2015, leader as baseline)" the certificate management button was missing in the Regatta panel in the AdminConsole. This has now been fixed.
• Bugfix: When an incomplete ORC certificate that is missing allowances for certain pre-configured course types, such as "non-Spinnaker," then loading those certificates after a server re-start failed. This problem has now been fixed, and such missing allowances will be represented as 0.0s values.
• Bugfix: ORC leg parameters editor reported tracked TWA flipped by 180°.
• Added "sanfrancisco" as a new WindFinder spot collection, covering several stations around the San Francisco Bay
• Bugfix for a regression: Updating the TracTrac live delay stopped working when no "official result reconciliation" was selected.

April 2021

• The /sailingserver/api/v1/wind/putWind method now has a missing null check in case there are untracked regattas in the scope analyzed for races that would accept wind fixed.
• Importing of results where sail numbers have leading or trailing space/blank characters works now.
• Image URLs used for events must not use the insecure HTTP protocol anymore; they have to use HTTPS now, meaning they should start with "http://".
• Fixed a problem with API access to seasonal/overall leaderboards regarding reporting "official" status. Clients received an error message when querying seasonal leaderboards. This is now solved.
• Fixed a regression regarding user e-mail validation, introduced when AdminConsole started supporting place / panel identification through URL fragments (such as https://www.sapsailing.com/gwt/AdminConsole.html?locale=es#UserManagementPlace:). The problem was caused by the fragment (#UserManagementPlace:) preceding what was supposed to be the URL parameters identifying the user and validation code. As a result, a user trying to validate an e-mail address would have seen an error message informing about a "null" user that couldn't be found.
• The "Refresh" button in the Leaderboards/Leaderboards panel now also appears if the user does not have permissions to create a new leaderboard.

March 2021

• When importing ORC certificates that provide 0.0s as allowance anywhere in the polar which cannot reasonably be represented in the internal format which is speed-based, those certificates can now at least be read successfully. The speeds will internally be set to "infinity" for those values for consistency.
• ORC Certificates provided in JSON format that lack allowances in certain categories, such as NonSpinnaker, or that lack a valid specification of their Family can now still be searched and imported.

February 2021

• The /sailingserver/windStatus servlet now shows more detailed information about the Igtimi fixes received and processed into a Wind fix.

January 2021

• A new competitor import plug-in is available now for YachtScoring (see https://www.yachtscoring.com/). You can simply enter your YachtScoring event ID (e.g., 13062 for the Bacardi Invitational Winter Series) and start importing your entries from YachtScoring into the SAP Sailing Analytics.
• The /gwt/status output now contains additional attributes describing the server name and more details about the replication status.
• The /sailingserver/api/v1/status servlet has been removed; should you have used it, please use /gwt/status from now on.
• The administration console has undergone some technical improvement. Panels including their code and data are loaded only when needed, significantly reducing initial code and data download. Furthermore, all panels can now be navigated to by a fragment identifier. Example: https://dev.sapsailing.com/gwt/AdminConsole.html#RegattasPlace:. These places become part of the browsing history, so the back/forward navigation in the browser is now aware of the click path and how it went through the panels which turns out to be particularly useful when leaving the AdminConsole through a link opening another URL in the same tab.
• It is now possible to construct AdminConsole links that have a filter and/or selection in place for the main table in the panel (should there be such a "main table"). Example: https://dev.sapsailing.com/gwt/AdminConsole.html#RegattasPlace:filter=Trave which shows only regattas containing the string "Trave", or https://dev.sapsailing.com/gwt/AdminConsole.html#LeaderboardGroupsPlace:select=0b7e71c5-f944-4650-bf09-f902ce76c3d3&filter=0b7e71c5-f944-4650-bf09-f902ce76c3d3 which selects and filters for a single leaderboard group. The selectExact parameter will usually select fewer line items than the select parameter because it tries to match its value with the whole column value: https://dev.sapsailing.com/gwt/AdminConsole.html#RegattasPlace:selectExact=Worlds. If filter and select parameter values are the same, you can replace it with the filterAndSelect parameter: https://dev.sapsailing.com/gwt/AdminConsole.html#RegattasPlace:filterAndSelect=Trave. You can combine all the filter and select parameters by using the ampersand-character. Example: https://dev.sapsailing.com/gwt/AdminConsole.html#RegattasPlace:filter=Trave&selectExact=Worlds. Use URL-encoding for special characters in the parameter values. See class FilterAndSelectParameters for a full documentation of the filter and select-parameters.
• When editing a user's permissions, the suggest box now shows the complete set of permissions.

December 2020

• On replicas, user group memberships did not always update correctly, due to a reference to a stale user store received with the initial load when replication starts up. This problem has been fixed now.
• Under "Race Manager App" the device configurations now offer additional options to pre-configure a device for a particular event, a specific course area of the event, and an optional role/priority such as "Officer on vessel" or "Shore control". The QR-code and link produced are in a new format that is understood starting with Race Manager App version 1.4.91 and which supports installing the app and still recognizing the configuration upon the first app start ("deep link support").
• In the Master Data Import panel under the Advanced category we changed the default setting for the checkbox that enables the transport of the tracking parameters required to track all races imported on the importing server again. This includes, e.g., the TracTrac JSON URLs and all other connectivity parameters. As an effect, by default after the Master Data Import completes, all races of the event(s) imported will automatically be loaded on the importing side.
• When changing competitor or boat ownerships from within a registration list at race or regatta level and then saving the list again, due to a bug only the single record whose ownership data was modified was still considered registered, and all other objects from the list got de-registered. This has now been fixed.

November 2020

• Anniversary calculation must now be turned on explicitly. Set system property

  -DAnniversaryRaceDeterminator.enabled=true

  at startup. Otherwise no anniversary is calculated.
• REST endpoint /api/v1/trackedRaces/getRaces to retrieve list of races that are available on the requested server has been extended to filter returned list of races by given events. A inclusive/exclusive logic is available. Using HTTP is deprecated for this interface from now. Use HTTP POST instead.

October 2020

• Fixed a regression regarding the transmission of a time-on-time/time-on-distance ranking metric configuration to a new replica server in the initial load.
• The "unlink" button in the competitor import dialog now shows again correctly.
• Competitors to be imported for which a competitor already exists with an equal ID are now recognized as "similar" and suggested for mapping.
• Fixed bug that occurred when a pairing list was to be inserted into a regatta's series, and another series existed whose races not yet had the flag set that allows per-race competitor assignments.
• WindFinder has offered us a new spot collection new_york which is now listed in the corresponding content assist in the Events editing dialog, tab "WindFinder".

September 2020

• Due to loadbalancing request between master and replica all GET requests are routed to replicas. As API calls going to /api/v1/regattas/{regattaName}/tracking_devices need to be answered by master, HTTP Post is required from now. Please update existing applications. Support for GET will be removed in the future.
• GET request for /sailingserver/api/v1/tracking_devices/[deviceUUID] are removed. Please use POST instead.
• Due to loadbalancing between master and replica all GET requests are routed to replicas. As API calls going to /sailingserver/api/v1/tracking_devices/[deviceUUID] need to be answered by master, HTTP POST is required from now. Please update existing applications. As support for GET will be removed in the near future.
• Master/replica loadbalancing introduced. GWT Async Services are now split between read and write operations. Requests being an HTTP POST or having the HTTP header X-SAPSSE-Forward-Request-To set to master will go to the master instance.
• In the /competitor/live API end point, if a gap to leader turns "infinite" because a VMG goes down to 0.0kts, the API will now output a null value for gapToLeader-s instead of throwing an exception.
• When generating a pairing list for a league style event, competitor-to-number assignments are now shuffled randomly before applying the numeric pairing list template to the competitor list. This way, the same numeric pairing list table will generate different competitor pairings each time applied.
• The REST API end point for posting GPS fixes has changed its behavior and offers two new query parameters to control this change. Maneuver changes are now only returned if the returnManeuverUpdate parameter is explicitly set to true. Additionally, the client posting the fixes can use the returnLiveDelay boolean parameter to request the live delay of each race the fixes were posted to. Clients may use this to adjust their sending delay and buffering behavior, e.g., as to preserve energy and bandwidth in case the server-side live delay permits for more latency in data transmission.
• A regression in the "Replication" panel has been fixed; it led to a growing empty space underneath the list of replicas attached.

August 2020

• Fixed a problem with "None" implied wind source selection for ORC PCS races. It caused a serialization error of the race log, e.g., when requested by the Race Manager App.
• Added boat classes X-332, J/92, and J/92S.
• SwissTiming races can now also be loaded from log files named {race-id}.log located in the same folder as the JSON document holding the event information if the host name in the connectivity information is left empty.

July 2020

• Fixed a problem with cross-track error calculations in case no track can be found for a competitor
• In the Competitor tables in AdminConsole, added the missing ToT handicap value column and made both, the ToT and ToD column, sortable.
• New menu entries in the header of the SAP Sailing home. Depending on the currently logged in users rights a link to the Administration Console and/or Data Mining is shown. When logging into a server without administration rights the event management entry will point to the value configured with the system property com.sap.sailing.eventmanagement.url (default: https://my.sapsailing.com).
• Fixed the passing through of a new mark's short name; so far, erroneously, the long name was stored also as the short name when using the AdminConsole to create a new mark.
• Added boat classes Spaekhugger, Scan Kap 99, and Dansk BB 10M.
• Fixed an internal locking problem that led to errors when trying to revoke a regatta log event, such as when removing a device mapping from a regatta.
• The /sailingserver/api/v1/regattas/{regattaname}/competitors endpoint now tells the effective, not the competitor-local handicap values which may have been adjusted at regatta level, overriding the default values that the competitor object provides. Compare with /sailingserver/api/v1/competitors/{competitorId}.
• Fixed a problem with assigning existing competitors (with boats) to regattas that are configured for competitors changing boats across races. Previously, competitors used in regattas where competitors don't change boats were not selectable for regattas where competitors do change boats. This is now changed such that competitors with boat assignments can also be used (without their boat assignments) in regattas where competitors change boats.
• Added boat class "Wayfarer"
• Fixed an issue with the /sailingserver/api/v1/boatclasses REST API which now delivers all known boat classes, regardless of whether any polar data exists for them or not.
• The file upload size limit was increased to a more contemporary 8GB.
• Added a field courseAreaId to the REST API output for regattas which now tells for each race in the regatta on which course area it saw its last start attempt.
• When creating or editing an event, URLs entered without protocol will now automatically be completed with "https://" as the protocol specification to avoid unnecessary errors.
• Remote Server Instance management has been made more selective. So far, all public events ("list on homepage == Yes") on a remote server were featured in the referencing server's event list and stage, as well as in a search operation. Now, administrators can pick and choose from the public event list on the remote server which ones to expose on the referencing side. The list can be including or excluding. Existing remote server references are handled as having and "excluding" with an empty list of events excluded, giving the classic behavior of drawing from all events. When creating new remote references, from now on they will be created as "including" starting out with an empty event list. The administrator hence has to pick events to feature explicitly, and new events added on the remote side will no longer automatically show on the referencing side. An "excluding" remote reference needs to be set up for this "legacy" behavior.
• Based on user input, the "selected" marker in rows supporting multiple selection now uses a stronger "SAP Blue" color so that selected rows can be recognized even easier.
• Passwords or secret access keys of file storage configuration are no longer displayed after submitting.
• Added "aarhus" as new WindFinder spot collection.

June 2020

• The REST endpoints /sailingserver/api/v1/competitors/{competitorId},
  /sailingsserver/api/v1/leaderboards/{leaderboardName}/competitors/{competitorId},
  /sailingserver/api/v1/regattas/{regattaname}/competitors and
  /sailingserver/api/v1/regattas/{regattaname}/entries
  have been brought to the same set of comeptitor attributes in the JSON result object.
  For backward compatibility of the endpoints /sailingserver/api/v1/competitors/{competitorId} and sailingsserver/api/v1/leaderboards/{leaderboardName}/competitors/{competitorId} the JSON result object was extended by the attributes
  • color (replaced by displayColor)
  • countryCode (replaced by nationalityISO2)
  • flagImage (replaced by flagImageUri)
  • teamImageUri (replaced by team/imageUri)
  
  These attributes are deprecated and will be removed in one of the next releases. For more information see the API documentation of /sailingserver/api/v1/competitors/{competitorId} and sailingsserver/api/v1/leaderboards/{leaderboardName}/competitors/{competitorId}
• The following REST endpoint URLs of the Usergroups-API and the Preferences-API have been replaced and are now deprecated. The deprecated URLs will be removed in one of the next releases.

  HTTP Method	Deprecated Endpoint URL	Replaced by URL
  GET	/sailingserver/api/v1/usergroups	/security/api/restsecurity/usergroup/list/groupsUserIsPartOf	see docs
  GET	/sailingserver/api/v1/usergroups/readable	/security/api/restsecurity/usergroup/list/readable	see docs
  POST	/sailingserver/api/v1/usergroups/setDefaultTenantForCurrentServerAndUser	/security/api/restsecurity/usergroup/setDefaultTenantForCurrentServerAndUser	see docs
  POST	/sailingserver/api/v1/usergroups/addAnyUserToGroup	/security/api/restsecurity/usergroup/addAnyUserToGroup	see docs
  GET	/sailingserver/api/v1/usergroups/{userGroupId}/roles	/security/api/restsecurity/usergroup/{groupId}	see docs
  DELETE	/sailingserver/api/v1/usergroups/{userGroupId}/roles	/security/api/restsecurity/{groupId}/role/{roleId}	see docs
  PUT	/sailingserver/api/v1/usergroups/{userGroupId}/roles	/security/api/restsecurity/usergroup/{groupId}/role/{roleId}	see docs
  GET	/sailingserver/api/v1/preferences/{settings_key}	/security/api/restsecurity//preferences/{settings_key}	see docs
  PUT	/sailingserver/api/v1/preferences/{settings_key}	/security/api/restsecurity//preferences/{settings_key}	see docs
  DELETE	/sailingserver/api/v1/preferences/{settings_key}	/security/api/restsecurity/preferences/{settings_key}	see docs

• Fixed a regression with the /security/api/restsecurity/ownership and the {regattaname}/races/{racename}/competitors/positions resource which produced empty output documents.
• Fixed a concurrency/synchronization issue with the WindFinder connector
• Fixed production of the "raceViewerUrl" attribute in the leaderboardgroups REST endpoint.

May 2020

• There are new Java Management Beans (MX Beans) for the thread pool executors that run various tasks inside the server. Find them at object name com.sap.sse.ThreadPool.{thread-pool-name} with {thread-pool-name} being something like "Default background executor" or "Default foreground executor". Particularly attributes such as QueuedTasks and CompletedTaskCount can help JMX clients such as JConsole to understand the state of the server.
• Leaderboards and regattas used to have a single "default" course area assignment. This caused problems when particularly split-fleet regattas assigned their different fleets to different course areas at the same time. See also bug 3465. Now it is possible to select more than one course area from the enclosing event for a regatta and flexible leaderboard. As an immediate effect, the SAP Sailing Race Manager app which uses the course area as a filter for the regattas to display for an event can now see the same regatta on different devices configured for different course areas. For example, if a regatta splits its Gold and Silver fleets to race on course areas Delta and Echo, respectively, then now users of the SAP Sailing Race Manager app will see this regatta when they are logged on to course area Delta or to course area Echo.
• When setting a start time for a race through the "Race Log," such as from the SAP Sailing Race Manager app or, e.g., the AdminConsole.html start time setting feature, the course area on which the start will happen can be captured in the log entry. If not provided, and if the regatta / leaderboard to whose log the entry is added has exactly one course area configured then that will be the default course area for the race. With this new feature is it possible to specify exactly on which course area a race has started, even if the enclosing regatta uses multiple course areas, either over time or even at the same time. The SAP Sailing Race Manager app now uses the course area to which the user logs on to fill this new field in the start time log entries.
• An incompatible change has been applied to the JSON output format of the sailingserver/api/v1/regattas/{regatta-name} end point. Instead of delivering the ID of the single "default" course area in the field courseAreaId now a list of such IDs is provided in the courseAreaIds field as an array that is always present but may be empty.
• "Flexible" leaderboards can no longer be renamed. The background of this change is that renaming was always flawed, particularly regarding the race logs attached to those leaderboards.
• The sailingserver/api/v1/events/createEvents REST endpoint now generates the event's default base URL by guessing the protocol (http/https) from any port seen in the request's scheme-specific part, if any, defaulting to https, assuming that even if the request arrives by HTTP it may likely have passed through an SSL-offloading reverse proxy or load balancer. Use the baseurl form parameter for the request to set this explicitly.

April 2020

• There is a new switch for the TracTrac connector you can use to automatically receive updates about official race status changes and competitor results from the TracTrac API. Use this only if results qualified as "OFFICIAL" by the TracTrac API are truly validated and you really want to automatically update your leaderboards from those results directly. As a result, race log events will be created automatically, as if they had been produced by the SAP Sailing Race Manager app.
• User name and password default to the current user for a master data import with blank user name and password fields. See detailed explanation in the Master Data Import tab in the Advanced section.
• The master data import (MDI) can now optionally also import the connectivity information needed to restore the tracked races attached to the structures imported. If this checkbox is selected, connection records will be added to the respective connector's tab, and the tracking of the races will be started automatically upon completing the data import. With the connection records added it will also be possible to load those races again on the importing side even if they are temporarily removed again or should fail to load.
• The TRACKED_RACE:EXPORT permission is now required on a tracked race in order to export raw position data for competitors and marks, as well as for obtaining the detailed wind fixes through the REST API.
• Good news for using the SAP Sailing Analytics with WindFinder support in the Caribbean and in particular the British Virgin Islands (BVIs): "tortola" was added to the list of supported WindFinder spot collections.

March 2020

• White label: Removal of SAP logos and brand related text from home page and racing panels. Use system property

  -Dcom.sap.sse.debranding=true

• The visualization for ORC certificates has been much improved. It now shows all the time allowances relevant for Performance Curve Scoring (PCS) and offers a link to the official PDF version of the respective certificate, based on its reference number.
• Improved ESC/Enter key handling in user role/permission editing dialog
• The "Replication" panel in the "Advanced" category now has improved information about the replicables shown. An advanced replica information string may reveal more than just the address, and the address is now resolved through any X-Forwarded-For header fields present during replica registration, hence also working through load balancers and reverse proxies.
• Mark Properties positioning information can now also be removed from a Mark Properties object again.

February 2020

• The "Local Server" tab now refreshes automatically when it comes into view.
• There is a new system property repliate.restore.replicas. When it is set to true (which is the default), upon start-up the server instance will read the replica descriptors stored persistently when a replica registers, assuming that those replicas are still alive and want to continue to receive replication updates from this server. This way, replicas may not have to be re-started or re-connected to the re-started master instance. Note, though, that as the re-started master loads races, those loading activities will be broadcast to all replicas which are likely to have all that information already. Use the flag, e.g., in the ADDITIONAL_JAVA_ARGS environment variable that the start script will consider, as in

                                ADDITIONAL_JAVA_ARGS=" -Drepliate.restore.replicas=true"
                              

• Replication from replica to master will now re-send upon HTTP status 404 which may indicate a re-starting master where the health check hasn't properly disabled forwarding requests to the instance.
• Replication operations that a replica needs to send back to the master instance are now consistently sent in a background task, avoiding any hold-ups and latencies in client / user interaction.

January 2020

• Overhaul of the Result Import URLs page to be more user friendly and to better fit in with the other pages. The Manage2Sail and Yachtscoring importers now support entering an event id instead of a full URL.
• Implemented API endpoints for configuring courses independently from regattas. The model has been extended by the new domain types mark template, mark properties, mark role and course template.
  • A mark template defines the appearance of a mark in a regatta independent representation. Mark templates represent marks in the waypoint sequence of a course template.
  • Mark properties also define the appearance of a mark. Despite the appearance it may contain a reference to a tracking device or a fixed mark position. They can be used to represent a catalogue of resusable mark definitions to describe real world marks or to supply a box of tracking devices.
  • A course template can be used to create a course based on mark templates and a sequence of waypoints. The sequence of waypoints may contain a repeatable sub sequence of waypoints which will insert repeating mark sequences for the number of laps specified when creating a course.
  • A mark role defines the purpose of a mark used in the waypoint sequences of a regatta course or course template and allows to swap out marks or mark templates without changing the the effective waypoint sequence. Having this a course template and regatta course may define a compatible waypoint sequence while being based on different mark definitions.

  Dialogs to create mark roles, mark template, mark properties and course templates are provided in the admin console accessible by a new menu point "Course Creation". There is currently no dialog to create a course from a coursetemplate.

• Added an API for course configurations as a general model that can be used to create a course or a course template by using mark templates, mark properties and freestyle defined mark configurations. It is possible to create a course configuration out of an existing course and modify the course by updating the course configuration.

November 2019

• Added system property security.sharedAcrossSubdomainsOf which can be used to configure the security service as shared across several subdomains of the parent domain specified by the system property. Use, e.g., as in

                                -Dsecurity.sharedAcrossSubdomainsOf=sapsailing.com
                              

• Added system property security.baseUrlForCrossDomainStorage which can be used to configure which origin's local storage is used, e.g., for storing settings and the time point a user was seen last. Use, e.g., as in

                                -Dsecurity.baseUrlForCrossDomainStorage=https://www.sapsailing.com
                              

  This allows the settings to be shared across different sub-domains. Note that the instance of the SAP Sailing Analytics running at the base URL chosen needs to be configured to allow requests from the domain hosting your instance of the application.

  The implementation includes an invisible iframe element in the page, loaded from the base URL provided in the system property and then uses cross-window, cross-domain messaging between the application and the iframe to request storage access and receive responses and storage events.

• Added system property gwt.acceptableCrossDomainStorageRequestOriginRegexp which can be used to configure which origins are permitted to access the local storage in the server instance. For example, to grant access to the local storage of www.sapsailing.com for all sub-domains of sapsailing.com including sapsailing.com itself, specify the following regular expression:

                                -Dgwt.acceptableCrossDomainStorageRequestOriginRegexp=https?://(.*\.)?sapsailing\.com$
                              

  or, for allowing for an optional port specification, it could be something like

                                -Dgwt.acceptableCrossDomainStorageRequestOriginRegexp=https?://(.*\.)?sapsailing\.com(:[0-9]*)?$
                              

  To represent this in the env.sh configuration file for an instance, use, e.g., something like this:

                                  ADDITIONAL_JAVA_ARGS="$ADDITIONAL_JAVA_ARGS -Dgwt.acceptableCrossDomainStorageRequestOriginRegexp=https?://(.*\\.)?sapsailing\\.com$"
                              

  Note the escaping of the backslashes and the $ sign with a preceding backslash character in this Bash syntax.

  This allows the iframe embedded in other instances for cross-domain local storage access to read from the local storage compartment for domain www.sapsailing.com (the example instance configured by the system property shown above) if the other instance's origin ends on ".sapsailing.com".

  Note that the origin is presented as the scheme (e.g., "https://") plus the hostname, plus optionally the colon-separated port, so you may be seeing something like "https://lyc.sapsailing.com" or "http://127.0.0.1:8888".

  If the system property is not specified, no origin will be permitted to use this instance's local storage through the cross-domain storage mechanism.

October 2019

• The ORC Performance Curve (PCS) ranking metric is now implemented. Two flavors exist, one as valid up until 2015 with ranking by implied wind and corrected times calculated using a scratch boat's performance curve; and the current default one valid starting from 2015, using each competitor's own performance curve to calculate the allowance based on the greatest implied wind achieved in the race and then computing the corrected time as the delta between time elapsed and individual allowance.

  In the Regattas/Regattas tab the boat certificates can be managed with a new action button. Certificates can be uploaded, and certificates can be referenced by URL, e.g., pointing to the ORC web site's certificate database. Then, the certificates can be assigned to the boats one by one. Certifiate assignment can be overruled on a per-race basis in the Leaderboards/Leaderboards tab.

  Furthermore, course definitions can be fixed for the ORC PCS rules; legs can be defined to be "constructed course" or any of the pre-defined types (windward/leeward, coastal long distance, non-spinnaker, and circular random). Tracking data can be used to pre-fill leg distance and true wind angle. Desired total course distances can be spread proportionally across the legs based on their estimated length. For more details see https://wiki.sapsailing.com/wiki/howto/setup-orc-regatta.

• Loading a race using the TracTrac connector used to determine the race's boat class based on the boat class of the majority of the race's competitors. This approach leads to trouble specifically for non-one-design regattas where different boats compete against each other, and the regatta is modeled with a "boat class" representing the handicap rule set, such as IRC, ORC, or similar. Now, the race boat class is inferred from the regatta boat class in which the race is created. Only in case a default regatta needs to be created, the old majority rule applies to determining the regatta's (and consequently the race's) boat class.

September 2019

• The RaceBoard timeslider has been adjusted to react to blue flag events. In particular the timeslider will wait for a blue flag down event if a blue flag up event has occurred.

August 2019

• New API endpoints were added to get the status of tracking devices. By now, just the last received GPS fix is returned in the status. Under /sailingserver/api/v1/tracking_devices/[deviceUUID] the status of smartphone tracking devices can be read by using the device's UUID. /sailingserver/api/v1/regattas/[regattaName]/tracking_devices the status for all tracking devices associated to a regatta is returned. While the first requires the non public device UUID to be included in the request, the latter requires a user to have UPDATE permission for the regatta in question.
• Added a filter to hide all elements the current user is not allowed to edit. The filter can be applied for each table in the AdminConsole and is active per default.

July 2019

• Result and competitor import URLs are now only considered when the requesting user has the permission to read that URL.
• A new wind source that estimates true wind direction and speed from maneuvers is available. It has been trained using machine learning techniques, based on approximately 12 million maneuvers that the SAP Sailing Analytics have tracked and classified so far. It is intended to serve as a fallback wind source in case the wind direction is not being made available to a tracked race in any other way (entry through the Race Manager app, the web page or estimated based on the first upwind leg's direction). Therefore, the confidence level has been set fairly low, hence this wind source will always be outweighed by any real wind sensor out on the course.

  To make the wind source available in a server, the trained maneuver classification models have to be available in the server's underlying database. To achieve this, the system property parameter -Dwindestimation.source.url=https://www.sapsailing.com can be used to import the wind data from the archive server in case no local model exists yet in the server's database. To force loading the data from another server, regardless of whether a model exists in the local server's database, use -Dwindestimation.source.always.url, respectively. Alternatively, the model data can be obtained as a file from another server like this: curl -o windEstimationModels.dat https://www.sapsailing.com/windestimation/api/windestimation_data. Alternatively, a recent copy is also maintained at http://static.sapsailing.com/windEstimationModels.dat. The resulting file, windEstimationModels.dat, can then be uploaded to another server, like this: curl -X POST -H "Content-Type: application/octet-stream" --data-binary @windEstimationModels.dat https://username:password@host.sapsailing.com/windestimation/api/windestimation_data Note that user credentials need to be provided with the request. The user must have the permission WIND_ESTIMATION_MODELS:UPDATE:<server-name> for the server to which the model data is to be stored.

  Subsequent server starts won't need to load the remote model data again because it has been stored in the server's database during the initial import. Replicas will receive the model data from their master.

  For more details, in particular how to re-train the models, see also https://wiki.sapsailing.com/wiki/howto/windestimation.

• JMX metrics in Prometheus-ready form have been added for the leaderboard computation times. Metrics are offered for each leaderboard in a server, as well as a summary averaging and counting all leaderboard accesses, each in a short, medium and long time interval (e.g., 5, 30, and 60 seconds, respectively).

  
  Example of the overall leaderboard computation statistics

  
  Example of the specific leaderboard computation statistics for one leaderboard

  This can then also be used, e.g., to export these metrics to other tools, such as Prometheus. See here for an exporter that can be used to expose JMX data to Prometheus. If the Java VM running the SAP Sailing Analytics server is invoked with a VM argument such as -javaagent:/path/to/jmx_prometheus_javaagent-0.12.0.jar=9000:/path/to/jmxPrometheusConfig.yaml then an HTTP GET request to http://hostname:9000/ will produce a document that contains lines such as:

                              com_sap_sailing_Leaderboard_ComputationTimeAverageMedium_averageComputeDurationInMillis{name="5O5-Worlds 2010 (5O5)",} -1.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageMedium_numberOfComputations{name="5O5-Worlds 2010 (5O5)",} 0.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageYoung_averageRangeInMillis{name="5O5-Worlds 2010 (5O5)",} 5000.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageOld_averageComputeDurationInMillis{name="5O5-Worlds 2010 (5O5)",} 597.0
                              com_sap_sailing_Leaderboard_DelayToLiveInMillis{name="5O5-Worlds 2010 (5O5)",} 20000.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageYoung_numberOfComputations{name="5O5-Worlds 2010 (5O5)",} 0.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageOld_numberOfComputations{name="5O5-Worlds 2010 (5O5)",} 1.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageOld_averageRangeInMillis{name="5O5-Worlds 2010 (5O5)",} 60000.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageYoung_averageComputeDurationInMillis{name="5O5-Worlds 2010 (5O5)",} -1.0
                              com_sap_sailing_Leaderboard_NumberOfCompetitors{name="5O5-Worlds 2010 (5O5)",} 147.0
                              com_sap_sailing_Leaderboard_NumberOfAllCompetitors{name="5O5-Worlds 2010 (5O5)",} 147.0
                              com_sap_sailing_Leaderboard_ComputationTimeAverageMedium_averageRangeInMillis{name="5O5-Worlds 2010 (5O5)",} 30000.0
                              ...
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsYoung_averageComputeDurationInMillis 13.0
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsMedium_averageComputeDurationInMillis 52.0
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsYoung_numberOfComputations 5.0
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsMedium_numberOfComputations 17.0
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsYoung_averageRangeInMillis 30000.0
                              com_sap_sailing_RacingEventService_LeaderboardComputationStatisticsMedium_averageRangeInMillis 60000.0
                              

  Note that average durations of -1 mean "no data" and should be ignored. The corresponding numberOfComputations value will be 0.0 in those cases.

June 2019

• Added new API endpoints for creating, reading, updating and deleting roles under /restsecurity/role.
• A new set of API end points for managing user groups was added under /restsecurity/usergroup. The new end points support resolving, creation and deletion of user groups, as well as adding and removing users and roles to and from user groups.
• The Device Configurations table for the Race Manager App now updates its underlying data properly when a configuration is edited locally.
• Blue flag up/down times can be cleared in the AdminConsole now
• Users can now create media tracks if they have the permissions based on the ownership that will result from the creation process.
• A couple of new API end points for managing tracked events were added under /api/v1/trackedevents/. The new end points support creation, reading, updating and deleting tracked events and their associated device-competitor/boat/mark elements for the current user.

May 2019

• Ranks (finishing orders) entered by the Race Manager app user are no longer considered for handicap regattas. Only an explicit score will be accepted, or a finishing time can be provided which will then let the handicap ranking metric infer the correct rank from that.
• Maneuver markers that appear when clicking on a boat while the RaceBoard is paused were sometimes hard to click because they disappeared behind the boat's tail. This behavior is now fixed.
• Fixed an issue with result import URL removal in case the URL erroneously contains more than one space character.
• Fixed a problem with competitor import: competitors imported now correctly obtain the current session's user as their owner, and the current session's user's default creation group as their owning group.
• Fixed issues with Manage2Sail regatta structure import: Imports of regattas with no "ClassName" property, such as handicap / Yardstick regattas, will now create regattas with "?" as boat class name to avoid other problems; furthermore, due to a permission check that was too restrictive, regattas to import could not be seen unless the user had "super-admin" power.
• Introduced a new permission SERVER:CAN_EXPORT_MASTERDATA:<server-name> which controls if a user is allowed to export masterdata used by the MDI. In addition, the user still needs to be able to read the data to be imported. On the importing server, the user needs to have the permission SERVER:CAN_IMPORT_MASTERDATA:<server-name>.

April 2019

• Filtering the leaderboard groups during a Master Data Import now also handles quoted strings correctly. With this, e.g., searching for a leaderboard group containing "Apr 2" in its name is doable.
• In AdminConsole.html all tables and lists are now filtered to only show domain objects readable by the current user. This means additional objects may exist on the server and can cause errors due to name conflicts.
  To allow users to grant others permissions for their stuff, it is possible to manage permissions for users whose username is known without having a read permission for that user. In addition, users may be added to groups by only knowing their username.
• The permission system was extended to allow groups to directly grant roles to their users. In addition such a role can also be granted to all users (including anonymous ones). Roles associated to groups only grant permissions to domain objects owned by that group.
  Example: By associating the sailing_viewer role to a group with "for all users" enabled, all objects owned by that group are publicly readable.
• When loading or tracking wind from Igtimi, only accounts readable by the current user will be used. On dedicated event servers, such an account should be owned by the server group. This ensures, that all server admins will consistently use this account while tracking races.
• Replication is now also secured by several actions of the SERVER security type. Due to permission checks on the master side, it is now necessary to provide credentials of a user that exists on the master server that is used when a replica contacts the master. This user at least needs to have the permission SERVER:REPLICATE:&server-name& granted on the master.
  Server start scripts as well as the replication documentation have been updated to include details about configuring credentials for auto replication. Newly created servers should automatically contain adjusted versions of the relevant scripts. The configuration of existing servers needs to get updated accordingly. The environment variables considered by the start script are: REPLICATE_MASTER_USERNAME and REPLICATE_MASTER_PASSWORD, or alternatively, REPLICATE_MASTER_BEARER_TOKEN which can be obtained from the master server, e.g., by curl -d "username=myuser&password=mysecretpassword" "https://master-server.sapsailing.com/security/api/restsecurity/access_token" | jq .access_token. These map to the system properties replicate.master.username, replicate.master.password, and replicate.master.bearer_token, respectively.

March 2019

• By caching serialized results of leaderboard requests the server now requires significantly less CPU power during live situations. Instead of computing the serialized representation of a leaderboard again and again, the serialized version is maintained in the cache as long as the original object from which the serialized version was produced is referenced. This way, the cache cleans itself. It can be observed through JMX, e.g., using JConsole, by looking at the JMX bean com.sap.sse:type=GWTRPCSerializedResultCache_*.

February 2019

• The pairing list construction supports a new parameter that can be used to balance fairness of boat assignment with the reduction of boat changes between flights. It can be set between 0 (focus on fair boat assignments; use this, e.g., if there are noticeable differences between the boats used to ensure a fair distribution) and the number of flights, e.g., 14 or 15 for a typical league set-up (focus on reducing the number of boat changes while sacrificing a bit of boat assignment fairness).
• The built-in mark passing calculator that is primarily used for smartphone tracking has been improved. In particular, it now recognizes trackers left behind, e.g., on a committee boat, and avoids performance issues incurred by these scenarios by filtering possible mark passing candidates using a bounding box-based approach: if a tracker hardly moves over some time, only the most promising candidates from that time interval are considered. This avoids compute time and memory issues seen in the past.
• When during a server re-start with the -Drestore.tracked.races=true parameter restoring a race fails with an exception, that race is now removed from the restore list, a corresponding SEVERE log entry is written, and the server will no longer try to restore that race upon future restarts. This way, races that have been removed at their source will not keep causing permanent restore trouble, and manual database intervention is no longer necessary.
• A new status REST endpoint has been added: /gwt/status. It combines the status checks of /sailingserver/api/v1/status and /replication/replication?action=STATUS, and because it is offered by the same module hosting the web UI of the server, its availability indicates that the corresponding module has started and has registered with the web server successfully. It reports a 200 HTTP response if itself and the status reports it syndicates report availability, a non-2XX status otherwise.

January 2019

• Allow entering a priority for courses managed in the AdminConsole. The new default priority now is 1. It used to be 0 which caused problems because the Race Manager app's highest (logically) priority is 1 which never took priority over the AdminConsole-provided prio-0 events.
• User sessions are now stored durably in the database so that they can be restored in case of a server re-start. Users therefore will no longer need to sign in again only because a server was re-started.
• New availability checks have been implemented. Two new REST endpoints are provided:
  • /sailingserver/api/v1/status reports the availability of the "Sailing" application
  • /replication/replication?action=STATUS reports the availability of the replication module, providing details about each replication-capable component and queue lengths
  • the "status" script in the server's working directory, next to the "start" and "stop" script, now provides output based on the status checks above, plus a check for a 2XX response code for /index.html. The exit code for the "status" script is now 1 in case of an error / lack of availability, and 0 if all checks passed and server looks available.
• Upgraded the MongoDB driver to version 3.6.4. This allows you to specify the new retryWrites parameter, e.g., as in "mongodb://mongo0.internal.sapsailing.com/mydb?replicaSet=live&retryWrites=true". This will improve your system's behavior if you run with a MongoDB replica set and have to assume that at some point the PRIMARY MongoDB system may fail, with the remaining systems in the replica set voting for a new PRIMARY. Without retryWrites your system will bluntly fail, but with retryWrites, write operations will be re-tried once, with a timeout usually enough for the remaining replicas to agree on a new PRIMARY.

October 2018

• Added progress indicator to device mappings panel for smartphone tracking.

September 2018

• Added automatic resizing when adding images to an event using the ImageDialog. It shows a check box if resizing is necessary, if you check it, the service will resize the image for you.
• Now showing an error when trying to upload an image or video to an event and no working FileStorageService is registered.

August 2018

• The mark passing editor now uses a full date/time format for the mark passing time points.
• The TracTrac connector panel no longer shows a password visibly but uses a password text field.
• The SwissTiming connector can now handle an "Update URL" together with username/password access credentials which are used, if present, to send feedback requests about start times, race status and course changes to that URL.

July 2018

• When adding a YouTube video for tracked races ("Manage Media" in RaceBoard.html or "Tracked Races > Audio & Video" in AdminConsole.html) the respective video metadata is now read using YouTube API v3. This functionality used to work some years ago using API v2 but was broken since this API version was discontinued some time ago. Due to limitations of the new API we can't read the start timepoint of videos by now. You still need to provide this value manually.
• In the "Tracked races" tab, within the eponymous section of the AdminConsole, the "Set start time received" dialog can be used to remove the currently set start time received, by simply leaving the value empty and confirming the dialog.
• Up to 15 discards can now be configured for series and leaderboards. This enables, e.g., "Wednesday Night" scenarios where over the season, say, 20 races are run but due to changing participation only, say, the five best ones shall be scored.
• There is a new scoring scheme available to be selected upon regatta creation. The scoring scheme is named "Low Point System, First with two wins in medals is winner" and introduces the following specifics compared to the standard low point scheme:
  • Medal series does not feature doubling of points in the medal series by default.
  • A competitor having two wins in the medal series is treated as overall winner. If there is a carry forward column in the medal series, having one point there also counts as a win which means the best competitor in the qualification needs a win less than any other finalist to be the overall winner.
  • If the medal series isn't started yet or no competitor has collected two wins, scoring by points is used. This also applies if the regatta is aborted (e.g. due to weather conditions) before any competitor could win two races in the medal series.
  • If two competitors have the same amount of points in the medal series the tie breaking criteria is the carry forward column of the medal series. If there is no carry forward column in the medal series, the last medal race is used as tie breaking criteria. For any non-medal series, the standard low point rules apply.
• A TracAPI upgrade from version 3.10.1 to 3.11.0 unifies the handling of course updates and solves an issue observed with updating mark passing instructions.
• Bug fix for mark position editor, now providing consistent behavior during adding of new mark fixes
• Data Mining now more aggressively terminates running queries if needed.

June 2018

• Added the available WindFinder Spot Collections. The desired ones can be selected from the WindFinder Tab in the Event Dialog.
• Added the ability to change the url of multiple Mediatracks with a common prefix at once. This is useful e.g. for video migration scenarios when movin videaos from one server to another. This can be done from the adminconsole->tracked races->audio & videos tab
• In raceboard when you edit a video you do not need to explicitly press "Preview" before saving anymore. Saving now implicitly applies the changes.
• The URLs of our GWT services are extended to include a leaderboard name if a call is context sensitive to a specific leaderboard. This does not affect the functionality of any service but allows us to setup load balancing with leaderboard specific routing. The leaderboard names put into the URL are cleaned: Any character that isn't a latin upper/lowercase letter or digit is replaced with an underscore character. Currently, the following leaderboard specific URLs are used:
  • /gwt/service/sailing/leaderboard/[CLEANED-LEADERBOARD-NAME]
  • /gwt/service/dispatch/leaderboard/[CLEANED-LEADERBOARD-NAME]
  Be aware that request without leaderboard suffix may be sent from pages that do not show leaderboard specific contents. Due to this it is required to define a fallback rule for any unqualified request.

May 2018

• Added the ability to add multiple mp4 videos as mediatracks at once via the new multi video dialog, located at trackedraces -> Audio & Video. This features requires a webserver with index listing enabled. Additionally the dialog offers the ability to add the new mediatracks directly to all races overlapping the starttime and duration of the mediatrack.
• On the "Edit mark positions" panel within RaceBoard, now a "Clear selection" button appears when selecting a mark from the table, which provides an easier and more obvious way to deselect all marks, what is needed in order to see the full course with all marks again.
• The AutoPlay.html configuration "Sixty Inch" was improved for the usage with events that aren't part of an event series. While no race is live or scheduled, only the overall leaderboard used to be shown. In addition to this, also the regatta leaderboard is shown in an alternating order. For non series events there is no overall leaderboard which means, that only the regatta leaderboard is shown.

April 2018

• The import of additional expedition data was extended to read many additional measures. These can be visualized in the leaderboard as well as the competitor charts in RaceBoard.html. In addition, the leaderboard has been extended to provide bravo and expedition related measures consistently on race and leg level. The respective settings dialogs were changed as well to only show specific options, if bravo or expedition tracks are available. Any previously imported expedition tracks may be dropped and reimported to gain access to the newly introduced measures.
• The settings dialog of the competitor charts in RaceBoard.html now provides the measures in alphabetical order (based on the current locale). Expedition specific measures - if available - are shown at the end of the list.
• The all in one expedition import has been extended to be able to import new competitor tracks or new races to an existing regatta. Previously it was only possible to import a new event structure.
• The Expedition log file import now prefers "GPS Time" for time stamping over "Utc" and over other date / time formats, making it more consistent with the Expedition live connector which uses column 146 for time stamping which is GPS Time.
• Two dimensional metrics can now be displayed by using a scatter plot presenter within the data mining tool. Select a metric that returns a pair of numbers and choose "Average" or "Identity" as an aggregator.
• Replication was made more robust for fixes that are delivered and applied asynchronously. If a race was removed while still in tracking mode, fix-related operations may have been queued already on the replica when the tracked race is removed. The pending GPS fix operations then would have clogged the executor threads until the entire replica comes to a halt. With the change, race-related asynchronous operations will simply be dropped when the race to which they pertain is not found on the replica.
• When editing mark positions, all fixes are now displayed, including potential outliers.

March 2018

• Boats are now separate entities. See the "Tracked Races / Boats" tab in the admin console. When creating a regatta, you now need to specify whether in that regatta the competitors may sail on changing boats ("Can boats of competitors change per race"). If boats can change, boat assignments need to be specified per race. For the TracTrac connector this may happen as in the past, using the corresponding metadata attributes (boatName, either one of boatId or boatUuid, and boatColor) on the competitors in the race. For smartphone tracking, boats can be specified in the "Connectors / Smartphone Tracking" tab by using the boat icon in the actions column of the leaderboards table ("Boat Registrations"). This defines the boats from which you can then select in the scope of each race of the regatta. When adding competitors to such a race then you now have to assign boats from the boats list to each competitor before you can confirm the competitor-to-race assignments.
• User, role and permission management has been extended. A new "tenant" concept is now available. Users can belong to zero or more tenants and can have a default tenant for a login session. Zero or more users can belong to a tenant. Objects have a tenant owner and a user owner, similar to group and user ownerships of files in a file system.

  By default, each user receives a default tenant that is named like the user, with "-tenant" appended. This applies during user migration to this new version, as well as during creation of new users. While a "default tenant" only specifies the tenant that objects created by the user will have as their tenant owner, by default the user also "belongs" to its default tenant (is part of that tenant's user group).

  Roles are now defined explicitly, in the "Roles" tab in the "Advanced" category. A new server that is not sharing the security service with any other server will start out with a few default role definitions, such as "admin" and "user". Roles imply permissions, and the permissions they imply can be modeled in the "Roles" tab.

  Roles can be assigned to users in the UI-refurbished "User Management" tab in the "Advanced" category. There is now a table with users that currently exist in the system, with a pager and a filter box. Editing a user shows an edit dialog for that user where roles and permissions can be added. Adding permissions works as usual. However, when adding roles, qualifications for a tenant owner and a user owner can be added using the following format for the role's name: <rolename>[:[<tenantname>][:[<username>]]].

• In addition to track competitors and marks using smartphone-tracking it is now possible to track boats. This is e.g. useful for several national leagues where competitors are assigned dynamically to boats for each race. In this case the competitors were used to bring a smartphone with them to the assigned boat. With the recent changes regarding boat and competitor mapping per race, Smartphone-tracking is now enabled to dynamically track boat-mapped devices to the correct competitors in the context of a race. There are two ways to add boats to be tracked to a regatta:
  • After adding a denotation to the racelog(s), add competitors to at least one race and ensure that the boats to be tracked are mapped to those
  • Register boats directly to the regatta
  For available boats, you can now add mappings and generate a QR code in the corresponding dialog. In addition, it is possible to upload tracking files and map them to boats.

February 2018

• Further improvements of maneuver detection algorithm were introduced. Mark Passing is no longer regarded as a separate maneuver type. Instead, it is regarded as a supplementary information which gets appended to a maneuver instance. Therefore, a new filtering dimension was added for maneuver data mining, which is boolean and is named as "Mark Passing".
• Added leaderboard group name as a dimension to a leaderboard's context
• Added True Wind Angle as a data mining statistic on GPS fixes
• Time points for wind data related to individual fixes now uses the fixes' specific time points, not the wind at the middle of the leg
• Finally, the data mining UI sorts wind strengths given in Beaufort according to their strengths, not their names
For example, a simple role name such as "admin" will give an unqualified role to the user. To constrain the "admin" role to objects whose tenant owner is the tenant "abc", use "admin:abc" for the role. To assign the role "admin" so that it applies only to objects owner by user "u938" use "admin::u938".

Tenants can be managed in the "Tenant Management" tab in the "Advanced" category. Here, tenants can be created, removed and the set of users belonging to each tenant can be edited.

During migration of an existing server to this new version, a new default tenant will be created using the server's name. All existing objects will by default have this new default tenant as their tenant owner, and no user owner. All existing role assignments will be migrated such that all roles will have as tenant qualification the new default tenant. This way, users will maintain the rights they were assigned through roles only for those objects belonging to the server's new default tenant (by default all objects on that server). Only when new objects are created with a different tenant then the role's permissions won't apply because the roles were by default constrained to the server's default tenant. This will allow us to consolidate, merge and join the security services of various servers at a later point in time, ensuring that users will not obtain permissions for objects they are not eligible for.

January 2018

• The auto detection for the media add dialog was improved. It will now attempt to only load the parts of a video that are required to parse the tags. Additionally if the server cannot reach a video, the client (browser) will make an attempt to load the video. This allows to analyze locally hosted videos without the need to upload them.
• In the raceboard the floating video box was improved, leading to a more solid resizing and moving behavior.
• In the raceboard, the adding of videos has now an additional fallback startDate, if no startOfRace could be determined, and the file did not contain a proper creationtime tag, startOfTracking is used.
• In the raceboard, the floating video box will now only display an edit button in the header, next to close and minimize. Upon clicking it, the box will expand and show the prior always shown editing buttons. This saves a lot of screenspace for logged in admin enabled users.
• For smartphone tracked races it's now possible to slice a new race from an existing one in the RaceBoard. As a user having sufficient permissions you need to select a specific time range in the competitor chart of a race. This will make a new Button appear near to the settings button of the chart. When you click this button you are being asked for a name of the new race. A new race column is created in the same series the current race is associated to. A new tracked race is then associated to the new column for the fleet of the current race. This new race is being filled with the data from the current race for the selected time range. After the slicing process is finished, a dialog will open providing a link to the RaceBoard for the newly added race.

December 2017

• The date and time pickers have been replaced by more native browser elements, ensuring that they work in all locales such as Japan where problems were reported with the date/time pickers used in the Administration Console up to now.
• In the raceboard it is now possible to upload 360° videos in addition to the already supported video types. 360° Videos must use MimeType mp4panorama, 2d mp4 videos must still use mimetype mp4, as in older releases. The dialog will try an auto-detection for the mimetype upon entering the link. Additionally, for mp4 videos it is now possible to use the start time, written in the file, as a start time preset for the mediatrack, simplifying the video linking.
• In Home it is now also possible to use 360° videos, for example as a highlight video
• Various fix importers can now properly report errors and other states.
• Pairing list generation is now supported. Add competitors to a regatta, then use the new action icons in the Leaderboards/Leaderboards panel in the administration console to generate a pairing list. The result can be exported as a CSV file compatible with the TracTrac Excel spreadsheet for importing the pairing lists into their solution; printing is also enabled. For smart phone tracking it is possible to fill the pairing list into the race logs in order to record the competitor / boat assignments according to the pairing list. To allow for contiguous race numbering, in this context a new feature was introduced that allows users to pick a race name prefix during denoting all races of a regatta for smart phone tracking, producing contiguously increasing race names/numbers (R1, R2, ..., R45).

November 2017

• In addition to the "Set start time" dialog there's now a "Set finishing and end time dialog". This dialog makes it possible to set the finishing as well as the end time in the RaceLog. It is intended to be used in cases where a race wasn't correctly finished using the race management app.
• New GPS fix, wind and sensor data importers have been implemented: "Bravo" and "Expedition."
• An upgrade to TracAPI 3.8.0 is expected to have fixed the issue with static marks not providing a position fix within a race's tracking time interval when the tracking start is set after the static position was entered.

September 2017

• Authentication for Igtimi accounts is now possible with an OAuth process. Instead of having to enter the username/password combination into the administration console, a popup window will show an IFrame with Igtimi's authentication form. Redirection goes to www.sapsailing.com, together with a "state" URL parameter providing the base URL of the original server instance requesting authentication. www.sapsailing.com will then redirect to that server, removing the "state" parameter from the request and leaving only the "code" parameter in the URL which the server ultimately receiving the redirected request will use to obtain an access token and the Igtimi account details. For now, and as a fallback, the old, non-OAuth process is still supported for a while, though deprecated as of now.
• In the process of supporting Igtimi OAuth authentication, new optional system properties for the Igtimi connector have been introduced:
  • igtimi.client.redirect.protocol: the redirection protocol, usually one of http or https
  • igtimi.client.redirect.host: redirection host; defaults to www.sapsailing.com
  • igtimi.client.redirect.port: redirection port; defaults to empty, using the default port for the protocol
• When using a TracTrac update URI, errors were possible due to the incorrect use of HTTP instead of HTTPS as the URI/URL's protocol. The TracTrac server responds to an HTTP request with a response code 302 (temporary redirect), but our TracTrac connector did not handle this due to redirects that change protocols are not followed by default in Java. This has now been changed, and although it is of course better to use the correct protocol (HTTPS) right away, redirects will now be handled correctly, too.

August 2017

• An NMEA wind import feature is now available under "Tracked Races -- Wind." It can be used to import .txt and .zip files containing data in NMEA-0183 format. The importer recognizes wind data provided by MWD and MDA sentences but can also use apparent and true wind readings from MWV sentences which are then combined with position, heading and motion data to obtain a true wind speed and direction. ZIP files are searched for .txt files which are then analyzed.
• A new scoring scheme "Low Point with Automatic RDG" is now available. It can help in league set-ups where one possible definition for the score of a redress given can be to average the scores of the competitor in all other flights scored, for past and coming races. This scoring scheme will apply as a default score for an RDG this average. As usual, as soon as an explicit score is provided for the race, the default calculation will no longer be applied.

July 2017

• The sort order of Events/Leaderboards in event series in Home.html is now more consistent by using the declared sort order in the respective LeaderboardGroup. In addition, the flag "Display groups in reverse order" in the LeaderboardGroup dialog now affects all occurrences of Events/Leaderboards in event series in Home.html. If the flag is not set, the order is latest on top in vertical lists and latest right in horizontal lists. With this change, the operator is now fully responsible for the sort order.

May 2017

• The logic of the "Control tracking from start and finish times" check box now behaves slightly differently. As before, a default start of tracking time is derived from the race start time (currently five minutes before race start). Likewise, a default end of tracking time is derived from the race finish time (the time when the blue flag was lowered, or more technically, when a FINISHED race state was set in the race log) which is currently two minutes after the race has finished. However, previously, when deviating start of tracking or end of tracking times were set through other channels, such as received from TracTrac or set explicitly through the administration console, new events would have been written to the race log, fixing the start of tracking / end of tracking times according to the derivation rules.

  This logic has caused undesired effects and has therefore been removed. For example, when an end of tracking time has been set explicitly through the administration console then it may have been overwritten by a new end-of-tracking-time event appended to the race log when the race is loaded again. Similarly, when a new start time was provided, an explicitly set start of tracking time would have been canceled. With the new behavior, explicit settings of start/end of tracking will remain untouched.

  For "Smartphone Tracking" the check box therefore now mainly controls whether or not a start/end of tracking time is written to the race log when the user starts/stops tracking for the first time through the administration console: when the tracking times are to be controlled by the race's start and finish times, simply starting / stopping to track a race with the smartphone connector won't set the start / end of tracking times.

  For the TracTrac connector, when the check box is set, as before messages will go out to TracTrac when the race start / finish times have changed. The feedback from TracTrac will adjust the tracking times as received by the connector, but no race log entries for the tracking times will be created anymore.

• A new type of leaderboard has been introduced: a regatta leaderboard with competitor elimination. Such a leaderboard creates a view onto a regular regatta leaderboard and allows the user to eliminate a subset of the competitors from its display. The scores of all remaining competitors are taken from the original regatta leaderboard without modification, including all corrections, penalties and the discarding rule, including the live ranks. This means, in particular, that the ranks shown for a race in such a leaderboard are not contiguous in case there are eliminated competitors. The score sum for each competitor is computed as usual. For the regatta rank, a contiguous count is applied. This way it is possible to create a new ranking for only a subset of the competitors; a practice common for championships that want to publish a separate youth leaderboard, e.g., for all competitors under a certain age.

April 2017

• /gwt/AutoPlay.html can be fully parameterized. Previously, only few of the available settings for Leaderboard and RaceBoard embedded into this view were effectively passed via URL to the views. /gwt/AutoPlay.html is now based on the settings framework so that specific URL parameters may have changed. Please recreate your bookmarks if you are affected by non-working parameters.
• The leaderboard configuration dialog in the admin console has been updated. Now it is possible to configure a leaderboard with the whole range of settings it supports.

April 2017

• Marks can now be given any valid CSS color. This will be considered also in the SAP Race Management app where the mark will be shown in their actual color in the "By Marks" course editor.
• Polar diagrams (also known as VPPs) will now be updated after importing wind.
• Competitors that the TracTrac connector declares as "non-competing" are consistently ignored. This may include camera boats, jury boats and other moving objects that do not represent competitor boats.
• Upgraded to TracAPI 3.6.3 which offers improvements regarding the identification of marks and waypoints.
• A bug regarding the regatta filter setting for the tracked races list has been fixed. The filter setting now survives a refresh cycle of the tracked races list.
• When using the TracTrac connector, identification of marks has slightly changed for gates and lines. Before, the mark IDs were constructed based on the control point's name. Now, the control point's ID plus a numeric suffic (1/2) is used instead, providing uniqueness at the same scope that TracTrac provides uniqueness regarding their control point IDs.

March 2017

• A more compact internal storage format for GPS and Wind fixes is now being used. Instead of a full 64-bit "double" value for all components such at latitude, longitude, speed over ground or course over ground, "smaller" data types such as "int" and "short" are now employed. The reduction of accuracy that this brings about is negligible given the accuracy of the tracking systems used. For example, the latitude values are encoded such that while covering the full range from -90° to +90°, the resolution is at 4.6mm. Similarly, speeds are represented in their compact form in such a way that speeds up to 500kts can be represented at a resolution of 0.015kts.
• When a race cannot be loaded successfully through the TracTrac connector, e.g., because its boat class does not match the regatta's boat class, the tracker is now stopped, and a SEVERE log message is written, giving the reason for the failure to load the race. This gives administrators an opportunity to correct any errors in the underlying data and try again. Previously, tracking such a was not possible without a server re-start because the tracker continued to exist.
• The application's locale now switches based on the client's "Accept-Language" HTTP header field. This means that the application as well as all its parts, including the administration console, will show in the user's default language if supported, defaulting to English otherwise.

February 2017

• Wind data in GRIB format can now be imported in the "Wind" sub-tab of the "Tracked Races" tab in the AdminConsole. When one or more races are being tracked, with a tracking time interval that includes the time point(s) for which the GRIB data is valid, the wind data at the resolution of the GRIB file is added as separate wind fixes with type "WEB" to the race(s) selected, or to all races if no race is selected.

  Multiple GRIB files can be specified; this is even necessary if GRIB sources are being used where the so-called "U" and "V" or "speed" and "direction" components, respectively, are provided in separate files. The importer will merge the GRIB sources to produce wind readings with true wind direction and true wind speed. Note that large GRIB files can result in many wind fixes being added to the WEB source. Make sure the GRIB files you use are adequate in resolution and region as well as adequate in time. Obtaining a forecast 72h in the future makes little sense for an in-shore race starting in 30min.

• The REST service for wind (/sailingservice/api/v1/regattas/{regatta}/races/{race}/wind) now considers the center of the course to calculate the COMBINED wind readings. Previously, all wind readings for the COMBINED wind track as published through the REST API were equally considered, regardless of how far away a wind sensor was from the course. Now, sensors closer to the course count more than those further away. Furthermore, the time between two readings in the COMBINED wind track in the REST output has been reduced from ten seconds to one second.

January 2017

• Filter boxes now support quoting phrases, such as "Race 2" to make them a single search term. Previously, when entering Race 2 this would match all lines containing Race as well as all lines containing the digit 2, such as it occurs in 2015 or 2016. Enclosing the phrase with double quotes as in "Race 2" will consider the full string in quotes as a search term. In the unlikely case of searching for a double quote you can do that by prefixing the double quote with a backslash character, as in \".
• When changing the start/end of tracking times in the "Smartphone Tracking" tab, it is now possible to "unset" one or both of these time stamps. Next to the date/time entry field these is now a "Set" checkbox. When the date/time field is modified, the box is automatically checked because it seems reasonable to assume that the user wants this change to be committed. When committing an empty date/time field with the "Set" checkbox ticked, the null time stamp which makes this an open tracking interval is committed and will override any inference that may be made based on the race's start and finish time. When unchecking the "Set" checkbox, the previously committed timestamp is revoked (regardless of the contents of the date/time field), allowing for inference to take place if the regatta has been configured for tracking times inference.
• There is a new permission, DATA_MINING, which is now required in order to use the /gwt/DataMining.html entry point and the related back-end service.
• Quoted filtering keywords may now contain leading and/or trailing space characters that are considered when applying the filter. For example, if you have regatta names "Regatta I - 2017" and "Regatta II - 2017" and you would like to filter for "Regatta I" then you now may enter the search term "Regatta I " (with a trailing blank) which then will no longer match "Regatta II - 2017".

December 2016

• Partial replication is now possible. If the system property replicate.on.start that controls automatic replication upon start-up provides only a partial comma-separated list of replicables, the connection to the master server (configured by the other replication-related system properties such as replicate.master.servlet.host etc.) will be used to replicate only those replicables whose IDs are specified in replicate.on.start. All other replicables will operate locally. Usually, the replicate.on.start system property is controlled by the environment variable REPLICATE_ON_START that is set in the env.sh configuration file used during server startup and influenced by the server environments from http://releases.sapsailing.com/environments and overridden by the user details provided to the instance through the AWS EC2 machinery.

  The Administration Console (/gwt/AdminConsole.html entry point) will now show which replicables a replica replicates, both, on the replica's administration console's "Replication" panel, as well as on the master's "Replication" panel, there for each replica.

  The master will restrict broadcasting its operations to those replicables for which at least one replica has subscribed. While the initial load is requested individually for each replica and can therefore be tailored to the replicas requested, the operation broadcast channel is not specific to any replica. It therefore contains the operations of all replicables for which at least one replica has subscribed. Replicas receiving operations for replicables for which they did not subscribe will simply drop those operations (note, however, that the replica will still have to read the operations from the channel before dropping; this way, registering a replica may have bandwidth effects for other replicas). Similarly, "backward replication" from a replica to a master will only take place for those replicables for which the replica has requested replication from (and therefore also "to") the master.

  With this it is now possible to replicate only the Security Service, using ID com.sap.sse.security.impl.SecurityServiceImpl, running all other replicables in "master mode." This will let the instance share user, permission, role and session management details with the instance from which the Security Service is being replicated while having its own master objects for all other replicables, such as the sailing application (RacingEventService), mail service or the polar data service. Note that with this feature the server replicating another instance's Security Service will grant the roles and permissions to subjects authenticated against that replicated Security Service. For example, if a user has been granted the admin role by that service then the user has that role also in all other server instances replicating that Security Service. Therefore, use this feature with extreme caution. Keep in mind that in the near future we will extend the permissions and role concept by the possibility to restrict permissions and roles to "scopes" such as an event or a regatta or an account. See also https://bugzilla.sapsailing.com/bugzilla/show_bug.cgi?id=3504.

• The server can now optionally restore all races it had tracked the last time. This is similar to a web browser's capability to restore the tabs the user had open when the browser was terminated or crashed. To enable this feature, use the system property restore.tracked.races, using the command line option -Drestore.tracked.races=true. So far, the default for this system property is false, so by default, when the property is not provided at all on the command line then the tracked races loaded last won't be restored, and the server will start out with an empty set of tracked races.

  Note that the wind tracking properties, as set when initially tracking the race, are also restored to their last state. If a live race has last been tracked with live wind tracking, with wind directions being corrected by the local magnetic declination, then upon server restore the same live tracking will be started again, including live wind tracking with the same declination correction settings.

  When the "Stop Tracking" feature is used, implicitly tracking wind will be stopped in case live wind tracking had previously been requested for that race. This change is also considered during the restore process where such a race will no longer receive live wind tracking upon restoring it.

  When a tracked race is removed from the server then it will not be restored anymore upon the next server restart with the restore option enabled. When an entire regatta with a number of tracked races linked into it is removed then the tracked races are removed as well and will not be restored upon server re-start.

  The restore progress can be monitored using the JConsole or any other JMX monitoring tool. In the com.sap.sailing category you will find the RacingEventService object. Among its attributes there are now the two new ones: NumberOfTrackedRacesToRestore and NumberOfTrackedRacesRestored. See the following two screen shots:

  

  

November 2016

• When launching a server, a system property polardata.source.url can be provided in order to specify a server base URL from where to import polar data into the upstarting server. Usually, this would be the "archive" server's base URL, such as https://www.sapsailing.com. Note that the exporting server needs to already support this feature and the importing and exporting server should be at roughly the same version to ensure binary compatibility for the polar sheet data.
• In the Tracked Races / Competitors tab there is now a new button "Import Competitor" that opens a dialog for selecting an import source. The Manage2Sail source is configured through the same URL as used for the result importer. Select the regatta from which you want to import, then check for which competitors there are matching / similar existing competitors. Single selection on the left lets you map to one of the matching existing competitors. Ultimately, select those competitors (including those you mapped to existing ones) you want to import. Optionally provide a search tag for them which will be added to the new and mapped-to competitors for easy retrieval later when selecting competitors to add to a regatta or race.

October 2016

• A regatta now has an additional property: "Buoy zone radius in hull lengths." It can be used to determine the radius of the zone around the marks in terms of hull lengths. This sets the default for the race viewer (RaceBoard.html entry point) based on the hull length as known from the boat class.
• When producing the QR code for the Race Management App's device configurations, the access token parameter was not properly URL-encoded. In case the access token contains a '+' character it is incorrectly decoded by the app, letting the authentication fail. This issue has now been fixed in the AdminConsole, and the access token parameter is now properly URL-encoded.
• Tracked races can now also be filtered by the regatta to which they belong. When selecting a regatta leaderboard, by default the table of tracked races will be filtered by the regatta whose leaderboard was selected. The regatta filter can be used in conjunction with the regular text filter field.

September 2016

• When denoting a regatta for smartphone tracking, the "By Marks" course designer is automatically selected if no active regatta configuration was set yet, or a warning and question to the user is issued, strongly suggesting the use of the "By Marks" course designer. Background: using the "By Name" course designer could accidentally delete a valid course layout.
• Regattas now have an additional setting: "Control tracking from start and finish times." With it, the start and finish times for a race as entered into the race log, e.g., through the Race Management app, can be used by tracking connectors to control the tracking for that race. So far, the TracTrac connector and the Smartphone connector have been enabled. When a start time for a race is received and the "Control..." flag is set, the tracking start time will be set to five minutes before the race start time. Similarly, when the blue flag is lowered, signaling that the race has finished, the tracking end time will be set to two minutes later. This should make an operator's job easier when the race timing is maintained properly through the race log, i.e., through the Race Management app.

  In turn, for the Smartphone tracking connector, start/end tracking times are recorded automatically upon start and stop tracking actions only if the regatta is not marked as "Control tracking from start and finish times." Background: with this it is possible to start tracking for a number of races scheduled for a day and having the Race Management app control the tracking times automatically.

• The "start of tracking" property on a tracked race now has to be set to a valid, non-empty value in order for fixed to be accepted into the race. As before, an empty "end of tracking" value means an open-ended interval, and fixes at or after the start of tracking time point will then continue to be accepted.
• The device mappings dialog now shows the time point of the last fix received from each mapping and has a convenient filter text box.
• Thread management has been improved. Fewer and more reasonably-designed thread pools are now created, and thread priorities less than normal (for background operations) now correctly map to operating system thread priorities, making foreground tasks more responsive. The less excessive concurrency has furthermore healthy effects on memory mamangement and garbage collection.
• Fixed a bug in the smart phone tracking course designer. When adding or removing marks now, unsaved changes to the waypoints and control points tables are preserved.

July 2016

• According to some change in a tracked races lifecycle, fix-tracking no longer depends on tracking races via racelog event but is bound to denotation only. So fix-tracking via smartphone apps or uploading tracking files can also be used in combination with e.g. TracTrac.
• Because fix-tracking is now more flexible (see above), it is no longer restricted to GPS-fixes.
• It is now possible to track fixes from Bravo foiling sensor devices, currently used in Extreme Sailing Series events only. This kind of data can be uploaded via a new dialog within the AdminConsole (Connectors > Smartphone Tracking)
• When a competitor is suppressed in a leaderboard, now the other competitors ranking worse will be "promoted" by one rank per better suppressed competitor. This way, live ranks will be correct if, e.g., a "Flexible Leaderboard" is used for a separate scoring scheme for only a subset of the competitor.
• When entering a fixed position for a mark in the "Smartphone Tracking" environment it is now possible to enter a time stamp for the fix. This way it is also possible to adjust a mark's position to a fixed lat/lng for some time point in the past.
• A series within a regatta can now define a maximum number of discards applied in that series. When combined with leaderboard-wide discards, generally discards can be distributed across the leaderboard as needed, but restricted by the maximum specified for each series. Leave the maximum empty to not provide any maximum. Setting to 0 will cause no scores to be discarded in that series.
• An event now has a "Base URL" which should be used to enable useful e-mail notifications with links embedded in them that lead to the correct server. If a notification is to contain a link to a dedicated event server, the event cannot be reached through www.sapsailing.com, and so if this generic link is used as a default, users will end up not finding the page linked to by the notification.
• The checkboxes "Track Wind" and "Correct by Declination" are now switched on by default for smartphone-tracked races

June 2016

• Some REST APIs have slightly changed. The /api/v1/leaderboards/{name} resource now has the "netPoints" and "totalPoints" stuff right. The "netPoints" always refer to scores which may be reduced due to discarding rules. Total points always refer to the points before applying any discarding rules. Those numeric values for which so far accidentally String types with double-quoted values were used have been changed to numeric types, represented in the JSON documents without double quotes.
• It is now possible to use overlapping leaderboard groups in an event, such that one leaderboard can be part of more than one leaderboard group of the event. This comes in handy if there are different schemes by which the regattas or leaderboards may be grouped and is particularly useful for large events for filtering the regattas in the event overview. Please note that in case a leaderboard is part of a leaderboard group with an overall leaderboard ("series scoring"), the leaderboard group with the overall leaderboard must be provided as the first of the overlapping leaderboard groups in the scope of the event.
• Earlier releases have introduced an issue with leaderboard configuration and with binding tracked races to their leaderboard slots. When a filter is set for the tracked races list, changing the leaderboard selection or changing the race column selection such that the tracked race for a selected race column is not visible due to the filter, the connection between the race column and the tracked race is removed.

  In order to reduce chances for failure, now at least changing the leaderboard selection will de-select any selected race column, making sure that nothing needs to be selected in the potentially filtered list of tracked races.

  However, trouble remains: changing the tracked races filter while having a race column with a tracked race connected selected in the table on the left will unlink the race column's tracked race. As a workaround, you'll have to either de-select the race column in the left table before changing the filter, e.g., by Ctrl-clicking the race column selected. Or you remove any filter text for the tracked races list before you change the selection in the race column table. This will make sure that the race connected to the race column that you may select next will be available for automatic selection.

May 2016

• Smartphone tracking support has been improved. When starting to track a race that has no start-of-tracking time set yet, the start-of-tracking time will be set to the time point when tracking has been started. Similarly, when stopping tracking and no end-of-tracking time is set for the race yet, the current time is set as the end-of-tracking time for that race.
• Regatta structure import from Manage2Sail now takes the boat class name from the regatta, not the division element, giving better results.

April 2016

• In the "Race Manager App" regatta configuration settings, a new preference "Activate result entry" has been added. It can enable or diable result entry during or after the finishing phase in the Race Manager app. With this, it is possible to configure up-front whether a race officer is offered the possibility to manage results directly from the Race Manager app. This should not be used if an external, official regatta management system is being used to capture and manage the official scores.

March 2016

• For smartphone tracking, added shortcut to start/stop tracking of race to each individual race (play/stop button in action column).
• When starting/stopping to track a race using smartphone tracking the tracking start/stop time is set to "now" if no time has previously been set.
• With the MANAGE_MARK_POSITIONS permission, users of the smartphone tracking feature can now conveniently manipulate course mark positions from the RaceBoard.html entry point. When having the permission, a new button "Edit Mark Positions" will be shown. Marks can then be selected from a table, new fixes can be added and existing fixes can be moved. Note that the "Delete" menu item is currently still disabled. Delete may be supported in future versions, though.
• The sailors info link is now also available for single regatta events in addition to multi regatta events that used to have this feature. If a sailors info link is configured for events that are part of a series, this isn't shown on the event page because the link to the series uses the same space in the UI and has higher priority.
• It's possible to configure language specific sailors info website links for events. There is a default value that can be overwritten on a per locale base. No sailors info link is shown for UI languages if there is neither a default link nor one for the specific locale, even if there is one for another locale configured.
• The mechanism to handle RegattaOverview settings has been changed to a more generic approach. This leads to slightly changed URL parameter names so that old bookmarks could be broken in a way so that the actual shown set of races is different using the new version because the old parameters aren't correctly recognized. All automatically generated links to this page in Home and AdminConsole have been updated to use the new parameter names.

February 2016

• Several improvements regarding the creation of race metadata (events, regatta, etc.) including: automatic creation of default series, dialog for creating a default leaderboard group
• The RaceBoard URL Parameter "canReplayDuringLiveRaces" has been removed. This parameter was used to allow users to trigger autoplay for live races on non-live points in time. The permission "CAN_REPLAY_DURING_LIVE_RACES" and role "moderator" now grant this functionality to users.
• The "Manage Media" button in RegattaOverview is now bound to the Permission "MANAGE_MEDIA". The Roles "eventmanager" and "mediaeditor" grant the "MANAGE_MEDIA" permission.
• The "Edit mark passings" button in RegattaOverview is now bound to the Permission "MANAGE_MARK_PASSINGS". The Role "eventmanager" grants the "MANAGE_MARK_PASSINGS" permission.
• The user management page now provides a "Refresh" button to reload the user list.
• The user management page now also lists sailing roles and permissions in the respective suggest boxes.
• The "Edit Points" module is now bound to the Permission "MANAGE_LEADERBOARD_RESULTS". The Role "eventmanager" grants the "MANAGE_LEADERBOARD_RESULTS" permission.
• There is now a UI element in the header of "Edit Points", "Admin Console" and "Races Overview" pages that indicates the authentication and makes it possible to sign in/sign out without leaving the page. The pages "Edit Points" and "Admin Console" will show a message instead of the page content if you aren't autenticated or don't have the required permissions.

October 2015

• The "RaceLog Tracking" panel was renamed to the more intuitive "Smartphone Tracking".
• Competitor and course information can now be copied independently from one race to another within a Smartphone-tracked leaderboard.

November 2015

• Adding a competitor to a leaderboard or a regatta pre-sets the competitor's boat class according to the leaderboard's / regatta's boat class.
• When done with creating a regatta, the user can have the corresponding regatta leaderboard created with a simple click instead of having to navigate to the "Leaderboards" tab.
• Trim leaderboard and leaderboard group names during creation, removing leading and trailing blanks. These names can occur in URLs, and trailing blanks in particular may be trimmed, causing the objects to not be found.

October 2015

• The "RaceLog Tracking" panel was renamed to the more intuitive "Smartphone Tracking".
• Competitor and course information can now be copied independently from one race to another within a Smartphone-tracked leaderboard.

September 2015

• A new scoring scheme for elimination rounds has been added. It will first be used at a major wind surfing event.
• The "Device Configuration" tab has been moved into a new top-level tab "Race Committee App".
• Included magnetic declination data for 2016 already.
• Bug fix: in rare cases, adding several series to a regatta in one go swapped the order of the series to be created. This has now been fixed.

August 2015

• Race log tracking now allows administrators to set the start and end of tracking for a race. Competitor and mark positions as well as wind data are filtered based on the start/end of tracking intervals.
• Setting the boat class for a regatta and when creating a competitor has been unified and now uses a suggest text box which makes suggestions based on all the boat classes known by the application. In both cases can users now also enter a "free-form" boat class which is then created by the server if not known yet. Note that for such boat classes no boat class icon will be present when showing the regatta on the web page.
• Added boat classes Soling, Lago 26, Kielzugvogel, PWA (Professional Windsurfers Association)

June 2015

• An event an now have a "Sailors' Info" URL configured. If provided, there will be a button displayed on the event's web page that navigates to this link. It can be used, e.g., to link to official documents such as the notice of race, sailing instructions, weather information or similar.

April 2015

• Competitors can now have a flag image assigned. This image should ideally be sized 18x11px. If such an image is assigned, it overrules the nationality flag. Use this feature to provide club flags for sailing league events.

February 2015

• The Event panel now links the event name to the event page in the new design. The old "RegattaOverview" link is now shown in the panel below, shown when selecting the event in the table above, called "Event Overview."

December 2014

• We added user management. The /gwt/AdminConsole.html entry point for a fresh server set-up uses admin/admin as username/password. You can change the password in the "Advanced > User Management" tab where also new users can be created. If you assign a use the role "admin" then the user will be able to use the administration console. Stay tuned for a more sophisticated set of roles and permissions to be added in the future.
• Reverse replication is now possible for selected events. When a replica instance receives a modifying operation, such as a user logging in (creating a user session) or a wind fix being entered through the Race Committee App, this change will be sent from the replica to the master and from there be replicated to all other replicas attached.
• Starting a server with auto-replication enabled has been changed. The REPLICATE_ON_START environment variable no longer is a Boolean value (True/False) but now has to list the replication services to be replicated from the master. The default environments for replicas at http://releases.sapsailing.com/environments show how this works.
• The "Connectors" category has a new tab in the administration console, entitled "Regatta Structure Import". If your regatta management system happens to be Manage2Sail you can enter an event ID and show the list of regattas, then set defaults for how they shall be created in the SAP Sailing Analytics. This allows you to import and create many regattas at once, saving the laborious effort of manually creating them. Obviously, this can come in handy at large events with regattas on many course areas in several different boat classes.

July 2014

• Replication has become much more robust and efficient. The initial load which used to be sent in a single huge (although compressed) stream of data from the master to the replica(s) was hard to get transmitted in the face of flaky and slow network connections. We've changed this: now the initial load is transmitted as a sequence of messages using a message broker infrastructure. If a single message doesn't arrive, it will be re-sent until it got through. The messages are buffered for several minutes, so the initial load transmission can even survive and recover from severe network outages.

  For the incremental replication process, we added compression, making the transmission more bandwidth-efficient and therefore quicker and leaner. In addition, we've cleaned up the protocol a little, avoiding the sending of redundant data, adding to the effects of compression. Replicating five live races with approximately 40 to 50 competitors each, with four active wind measurement units each, requires approximately 30kB/s of network bandwidth between master and replica.

• Events now have lots of new attributes, particularly start/end date and multimedia content URLs
• Regattas can now be edited to not perform start time inference based on start mark passings. Usually, when no start time is set by the race committee app or by the tracking provider or manually through the administration console, the start time is inferred from the mark passings for the start line. However, this can lead to unpleasant effects when the race committee aborts or postpones a race and doesn't set a new start time for some period of time. When during this period one or more boats cross the start line, a new start time would be inferred implicitly, showing scores in the leaderboard and starting to compute all sorts of metrics. To avoid this, uncheck the checkbox "Use start time inference from start mark passings" in the regatta create / edit dialog.
• When creating a regatta in the administration console, the regatta name is now taken from the create dialog's "Name" field as-is and is no longer automatically extended by appending the boat class name in parentheses to the base name. This is important to know if you so far have created several regattas within the scope of the same event by simply providing the event name and the boat class name, relying on the administration console to extend the regatta name by the boat class name because now with this strategy your regattas would all be named the same. If you want to continue using some base name and see the boat class name after the base name in parentheses you will now have to add that to the "Name" field yourself, as in "Kieler Woche 2014 (470)". With this change, you can avoid having special characters such as "/" in the regatta name which used to be a problem in particular for RESTful web services that use the regatta name as a URL element. Boat classes such as "B/one" and "J/70" traditionally had issues with this. Now, the regatta can simply be named "My Event (J70)" instead, and web service access is hassle-free. The boat class can still be called "J/70" which can be useful if the result management tool or the tracking partner spells it that way.

March 2014

• XML export of leaderboards now also taking into account competitors that haven't sailed a race but got a score

February 2014

• Series name can be edited
• Now one can add a new series to an existing regatta
• Introduced new series scheme where competitors are scored contigously over all fleets

January 2014

• New version of TracTrac connector that fixes issues with concurrent loading of many races
• Wind data can be imported from Expedition log files and from Igtimi WindBots
• Competitors can be assigned fixed colors
• Video files can be interactively linked to races
• Admin Console consistently sorts alpha-numeric items such that numbers embedded in text are sorted by their numeric values (Race 2 precedes Race 11)
• AdminConsole has more consistent filter behavior as more columns are used for filtering; some sorting options were added
• Added a button to set the start time received of a tracked race. This time isn't persistent, so it'll be forgotten after a server restart
• Tracking a race with a wrong regatta is now forbidden