Business Planning and Simulation version for Netweaver successfully leverages the Netweaver infrastructure and we can use many tools and techniques that are available to us in the Netweaver platform. Debugging is one of the powerful tools that one can effectively use for issue resolution. However debugging in BPC7NW is different than debugging other usual SAP transactions. In this blog let us talk about why it is different and what we need to do to enable us to debug with BPC7NW.
Why debugging is different in BPC7NW:
In a regular SAP transaction, if an end user is executing a transaction and we want to debug it, one of the usual ways might be to set up a break point for that user so that the debugger will prompt us when the underlying program encounters the transaction executed by that user. It is little bit different in BPC7NW. To understand the difference, let us look at the architecture of BPC7NW. The following diagram shows the high level architecture of BPC7NW.
The end user of BPC7NW does not use SAP GUI. He/she uses BPC front end. BPC users as well as their authorizations are maintained on the BPC front end. When a BPC user takes an action, for example – modify a property or edit a dimension member, the corresponding BW infoobject in the BPC namespace is automatically modified. (You can read more about the automatic generation of infoobjects in the BPC namespace at A reservation of a different kind – why, what and how of BPC namespace) The BPC front end, which is on the .NET layer, communicates with the ABAP layer by means of service users. If we want to debug any BPC activity, we need to map a valid debug user in the ABAP layer to the BPC user so that the debugging can be done with that debug user instead of anonymous service user. This step of mapping a debug user is generally not necessary for debugging a usual SAP transaction. In this regard, debugging in BPC7NW is different. Now the next question is what do we have to do to take care of this difference. Let us discuss that.
How to enable a BPC user to debug in BPC7NW:
In order for us to map debug user to BPC user, we need to access the BPC Server Manager. Within the BPC Server Manager, we have the option to maintain debug users as shown below.
Here we can maintain debug user and password for each BPC user as shown below. Many BPC users can share the same debug user if necessary. If a BPC user is not maintained here, that BPC user may not be able to debug.
Once we maintain the debug user, we have made the necessary set up required for debugging in BPC7NW. The next question is how to know what program, API, function module etc to debug for a specific BPC action. For example, if someone is having an issue in say modifying an application, then how can he/she know which API/program/function module that ‘modify application’ task is using.
Identifying the development objects germane to a specific BPC task:
Fortunately BPC7NW provides us a very simple way to identify all the development objects pertinent to the BPC task or action that we want to debug. Just go to the Object Navigator (transaction se80) and select package UJ as illustrated below.
Here we get a list of all APIS for BPC7NW as shown below. We can easily select the program appropriate for the BPC task that we want to debug.
We can set an external breakpoint in this session. Whenever that BPC user linked to the debug user executes that BPC action, the debugger screen will open. For example, if we are facing an issue in modifying an application, then we would select the API for modifying application and set a breakpoint there. Next time our BPC user (linked to the debug user) clicks on modify application; it would stop at the breakpoint set by us.
Ability to debug in this way is a feature that becomes very useful – especially while troubleshooting. Though we still can’t easily debug the issues in .NET layer of BPC7NW, we can definitely take advantage of this powerful debugging feature for any issues in the ABAP layer where majority of processing occurs.