Introduction
Welcome back! This is part 3 of a 4-part blog series examining the most compelling features of the recent EDM 22.09 release. In part 1, we looked at end-to-end integration between EDM and Cloud GL. In part 2, we explored the Model After Node feature.
For this entry, we will pop the hood on another compelling feature – Inclusion Property Subscription Filter.
For a complete listing of all the features included in Oracle EDM 22.09, please refer to this link: EDM Sep 2022 Update
Inclusion Property Subscription Filter
Background
You might be wondering, what in the tarnation is an inclusion property filter? The best way to think of it is as a “membership” flag. The inclusion property filter allows you to manage which EDM applications a specific node belongs to.
This feature will be most useful when your EDM implementation follows the “master” or “front door” application design pattern. The visual below (courtesy of Oracle) outlines the two primary design patterns for EDM. At Alithya, we have utilized both patterns in multiple implementations and both patterns are tremendously useful and valid.
The idea behind the “master” design pattern is to have an up-front (front door) application that is the primary entry point for changes in your EDM environment. You can think of this application as a centralized, data governance engine that drives your master data management across all your business domains. The majority, if not all, of your data governance workflows (approval policies) will reside in this application.
There are two reasons I find this pattern useful:
- For those clients migrating from DRM, this pattern resonates with the DRM approach of centralization with a primary working version containing many hierarchies.
- It provides a level of separation and abstraction from your “deployment” applications. The front door application is positioned as a purpose-built and finely tuned data governance engine while keeping your other EDM applications (Planning, Financial Consolidation and Close, Profitability and Cost Management, Cloud ERP, and many others) focused on managing and deploying dimensions in a purpose-built approach for each target application.
How It Works
To utilize this feature, you first need to decide which filter approach you wish to take. There are two choices:
- List property – a single list property that contains a picklist of values representing the various target EDM applications the nodes will belong to. You select/unselect applications to control the membership, like how you might utilize a UDA.
- Boolean property – a true/false property that signifies if the nodes belong to a specific application or not. You will need multiple Boolean properties, one for each target EDM application, to function as a type of “on-off” switch for that application.
For this example, we are going to use the List property approach. Once you have defined your property, you will need to create/edit a subscription. On the Filters tab, a fourth type of filter is now available in addition to Actions, Top Nodes, and Conditions. This is where you select your List or Boolean property.
I created a custom List property populated with values representing my different applications. For this example, since I am modifying the subscription to my Financial Consolidation and Close application, I will select that value from the drop-down list.
NOTE:
- You need to add your Inclusion Filter property to your Source node type, not the target.
- You do not need to copy/transform your Inclusion Filter property in the node type converter.
- The inclusion property name and list values can be adjusted to your needs. They do not need to match what is shown in this screenshot.
Examples
Now we can see this feature in action. In the first example, I add an entity to my GL Entity viewpoint and select “Financial Close and Consolidation” and “Planning” as my inclusion filters. After submitting this request, EDM generates a subscription request to introduce the same entity into both target viewpoints, based on how the subscription inclusion filter was configured.
Granted, this is not too exciting or all that different than what EDM could do before. It is the ongoing maintenance of “node membership” where this feature will really shine.
Now I can make a second request, where I realize that Planning does not need and should not have received my new entity value. I can submit a new request in my GL Entity viewpoint, update the inclusion filter accordingly, and submit the request. As you see from the screenshots below, entity C_199 remains in the FCCS viewpoint but no longer exists in Planning. The final screenshot shows the subscription request EDM generated with the Delete action.
This last example really highlights the power of this feature. It allows you to centrally control node membership, on an ongoing basis, to multiple downstream EDM applications by adjusting the inclusion filter in your master or front door EDM application.
A final cautionary note: it goes without saying that you should exercise caution when deleting a node from any EDM application, when that node has already been loaded to the target application and may contain data.
But for those EDM implementations utilizing the master or front door design pattern, and where there are several deployment applications subscribing to the front door application, this feature simplifies management of node membership for the EDM administrator.
Conclusion
Hopefully, you found this post useful! Please reach out if you have questions and look for the grand finale, Part 4, of the blog series coming soon!
