Essbase 11.1.2.3 BSO to ASO Partitions with extra dims

Hello Essbase brain trust.
I have a situation where my BSO/planning cube has less dimensions than my ASO reporting cube. I have tried all of the ways mentioned in the documentation to map the extra dimension to no avail. Seems like the documentation is lacking.
Does anyone have a working situation where they could share the exported partition? Or enlightened me.
I did this using the planning mapping tool but it's very slow to refresh although it works. Even the xml from this works not helpful.
Thanks
Dave

It works fine. I tried with ASOSamp and Sample
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<EASFrameworkTransferObject>
    <Partition>
        <transparent comment="" direction="to" outline="reverse" replace="yes">
            <sourcedb application="Sample" database="Basic" password="bCw6vmd7Zyvt7ZGiTqaotQ==" server="EPM11123:1423" usernme="admin@Native Directory"/>
            <targetdb application="ASOsamp" database="Sample" password="bCw6vmd7Zyvt7ZGiTqaotQ==" server="EPM11123:1423" usernme="admin@Native Directory"/>
            <areaspec sourcealias="sourcearea1" sourcearea=""Jan","Sales","100-10","New York","Actual"" targetalias="targetarea1" targetarea=""Jan","Price Paid","Curr Year","Sale","Cash","Coupon","1 to 13 Years","Under 20,000","Displays","044862","10006""/>
            <globalmap sourcemember=""Jan"" targetmember=""Jan""/>
            <globalmap sourcemember=""Sales"" targetmember=""Price Paid""/>
            <globalmap sourcemember=""100-10"" targetmember=""Displays""/>
            <globalmap sourcemember=""New York"" targetmember=""10006""/>
            <globalmap sourcemember="Actual" targetmember="Sale"/>
            <globalmap sourcemember="" targetmember="Cash"/>
            <globalmap sourcemember="" targetmember="Coupon"/>
            <globalmap sourcemember="" targetmember=""1 to 13 Years""/>
            <globalmap sourcemember="" targetmember=""Under 20,000""/>
            <globalmap sourcemember="" targetmember=""Curr Year""/>
            <globalmap sourcemember="" targetmember="044862"/>
            <globalmap sourcemember="" targetmember=""Store Manager""/>
            <globalmap sourcemember="" targetmember=""Square Footage""/>
            <globalmap sourcemember="" targetmember=""Area Code""/>
        </transparent>
    </Partition>
</EASFrameworkTransferObject>Planning mapping tool uses a different method. It uses (creates on the fly) DATAEXPORT calc script and a load rule to load data.
Regards
Celvin
http://www.orahyplabs.com

Similar Messages

BSO to ASO Partitioning Help

Can anyone help me with a couple questions in regards to our partitioning strategy from our Block Storage planning cube to our Aggregate storage planning cube in 11.1.2? Our original approach was to use a transparent partition for planning scenario (Budget, Forecast) data from BSO source to ASO target for level-zero only. ASO would handle aggregations. Also loading Actuals data directly into ASO cube from source system. We would like to have additional dimensions not required for Planning to be stored just in the ASO database in order to minimize database size and calc times on the BSO side. Two questions:
1) We've found that the Actuals scenario data can not be queried in the ASO target (return #missing). Is this standard behavior for a transparent partitioned ASO target in 11.1.2?
2) Regardless of partition type (Replicated or Transparent) can we have a different number of dimensions in our BSO and ASO cubes? Again my understanding is no, but wanted to confirm.
Thanks in advance for any help that can be provided.

data that is loaded directly to an ASO cube that is the target of a transparent partition is not visible^^^Isn't this the key? I read that the natively loaded data is overwritten (not really, more like overpartitioned) by the partition definition and the partition takes precedence.
So the answer then would be to not have that conflict.
Unless Tom was talking about something else/I'm misunderstanding.
Regards,
Cameron Lackpour
Edited by: CL on Mar 10, 2011 8:13 AM
Whoops, missed this part:
This is the case even when the intersection of the data is outside the area defined by the partition.I still wonder if there's an overwrite of intersections going on.

Building BSO using ASO Rules file

Hi All,
We are building a new application where in we want to have both ASO and BSO. Eventually we wanted to do partition between these two cubes.
We already have a fully functional ASO with data loaded into it. This ASO also has bunch of rules files using which the ASO cube was built.
We need to build a new BSO and it should have same outline as ASO and in order to achieve this as used the same rules file that are in ASO. I already built the BSO usinng ASO rules files
My issue is with the dimension which are deifned as Multiplw Heirarchy and I would appreciate if some one can help me how do i define them in BSO. Also if some one canhelp me understand what are additional changes that needs to be taken care when I am building BSO using ASO rules files
I am trying to apply a caluclation which is in ASO and I am getting following error -- Error(1200337) - Error compiling formula for [Feb YTD] (line 1): [)] without [(]. As part of my research i found that error code is very generic. I checked the caluclation for missing ) or ( but everything looks good
Any help is greatly appreciated
Thanks
Satish

Your ASO formulas will not work in BSO cube. ASO uses MDX formulas and BSO uses Essbase calc script language. There is a guide in the technical reference that helps convert from one to the other.
As far as multiple hierarchies, BSO does not have this concept. You should be able to load the hierarchies as is with perhaps a few changes to the load rule to address how to handle shared members.
You will not have a direct one to one from BSO to ASO. They are a different architecture and as such have variances that are not 1 to 1 compatible.

Drill through Funtionality Across different cubes (ASO to BSO to ASO)

Hi All,
I have one complicated problem. I have one essbase ASO cube where the We load the account data on most granular level (Generation 7) and then it rolls up the data in generation 5 and that generation 5 data is pushed to another cube ( BSO ) for which generation 5 is in BSO cube which in turn push the data in ASO1 at generation 5.
Now user want to log into ASO1 to see the data and want that if user need to see more granular level data (Generation 7), user can be able to see without getting logged out or loggin into another cube.
Any solution or suggestion how it can achived.
Cheers
AB

Hi Celvin,
Yes you are right. The data is ASO rolls ups to become Level0 in ASO1. but there is mapping which needs to be done between ASO and ASO1 which is kinda i am worry about.
Eg Profit centre in ASO is 11000 and 12000 mapped to ASO1 at PC2078 (both level zero).
Account in ASO(Level zero) rolls to Gen5 which mappes to Level zero in ASO1.
i was thinking of making alternate hierarchy in ASO instead of using mapping and integration tool. (Since we are messing up ASO cube).
in account and
in this way the Drill will be good. and no data mapping required between ASO to BSO and ASO to ASO1.
Please let me know your thoughts/input/suggestions on this solution.
Cheers
AB

Running calculations BSO versus ASO

which architecture is better to use if you have to run large calculations? (Essbase Version 11)

Allocations were introduced in ASO in 11.1.2. They are done in memory and create data slices. In theory, this could be quicker than an allocation done in BSO especially if you have to agg the cube to get what is being allocated. Plus you are not bringing in whole blocks just cells. I cant give you an honost answer because I've not tried large allocations in ASO yet. I will say if they are complicated, it will take a lot more work to set them up in ASO than in BSO. Also, if you actually use the allocation function in BSO it can be quite slow. You also get the block creation issue at time.
I guess the onl;y thing I can advise is to set up tests in both ASO and BSO and see which performs better.

Partitioning BSO to ASO to get around FDM limitations

FDM only currently loads to BSO Essbase cubes. However, one of our FDM-loaded BSO cube is far better suited to being ASO, not least because it has:
- Twelve dimensions.
- A huge "customer" hierarchy (over 40,000 members), which is purely aggregating.
- Most of the other dimensions are also purely aggregating (although there are a few complex calcs on specific members).
The sheer size of the BSO cube outline and the data being loaded results in prohibitive calculation times, so we are looking for a workaround.
Thoughts at present are to create an ASO cube (effectively copying and converting the current outline to ASO using the Wizard), create a replicated partition to transfer data from the BSO to ASO cube (mostly from level-0 members) and to use the BSO cube purely as a data-entry point. Users would then report from the ASO cube, which could be refreshed from the BSO cube when required.
This would then mean that upper-level members and any calculations in the BSO cube are pretty much redundant.
Does anyone agree with, or have any reservations on the above idea? Is there potentially a better method here? Also, could anyone please hazard a guess on how long the replicated partition refresh might take?

Is the BSO cube only loaded from FDM / other loads? Or are users entering data? Is it an Essbase or Planning app?
While it is true that there isn't a FDM adapter to load into ASO, you do not have to go from a BSO cube to the ASO cube for the data loads. Just have FDM export to a flat file and load that into ASO using maxl / batch script.
Deanna Sunde
Sr. Director
The Hackett Group

ASO Cube with BSO Partition as a Target

Hi,
Can someone please explain me the following because after reading different blogs as well as some other Essbase documents I am not able to understand,
What is the actual use of having a BSO Transparent partition (target) of an ASO cube (source)?
How exactly does the Write-Back functionality works if I have a BSO Transparent partition (target) of an ASO cube (source)?
And lastly, in what business scenario one would implement a BSO Transparent partition (target) of an ASO cube (source)?
Your help is much appreciated.
thanks,
fikes

I have a situation where I have a BSO (target) on top of an ASO (source). This was to try and resolve the dynamic time series (where time and periods are in different dimensions). The DTS works almost great in the BSO partition.
The other problem (or why we wanted to go to ASO) was that BSO cubes do not handle attributes across partitions (we have quarterly data in transparent partitions) to the target cube. -- but we do have dynamic time series.
What I'm facing now it that the attributes work in the BSO (target) except when using a dynamic time series.
The attributes are defined in both the BSO and ASO cubes.
Any suggestions on how to handle attributes AND dynamic time series ?

Sign changing to - when converted from BSO to ASO

HI Guys ,
when I change ab BSO app to an ASO the default + operator is changing to - ,how do I deal with this problem .
Thanks

Hi,
We experienced the same problem with Essbase 9.3.1.2.
The workaround we used was to use the outline extractor on both the BSO and ASO outlines and then compare the text files to catch the differences and manually fix them. It took some time but we got the outlines in sync.
Outline extractor is a freeware from Applied OLAP http://www.appliedolap.com/default.asp?ID=22
Edited by: Calle on Dec 23, 2008 1:27 PM

BSO to ASO Formula Conversion - Help Needed

ASO is not my forte...I am trying to get a simple formula to work in ASO cube as part of BSO->ASO conversion.
If it is level 0 entity, the formula is (Last Shipped (PU) * Part Volume)...works fine.
If its upper level, it should just sum the values of its children. The BSO equivalent that we typically use is @SUM(@CHILDREN(@CURRMBR("Entity"))).
I attempted the same in the ASO MDX script as shown below, it is not yielding me the correct result....any thoughts why this is not working?
Thanks in advance.
Nima
Member Formula*
CASE WHEN ISLEVEL(Entity.CurrentMember, 0) THEN+
Last Shipped (PU) x Part Volume+
ELSE+
SUM(Children(Entity.CurrentMember))+
END+
Edited by: Nima.V on Nov 12, 2008 7:12 PM

Have you tried specifying which measure you want it to sum?
e.g.
CASE WHEN ISLEVEL(Entity.CurrentMember, 0) THEN
Last Shipped (PU) x Part Volume
ELSE
SUM(Children(Entity.CurrentMember), [Measure].[Part Volume])
END
also I'm not sure whether the SUM is correct. This might work as it definately specifies the tuples:
SUM({Products.CurrentMember.children},[Measures].[Part Volume])
hope it helps,
Gee

Repl. Partioning BSO to ASO: increase of size of .dat file in temp-folder

Hello,
we are shifting data from a BSO Cube to an ASO cube via replicated partitioning. The partitioning takes about 50 minutes to execute.
Size of .dat in metadata-folder: 8 mb
Size of .dat in default-folder: 150 mb
Size of .dat in temp-folder: 38 gb
Does anyone have an explanation for the enormous size of the .dat file in temp-folder?
Many thanks in advance!
Michael

I am doing the same BSO to ASO. My ess00001.dat in default is 1.9GB, in metadata it is 8.2MB, the OTL file in <db> is 18MB and the outline has about 10,000 members (rough guess). Our partition replication script looks like this:
login <user> identified by <password> on <server>;
spool on to <logfile>;
refresh replicated partition <srcBSO_App>.<srcBSO_DB> to <tgtASO_App>.<tgtASO_db> at <server> updated data;
Exit;
I have a second process running in a task scheduler that is continuously updating the aggregates in the ASO cube. Perhaps that is cleaning out my temp .dat. The MaxL command it calls is:
execute aggregate selection on database <tgtASO_App>.<tgtASO_db> based on query_data;
Please check out the post I put on the other thread about how we run MaxL from a calc script and other thoughts on "round tripping" Planning-ASO-Planning. Another trick: Retrieve speed is dramatically improved by disabling and working around the @XREFs.

Cannot see data in BSO from transparent ASO partition

I have 2 cubes: BSO (target) and ASO (source).
BSO should show data from ASO corresponding element "Fact" from dimension "Scenario".
I can see the data using ASO directly, but I cannot see data viewing it from BSO using transparent partition...

Hi,
When you have the data in the ASO( i.e source cube) ,it should reflect in the BSO ( i.e destination) . I am sure there is problem with the transparent partition ,you had created .Validate and share more info of error ( if you encounter during partition creatino) , that should be resourceful
Sandeep Reddy Enti
HCC

ASO Cube with attributes very slow in retrieval

Hi,
I have a ASO Cube with 5 base dimensions and 8-9 attributes on the entity dimension. I have only 5-6 measures, which do the averages and counts based on the 40 day period. Howere, the data is loaded at the 15 minute increment
Entity
Date - (date-time, lowest level being date)
TIme - ( 15 minute time for the full 24 hour period, has a attribute assocuated with oit)
LocationType
Measures.
The sample formula is
IIF(Islevel([Locations].CurrentMember,0), Avg(CrossJoin({[Measure].[Sale]},{[DateDim].CurrentMember.lag(40):[DateDim].CurrentMember})),Missing)
Is there a way, i can have this calculated as a part of the script? DO you suggest i create a BSO, to do these calculations and pass on the result.
In OBIEE, the report is to display the followung based on the date input.
Entity Gen7, Entity Gen 6..... Entity Gen 2, Attr1, Attr2, Attr3, Attr4, Attr5, Attr6, Attr7, Measures

2 things I would look at
1st - I don't know how much performance you would get out of this, but I'm not clear why you are using a crossjoin in your MDX, it seems unnecessary and may cause more overhead. The following should work, you could also try using IsLeaf instead and see if that is any faster
IIF(Isleaf([Locations].CurrentMember),
Avg({[DateDim].CurrentMember.lag(40):[DateDim].CurrentMember},
[Measure].[Sale], INCLUDEEMPTY)
2nd - your problem mostly revolves around the fact that you are running a 40 member sum/avg for every member you are querying. It also sounds like the average is at the Day level, which is not level 0. So for all forty days, ASO also has to calc the results of each of those days. Remember that aggregations only get you so far, you should really think of everything in ASO as dynamic and that is why you can see what you have set up is not going to work that well, it is too calc intensive.
I don't know how practical this is, but to get this to work fast you would probably need to break out the 15 minute increments below the day level to another dimension so the day level becomes a stored level zero member. The 15 minute increment dimension should also be stored. If at all possible you would want to have an alternate stored hierarchy with the 40 days you want to base the average on. Enable alternate hierarchies in your aggregations, then change your MDX calc to be based on the parent of the 40 day hierarchy divided by 40. That would be fast.
I suppose you could opt to not break out the 15 minute increments and just have the shared hierarchy made up of the 15 minute increments that are below the 40 days. That would still give you a good stored subtotal that with some query hints you could get optimized.

Data issues in Migrating Essbase(BSO and ASO apps)from Server 7 to Server 9

I was able to copy application one is BSO another one is Aso
Both APPS ARE CLEARED IN BATCH FILE.
Budget data excel and flat files is loaded to BSO, calcualation for current year data is done the some for budget files loaded and then calcs are executed.
Then the data for curent year is extracted from bso
then this data all such previus yr and prev exports are loaded to ASO
Then agg is enabled in ASo
All this is done using a batch which call s 10 maxl and which in turn load data and run staggered calcs.
But the issues is Data is not matching after perform these steps in Server 9 at many intersections
Every artifact/var are copied, batch logs are success but still data does not match vs Server 7.
I believe some extra data is generated by Creteblockoneq, createnonmissblock and other calc functions.
I tried copy/Migrate/Manual copy but nothing worked.
Data analysis shows atleast some extra recored are generated after calc in export file
Help needed?

Hi
Thanks for the reply.
There are no rejects.
I am exporting level 0 data and loaading it to ASO.
And, the issue includes both points-
1)Extra data points coming in
2)Some intersections data is missing
It is like 80% data is matching
It seems some essbase Calcs calculation way is modified although not sure.

Problem with BSO - ASO partitions (Essbase 9.3.1)

Hi there,
Is it possible to create a BSO partition on top of four ASO cubes when using member set functions in the partition definition (e.g. @GENMBRS or @LEVMBRS)?
I have tried that but always get an “overlapping partitions” error, although the partition members are not defined overlapped. The cellcount does match.
Appreciate any hints.
Thanks in advance.

Obviously this won't resolve your entire problem, but just to answer the first question you can definitely use e.g. @GENMBRS successfully in the partition definitions for a single BSO cube over multiple ASO cubes in 9.3.1.

Best way to keep a BSO and ASO in sync?

Hi all,
I have been trying to find the best way to keep in sync the same outline. Source is a planning cube, while the "target" is an ASO one for reporting purposes.
My approach has been to use ODI in order to load the metadata in the Planning app, but after some research I figured out I cannot use ODI to build the ASO outline due to license restricitions (It isn't "free" for this).
As I already have created the interfaces to load the metadata in the planning app, I would like to keep this and then create a method in order use the BSO outline to get the ASO one
I know there is a wizard to convert the BSO outline to an ASO one, but I wonder if there is a way to execute and automate this process by using a command line script? and if yes, where I can find information about how to set this operation ( with all the automatic outline changes we found in the wizard)
I appreciate you comments and I'm open to receive you suggestions about any method to get both outlines in sync.
Thanks in advance
Edited by: Motorstock on Oct 4, 2011 8:28 AM

Depending on version you can also extract planning dimensions using the outline load utility - http://john-goodwin.blogspot.com/2011/04/planning-11121-exporting-metadata.html
Though If you are using ODI to load planning metadata from a source you could create an essbase load rule to load from the same source to the ASO database.
I would have thought if you are not licensed to use ODI with ASO then you are not licensed to use ASO, it used to be that if you only had a license for planning then you couldn't use ASO.
Cheers
John
http://john-goodwin.blogspot.com/

Essbase 11.1.2.3 BSO to ASO Partitions with extra dims

Similar Messages

Maybe you are looking for