In the course of configuring your SAP BW, you might come across a situation where you'll have to create your own infoobject instead of using the standard business content. So, how do you that? First, as usual go to RSA1. Then choose infoobject, and expand to the relevant infoarea.
If you want to create a characteristic, go to the Characteristic Catalog and right-click:
Same goes to key figure, go to the Key Figure Catalog and right click on it and create InfoObjects. You'll get to the next screen:
If you want to create the infoobject based on template, fill the template field, otherwise leave it empty. If you fill the reference field, the infoobject you create will be sort of like a "C pointer", or reference to the existing Infoobject. The difference is just the name.
In the next screen, you'll be able to configure the InfoObjects. You can create master data, text, hierarchy, attributes, unit, time dependent etc etc, to suit your needs. And that's all folks.
Wednesday, January 25, 2006
0
Monday, January 16, 2006
4
How to create hierarchy in SAP BW
Before you can create a hierarchy for an infoobject, say cost center, you must first ensure that the infoobject supports hierarchy. So in the infoobject change screen, choose the hierarchy tab and select "with hierarchies":
Save/Activate etc usual stuff. Now, go back to the infobject catalog directory, right click on the infoobject and choose create hierarchy:
And walla. You'll get to the hierachy screen, and can add nodes and such. But to make things much easier, I recommend using flat files upload to load your hierachy from excel. Which I will cover in a much later post.
Save/Activate etc usual stuff. Now, go back to the infobject catalog directory, right click on the infoobject and choose create hierarchy:
And walla. You'll get to the hierachy screen, and can add nodes and such. But to make things much easier, I recommend using flat files upload to load your hierachy from excel. Which I will cover in a much later post.
Labels:
modelling
Monday, January 09, 2006
0
Dataflow in SAP BW
Sometimes, in your cause of creating "stuff" in SAP BW, you'll get lost in a puddle of Infocubes, ODS, Infoobject, Infosource blah blah blah. So how do you find yourself in this sea of confusion?
The answer is dataflow. With dataflow, you can see exactly how does the data comes from the source system up to the data target. You can do this by right clicking on the data target and choose data flow:
and you'll get something like this:
Which is quite nifty eh?
The answer is dataflow. With dataflow, you can see exactly how does the data comes from the source system up to the data target. You can do this by right clicking on the data target and choose data flow:
and you'll get something like this:
Which is quite nifty eh?
Tuesday, January 03, 2006
10
SAP BW Communication Structure and Transfer Structure
When I first started dabbling with SAP BW, one of the questions that boggles my mind is "What's the difference between a Communication Structure (short: Comm Structure) and Transfer Structure?".
Well, transfer structure is like the data template of the source system. What it means is that, this transfer structure is exactly like the fields of the originating data. So, if you have a flat files with the fields: Cost Center, Business Area, Sales Amount, the transfer would be exactly like that. Also, in the transfer structure, you can have some conversion routine to convert for example, the date format of the originating data. Things like that.
But what about the communication structure? Why do we need it? Well, the answer to that my friend, is that, from the transfer structure, using a certain "transfer rules", we map the fields in the transfer structure to the communication structure. This communication structure is data-source independent, and this is what the "infocube" or the data targets would see. Not the transfer structure. Why is this good? Say, when extracting from legacy system, you still don't have in mind which fields you want to transfer and all. So, what you did is you transfer everything, which means that your transfer structure would be quite humongous. But, for now, you knew, you only need a few fields for reporting purposes.
So, in the communication structure, you will only select the "infoobjects" that you need, not all the fields in the transfer structure. In a way it acts as a filter for the transfer structure.
That, ladies and gentleman, is why you have a transfer structure and a communication structure.
Well, transfer structure is like the data template of the source system. What it means is that, this transfer structure is exactly like the fields of the originating data. So, if you have a flat files with the fields: Cost Center, Business Area, Sales Amount, the transfer would be exactly like that. Also, in the transfer structure, you can have some conversion routine to convert for example, the date format of the originating data. Things like that.
But what about the communication structure? Why do we need it? Well, the answer to that my friend, is that, from the transfer structure, using a certain "transfer rules", we map the fields in the transfer structure to the communication structure. This communication structure is data-source independent, and this is what the "infocube" or the data targets would see. Not the transfer structure. Why is this good? Say, when extracting from legacy system, you still don't have in mind which fields you want to transfer and all. So, what you did is you transfer everything, which means that your transfer structure would be quite humongous. But, for now, you knew, you only need a few fields for reporting purposes.
So, in the communication structure, you will only select the "infoobjects" that you need, not all the fields in the transfer structure. In a way it acts as a filter for the transfer structure.
That, ladies and gentleman, is why you have a transfer structure and a communication structure.
Labels:
modelling