Since Oracle EPM 22.214.171.124 Oracle has introduced EPM Diagnostic Utility (validate.bat). For the newbies, the EPM diagnostic utility is a java based tool with the purpose to technically validate an EPM instance. Executing this utility results in two things: A full HTML diagnostics report, and a ZIP file containing all log files from the instance it was executed from. The Oracle EPM documentation related to this utility can be found here.
Since Oracle EPM 126.96.36.199, the EPM diagnostic utility is a good start when validating a installation or troubleshooting issues. However there are some minor downsides: It always performs all tests, always creates a ZIP file after completion and there is not option to selectively test... at least so I thought.
For an automation project, this default behavior was a problem. As such, I examined the java code related to the EPM diagnostic Execution and discovered that it excepts various command line parameters borrowed from the EPM installation utility wizard.
Personally I never paid attention to specific UEFI (Unified Extensible Firmware Interface) settings when installing and configuring EPM. It was always on factory default values. During a project however, I was triggered to have a look at these setting due to an issue I could not explain.
If you ever had to publish Planning utilities for administrators in e.g. Terminal Server or Citrix, you experienced the difficulties of doing that. Planning utilities can only be executed on the server where Planning is installed. Solutions to provide access to these utilities range from full administrative (RDP) access on the Planning server to PowerShell scripts using remote execution. In my experience non of these solutions are ideal and at best cumbersome to maintain.
Already for a few years I though: "There must be another way".
Probably most of you who worked with EPM Architect before faced the situation where an application in EPMA is in a corrupted deployment state and cannot be deleted properly from EPMA the usual way, or EPMA complains that the application already exists while attempting to recreate the EPMA application you deleted.
In most cases running diagnostic against the application would get you back on-track. If not, as a last resort you can drop all tables from the EPMA database by re-configuring the EPMA data source. However in most cases this is not an option.
If you have manually removed all references of the application in all EPM components (how is out-of-scope of this post) and still you cannot re-create the application in EPMA, consider using my SQL script below to ZAP! that orphaned application from the EPMA database.