Transactional InfoCubes differ from Basic InfoCubes in their ability to support parallel write accesses. Basic InfoCubes are technically optimized for read accesses to the detriment of write accesses.

The transactional InfoCube was developed to meet the demands of SAP Strategic Enterprise Management (SEM).

Transactional InfoCubes are used only in conjunction with SEM. The data from this kind of InfoCube is accessed transactionally, meaning data is written to the InfoCube (possibly by several users at the same time) and reread as soon as possible. Basic InfoCubes are not suitable for this. You should use Basic InfoCubes for read-only access (for example, when reading reference data).

Transactional InfoCubes can be filled with data using two different methods: Loading planned data via SEM or via BW Staging, where no planned data can be loaded. You have the option to convert a transactional Info Cube Select Convert Transactional InfoCube using the context menu in your transactional InfoCube in the InfoProvider tree. By default, the Transactional Cube Can Be Planned; Loading of Data Not Permitted is selected. The system then fills the cube using the SEM functions. Switch this setting to Transactional Cube Can Be Loaded With Data; Planning Not Permitted, if you want to fill the cube with data via BW Staging.

Using the SEM process, data is written to a transactional InfoCube data request. As soon as the number of records in a data request exceeds a threshold value, the request is closed and a rollup is carried out for this request in defined aggregates (asynchronously). You can still rollup and define aggregates, collapse, and so on, as before.

According to the database on which they are based, transactional InfoCubes differ from Basic InfoCubes in the way they are indexed and partitioned. For an Oracle DBMS this means, for example, no Bitmap indices for the fact table and no partitioning (initiated by BW) of the fact table according to the package dimensions.

Reduced read-only performance is accepted as a drawback of transactional InfoCubes, in the face of the parallel (transactional) writing option and improved write performance.

Select the Transactional indicator when creating a new (Basis) InfoCube in the Administrator Workbench.

Where the Basic InfoCube already contains transaction data, which you no longer need (such as test data from the system’s implementation phase), proceed as follows:

1. In the InfoCube maintenance in the Administrator Workbench choose, from the main menu, InfoCube ® Delete Data Content. The transaction data is deleted and the InfoCube is set to "inactive".
2. Continue with the same procedure as with Creating a Transactional InfoCube.

If the Basic InfoCube already contains transaction data from the production operation you still need, proceed as follows:

Execute the SAP_CONVERT_TO_TRANSACTIONAL ABAP report under the name of the corresponding InfoCube. You should schedule this report as a background job for InfoCubes with more than 10,000 data records. This is to avoid a potentially long run-time.

The following typical scenarios demonstrate the connection between BW and SEM and the use of transactional InfoCubes:

Actual data (read-only access) and planned data (read-only and write access) have to be held in different InfoCubes. Therefore, use a Basic InfoCube for actual data and a transactional InfoCube for planned data. Data integration is achieved using an SEM multi-planning area, which contains the areas that are assigned to the InfoCubes. Access to the two different InfoCubes is controlled here by the characteristic "Planning area", which is added automatically.

In this scenario, the planned and actual data have to be together in one InfoCube. This is the case, for example, with special rolling forecast variants. Here you have to use a transactional InfoCube, since both read-only and write accesses take place. You can no longer load data directly that has already arrived in the InfoCube by means of an upload or import source. To be able to load data nevertheless, you have to make a copy of the transactional InfoCube that is identified as a Basic InfoCube and not as transactional. Data is loaded as usual here and subsequently updated to the transactional InfoCube.