{"id":1441,"date":"2022-12-19T09:40:12","date_gmt":"2022-12-19T04:10:12","guid":{"rendered":"https:\/\/blogs.infosys.com\/infosys-cobalt\/?p=1441"},"modified":"2022-12-19T09:40:12","modified_gmt":"2022-12-19T04:10:12","slug":"simplifying-maintenance-in-enterprise-data-management-edm-by-calculating-node-name-prefix-through-subscriptions","status":"publish","type":"post","link":"https:\/\/blogs.infosys.com\/infosys-cobalt\/cloud-analytics\/simplifying-maintenance-in-enterprise-data-management-edm-by-calculating-node-name-prefix-through-subscriptions.html","title":{"rendered":"Simplifying maintenance in Enterprise Data Management (EDM) by calculating Node Name Prefix through Subscriptions"},"content":{"rendered":"

A typical Enterprise Data Management (EDM) Application feeds metadata to multiple downstream applications. Each of these applications may have prefixes in their node names, which may be completely different from the prefixing nomenclature of any other system in the landscape. To increase the complexity, parent nodes in a system may have different prefixes in their names from the base nodes. Configuring subscriptions in such a landscape can be a massive headache. In this blogpost, I look to provide an approach to this kind of a scenario by drawing from my experience from an engagement in which Enterprise Data Management (EDM) was feeding 10 different target systems, each with a unique prefixing requirement.<\/p>\n

 <\/p>\n

Scenario:<\/p>\n

Let us assume that we have EDM feeding metadata to the below target systems:<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Fusion Cloud GL<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Planning Cloud<\/p>\n

\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Financial Consolidation Close<\/p>\n

 <\/p>\n

We also assume that the hierarchies of each of these 3 systems are similar apart from the different prefixes.<\/p>\n

Typically, the GL system will be the primary application and the other applications will be the subscribing applications for setting up Subscriptions. Imagine that in Table 1 below is the prefixing requirement for the ACCOUNT dimension for each of the systems:<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Solution Approach:<\/p>\n

Step 1: Create a \u2018Boolean\u2019 property \u2018Is Base\u2019 which indicates whether the node in consideration is a PARENT or a BASE. This property will require user input while adding a new node in the primary GL Viewpoint to indicate whether the node being added is a PARENT or a BASE.<\/p>\n

Note that this property may not be created during application registration as we need this property only to help us in configuring our prefixing logic. We do not need this to be a part of our exports. So, this property should be added to the NODE TYPE of all the concerned dimensions from the NODE TYPE menu. Make this a REQUIRED property. Refer to Snapshot 1<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Step 2: Define the \u2018Default Qualifier\u2019 and \u2018Alternate Qualifier\u2019 in the Node Type for the ACCOUNT dimension of the Planning Cloud and the Financial Consolidation Close Cloud Applications. Refer to Snapshot 2 and 3.<\/p>\n

Note: You may define either the PARENT prefix as the \u2018Default Qualifier\u2019 and the BASE prefix as the \u2018Alternate Qualifier\u2019 or vice versa. I suggest defining the base prefix as the \u2018Default Qualifier\u2019. More on that a bit later in the blog.<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

 <\/p>\n

 <\/p>\n

Step 3: Setup the Node Type Converters between GL and Planning Cloud Node Types and the GL and Consolidation Close Node Type. This is where we define the logic for the calculation of prefixes.<\/p>\n

Taking the example of the Node Type of Planning Cloud where the converter with GL Cloud is setup. The logic resides in the \u2018Core.Name\u2019 property. In the \u2018Operation\u2019 select TRANSFORM. Refer to Snapshot 4.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

The logic used is simple:<\/p>\n

If the node being added is a PARENT node, concatenate \u2018AC_\u2019 to the node name<\/p>\n

ELSE<\/p>\n

Concatenate \u2018AC\u2019 to the node name<\/p>\n

Refer to Snapshots 5 and 6 for how the above logic is implemented in EDM:<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

 <\/p>\n

The same logic is written to calculate the prefixes for the \u2018Consolidation Close\u2019 viewpoint.<\/p>\n

 <\/p>\n

Step 4: Configure Subscriptions between the primary GL Viewpoint and the subscribing Planning Cloud and Consolidation Close Viewpoints and you are good to go!<\/p>\n

 <\/p>\n

 <\/p>\n

Logic in Action:<\/p>\n

Once we have done the above setups, we can try out the logic.<\/p>\n

I have created the \u2018Account Maintenance View\u2019 (Snapshot 7) which includes ACCOUNT Viewpoints for each of Fusion GL, Planning Cloud and Consolidation Close.<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Now let us add a new PARENT \u2018100003\u2019 under \u2018100000\u2019 in the GL Viewpoint (Snapshot 10) . Let us also add a BASE \u2018100031\u2019 under the PARENT \u2018100003\u2019.<\/p>\n

Let us make sure that the \u2018Is Base\u2019 property value for \u2018100003\u2019 is \u2018FALSE\u2019 and for \u2018100031\u2019 is \u2018TRUE\u2019.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

On submitting this request, the below 3 actions take place:<\/p>\n

a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Nodes \u2018100003\u2019 and \u2018100031\u2019 will get added as PARENT and BASE nodes respectively. Refer to snapshot 11.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 A subscription request should get triggered with 4 items (2 new nodes each to be added in the Planning Viewpoint and Consolidation Close Viewpoint). Refer to snapshot 12.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

a.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The new PARENT and BASE nodes should get added to the subscribing viewpoints with the correct prefixes. Refer to snapshot 13.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Keep in Mind!<\/p>\n

Though this approach works wonderfully well, it does have a minor limitation. And you have Oracle and the EDM Development team to blame for it!<\/p>\n

In our scenario, if we DELETE a PARENT node in the primary GL Viewpoint, the corresponding PARENT node in the subscribing viewpoints will NOT get deleted. In other words, if the prefix for the PARENT nodes is listed as the \u2018Alternate Qualifier\u2019, the PARENT nodes will not get deleted. Vice versa, if the prefix of the BASE nodes is listed as the \u2018Alternate Qualifier\u2019, the BASE nodes will not get deleted. So, the deletes will have to be performed manually.<\/p>\n

Obviously, I reported this to Oracle, and they acknowledged this limitation. The reason given for the same is that once a node (with prefix listed as \u2018Alternate Qualifier\u2019) is deleted in the primary viewpoint, the node is gone from that application and ceases to exist. As a result, EDM is unable to establish any linkage of this now DELETED node with the corresponding nodes in the subscribing viewpoints.<\/p>\n

Earlier, I had recommended to list the prefix of the BASE nodes as the default qualifier. The simple reasoning behind this was that you will more often end up deleting BASE nodes rather than PARENT nodes. So, listing the prefix of the BASE nodes as the default qualifier will save you some effort with the manual DELETES. Having said that, DELETES themselves are normally extremely rare.<\/p>\n

Some may rightly point out that DELETES normally are not done in GL systems anyway. I am just trying to make a point that there can be cases when GL may not be your primary application or is not being managed in EDM. In other applications, DELETES are very much possible. So, the knowledge of this small limitation will come in handy.<\/p>\n

 <\/p>\n

Note: The IDEA for this enhancement was submitted in IDEA LABS and Oracle is working on addressing this limitation.<\/p>\n","protected":false},"excerpt":{"rendered":"

A typical Enterprise Data Management (EDM) Application feeds metadata to multiple downstream applications. Each […]<\/p>\n","protected":false},"author":312,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[11,69,72],"tags":[158,159],"coauthors":[155],"class_list":["post-1441","post","type-post","status-publish","format-standard","hentry","category-cloud-analytics","category-oracle","category-oracle-cloud-infrastructure","tag-edm","tag-metadatamaintenance"],"acf":[],"_links":{"self":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1441","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/users\/312"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/comments?post=1441"}],"version-history":[{"count":4,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1441\/revisions"}],"predecessor-version":[{"id":1590,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/posts\/1441\/revisions\/1590"}],"wp:attachment":[{"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/media?parent=1441"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/categories?post=1441"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/tags?post=1441"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.infosys.com\/infosys-cobalt\/wp-json\/wp\/v2\/coauthors?post=1441"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}