BPC is a tool for planning and consolidation, which is available in two platforms one in Microsoft and other in Netweaver. All the objects created in BPC Netweaver platform are created as BI objects and saved in the backend BI system connected to it.
All the logics and functions defined in BPC NW frontend are developed using ABAP logics in the backend. Also we have option to write custom ABAP codes using standard BADI’s delivered with the tool for various business requirements. So for checking the malfunctioning of any function in BPC frontend we need to debug the corresponding ABAP logic of that function in backend. For which we need the option for debugging. The same is provided in the BPC NW system which has to be configured in the server end with the details for Domain User, BI user ID and its Password.
System Connection Issue:
The user details what we use in the front end to connect to the BPC system is domain/system specific, whereas different set of user details are used to connect to BI system in the back end. So when a domain specific user connects to the BPC system in front end, simultaneously a connection is established with the backend BI system.
To establish this connection with the backend BI system, it uses different BI user details depending on the debug user maintained in the server. Below flow chart clearly states the procedure for connection establishment between BPC and BI system.
So having said these one can connect to a BPC NW system only when,
- Domain User ID and Password are correct
- Backend BI user ID and Password are correct
The Domain user ID and Password are the one we would be providing from the front when connecting to the BPC system, but BI user ID and password are automatically taken by the system for establishing the connection with BI system. These values are taken either from the key user details or from debug user details depending on the user logging in and the debug user table.
Consider we have a domain user maintained with his corresponding BI user ID and password in the debug user screen of the server. When the user tries to connect to BPC, the BI credentials provided in the debug user screen of the server will be used for establishing connection with BI system. Having said this, if the details are not maintained correctly or the BI password is locked then the user will not be able to connect to the system.
When we don’t have any debug user maintained in the system, we are connected using a Key BI user ID which will have all access to the system and so from the frontend we will not face any problem in performing any operations. But if a debug user is maintained for a domain user and if the BI user used has a limited access in the BI system we may have problems in performing certain tasks from BPC end.
Consider a domain user which is maintained in the debug user screen with BI user ID and password. The BI user provided in the debug user screen has access only to certain functions like create BI objects and to some other transactions used for programming but do not have access to the transactions to save files in the SAP system. When this particular domain user logins to the BPC system and tries creating any BPC object he will not have any problem, as he have access to create any object.
But when he tries to run some Data Manager Package for loading a master data from a flat file which is in the BI server, since the BI user provided in the debug user screen doesn’t have authorization to access the file the data manager will fail stating “No Authorization for Accessing the file” in the error log.
So when we maintain debug user screen in the server we need to make sure of the following,
- The BI credentials provided are correct
- The Password for BI user provided is not locked
- BI user provided for debug user has all access which will be required when working from the front end BPC system.
If we miss the first and second option, the user will not be allowed to login to the system. If we miss the third option, it is not sure that user can perform all the actions from BPC end.
To prevent all these problems it is better to make sure that the Debug user details are maintained as and when it is required for debugging and removed when we don’t have the work with debugging.