Replacement Path in BEx Query
Replacement Path in BEx Query and BO Workaround
You want to make BEx query accessible to Business Objects, in which a variable of type replacement path with query is used.The replacement path query has a ready for input variable thus the BEx query cannot be made available for OLAP (SAP note: #820925).
In the above example YA_FPI is replacement path query with ready for input variable ‘Employee’.
BEx Output:
Shown below is the output of the main query that is based on the Employee(Person) fetched from the replacement path query.
BO Alternate Solution: Merging Dimensions
The same functionality can be achieved using the merged dimension functionality in BOBJ report.Create a report with 2 dataproviders: 1. Replacement Path Query, 2. Main Query and merge based on similar dimension (Replacement path variable from replacement path query and similar dimension from the main query should be merged).
Drag object from replacement path query(replacement path variable) and remaining objects from the main query.
This works similar way the left and right outer join works in RDBMS. See the below workflow for better understanding:
- Create 2 universes
1. on replacement path query
2. on main query
- Create a report based on above 2 dataproviders(Universe).
- Merge the object(replacement path variable) from replacement path query with the similar dimension object in the main query. As shown in below example – Employee Key from replacement path is merged with Employee Key from main query.
- Now we want replacement path query to drive the results, to achieve this open up each merged dimension object and use the dimension key that come from the replacement path query and fetch the other objects from the main query.
Here’s what the block kook like:
BO Output:
This way the objects from main query will be restricted only for those Employee Keys(Person) fetched from the replacement path query, as the dimensions are merged.
Hi Sonam,
Very useful blog. Quick question...
Will the main Query run in BW with open selection and the filtering done on Business Object side? I am just trying to see if this design will work in a case when the main query needs the restriction of the replacement path for optimum performance. Any insight is greatly appreciated.
Hi Sonam
From my understanding this approach require to retrieve all the data from the main query and but the 2nd query to be restricted. Then, Merge occurs on report side, enabling you to filter but this occurs post execution.
Naturally this has an impact on performance if main query retrieves a lot of records.
Best Regards
Erick