Forum Discussion
Solved
Dynamic Cube Data Load from BiBlend Table
I am currently working on a Dynamic Cube with Data Binding Type (Share Data using Workspace Assembly). I was able to load Local currency data from BiBlend table and verify data using Cube ...
Yes, it is possible with the "With Calculations" options.
Requirements to get the standard basic translation to work:
- FX rates (duh)
- In your ReadDynamicDataUnitContentTimestamp method, make sure you are NOT returning DateTime.Now - otherwise dataunits never get a chance to actually translate or consolidate
- In your ReadDynamicDataUnitData, make sure you check which Consolidation (currency) member is requested, returning only base data for local (e.g. If api.Cons.IsLocalCurrencyForEntity() And Not api.Entity.HasChildren() Then ... - same thing as in consolidation formulas).
- for all other consolidation members, return an empty dataunit (e.g. Return New DynamicDataUnitData(api, DateTime.Now, 10) )
This configuration will provide data for Local, and then you can launch a Translate in the usual way.
Otherwise, in your code you can check for the Consolidation member in api.Pov, and return translated data yourself (i.e. with custom code doing the calculation). As mentioned by rhankey , this allows you to provide translated data even without the "with calculations" option.
Henning
OneStream Employee
OneStream EmployeeHi, with the setting you used, you can "share" data dynamically. So you could pull the translated data from the BIBlend table and display it on the parent currency member in the consolidation dimension. Consolidated data could be displayed using dynamic aggregations in your workspace assembly code. But that dynamically aggregated data would not (automatically) take into account the consolidation rules applied in your cube solution.
Take a look at the different data binding types here:
https://documentation.onestream.com/1375907/Content/Design%20and%20Reference/Financial%20Model%20Guides/Dynamic-Cube-Services/Dynamic-Cube-Data-Binding-Types.html#Share_Data_Using_Workspace_Assembly_with_Calculations
I think what you need is to use "Copy Input Data From Workspace Assembly". So you copy the data from BIBlend to C#Local and then consolidate the dynamic cube.
Please note that this is just how I understand it at the moment. I did not test what you want to do here yet, but I am interested in your experience, so please share if you get it to work like this.
- JackLacava
I believe they can also use the "with Calculations" option.
I was not able to translate data in Dynamic Cube using Data Binding Type - Share & Edit Data Using Workspace Assembly with Calculations. I have tried Translation Algorithm options - Standard using business rules for FX, Custom. Cube View shows same data values in all Currencies (Local, Translated, Elimination, USD and other Consolidation members). Can you provide some insight if translation is possible in Dynamic Cube?
The Data Binding Types that include "With Calculations" do appear to enable the normal cube logic, and optionally allow you to invoke ServiceFactory calculations. But, you had better have data timeout stamps in your DynamicDataService set rather high, as set at default settings, it appears to initiate an awful lot of repeated ReadDynamicDataUnitData() calls for the same DataUnits while performing the cube consolidation.
A little further expansion from the original question... Your DynamicDataService can supply C#Local and/or C#Trans data for base and/or parent entities. Consolidation logic does not kick-in unless you use have chosen a "With Calculations" option.
Not what you have asked, but somewhat related. One thing I've noticed is that Dynamic members do not appear to aggregate to the parent member when using Vertical Extensibility. I have a number of nested extended Dynamic Dimensions to capture greater detail at base level entities, which is to be stripped off at parent entities. OS is not auto-aggregating the detailed dynamic members to the summary dynamic member when aggregating the data to the parent summary cube. The docs sort of allude to this, so this might be expected behavior. Dynamic member formulas will resolve the issue in this particular instance, but that isn't always a viable option.
