SAP BI Cube Zero Record Timing problem

This post is all about another problem that I faced in our production system. I had to do significant analysis/simulation to understand the problem.

When you have a configuration as below

1. Datastage job to post into BW (3.x datasource)
2. Infopackage triggered is of type – Update PSA and data target in parallel, typically a write optimized DSO
3. You use an external scheduling tool to trigger the datastage job
4. Have another BW chain to extract data from a DSO and post into a cube which is also triggered by an external scheduler

There is a possibility that your DTP load from the DSO to the cube could post empty data.

The reason why this happens is that, BW takes a lot of time to actually update the data in the WO DSO. BW responds back to datastage as soon as it recieves all the data and does not really wait for the data to get saved in the DSO.

If your BI system is slow for any reason, the external scheduler would trigger your DTP for the cube much before the data is actually saved in the DSO. This eventually results in zero records being transferred to the cube.

A solution to this problem is to only post to the PSA by datastage and have a process chain to push data to the DSO and DSO to the Cube.

 

Sap Datastage – Unable to delete variant problem

It has been a while now since I have created a post. I have slowly migrated SAP’s  BI product and have been learning it. Recently we hit a major issue with datastage working with SAP.  I had to perform extensive simulation/analysis to understand the problem and come to a solution. I would like to share the analysis with everyone (could save some precious time). . .

Explanation

Multiple calls are made by datastage to the function module Z_RFC_DS_SERVICE with different parameters. Accordingly different activities such as create variant, delete variant, load program etc. is done.

Z_RFC_DS_SERVICE is the function module invoked remotely by datastage through the RFC.

Z_RFC_DS_SERVICE invokes the function module RS_VARIANT_DELETE

This function in turn invokes the form check_v_used_in_job.

perform check_v_used_in_job using rsvar-report rsvar-variant.

This function invokes the function module BP_VARIANT_USED_IN_JOB

Depending on the response from this function module the “unable to rename/delete variant” error is thrown. If the number of jobs in TBTCP is not equal to the number of entries in TBTCO which has finished or aborted status, the error will be thrown.