Massively Assigning Infoobjects to Multiproviders
In my previous blog post in this series dealing with automation in SAP BW, I’ve discussed automation and scripting in SAP BW, delving into an example of how to load a setup table from an Excel spreadsheet. This time, we’ll go into using scripting to make a large number of assignments in a multiprovider.
Multiproviders are deprecated in BW On Hana and non-existent in BW4HANA, however in pre-HANA systems they are still one of the main types of models used, and the capabilities of scripting illustrated by this example may be relevant for other applications as well.
If you haven’t read the previous post, please do so now – it has some important details regarding preparations and precautions that won’t be repeated in this post. The following method is offered without any kind of warranty and some caution should be taken.
Multiproviders are logical unions of several physical infoproviders, also referred to as part providers. Each infoobject in the multiprovider is assigned to one or more infoobjects coming from the different part providers. It is often the case that the BW consultant is required by the business to add a navigational attribute to a multiprovider. Unfortunately this involves not only turning on the attribute in each of the relevant part providers, but also assigning the attribute to each of them. This last part is notoriously difficult and error-prone.
It’s not uncommon for a BW consultant to pull out hairs scrolling through the assignment window, looking for the relevant infocubes and characteristics. When there is a large number of infoproviders, and/or the assigned characteristic has a shared reference characteristic with a lot of other infoobjects in the part providers, the difficulty level grows exponentially. Issues stemming from incorrect assignment of infoproviders in such cases are also quite common.
My first thought of how to deal with this was in the realm of quality assurance. The first thing I’d do after assigning a navigational attribute was to check the table RSDICMULTIIOBJ for the new rows added and see if the assignments were made for all infoproviders, and for the correct infoproviders and infoobjects.
That was before I got a requirement to assign 14 new attributes, each coming from 8 part providers.
Solution in detail
One of the first thing one notices when looking at the table RSDICMULTIIOBJ, which is the source table for the multiprovider structure, is that BW consultants can create new entries, and even change existing entries (obviously this may depend on the exact permissions). These capabilities represent a simpler, faster and safer way to assign infoobjects than RSA1 when dealing with a large number of part providers and characteristics. SAPGUI scripting makes this process even faster, with very little extra effort and without sacrificing simplicity or safety.
As we did with the setup table transaction, we’ll first need to prepare an excel file containing the data which we want to load into the system. In this case, this data should be structured like RSDICMULTIIOBJ, with each row containing an assignment between the characteristic in the multiprovider and a characteristic in the part provider. Note that the value of version needs to be M. The reason for that is that we are essentially going to replace the process of editing the multiprovider – changing version M, but we still need to activate it as we usually do.
For that purpose, you may first want to go into RSA1 and change the multiprovider. Save it to a transport – without activating it – and then exit RSA1.
Now go to the ALV table display of RSDICMULTIIOBJ in SE11 or SE16 and click on the “Create” button. You’ll get a screen which essentially allows you to create a new assignment in the multiprovider.
As in the previous post, open the script recording and playback window through the “customize local layout” button.You will need to choose the name and location of the script you want to save. Once you’ve done that, hit record.
Now fill the fields to add one assignment – say, the first one from the excel file – and click save. You can then stop the recording.
Go to the folder in which you’ve saved the file, and then right click the file and choose edit.
We will now edit this script to loop over the excel file, inserting all of the new records into the table, replacing the values with references to the cells in the Excel file and determining which rows the loop would go over. This process is described in full in the previous post.
To run the script, simply go back to the “Create” screen for the table, and reopen the scripting window, only this time click the play button and choose the script you’ve created (remember to close the excel file beforehand!). If you’ve done everything correctly, you should be seeing SAPGUI quickly filling the fields on the screen for each row. You can then open the multiprovider in RSA1 and activate it to complete the process.
The ability to change models using a script has far more potential than this one simple use. For multiproviders, adding a new part provider could also benefit from the same script. There are various requirements where similar scripts come in handy.
One requirement that immediately springs to mind is adding infoobjects to several infocubes – which is the complement of enhancing the multiprovider in the case of the requirement to add navigational attributes. However this specific requirement is not as easy to perform with scripts – I leave it as an exercise to the reader to determine why.
In the fourth part of this series we’ll give an ABAP solution for this very issue. But before that, we’ll see how ABAP can help us to divide long loading processes dynamically – in the next part.