Working with EDMCS Subscriptions

Subscriptions in EDMCS are the special sauce to keeping applications in sync, and alternate hierarchies up to date. In implementations with more than one target application with at least one dimension that needs to be synchronized for updates – you’ll need to implement a subscription to reduce overhead of your data stewards.

Subscriptions take updates from a Viewpoint and trigger a request into another Viewpoint. This is extremely helpful when your dimension needs to be an exact 1-to-1. But what if there are some other factors that need to be included?

• What if its just certain parents/hierarchies of the dimension that need updates?
• What if you want to process new additions, but you don’t want to delete in the target Viewpoint?
• What if you only want subscriptions based on some other criteria?

Luckily, EDMCS has advanced configurations that can help facilitate these requirements and ensure that the right data is kept in sync in the right circumstances.

Subscription Basics

Subscriptions are configured on the Target Viewpoint. So if I know that I will be updating the ERP Viewpoint first, and I want my FCCS hierarchy to get those updates, I will configure the Subscription on the FCCS Viewpoint.

To set up a subscription, go to the Target Viewpoint and Inspect and click over to the Subscriptions tab. this is where one or more subscriptions can be created. Press Create in the top right corner to begin.

The Subscription wizard allows you too pick the source Viewpoint – which can be any Viewpoint in the application. It shows you all Views with Viewpoints grouped underneath. I am going to select my HURON_ERP_ACCOUNT Viewpoint as my source.

Press Create to move to the settings. For any subscription, you must select a  Default Assignee. This is required, and it MUST be a specific username. You can use a service account, but in most instances it should be the Owner of the target application (for that dimension). If the Default Assignee is OOTO (and marked so in EDMCS), Alternate Assignee(s) will get the request instead.

As Alternate Assignee(s), you can put a group (KCS_GL_Maintenance in this example) and it will round-robin through that group to find the first available person that is not marked OOTO, or you can do a list of groups or users.

Next, you can define if the Request should be Auto-Submit when the subscription fires – which doesn’t allow for review before submitting. Leaving unchecked will allow for the Request to stay in Draft mode until the Default (or Alternate if OOTO) Assignees take a look.

Finally, if Auto-Submit is selected, the option to Bypass Approvals can be selected. If you have Approval Policies set on the Application, Dimension, Hierarchy Set, or Node Type in your Viewpoint; the approval will not be needed if this is set to True.

Pressing Save will save the subscription and it will fire for any change in the source Viewpoint; it will subscribe to the target. If you need more filtering and honing in, continue reading!

Action Filters

Once the subscription is saved, you can continue adding more logic to hone in on what types of updates to include and where the updates should come from.

On the Definition tab, there are more options to get more granular and apply logic to your Subscription. The first thing you can do is limit Actions.

Actions in EDMCS include Add, Delete, Remove, Update, Move, Reorder, Insert, and Rename (for hierarchies). If you press Edit on the Definition tab, and deselect the All check box next to Included Actions, you’ll see the full list. If you have a subscription from a list, only Add and Delete are options, FYI.

An example on where this would be helpful is if on your target Viewpoint, you have a specific ordering that you do not want to change; or you do not want to Remove/Delete nodes from the Target that may be removed from the source. If that is the case, you’d include the Add, Insert, Rename, and Move Actions from the list and not select the others.

Remember, updates are inherent and not available in the list to exclude/include. They will always be included (like Description updates).

Included Top Node Filters

Included Top Node filters allow you to filter on only specific areas of the source Viewpoint to get sent to the target Viewpoint. For example, perhaps there is one source hierarchy that is supposed to match the target; but there are other hierarchies in the source the target does not need. If you apply a Top Node Filter to the hierarchy that should align; the system will ignore subscribing updates to other non-selected hierarchies.

To add Included Top Nodes, select Add from that section and begin finding the top nodes you want to include. You can select more than one. The blue check shows it is selected, and then press OK to add the Top Node filter.

The below will include any (ALL) actions that occur under the 1200 GL Account.

Node Conditions

Lastly, and probably the most complex, are Node Conditions. The Expression Builder is a blog post in itself, but in general it allows you to create blocks of code using if/else statements and properties to render a value. This is what is used for Derived Properties, Node Type converter transformations, and likely other functions in the future (like the upcoming Conditional Workflows that should be released soon).

For Subscriptions, the Node Condition expression must either return a True or False for the system to know if that request should be made to the target Viewpoint.

One example, that I use often in implementation, is limiting the subscription to base level members for certain Viewpoints. For example, if I have an alternate hierarchy for EPBCS; I put it in its own Viewpoint; and then the subscription gets a Node Condition to just send over base level members to be inserted into the alternate hierarchy. This makes it easy for the EPBCS admin to get their new member and they get a subscribed request to place it into their reporting hierarchy.

You  can see in the expression below; if the sourceNode from the subscription does not have any children (children count = 0) then it returns True and the node/action is included in the subscription. Otherwise, it returns False and that node/action is not included (parent members).

 

Remember, when you apply Actions, Included Top Nodes, and Node Condition filters to your subscriptions, you’ll want to ensure you have sufficient test cases to test both included and excluded nodes so your logic is configured to your requirements.

Thanks for reading!