As the 126.96.36.199 release of the EPM suite looms, the changes specifically to the new release of DRM are anxiously awaited. As speculated, DRM is joining the party as an integration tool available in the PBCS offering – as Oracle works to push more products to the cloud. So far there are rumored to be about DRM 15 customers live with PBCS/Hyperion Planning on the cloud.
Also not a big surprise is the huge effort on improving the functionality of Data Relationship Governance (DRG) within DRM, and the workflow modeling and conditionals within the tool (which was introduced in just 188.8.131.52). Most notable of the new DRG features to me were the integration with EPM Mobile, and the functionality of conditional staging – in that workflow stages can pass through a specific user/stage, or split to another user/stage dependent on other conditionals/properties.
In terms of performance, I am excited to see the new improvements in processing speed due to changes in the DRM architecture. No more are the days of waiting for long-read operations and multiple engines – DRM is moving to a single-engine at application startup, and utilizing multiple processors for operations; instead of one processor per engine.
Other changes in basic DRM functionality include Import and Export improvements.
Below I go into more detail on the *unconfirmed* features for 184.108.40.206 release. Remember, since the verison hasn’t been officially released, these features aren’t 100% guaranteed.
If you have any additional questions, please feel free to leave a comment or send me an email.
- Share dimensions in DRM with PBCS
- Can have both on-premise applications and cloud-planning share in DRM dimensionality
Example: Great for companies that might have PBCS for planning but HFM/GL solutions on-premise, and want to share dimensionality and master data between all systems.
- Mobile Approvals! Integrated with EPM Mobile
- Can access requests/worklists, make decisions, ask questions, and track the progress of requests from your iPhone, tablet, etc.
- Separation of Duties
- Approvers cannot approve multiple stages within one request item; so users cannot approve their own enrichment stages – approval happens at the right level.
- Conditional Workflows
- You can assign a conditional action for a stage, and if the condition is met you go to the conditional stage; otherwise it skips it and keeps following the workflow.
Example: if a new account is not in an alternate hierarchy, enter stage for the appropriate user to insert it. If it is already there – move onto the next stage and skip the conditional stage.
- DRG User Experience Improvements
- Load multiple requests at once from a flat file!
- Via web or batch-client
- Add attachments to requests – can upload them and other users can download/view them
- Word, Excel, PDF, etc.
- Layouts with tabs to keep requests separate from other activities
- Task instructions
- Ex: Add a description for the account.
- Show/hide task instructions to free up space on console
- Load multiple requests at once from a flat file!
- Request Auditing
- Similar to DRM native audit functionality on master data
- Query workflow tasks to see the users, stage, time, type of task for requests
- DRG User permission changes/upgrades:
- Submitter Users can withdraw requests
- Commit Users may escalation requests from prior stages
- Escalation Users can advance requests up the chain
- Data Manager can un-claim requests (even if already claimed by someone else) in any stage, and delete any request that is not yet committed.
- Single Section File
- Don’t need “hier” headers anymore! Import dimension section using just parent-child relationship file exports; cuts down on custom formatting
- Create Hierarchies from Orphans
- List orphans into a hierarchy without a structure
- Can Assign Validations, Hierarchy Groups, and Node Types at Import
- Cuts down on administrator time spent configuring after an import
- Import Multi-line Formatted String Properties
- Helpful for member formulas from Essbase/Planning) by enclosing in quotation marks
- Substitution Parameters
- Filter list of exports by Hierarchy group (instead of long list in alphabetical order)
- Hierarchy Groups
- Use already-defined hierarchy groups to auto-select hierarchies by context for
- Example: Export everything in hierarchy group X for this dimension
- Dynamic Export Columns
- Dynamically change the columns exported based upon a substitution parameter
- Load version from DB only once (instead of once per engine: RW, SRO, RV, LRO)
- High-concurrency for read operations
- Read-operations are now non-blocking (don’t have to wait for ops in queue)
- Long-read operations run immediately instead of having to wait for the LRO engine to startup or for a version to be loaded
What does this mean?
DRM now can utilize mutli-processor servers to run operations, so the calculation and read operations have more power – making DRM faster and more scalable.
Higher Concurrency: Improved Performance: Improved Scalability
DRM is now optimized for multi-processor, single machine deployments instead of having several application servers for a configuration. Parallel read operations are improved, aka browsing hierarchies and flipping between tasks.
There are some installation/configuration changes that come along with these improvements: you can no longer have secondary app servers for one DRM application (but can still have multiple web servers for high-availability).
CSS Bridge can be installed on a separate machine from the DRM app server – so now stand-alone DRM environments can be integrated with Shared Services.