Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Features of  Advanced Datastore Objects

This blog post describes the features of ADSO’s and how to use them.

First let’s have a look on the pre-requisites for using ADSO’s. The system has to be a BW 7.40 SP8 at a minimum.

Then still a bunch of Notes have to be implemented to make it ready for the new functions.

It is very advisable to go at least on 7.40 with SP9 or SP10, just to have an easier and more comfortable start.

What’s really new is the modeling User Interface; for the first time in BW History Info Provider have to be modeled in an Eclipse Environment, there is no possibility to use the ‚classical SAP GUI‘ to create Advanced DSO’s.

So normally, if you work with new technology you should read some documentation to get a clue of how to do the implementation.

However, at this point of the project we already were stuck, unfortunately documents dealing with ADSO’s are rarely available.

Therefore, we identified how it works by ourselves.

Following we like to give a short overview of the most important (just from our point of view!) points to take into account.

When creating the Object you have to decide about the properties the Info Provider shall have.

Like, should it have a Changelog? Shall data be activated? Should it have the same behavior like the well-known Info Cube?

The second step to take is to define the structure of the Object. Which Info Objects respectively fields will be the key or data part?

If you have no key defined, the so called ‚REQUEST TSN‘ or, if defined in the appropriate tab strip, the Partition will be representing the key of the object.

If these steps are finished you can start to care about the ETL Process, with ADSO’s you can use normal transformations and DTP’s we did not encounter any problems here.

Caution: technical names of ADSO tables are different that the one of Classic DSO’s

All tables are created when creating the ADSO, regardless if they are used or not (e.g changelog)

Then naming convention follows this pattern

/BIC/A…….1 = New data

/BIC/A…….2 = Active data

/BIC/A…….3 = Changelog

/BIC/A.......6 = View for extraction

/BIC/A.......7 = View for reporting



One additional topic to mention is about using Navigational attributes: Up to now the navigational attributes had to be flagged in the Infoprovider to be usable in die Multiprovider on top.

With ADSO's you can't select/flag Navigational attributes! It is not necessary or even possible anymore, from now on the navigational attributes have to be selected/flagged only in Composite Provider!

Negative side-effect: you are lost if you want to use Navigational attributes for ETL purposes -> as far as i know there will be a possibility in future-releases.

We cannot see any restriction in transformation part (e.g. coding).

The transformations are modeled within the SAP GUI environment.

Next step is to include the model in regular data loads, so usually process chains are the best option.

For activating data the already existing process type can be used.

One thing missing at the moment is the possibility to delete the Changelog via process type. But according to SAP this functionality is to come in future.

Other functions that will be provided in future?

  • - Planning functionality
  • - Semantic Partitioned objects

SUMMARY

Our experience with Advanced DSO’s is good; we did not encounter severe problems. Everything worked after we gain the knowledge how to use it.

5 Comments
Labels in this area