Skip to Content
Personal Insights
Author's profile photo Matthew Billingham

Problem solving – a case history

I recently got a request for help from colleagues. They had a DataSource in BW, and it was, apparently, taking 23 hours to load 1500 records. They couldn’t figure out what was wrong.

It’s a push Web Service DataSource, and I’ve never worked on anything like it. I quickly searched on for information about it, and a few questions concerning in on, and understood that it is a Web Service called from a remote system, to push data in SAP BW.

But why was it taking so long?

I checked the monitor of the InfoPackage and saw there was a timestamp for Data request arranged of 18.12.2019 14:32:03. I checked the timestamp for Data request received and that was 19.12.2019 13:00:07.

Hmm. So what was the InfoPackage doing during that time?

I checked the times for other loads, and noticed a curious thing. While the Data request arranged timestamp varied, the Data request received timestamp was always just after 13:00 or 14:00. In fact, if the first time stamp was after 13:00, then the second was always just after 14:00 on the same day. There were three different scenarios:

First Timestamp Second Timestamp
Between 13:00 and 14:00 Just after 14:00, same day
Before 13:00 Just after 13:00, same day
After 14:00 Just after 13:00, next day

On a BW system, what kind of things run regularly? Well, process chains can be scheduled, and the InfoPackage is part of a process chain, so I had a look at that. Checking the log, I found that the process chain was scheduled to run at (drum roll) 13:00 and 14:00.

In one log, the chain had run only once at 17:32:14, so I looked for the InfoPackage log for that date and time, and lo and behold, the second time stamp was almost exactly that time.

My final conclusion was that there is no performance issue, just a scheduling issue. The time the external system pushes the data is the time, near enough, of the first time stamp. The second time stamp is when the chain runs.

Schedule the chain to run hourly, and you’ll get data in the final InfoProvider – if any is sent – hourly.

I found confirmation of this, finally, in

Real-time data acquisition (RDA) supports tactical decision-making. It also supports operational reporting by allowing you to send data to the delta queue or PSA table in real time. You then use an RDA job to transfer data into InfoProviders in the Operational DataStore layer at defined intervals. The data is stored persistently in BW.

I had no prior knowledge of RDA. I didn’t realise that a web service push DataSource is RDA. But by finding the patterns and applying a little logical thinking, I was able to resolve the issue.

Client is happy, so I’m happy.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ramana Kumar
      Ramana Kumar

      Interesting Case and Good analytical approach to find the root cause and resolve the issue.

      Author's profile photo Morten Wittrock
      Morten Wittrock

      Thanks for sharing. I love reading debugging/problem solving stories 🙂