Embedded Input Schedule from Bex Query

Hi Experts,

I have created an input ready query in Bex, based on a BI-IP Filter etc, incorporated in a workbook and all works 100%. All the infoobjects are based on the queries' Extended-Master Data setting and behaves correctly. However, as soon as I use the query in BPC Embedded in an input schedule, I only get values as posted in the cube. It seems that the Bex-Extended-Master Data setting is ignored.

Is this normal for BPC 10.1 Embedded or not?

SAP Managed Tags:
SAP Business Planning and Consolidation, version for SAP NetWeaver

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (1)

Hi Lambertus,

I'm one step behind you, trying to get an input ready BEX to work with a BPC 10.1 classic cube.

Did you create the aggregation level on the BPC Multiprovider? Are you using the save std planning function from a button in the analyzer? I can see the data from the BPC cube, but I can't input/change any data, although the query is defined as planning and I select a value for each characteristic/dimension.

Thanks in advance for your feedback.

Regards,

David

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi,

I created the Aggregation level on the Real-time infoprovider directly, but you can create it on the multiprovider, so no differences there. as long as the infoprovider is real-time and switched to planning mode.

So we move away from Analyzer and now use BOA, which works much better in my opinion. But if you use Bex Analyzer, use the standard 'Save' button. So messaging really is not good in Bex, if you can't plan data, I suggest use transaction RSRT first to get a detailed error message display or add the messages using the bex toolbox to your report.

Let me know how it goes...

Hi Lambertus,

Thanks for your reply.

Are you working with a BW planning cube or a BPC cube? I'm trying to create a bex input query on the BPC multiprov that is automatically created for the cubes created by BPC (Classic version not on HANA).

My goal is to create additional topdown and planning functions with IP, to be used by the BPC users, as IP is more flexible for some complex scenarios.

I'll appreciate any further comments on experiences integrating BPC & IP.

Regards,

David

We use the scenario of Classic BPC with BIIP planning procedures and Inout Ready Queries as well. It doesn't matter whether you are working with a BPC cube or a BIIP cube, HANA or not, the principles remains the same.

What I suspect might be happening is that with the query in BEX, the BPC dimensions are listed, but once you execute the query, the Characteristic InfoProvider is added as a free characteristic, you dont see it in Bex Query Designer. Dragging the InfoProvider characteristic into the query as a row/column will make it input ready again. See the screenshot below of a Bex input ready query in RSRT.

This query is on the MultiProvider. You may pick up problems after a full optimise or if you change the dimensions of the BPC model...

Hope this helps.

Hi Lambertus,

Thanks again for your reply.

You were right, the infoprovider selection was missing, but even in RSRT, because the input query was set to use the disaggregation option. Without this option, the infoprovider is added to the query and after selecting the cube, the query is ready for input, in RSRT and in BEX Analyzer.

I'm checking why the disaggregation option causes that effect, and also why the “planning on hierarchy nodes” is also not supported (there is a message: not supported by server), because I need to be able to plan top/down.

In your previous comment, you mentioned you were using BOA, instead of BEX Analyzer, but how do you save data in BOA?

If you happen to know how to fix/add any off these functionalities, I'll be more than grateful.

I hope I can be of help for you in the future.

Thanks and regards,

David

so my experience with disaggregation, I am assuming that you are using the BEX key figure settings, are that the totals will not be input ready if there is a mix of UoM or currencies etc. any more than that I cannot think of except by actually looking at the query.

ill quickly run a test on our system to see if I can disaggregate hierarchy nodes,

Saving data is supported in BOA, you just need to activate the planning functions under options. It gives you a save button as well as some other features. At the moment I also prefer BoA over the EPM add in for embedded.

will check the hierarchies and revert.

I get to disaggregate on a hierarchy node for an input ready query, see below. Data also saves without any issues. So I have no idea why your server says not supported, one of SAPs many 'special' features I guess.

Here are our patch levels if it may help:

SAP_BASIS	740	0009
SAP_ABA	740	0009
SAP_GWFND	740	0010
SAP_UI	740	0011
PI_BASIS	740	0009
ST-PI	740	0001
BI_CONT	757	0005
BI_CONT_XT	757	0005
SAP_BW	740	0009
CPMBPC	810	0004
POASBC	100_731	0006
ST-A/PI	01R_731	0001

Let me know if you need more info

Hi,

just for clarification:

Usage of 'disaggregation':

a) If disaggregation is switched off all characteristics needed to make input-ready structure elements (cf. Query Designer) really input-ready at run time are added as free characteristics in the query. This is because - without disaggregation - a cell in an input-ready query can only be input-ready if all characteristics in the aggregation level at the cell level are uniquely determined. In other words, aggregated cells (with respect to the characteristics in the aggregation level) without 'disaggregation' cannot be input-ready.

b) If disaggregation is switched on, even aggregated cells with respect to the characteristics in the aggregation level can be input-ready. Changing a cell value triggers 'disaggregation', i.e. the system disaggregates the changed value to the level defined by the aggregation level used in the cell. Thus the 'required' characteristics in case a) (that were added as free characteristics) are not needed here because of disaggregation. Thus these characteristics will not added as free characteristics. Hierarchy nodes represent also aggregated values and are thus also disaggregated.

c) The characteristics 0INFOPROV and currencies/units (if an amount or quatity key figure is used, respectively) always have to be determined uniquely in an input-ready cell.

d) The Query Designer shows a not yet implemented feature, that is called 'Planning on Hierarchy Nodes' and would have to be set per characteristic or even better per axis. This name is a little misleading. This feature was implemented in SEM-BPS/BW-BPS and was called 'budgeting'. This is a special handling of hierarchies with postable hierarchy nodes: a postable hierarchy node always has a leaf with the same characteristic value; key figure values are stored on leaves, never on inner hierarchy nodes. 'Budgeting' means that changing the node value in fact changes the corresponding leaf (with the delta) and not the other leaves below the node. This is a very special kind of 'disaggregation' and should no be confused with disaggregation.

Warning:

InfoCubes generated in BPC standard are special BW InfoCubes, e.g. no BW time dimension or BW unit dimension is used. In addition, BPC standard treats this InfoCubes in a special way not known in BW. As a result, using BW-IP features on BPC standard generated InfoCubes might invalidate BPC standard logic. You have to know what you are doing here.

Regards,

Gregor

Hi L,

Bex input query works fine if I don't use the disaggregation options. If I use any of these options I get the following error, when I execute it in BEX Analyzer:

If I execute it with BOA, I get the following error, when it's opening the BEX query:

Unable to cast object of type 'System.NullReferenceException' to type 'bali.lang.Exception'.

Regards,

David

Hi Gregor,

Thanks for your comments and warning.

Do you know any specific situation when using BW-IP features might invalidate BPC standard logic? It's clear that you should never change a BPC cube or other BPC objects from BW, but creating aggregation levels, BEW input queries or planning functions could cause a problem in BPC logic?

I'm using the ENABLE_FIXED_CUBENAME parameter on the BPC cube, to avoid BPC to invalidate the IP logic.

I'll appreciate your comments.

Regads,

David

Hi David,

for the program error check note 2084297.

With respect to BPC limitations check note 1916315; even using BEx tools on BPC generated InfoCubes in reporting might lead to 'wrong' results, since BPC logic is not involved, cf. section

BI Integration - Reporting through BI reportings tools might have different
results as EPM Add-in

in the above note.

Changing data in BPC 'standard' generated InfoCubes via BW-IP might lead to inconsistent data with respect to BPC 'standard' in a lot of cases. Very basic concepts of BPC standard are not known in BW-IP and will thus be ignored in BW-IP, e.g.

- periodic or YTD store in InfoCubes,

- BPC dimension types, especially for account dimension and logic coming from account type EXP, INC, AST and LEQ, cf. also hierarchy aggregation

- calculated members in BPC standard are just characteristic values from BW point of view,

- and many more.

Sorry for self-referencing here, but the following link might also be helpful:

http://scn.sap.com/docs/DOC-58899

Regards,

Gregor

Ask a Question

Top Q&A Solution Author

User

Count