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 help.sap.com for information about it, and a few questions concerning in on answers.sap.com, 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 help.sap.com
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.