So, I may or may not have called the Essbase DBAG drunk yesterday out of frustration. But I had a good reason! I was trying to figure out how to map partitions between cubes with different dimensionality. I went to my favorite Essbase book eva – the Essbase DBAG – but all they had was this blip:
That’s it. No screenshots. No demo love. Nada.
Somehow, from this we are supposed to be able to figure out how to map the members/dimensions. Maybe I’m just dense, but I couldn’t figure it out from the DBAG. So I asked my trusty friend, Google. Nada. Nothing to help me out worldwide. Thanks for nothing, Google.
But this woman is stubborn. This woman is tenacious. This woman ROARS. And this woman figured it out.
So either I haven’t done this in a long time or I have never done this type of partitioning. I’m not sure. However, the issue came up about creating a partition where there is an ASO cube atop a BSO cube, but the dimensionality is different. Oh, and in one of the like dimensions, the ASO cube has the level 1 members of the BSO cube. Confused yet? Let me try to explain.
As you can see, 2 dimensions from the BSO make 1 dimension in the ASO cube and we have added a View dimension to the ASO cube. Additionally, in DimB, we are only taking the level one members from BSO. We are using a transparent partition, so the questions are these:
- How do you create mappings in EAS for the transparent partition between the two cubes?
- What is the MaxL used to create these partition mappings?
- How can do error trapping in my automation of these partition mappings? (Come on! Did you really think you wouldn’t get some kind of automation help from me in this blog???)
Creating Mappings in EAS for the Partition
1. Choose the type of partition you would like. Our example will show Transparent.
2. Select the source (holding the data) and target (where you want to see the data) databases. Choose the correct application and database. Login with the appropriate level of ID.
3. For the dimensions that are different, choose the intersection in the source and target where the data will be held. Notice there is *nothing* here for the dimension that is the same, but where data is held at different levels. You won’t do a thing with that!
4. Map the values to where they will be held. …Recall that there is no direct mapping between the two cubes! Therefore, we need to create them. Because there is no equivalent, we need to map them to “void”. It is important to note that you do NOT want to type “(void)”. Just let the system enter the values in…it will work that way.
5. When you go to validate, you may see a warning about cell count mismatches. This is okay for what we are trying to do. However, if you are using a replicated partition these counts would need to be equal.
6. Save this partition and you are ready to go!
MaxL to Create Partitions and the Mappings
Using January of FY14 as an example, you can create the MaxL in one of two ways:
- Manually typing it out
- Having the MaxL editor in EAS write it for you then you save it off
So, the actual MaxL is the following:
You can customize the source area name (sourcearea1 above) and the target area (targetarea1 above).
You can also have EAS create this for you by going into the MaxL editor and start typing “create transparent partition” and at some point during that command type, the same partition screens you saw earlier in this post will show. Once you hit Save, the MaxL will fill in for you. 🙂
Error Trapping for the Partition Mappings Creation
In the batch file I have created to run this MaxL, the following is shown to the admin regarding error level 102:
Note: for more info on error trapping for Essbase in MaxL, see my blog post here.
Voila. Now you create your partitions and mappings in EAS & MaxL.
PS…If you are TRULY a geek…
I had to make NUMEROUS iterations of these types of partition mappings. Since I’m resourceful, I created the first XML file (for Jan-FY14) then modified it for each month needing the mapping. As you can see, in the XML file, it is quite easy.