I’m on a team that recently decided to patch a client environment, upgrading Hyperion Planning 184.108.40.206 from the .501 patch to the .700 patch. We quickly started having deployment issues related to unknown members in member formulas. This was with a “classic” Hyperion Planning application, not an EPMA app.
We soon realized that we had issues with member formulas that referenced members with names that included a “%” sign. An example is below:
The screenshot above represents a brand-new formula. It hadn’t been saved, and it hadn’t been validated. (As you have probably guessed, these two actions led to issues.)
Upon validating (or saving) the formula, an error was introduced. Interestingly, the validation returned with a “successful” message.
The number 25 was appended to the “%”. Subsequent validations added another “25”. The application repository was clean – formulas there were correct. LCM exports also looked good. But saving formulas suddenly got risky. This application had some very, very complex member formulas.
My immediate reaction was to start updating member names and formulas, replacing “%” with “Pct”. This would normally get the job done, however this particular application had a LOT of members with “%” in the name. Some of these members were referenced in FDMEE maps . . . and reports . . . and business rules . . . and partitions. Renaming was going to be a pain. Luckily we had another unpatched environment where development could move forward while we worked the SR. This leads us to a conversation regarding patch best practices:
- Read the Readme file! It details known issues and fixes addressed by the patch.
- Patch a Development or Sandbox environment first.
- Have a back-out plan.
- If you have apps in Production, make sure you plan for a thorough regression test.
- Schedule your patches for “low-disruption” time periods. (Don’t patch right before year-end close or go-live.)
- If you can, wait for others to patch first. (The best testers are strangers who don’t bill your project.)