I have seen a whitepaper from SAP that suggests the virtual provider generated when 'Use as a source of data for External Applications' is checked has a technical name that "may change in the target system" unless parameter ENABLE_FIXED_CUBENAME is switched on (which has it's own problems with changing and transporting models). The white paper can be found via this link -
However when we generated a virtual provider in our system, and then changed the model several times, we found the virtual provider technical name didn't change (as we had hoped). As I am working in a demo environment and don't have a BPC 10 that has been transported to a subsequent environment (Test/Prod), can we have your experience in transporting and changing models where a virtual provider has been generated and the effect on the technical name. As you would have guessed we are hoping to use the virtual provider to transfer data out of the BPC cube.
Thanks for your answer. My question is specifically around the virtual provider which can be generated (optional). If you have one it would be the name of the BPC transactional InfoCube with a '_B' suffix i.e. if your cube was called 'Planning', the virtual provider would be 'Planning_B'. This is the object that in BPC 7.5 did not change when transported, but in BPC 10 I need some confirmation of the behavior.
Virtual provide could not be transported with the model via BPC transport methodology.
It has to be generated on every system via the UI by clicking "Use as Source of Data"
Regarding the technical name of virtual provide, it should refer to the techname of the corresponding infoprovide/model/cube and replace "I" with "B". So ensure techname consistency against cube within the landscape is critical by enabling ENABLE_FIXED_CUBENAME on all systems.
That's bad news the setting can't be transported. We would love to use ENABLE_FIXED_CUBENAME but the guidance I get from our BPC functional consultants is that it's considered too difficult to back up the data before changing the model (required in development, and also in target systems before transporting) and restoring afterwards. Have you been using this setting without issue?
Note 1689814 explain parameter ENABLE_FIXED_CUBENAME in details that it will prevent cube from techname being changed on DEV. Since techname of multiprovider and virtualprovider are based on the techname of mode/cube when they are generated, so such technames will also keep consistant, right?
The important thing is to set this parameter to all DEV, QAS, PRD. and pay attention to whether the transport request contains transport the value of this parameter.
Virtual provider setting, as mentioned by Hengye, is not transportable
Transient query also generated with the virtual provider cannot be used in an APD to transfer data from the planning cubes (also not available in for BOBJ Web reporting, but is available for dashboards and BEx)
ENABLE_FIXED_CUBENAME would be the way to go, however changes to the model cannot be made with data loaded, which creates a requirement to unload and reload data for enhancements (including in subsequent systems in the landscape when transporting)
An alternative requiring more work and maintenance is to create a custom virtual provider that finds the technical name for the model from standard tables and reads from the BPC cube using a standard SAP function
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.