SAP BusinessObjects BI Services are a class of web services that can be easily created by converting web intelligence (webi) report blocks into web services. A simple GUI wizard guides the report developer through a few simple steps that publish the report block as a web service and provide a WSDL that can be used to interact with the report block data. As i wrote in an older post, the BI Services combine the power of Live Office in leveraging webi full capabilities (using variables, filters, formulas, cross tabs, etc) with the power of QaaWS web services (good caching capabilities for enhanced performance).
The BI Services publish with two default methods. A GetReportBlock method and a Drill method. For this post, i will examine the GetReportBlock configuration and describe some of the refinements you can apply to the web service as you consume it in your application.
First, a word about the difference between prompts and filters: BI Services introduce a powerful concept of filters. Basically, any object in the report can be used as a filter in the web service. Filters can be applied at the database level during query time, or to a saved report instance data. Prompts are only applicable at the database level and cannot be applied to saved instances.
Next, there are two main input parameters that control the GetReportBlock behavior with regards to filtering and running against the DB vs running against saved reports instances: refresh and getFromLastDocumentInstance (or getFromUserInstance in “bursting” schedules scenarios). All these parameters are boolean types and setting them to true or false will result in different behavior from the web service during consumption time. Here are some example:
The initial setup is a simple report that returns the Years object from the e-Fashion universe. The report has an optional prompt on the Year object. The simple report block was published as a BI Service. When we run the report, it looks like so in webi:

We can test the web service configuration right from within webi

In our first test, we set the refresh parameter to true and send the request. This is because we set the report to refresh, we did not specify a prompt value, and since our prompt is optional, it was ignored, and we did not specify any filter value.

In the second test, we still use the refresh parameter to hit the database, but this time we specify a prompt value. We get back the year row we expect.

To demonstrate the interoperability of the filter and the prompt in a refresh scenario, we clear out the prompt value and use a filter that is set to equal a different year now.

Now, let’s try review what options are available when we schedule the report and save it with data. Let’s schedule our report with two years (rows) of data: 2004 and 2005.

This time, when we go to test our web service, let’s use the saved report instance, and see what happens. First, let’s change our test settings to use the getFromLastDocumentInstance instead of refresh, and leave the filter value empty (since we are working with a saved instance, the prompt value will be ignored even we if we try to use it). This time, we will get the saved instance results, just two rows of data.

If we apply a filter for say, year 2005, we get the data from the report instance

We will not hit the database, so even if we try to filter for a value we know to exist in the DB, such as 2006, since we are only getting data from the saved report, we will not get any result back.
Also, if during testing you lose the state of your service between cached and non-cached versions, or need to reset the service state for any other reason, you can set the resetState parameter to true.

So all in all, the BI Services provide a lot of configuration options to address a wide range of reporting use cases from all saved data to no saved data used.