Profitability and Cost Management

Get Involved. Join the Conversation.


    Parmit Choudhury
    Allocation Rule Execution is not finishing
    Topic posted September 27, 2019 by Parmit ChoudhuryGreen Ribbon: 100+ Points, last edited September 27, 2019, tagged Allocations, PCM, Rules 
    22 Views, 2 Comments
    Allocation Rule Execution is not finishing
    Rule execution is taking too much time and we have to restart essbase service to kill the rule.

    Hi Guys,

    We are getting the following error when we are restarting the Essbase service to stop the Rule after it runs for about an hour.

    “Number of updated cells count is Zero for Rule” or

    “Allocation Rule failed

    Cannot set active application/cube. Essbase Error (1051544): message on contacting or from application: Local////Error (1013204) Client Commands are Currently Not Being Accepted.


    Please can anybody share Best Practices document for PCMCS.

    Any help on getting the rule to work will be much appreciated.

     Below is the scenario of the rule.

    The Rule is of type pro rata as per specifications.

    In the source definition currently we have specific or all or any members for all dimensions apart from a single dimension for which we have taken three separate members.


    In case of Driver basis, for Account dimension we have taken an alternate hierarchy with two shared members, as we are not able to add the two members separately and a single member from another dimension.

    In the specifications document it is given  that few of the Destination members would be same as Source and Basis. So destination members, which are same as driver basis, we followed a rule that we specified those members in destination rather than specifying them in Driver basis. Our understanding is that if we specify the same members in Destination then Driver basis will also pick up the same members during rule execution

    For destination, most of the members are any or all members of separate individual  dimensions. To take any or all members of a separate individual  dimensions we have created dynamic hierarchies for all those dimensions with shared members in them. We have also created an alternate hierarchy for another dimension with over 30 shared members and taken that hierarchy in destination definition

    For other destination members, which are same as source, we have ticked the “Same as Source” option.

    Offset Location is taken as Source


    So given the above scenario if anybody can suggest a better approach or design of the rule, it will be very helpful.

     Also if you can also suggest a better way to specify all or any member selection from any particular dimension in source or destination that will also be helpful



    • SanDip

      Hi Pramit,

          Can you please upload a snapshot of your rules screen?


      • Alecsandra Mlynarzek

        Hey there Parmit,

        A couple of pointers that may help you out. First of all, if you want to stop a calc that has been running for a terribly long time, go to Administer -> Database ->Administration -> Restart. That performs a force restart of the app in Essbase, which will hopefully kill the Essbase session and allow you to address the issue. 

        When designing allocations in PCM there are several items you want to pay attention to. One of the most impactful variables in a calc design, outside of app and metadata design, which is a more complex topic, is the total nb of intersections you are pulling into memory. This info is available in 2 places 1- exec stat report, 2- in the rule development tabs themselves, in Source and Destination. You must be mindful of how much you may be asking from the system to pull into memory at one time. So if that number is extremely high compared to any other script you have, then consider breaking that particular rule in smaller chunks. One other piece of advice: test your script on stored members vs shared members. This does not mean that you should not use shared members in rules - you can, but if you have shared members in both source selections and target, we have seen instances when apps would hiccup during run time and impact overall calc times. 

        So try to test your calc in small pieces and see where that breaking point occurs. Restrict the rules to a handful of data sets to see if it produces anything. 

        Sharing the calc setup is useful, but without seeing the app design, we're mostly going to shoot in the dark. Whatever you fix in one calc may not solve for the entire app, in case the problem stems from either a metadata design flaw or an app design flaw. In either case, my advice holds true and I hope it will make a difference. 

        Best of luck!

        Kind regards,