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.
As a consultant I’m responsible for the Analytics environment for an Innovative Company in Natural Chemistry and innovative in their IT. Recently I was forced to ponder on the post-Lumira question “ Now what ? ”.
Read more >
I recently finished a project for which I had to fetch public data of parking lots and load it to a multiprovider to use it in reporting. The data that I needed to fetch was from an open data API. After successfully finishing this project I thought I would share how I did this as an easy guide for others.Read more >
If there is one thing common in everyone’s career than it is that at some point everyone said: “Can’t this be automated or made simple?”. On a given moment at my customer I was asked to do a data-compare of two data providers with over 50 characteristics each and containing millions of records in SAP HANA. At first I started to run queries against the SAP HANA-tables to check the data but soon enough I thought…Read more >