- SAP Managed Tags:
I was about to start work on the next Integrated Planning Project but before that I wanted to spend some time exploring the new ADSO for planning. I could not find much on the web beyond the basic settings to be made in the ADSO for planning. So I decided to spend some time researching and trying it out myself.
I am positive that the usual things like creation of an aggregation level on the ADSO, the planning query etc. will work as expected. What I wanted to check was whether it was possible to do a lookup using ABAP in the plan data.
In this blog i will also describe why this small missing limitation was so needed for integrated planning projects .
Welcome to the new world of the SAP HANA Studio:
ADSO for planning and Integrated Planning:
Before the advent of the planning ADSO planning could only be done on transactional cubes and in SAP BI it was not possible to do a lookup using ABAP into the cubes. There was a function module “RSDRI_INFOPROV_READ” which could do a lookup into the cube but it had very limited use.
So how was this a problem for Integrated planning projects anymore then it was for the usual BW projects?
Consider a planning scenario where each yearly planning cycle consists of three versions V1 to V3. When the users have finished entering their numbers for V1, the planning administrator via an administrator workbench locks the version V1 and then he initialises V2 .In due time he does the same for V3 by locking V2 and initialising V3.As per requirements the administrator is not allowed to initialise V2 before V1 is ready and locked for a particular year and he is not allowed to initialise V3 before V1 and V2 are ready and locked for a particular year.
What is V1, V2 and V3???
Versions can be used in many ways in planning. For e.g. In V1 the country managers enter the forecast at the country level .In V2 the forecast is done by Country and state and in V3 by Country, state and city.
The planning scenarios are usually much more complex than what I have described here. But I think this is sufficient to help you understand the problems faced when I describe them in the next part.
Now lets discuss the real problem..
So let’s assume the administrator wants to initialise V3 so that the users can go in and start entering their numbers. So when the administrator presses the “Create New Active Version” button the system first want to check if V1 and V2 for that year have been submitted and are locked. To do this check we need to do a lookup into the plan cube data. So on pressing of the button the following steps are executed
Step 1: On the press of the button execute a planning sequence which triggers a process chain.
Step 2: In the process chain we move the planning cube to load mode, empty DSO,Load data from cube to DSO, activate data and move planning cube back to plan mode.
Step 3: We now execute a second planning sequence which calls a function module which does the lookup and if V1 and V2 are locked the system it will initialise V3, else produce an error message.
Step 4: The user keeps refreshing the page to get an error message like “Version V2 is still open for planning” or a success message “Version V3 is initialised”.
If you look closer you will realise that it was possible to do all of this without the process chain only if we could do a lookup into the cube at the very first step. And even better all that was done in steps 1 to 4 could be accomplished with a single planning sequence.
To get over this limitation with cubes we ended up using workarounds. One way is to create a DSO for each cube and load them with the planning cube data and then do a lookup into these DSO which is what we see in steps 1 to 4 above. The second way was to set up a fancy way of managing flags by writing into info objects or tables.
This led to the following problems
Problem 1: Bad design with redundant objects
A DSO for each cubes, planning sequences to trigger process chains, process chains themselves were all objects that could have been avoided leading to a better, simpler design of the application.
Problem 2: The bigger problem -Bad user experience
But if a lookup was possible then we could do all of this without a process chain and with a single planning sequence. One of the benefits of a planning sequence is that it would immediately give you the result of the operation. This is what the user expects and this is also the kind of experience that the design team wants to deliver.
So lets build a quick application and see if we can do a lookup into the plan data
In this blog I plan to create a simple planning layout on a ADSO for planning and see if that helps me get over this problem.
The planning DSO generated five tables .The first two are relevant to us. The inbound table contains the plan data which has not yet been activated. Think of this as the yellow request in the planning cube. This also includes any data that you may have loaded but not yet activated. The active data table has the data which has been activated. In ADSO for planning the open planning request is always green.
So to see if a lookup using ABAP was possible I copied the same DSO and created a transformation from the planning DSO to this DSO .In the end routine I introduced a look up with break points. I initially committed the error of going only for the Active Data table but soon I realized I also had to include the inbound table .The inbound table contains what was the yellow request of the old planning cubes. The Active Data table contains the data that has been activated.
On activating the request all data goes to the active table. Remember now just flipping the status of the cube from plan to load and back will not do the trick. You have to activate the request if for any reason you want to open a new planning request.
Conclusion
We can do a lookup into the plan data in the ADSO for planning .This means we don’t have to include a process chain in design every time we want to do just check status of some data.
And this makes me very happy and if given a chance I would like to go back and redo the old planning applications I worked on with the ADSO for planning.
I am positive that the usual things like creation of an aggregation level on the ADSO, the planning query etc. will work as expected. What I wanted to check was whether it was possible to do a lookup using ABAP in the plan data.
In this blog i will also describe why this small missing limitation was so needed for integrated planning projects .
Welcome to the new world of the SAP HANA Studio:
First thing I realised is if you want to use the ADSO for planning then you have to use the new HANA Studio based BI Modelling perspective. Now in the old SAP GUI menu there is no menu option to create an ADSO so don’t waste time trying to create one in the old RSA1. To use the HANA studio or create an ADSO you should be on version 7.4 or higher. I had already been using HANA Studio for some time for following the Open SAP Native HANA Software Development courses (Thomas Jung) and changing some design studio SDKs that I picked up from the web to include in the dashboard I was working on. So when I decided to explore the BW side of things I did not have much of a learning curve. I feel that working on the HANA Studio is easier than it was with the SAP GUI. As i spent more time working with the BI perspective i realised that multiple tabs are way easier to handle and refer back then multiple SAP GUI sessions. Also creating queries in a new tab and not having to open the query designer also makes life very simple. One inconvenience I faced when I worked with the earlier versions of the HANA Studio was that you had to step out of HANA Studio and open the SAP GUI for creating transformations etc. It is still not possible to create or edit a transformation in the HANA Studio. But now there is a new feature whereby you can open the old GUI based BI system within the HANA Studio and so you can do your transformations etc. without having to step out of HANA Studio. The overall BW Modelling perspective in HANA Studio is still WIP but whenever it is ready it will be very nice to open one tool and work on it rather than a separate SAP BI GUI, Query Designer etc.
ADSO for planning and Integrated Planning:
Before the advent of the planning ADSO planning could only be done on transactional cubes and in SAP BI it was not possible to do a lookup using ABAP into the cubes. There was a function module “RSDRI_INFOPROV_READ” which could do a lookup into the cube but it had very limited use.
So how was this a problem for Integrated planning projects anymore then it was for the usual BW projects?
Consider a planning scenario where each yearly planning cycle consists of three versions V1 to V3. When the users have finished entering their numbers for V1, the planning administrator via an administrator workbench locks the version V1 and then he initialises V2 .In due time he does the same for V3 by locking V2 and initialising V3.As per requirements the administrator is not allowed to initialise V2 before V1 is ready and locked for a particular year and he is not allowed to initialise V3 before V1 and V2 are ready and locked for a particular year.
What is V1, V2 and V3???
Versions can be used in many ways in planning. For e.g. In V1 the country managers enter the forecast at the country level .In V2 the forecast is done by Country and state and in V3 by Country, state and city.
The planning scenarios are usually much more complex than what I have described here. But I think this is sufficient to help you understand the problems faced when I describe them in the next part.
Now lets discuss the real problem..
So let’s assume the administrator wants to initialise V3 so that the users can go in and start entering their numbers. So when the administrator presses the “Create New Active Version” button the system first want to check if V1 and V2 for that year have been submitted and are locked. To do this check we need to do a lookup into the plan cube data. So on pressing of the button the following steps are executed
Step 1: On the press of the button execute a planning sequence which triggers a process chain.
Step 2: In the process chain we move the planning cube to load mode, empty DSO,Load data from cube to DSO, activate data and move planning cube back to plan mode.
Step 3: We now execute a second planning sequence which calls a function module which does the lookup and if V1 and V2 are locked the system it will initialise V3, else produce an error message.
Step 4: The user keeps refreshing the page to get an error message like “Version V2 is still open for planning” or a success message “Version V3 is initialised”.
If you look closer you will realise that it was possible to do all of this without the process chain only if we could do a lookup into the cube at the very first step. And even better all that was done in steps 1 to 4 could be accomplished with a single planning sequence.
To get over this limitation with cubes we ended up using workarounds. One way is to create a DSO for each cube and load them with the planning cube data and then do a lookup into these DSO which is what we see in steps 1 to 4 above. The second way was to set up a fancy way of managing flags by writing into info objects or tables.
This led to the following problems
Problem 1: Bad design with redundant objects
A DSO for each cubes, planning sequences to trigger process chains, process chains themselves were all objects that could have been avoided leading to a better, simpler design of the application.
Problem 2: The bigger problem -Bad user experience
- Since we are using a process chain, the user had to wait till the chain completed or stopped at an intermediate step for e.g. because the previous version was not locked. The relevant messages would then appear on the admin workbench screen.
- Sometimes the chain failed due to technical reasons but as there was no way to notify the user the user keeps on waiting for the notification or just leaves the application assuming the step is done.
- We also had to build in checks so that the user does not trigger the chain multiple times by pressing the button again and again.
- The user had to keep refreshing the page for messages. This was very inconvenient for the users.
But if a lookup was possible then we could do all of this without a process chain and with a single planning sequence. One of the benefits of a planning sequence is that it would immediately give you the result of the operation. This is what the user expects and this is also the kind of experience that the design team wants to deliver.
So lets build a quick application and see if we can do a lookup into the plan data
In this blog I plan to create a simple planning layout on a ADSO for planning and see if that helps me get over this problem.
The planning DSO generated five tables .The first two are relevant to us. The inbound table contains the plan data which has not yet been activated. Think of this as the yellow request in the planning cube. This also includes any data that you may have loaded but not yet activated. The active data table has the data which has been activated. In ADSO for planning the open planning request is always green.
So to see if a lookup using ABAP was possible I copied the same DSO and created a transformation from the planning DSO to this DSO .In the end routine I introduced a look up with break points. I initially committed the error of going only for the Active Data table but soon I realized I also had to include the inbound table .The inbound table contains what was the yellow request of the old planning cubes. The Active Data table contains the data that has been activated.
On activating the request all data goes to the active table. Remember now just flipping the status of the cube from plan to load and back will not do the trick. You have to activate the request if for any reason you want to open a new planning request.
Conclusion
We can do a lookup into the plan data in the ADSO for planning .This means we don’t have to include a process chain in design every time we want to do just check status of some data.
And this makes me very happy and if given a chance I would like to go back and redo the old planning applications I worked on with the ADSO for planning.
14 Comments
