Data Transformation and Storage

Feature testing of the DataModel involves three major aspects of data transformation and storage:

This does not include other aspects of the BW system like security, process chains, broadcasting, etc.

Initially, it would take a fair amount of effort to plan and create feature tests for the data modelling involved in data transformation and data storage. This would involve several iterations to cover the basic range of features involved. This implies that a decent amount of learning and research would need to be done by the developer when working with unfamiliar features.

“the process of identifying and creating Feature Tests
is a great way to learn data modeling in SAP BW”

To help put it into perspective; the high level view of this would create a list and then the matrix of the relationships between the list items:

There are additional features involved but now you can see how the planning and creation of feature tests is an ongoing and evolving process. This is great news as you would be able to focus on features in a specific order according to what you know and actually use within the BW system. For Example: Are you using inter-company elimination hierarchies for group currency reporting? Are you using transitive attributes? Are you using exception aggregated, high precision, unit of measure compounded key figure as an attribute on a time dependant, compounded, reference characteristic? Really?

Knowing the above is a growing feature list and relationship matrix you do not have to do it all at once, like a big-bang go-live. You can plan the next deliverable and get to work in an isolated approach knowing that it will contribute to the larger solution without interfering. This creates a great learning environment, as there are practical objectives that can build upon the prior feature tests.

Creating the feature tests could begin with this sequence for InfoObjects:

Now move on to include DataStores and expand the number of individual feature tests by the number of InfoObject features. This will start off simple and then grow rapidly. Eventually you will get to a point where it becomes obvious that certain combinations are statistically un-likely to be used by most DataModels. These feature tests you can identify and prioritise to the bottom of the list to be created. For Example: Min/Max exception aggregated key figures in a DataStore Change Log table where the sign of the key figures in the Before-Image and After-Image records have significant importance.

By now it is clear that the mere effort to identify the feature matrix is quite a large task in it’s own right. It would be good if a tool could be developed that would track the main objects, their features and the valid relationships. This feature matrix tool can then be used as the framework to automate the comparison of a BW system to features that are actually used. The results could be stored as time-dependant snap shots and provide system owners with a long-term understanding of the growing complexity of their environment.

The user interface for transaction RSRV has quite a few good properties that make it ideal for the feature tests to be added to. The current RSRV options provide a very good way to analyse object instances and their data quality, including a ‘Correct’ button if issues can be fixed. The feature tests would be an additional complement to test the standard code that is the behaviour of these standard objects.

What SAP BW Feature Testing would I prioritise to the top of the list? Why?

Further Reading: SAP Demo Content for Features – OLAP and Integrated Planning