Adding ALL to LOV or "ALL" Prompt Value in Business Objects

In this topic, we will discuss about "All" value in prompts.

This is the most frequent scenario, which comes across Business Users and developers, why this option is not available in BO. It is till XI R2. But in XI R3.1 SP3 it got little push-up. Even though, its not yet upto the mark when it comes to implementation in Universe Designer.

Let's take an example. There is a Region dimension object which contains values as "INDIA, CHINA, US, JAPAN, MEXICO".

When we define a prompt object, user can select one or multiple regions. If the user wants to select all regions, we must select one by one and pull it into required list of regions. To avoid that, if we have an "ALL Regions" or "ALL" or "*" option to consider all regions in report, that would make Business Users easier.

1.  Create a conditional object.
2. @(Location\Region) = @Prompt('Select Region','A','Location\Region',mono,free,Not_Persistent,, user:1)
3. The above condition is defined in general if we want to allow users to select one region from list of available regions. 
4. Now we will incorporate "ALL" option here.
5. @(Location\Region) = @Prompt('Select Region','A','Location\Region',mono,free,Not_Persistent,,user:1) or "ALL" =@Prompt('Select Region','A','Location\Region',mono,free,Not_Persistent,,user:1)
6. We just added a additional expression  or "ALL" =@Prompt('Select Region','A','Location\Region',mono,free,Not_Persistent,,user:1). 
7. This expression is added with an OR clause. This condition is valid when the user provides "ALL" as input value. 

Keep watching this space. Will come up with more interesting topics!

Advantages and disadvantages with Stored Procedure Universe in SAP Business Objects

 Stored procedures offer the following benefits:

• They encapsulate code. The database operation appears once, in the stored procedure, and not multiple times throughout the application source. This improves debugging as well as maintainability.

• Changes to the database schema affect the source code in only one place, the stored procedure. Any schema changes become a database administration task rather than code revision.

• Since the stored procedures reside on the server, you can set tighter security restrictions. This saves more trusted permissions for the well-protected stored procedure themselves.

• Because stored procedures are compiled and stored outside the client application, they can use more sensitive variables within the SQL syntax, such as passwords or personal data.

• Using stored procedures reduces network traffic. In BusinessObjects XI Release 3.0, you can use stored procedures with Desktop Intelligence and with universes in Designer. You also benefit from

universes that contain stored procedures for Crystal Reports and WebIntelligence.

 

Restrictions apply to stored procedures universes:

• No joins are permitted between objects in stored procedures universes.

• Filters cannot be used on the stored procedure universe.

• You cannot link a stored procedure universe to a standard universe.

• The Web Intelligence supervisor grants access to the database or account where stored procedures are located.

• Not all RDBMSs support stored procedures.

• COMPUTE, PRINT, OUTPUT or STATUS statements contained in stored procedures are not executed.