Following will be an article which is divided into 3pieces. First an introduction to what I do and why I write this article, as well as a must do before changing process chains and how to check which chains have performance issues. Second article will be on how to optimize infopackages and DTP’s. Lastly, we’ll end with how to improve the performance of DSO’s and Cubes.
I recently started working as a SAP analytic. My first project was in SAP BW where I had been given the chance to optimize the current process chains for a company.
At the time we had 4 daily chains running (one in the morning, at lunch, in the evening and at midnight). Most of the chains where divided into 4layers. One that loads in the master data, one for loading in info packages, one for the DSO’s and one for the Cubes. So a pretty organized structure to start in and get to know everything.
When I started the project I had almost no knowledge about process chains or the data and structure of the company. So for optimizing the process chains I had to rely on google to find solutions. Luckily for almost everything there is a solution on google, unfortunately everything I wanted to know about optimizing process chains was divided over the web and I had to get everything I wanted to know on 100+ different pages. This is where I wanted to start my first blog, a blog about all the information I gathered during the months I have been optimizing the process chains.
Note that I’m currently still working on optimizing the process chains, so if I come across new things I will include them in here as soon as possible.
So let’s start off.
(I’m going to assume since you want to optimize the process chains you are familiar with ‘RSPC’ and know how to get the chain ID and other common things).
The first thing I did when starting (and for me personally the most important step) was documentation. I started off creating an OneNote document where I mapped the current structure of all chains. Remember you are going to make changes in a system someone else created and is (hopefully) at the moment functioning correctly. If you are just going to change things without documenting it you will eventually make a mistake and have no idea on how it was before. It is important to keep track of everything you do as well as of how it was before. Creating good documentation has another positive side effect. When you are mapping the process chains you will also have a look into the monitoring of DSO’s, Cubes, … . So even before checking the runtime of the chains you can spot some abnormalities in here. For example I spotted a few DSO’s that loaded in daily but only added a record monthly, so I could already mark this load to be moved to the monthly chain.
Yes I know mapping out all the chains and documenting them takes a long time and becomes boring. But trust me, it is worth it.
Now for the real work. After you have made a good documentation on how everything is currently working you can go and have a look at the runtime of the chains. I personally like to look this up with transaction ‘ST13’. As tool name type in: ‘BW-TOOLS’ and press execute. Next cross on the radio button of Process Chain Analysis and again press execute. Click on the ‘Process chain button’ and type in the process chain ID (We have a chain that stands above all others, I like to take this ones ID because it will also display all chains underneath it) and press execute.
If you don’t use daily process chains you will have to adjust the start and end date accordingly to when the chain has run before. You can also select a broader range of dates that way you can compare the runtimes of the chain.
Here you can already see the Runtime of the chain. However we want see in detail what exactly is consuming a lot of time. So simply click on the underlined text in the column ‘Chain’ (A lot of info on images will be blurred out I’m not certain which info I can show and which not, so better safe than sorry J ).
In this detail view we can open each chain individually and take a closer look on what is having a long runtime. You can also see the amount of records loaded in which is a very helpful indicator on whether a load is taking an abnormally long time to run or not.
On this detail view you can already get a better look on loads that take a long time to process. Simply double click the load in the ‘Process Chain Hierarchy’ column, this will take you to a detail view of the load. Example of a Load from an infopackage:
So now you know how to spot the chains that are problematic. With this information we can start the real work in the second article. There we will begin with the loads from infopackages.
Loading data into a DWH can sometimes be a hassle. Defining your delta too. So let’s keep things simple. There are numerous ways to define a delta and load data into a DWH. But let’s highlight some simple strategies to do so. Eventually we will be able to combine a delta and a full extraction into one single flow by using variables and creating a conditional where clause.Read more >
In a SAP BPC standard environment, the main interface to input data is MS Excel. In order to communicate with your SAP BPC model, the BPC EPM Add-in needs to be installed. In some cases, it would be an advantage to avoid this installation on all BPC users’ laptops. Here are some reasons:Read more >
Getting structure in the new HANA environment is not as easy as it first seemed. It all started easy, just one model to combine some ADSO generated views and use it in Analysis for Office. But after these scenario’s some new requirements popped-up: the simple views needed an update and became more and more complex. Some logic from the ADSO was removed and put into HANA views, meaning that the previously used generated views had to be remapped. That got us thinking… We needed a more efficient way to avoid this in the future.Read more >