ILAP Analytics – Release Notes v2.13.0.0

Overview

This release adds the "Revised" revision type, a long-standing request from planners working with baselines — ready in ILAP Analytics, and selectable from IDE once a matching IDE release lands — and Parquet export of planning and reporting data. It also adds support for importing two schedules on the same cut-off, fixes several defects around reverting a revision, and corrects interface issues found in a UX review.

Pull Request: #3798

Component Summary

• Analytics API: Version 2.13.0.0
• Analytics Background Jobs: Version 2.13.0.0
• Analytics Web UI: Version 2.12.0.0

Infrastructure note: This release requires Bicep changes for both the Analytics API and Analytics Background Jobs, for the Parquet export feature. See Bicep changes below, and the Ilap Analytics Bicep Change History article for the parameters themselves, before upgrading.

Completed Work Items

7689 – New "Revised" revision type

A fourth revision type, Revised, joins Live, Baseline and Original Baseline. It exists for planners who need to hold a revised baseline alongside the original one rather than overwriting it.

Revised behaves like Current for time-phasing: every field carrying Current in its name has a Revised counterpart in Reporting_Activity and Reporting_ActivityPeriodized. So a schedule imported as Revised is periodized the same way, and the values are available wherever the Current ones are.

What you can do with it:

• Import a schedule as Revised, and see the values land in the Revised fields.
• Read those fields through both the REST and GraphQL endpoints, alongside the existing revision types.

Not yet available from the IDE desktop client. Choosing Revised when importing or exporting needs a matching change to Host System Parameters in IDE, and that change has not been released. Until it is, ILAP Analytics accepts and serves the Revised type, but you cannot select it in IDE. Nothing needs to be done here when the IDE release arrives — this side is ready.

7862 – Export IA data and reporting snapshots to Parquet

Planning and reporting data can now be exported to Parquet files in a dedicated storage account, so the data outlives the SQL retention purge and can be consumed from Fabric or Power BI. The feature is off by default and is turned on with the new deployment parameters described below.

7825 – Import of two schedules on the same cut-off

Two schedules sharing a cut-off date can now both be imported, rather than the second one conflicting with the first.

7968 – Periodized rows left behind on revert

Reverting a revision did not clean up the previous periodized rows, which could leave stale time-phased data behind.

8229 – Revert could null a sibling activity's foreign key

A set-based update used during revert was mistranslated by EF Core and could silently null a foreign key on a sibling activity. Fixed, with the translation now verified rather than assumed.

8242 – Report schedule interface defects

Fixes a clipped Delete button and duplicated, overlapping empty states in the report schedule views.

8046 – UX review

A pass over the interface, correcting the issues it surfaced.

Also in this release

Internal quality work, with no functional change:

• 8228 – automated test coverage for the Revised revision type in partial-import paths.
• 8230 – an automated review check that catches the class of EF Core mistranslation behind 8229 before it reaches a release.

Bicep changes

Required for the Analytics API and Analytics Background Jobs. Parquet export introduces new deployment parameters — a switch that turns the feature on, the storage account it writes to, and the container name that data-lake consumers shortcut into.

The feature is off by default. If you do not want it, set the switch to false and skip the rest: nothing is provisioned and nothing changes for you.

The parameters, with their comments and constraints, are listed under Release 2.13.0.0 in the Ilap Analytics Bicep Change History article. Read it before upgrading — the container name is set-once, and renaming it after snapshots exist strands the old data.