WSR 00102 error with Filtering on Merged Variables
I
InfoSol Consultant
started a topic
8 months ago
If you have multiple queries based on similar values in a
single field that you wish to combine into one table or use as section across a
report tab, then you are familiar with the concept of merging in
BusinessObjects.
The Webi RESTful SDK has long had an issue with filtering using merged variables as noted in the KB
2687452 - Error WSR 00102 when setting a report level filter using the RESTfulSDK.
As noted in the KB, the error can be somewhat intermittent
based on which query’s values are considered primary and is not a problem if
all the merged queries have the same list of values for the merged
variable. Depending upon which is
primary, you might get the error or you might get a blank results. Since Infoburst uses the SDK, this situation
can come up for our clients and we have some error handling built in for some
situations where the SDK code would allow.
For the times when Infoburst returns the WSR 00102 error,
however, there is the need to modify the document to work around the limits of
the SDK. One of the simplest methods, is
to use a prompt instead of a report filter to burst the document. As noted in the KB, prompt parameters are not
affected by this primary property.
Oftentimes, however, the priority is for a single
pass/single refresh run with multiple filter steps in order to have a large
burst document split for delivery under the best performance circumstance.
For this situation, a few other options exist as work
arounds for the burst by filtering of the document.
If one of the queries has all of the values in it, then you can create a detail variable of the object from this query and base it on the merged dimension as a whole. Then you can use this variable detail to filter the document for bursting.
But often some of the merged values come from one query and
some from another and you don’t have a query that has all existing values.
If there is not a query already existing that has all values, then an additional query must be added that does. This object in the query can either be renamed in a detail filter as above or the object could already have a different name as a different object in a universe or a different named column in a static excel list.
When a new query is added, that new object with all the values must also be merged in order for it to work in filtering.
As a workaround to the SDK limitation, managing the values
for this new query may require some special filtering especially when across
databases. There may be the need to
regularly copy lists of values from one database to another for this filtering
purpose. The requirement is to end up
with one query that has all the values for the burst filter.
There may also be a resulting error if you try to use a query filter from the values of another query. This should be avoided since it ties the queries together prior to the merge.
WSR 00102 can be frustrating, but there are ways to work around this limitation in the SDK and make for happy burst results. Infoburst On!
InfoSol Consultant
If you have multiple queries based on similar values in a single field that you wish to combine into one table or use as section across a report tab, then you are familiar with the concept of merging in BusinessObjects.
The Webi RESTful SDK has long had an issue with filtering using merged variables as noted in the KB 2687452 - Error WSR 00102 when setting a report level filter using the RESTful SDK.
As noted in the KB, the error can be somewhat intermittent based on which query’s values are considered primary and is not a problem if all the merged queries have the same list of values for the merged variable. Depending upon which is primary, you might get the error or you might get a blank results. Since Infoburst uses the SDK, this situation can come up for our clients and we have some error handling built in for some situations where the SDK code would allow.
For the times when Infoburst returns the WSR 00102 error, however, there is the need to modify the document to work around the limits of the SDK. One of the simplest methods, is to use a prompt instead of a report filter to burst the document. As noted in the KB, prompt parameters are not affected by this primary property.
Oftentimes, however, the priority is for a single pass/single refresh run with multiple filter steps in order to have a large burst document split for delivery under the best performance circumstance.
For this situation, a few other options exist as work arounds for the burst by filtering of the document.
If one of the queries has all of the values in it, then you can create a detail variable of the object from this query and base it on the merged dimension as a whole. Then you can use this variable detail to filter the document for bursting.
But often some of the merged values come from one query and some from another and you don’t have a query that has all existing values.
If there is not a query already existing that has all values, then an additional query must be added that does. This object in the query can either be renamed in a detail filter as above or the object could already have a different name as a different object in a universe or a different named column in a static excel list.
When a new query is added, that new object with all the values must also be merged in order for it to work in filtering.
As a workaround to the SDK limitation, managing the values for this new query may require some special filtering especially when across databases. There may be the need to regularly copy lists of values from one database to another for this filtering purpose. The requirement is to end up with one query that has all the values for the burst filter.
There may also be a resulting error if you try to use a query filter from the values of another query. This should be avoided since it ties the queries together prior to the merge.
WSR 00102 can be frustrating, but there are ways to work around this limitation in the SDK and make for happy burst results. Infoburst On!