Ability to import master data via packages without Manage Dimenions/Members security Tasks?

[alexander_b_white]

Hi BPC experts,

We are currently implementing BPC 11 for BW/4HANA as a replacement for BPC 10.1 MS. We have a few data manager packages that automatically import master data from various source systems, leveraging the out-of-box master data import processes. These packages are running fine when executed by an administrator. However, when run by our power users, we receive the following errors:

Upon granting these users the "Manage Members" and "Manage Dimensions" Tasks, they are able to successfully run the packages. However, this has the side effect of giving them the ability to modify all dimensions via the BPC web console. We would prefer not to grant this access since the whole idea is to allow these users to update only a few dimensions via an automated process, rather than opening up all of our master data to end user modifications. This was not a requirement in BPC MS; we had developed similar packages on that platform which did not necessitate adding any administrative security Tasks.

TL;DR: is there some way to allow users to update master data via data manager packages without granting them the "Manage Dimensions" and "Manage Members" security Tasks?

Thank you!
Alex

[former_member186338]

Strange idea to run MD import packages by end users.

Why do you need it?

Please explain the process in details:

Load from txt?

How the file is created?

[alexander_b_white]

Hi Vadim,

Thanks for the reply – great questions.

Why do you need it?

The short answer is this is already an established process we have working in BPC MS, so we need to replicate it in BPC NW for business continuity.

The long answer is that we have a very intensive close process that would be unacceptably delayed if, whenever master data needed to be added, we had to wait for a BPC administrator to be available to manually add the IDs in Production and/or take the system offline to transport a dimension from a lower environment. This is of particular relevance in regards to some of our dimensions that can require new members frequently and with little advanced notice throughout the close process. So for these dimensions, we have developed packages in BPC MS to automatically load in the master data and process the dimensions. These packages can be executed by a user without having administrative access. This allows users to keep these dimensions up-to-date on demand via a controlled process, without also being granted access to modify all master data.

Load from txt? / How the file is created?

In BPC NW we are implementing these as process chains. Above I said we were leveraging the out-of-box import processes – by that I mean we have based our development on the out-of-box processes to import the data at the BPC layer (so it is appropriately logged by the admin logging, etc)., rather than writing directly to the dimension tables via the back end; but we are not simply using the standard master data import packages. The data originates from our source systems via RFC connections in the BW layer. So rather than uploading a text file, the user just has to run the packages and they will automatically update the dimensions. This approach is already working reliably, but we just have this one issue with having to assign users too much administrative access!

[former_member186338 · Accepted solution]

First of all: "to transport a dimension from a lower environment" - for sure, it's a crazy idea to transport MD from development. Only changes in dimension structure are transported, not members. Members are loaded directly in production.

You can try to load MD by user using impersonation. Look on program UJD_TEST_PACKAGE

Read my answers: https://answers.sap.com/questions/693325/fmbapiclass-to-call-bpc-program-ujd-test-package-f.html?chi...

[alexander_b_white · Accepted solution]

Hi Vadim,

Thank you for your suggestion. I am pleased to confirm this approach worked for us! Our team was able to set up a DMP that a standard user can execute, which invokes the true MD load DMP via UJD_TEST_PACKAGE using a service account that has admin privileges. A side effect of this is that the user ends up seeing two packages running in the package logs – but that is a very minor nuisance given that this successfully allowed us to achieve our system requirements.

Out of curiosity, you mentioned above that it is crazy to transport MD from Dev to Prod. For master data that is not automated, do most customers have dedicated BPC admins who maintain the master data directly in Prod? This seems like a tedious role with potential for manual error, especially for master data that needs to be udpated somewhat regularly (but not regularly enough to make automation a worthwhile effort).

Cheers,
Alex

[former_member186338 · Accepted solution]

"do most customers have dedicated BPC admins who maintain the master data directly in Prod?" - Yes!

The following activities need to be executed directly in Prod by some admin:

1. Adding new members in WEB interface or DM text load. Example - adding new statistical account that is not loaded from ERP MD...

2. Changing properties of the existing members - for example properties used in BPC calculations (like target member derivation)