The most recent version of Planning Analytics 2.0.6 which incorporates TM1 server version 11.4 contains a number of fixes listed in the release notes. One of these fixes introduces a potentially breaking change to custom code if your application has any processes or cubes already making use of the new }Subsets_ control dimensions.

The fix is listed as:
[PI99205] DELETING A SUBSET FROM DEFAULT HIERARCHY WHICH EXISTS IN ALTERNATE HIERARCHIES REMOVES ELEMENT FROM CONTROL-SUBSETS-DIMENSION

Previously the }Subsets_dimensionName dimension existing per dimension in your model was not properly “hierarchy aware” and elements in the dimension were identified by subset name only. Thus if a subset “Default” existed for multiple hierarchies within a dimension then only a single element would be created in the }Subsets dimension, leading to the inability to trace which hierarchy a subset belonged to an inability to easily count in total the number of subsets existing per hierarchy or per dimension. (And also inadvertently to the bug listed above whereby deleting a subset from the same-named hierarchy would remove the element from the }Subsets dimension even if a subset of the same name existed in one or more alternate hierarchies.)

IBM have addressed this issue in 2.0.6 by extending the key for the element names in each }Subsets_dimensionName dimension to include the hierarchy name delimited by a colon (except for subsets in the same named hierarchy which retain the simple key).
E.g. the new key for the elements is now hierarchyName:subsetName

The change to element names in the }Subsets control dimension is illustrated in the following screenshot from Architect. In this example our Product dimension contains a same named hierarchy plus 3 additional hierarchies;“Hier 1”, “Hier 2” & “Hier 3”. Each hierarchy contains some standard subsets (All Elements, All C Elements, All N Elements, Default Member). Previously, we wouldn’t have been able to see within the }Subsets_Product dimension that these subsets do exist in each hierarchy.

The fix is great! (In fact, it should have been implemented like this to start with). …. but for any keen developers and system admins who already have solutions in place leveraging the }Subsets_dimensionName dimensions the change could break your existing application which will now need to be modified. Previously you might have been doing SubsetExists, SubsetGetSize or SubsetMDXGet tests. (Or in conjunction with looping the }Hierarchies_dimensionName dimension tests for HierarchySubsetExists, HierarchySubsetGetSize or HierarchySubsetMDXGet). Now however any such tests on subsets in alternate hierarchies will be broken since the element name no longer corresponds to a subset name. To restore any such functionality you will need to amend your application to substring the element name and remove the prefixed hierarchy name before doing these tests. Of course let’s look on the bright side, no more looping of the }Hierarchies dimension is needed to identify the hierarchy to which a subset belongs!