A typical problem
Did you notice that there are a lot of requests coming where you need to build large queries with lots of rows just because people want to populate a database for a different application?
Let’s say there’s a car company building an order reversal process. To reverse the order they need information about the order itself (customer, order number, rebates, etc.), the billing information and about the car that was built.
Nicely enough they don’t ask each of the original systems but they are asking you as the BI team. All the data is available in the BI but they have a complex application and they don’t want the user to open BI in a second window and copy over the information (which would be a huge waste of time).
No problem, you might think, I’ll just use the Open Hub functionality of the BI to send them all the data they want. Or I’ll let them send me an MDX statement to get the data. Easily said, isn’t it?
A modern solution
But we’re not in 2005 anymore, it’s 2010. So instead of using proprietary interfaces why not use SOA? Could it be as simple as it sounds? Yes, it can.
SAP provides a simple WebService called GetQueryViewData. You provide an InfoProvider, a Query name and you have the chance to pass different parameters. Does this solve our problems? Yes. Now the order reversal system can call the web service (in this case it was three times for three different queries), pass the order number that needs to be reversed and receives the information.
- You don’t need to deliver a file with thousands of orders per day when only a few of them get reversed.
- You have a stable and commonly used interface and you can change (within limits) the underlying data model without the need to completely rebuild the interface.
- The caller doesn’t need to meddle with MDX statements that he doesn’t understand. All he needs is the query name and variable names.
- Using a WebService requires some more customizing especially if you don’t use the portal – but it’s worth it.
- Don’t use the WS to read thousands of data lines.
- The calling system now relies on the BW as a constant data provider. So if a load process breaks or your BW system shuts down shortly there should be a fallback scenario.
The described scenario is now in production for more than a year without a single problem on the BI side. Implementing this scenario made me SOA contact for my department which leads to an interesting new look at projects.
SAP positions the BW as enterprise data warehouse for quite some time now. This webservice is the easiest way to get the data OUT of the BW again if you need the data in small chunks. Use it wisely and learn to play with SOA on the way.
If you want to see in in use, Prakash Darji wrote a nice blog about it. You can find it here: