Skip to Content

CRON Legacy – an SAP BW Story

Every day in the morning we receive a bunch of e-mails from our SAP BW system on data load completion and status

We get mails like :
“The data target XXXXX has been loaded with 20000 records from source system PCFILE”

Before going into details .. let me explain the setup we had ..

We have a custom program to send out mails which tell us how many records were loaded from a particular source system – in this case we have separate flat file systems for each source of data and this program reads the number of records activated and sends out the mail.

Some questions I have on the informing users and its related challenges

What kind of information do you send out to users ?
I have seen some projects where people decide not to inform users about data load completion but instead expect the user to find out the data availability form the technical content. But then when you use multiproviders , there is a challenge to update the specific dates when specific cues were updated – for instance if you have a plan and actual multiprovider and the plan values are loaded every month and the actual value every day – the multiprovider would still show the date when the plan cube / ods was loaded.

In this scenario – do you send out mails to users on data load completion ? here too there are some challenges namely :

  • The automated mail that BW process chains produce is not something that end users would understand and whenever you have an additional end user – you would have to walk them through the mail
  • You can draft a custom mail program to do the same but its additional effort
  • If you have an offshore team monitoring data loads , they could draft the e-mail and send it across ( but is this something that offshore should do is debatable – and also depends on the project constraints )

Another beast is the consolidated load statement that many projects send out to the project managers about all the data loads done during the nightly batch cycle and successive teams of offshore members and onsite automation seem to have either simplified it to something that no one trusts or made it too complicated that it takes 2 hours to prepare the same!!

But then the irony of the fact is that these reports are taken in all their seriousness only when :

  • UAT – when the solution is being built and tested
  • When a serious issue occurs and people dig up previous mails with status updates to find out what exactly happened

My take on this is that – have a BSP Page or a Web Dynpro which gives all these details ( the table information is quite easy to get to and building this report should be straightforward ) and put up the same on Portal.


A  Better way IMHO would be to generate these reports using programs and then store them in a central location – in most cases SOLMAN is already the system of choice to manage SAP systems – and since this information is available in standard SAP Tables – you could then get the data into SOLMAN – build a cube / ODS on top of it and have reports and if you need regulatory reports – generate BW reports of SOLMAN and store them so that the data is logged.

Alerting End users regarding data availability

The next question is to whether users should be alerted regarding data availability – which leads me to a different question – if you have a BW-BO setup – in many cases , it is common to precache or precalculate reports for faster execution – and in many cases this is done using trigger files – do you do it with trigger files sent from within the BW system or how does the BO system know that the sales cube is refreshed and the sales report has to be refreshed after the daily data loads

Doing the above with time of load should be easy but then there is always the uneasy feeling that if the data load does not complete , then the reports could be wrong!!!

And another challenging question is – if you have real time loads running from ECC into BW – do you alert the users everytime or some time or not at all?

In some projects there is a technical power user group who handle all communication and as long as user X,Y.Z are informed , the rest of the business users would find out the status of the same from these users and we do not need massive mail lists but then each project works differently…

This question also becomes to a larger question – how do you trust your data ? – I will reserve that for a separate blog.

Some of the points above would be ranting off some of the concerns I have regarding the alerting mechanism but I think they are valid points for discussion and am very interested in knowing what others do …

The link referred to in the blog is something that triggered me to write a blog on my own and the poetry referenced in the blog link was something I thought was extremely good

Disclaimer : All the thoughts and opinions reflected in this blog are my own and do not represent any of my employer’s 

1 Comment
You must be Logged on to comment or reply to a post.
  • Hello Arun,

    Some concepts are timeless, this blog post from 2011 is valid now and will be so for some more years. I believe the monitoring and alert mechanisms should be automated to a high level. BW operations team should come into picture only if something happens out of process and even then they should just update the reason and expected resolution time. This update should also happen at a single place like a portal from where all users can get the relevant information that they are interested in. This reduces the burden on the operations team. This in turn means that the monitoring and alerting process is very simple and easy to maintain and understand.