""

Implementación de SAP Rapid Marts Xi 3.2: lecciones aprendidas

I would like to share with you two lessons learned about the implementation of SAP Rapid Marts XI 3.2, version for SAP Solutions. In our particular case the customer didn´t allow us make any modification to the out-of-the-box solution, and this must be taken into account when reading the article.

Lesson 1: Don´t be scared by the TSV_TNEW_PAGE_ALLOC_FAILED Error

If part of your implementation of SAP Rapid Marts includes General Ledger, Inventory or Cost Center you will probably have to perform a massive extraction of information from SAP ERP during your initial load. Most probably your customer will have been working with their ERP for quite some time, and you are likely to face the following error:

At this point, you will possibly start looking at configuration of SAP Data Services or you will start trying to tune the SAP ERP configuration in order to achieve the end-to-end execution. In general terms, you will have a headache trying to solve this problem and most likely none of the configurations will work…

The truth is out there… After many hours trying to tune configurations you will understand that the only solution is to modify the ABAP extraction itself… BAD NEWS: your customer does not allow you to do this because this means altering the out-of-the-box product. GOOD NEWS: the guys from SAP Support already tackled this problem and they published the following SAP Note 1446203 - Multiple Query Transforms in ABAP Data Flows, there they clearly explain that your conclusion is correct: this error is a memory allocation error on the SAP solutions server, it indicates that the SAP solutions server has run out of memory for the SAP Data Services generated ABAP program.

You will find an attachment in the SAP Note with some ATLs where they basically tune all the ABAP extractions of the SAP Rapid Marts XI 3.2 package, after applying this ATL to the out-of-the-box solution your extraction will work like a charm.

 

Lesson 2: How to improve performance of Delta Load for FINANCIAL_DOCUMENT_FACT

This lesson is useful to you if SAP Rapid Mart XI 3.2 General Ledger is part of your implementation.

After finishing the initial load of this SAP Rapid Mart you will start running the delta load. At this moment you may be shocked by the bad performance. Depending of your requirement this delta load can be something simply not affordable.

In basic terms this delta load tries to rebuild all the information of the current fiscal year. We ran an extensive performance analysis and the conclusion was clear: the logic for the processing of delta loads to the table FINANCIAL_DOCUMENT_FACT was causing serious performance issues to our environment.

Only one possible solution was in sight: introduce a new logic for the processing of delta loads to the table FINANCIAL_DOCUMENT_FACT. Breathe deeply because indeed this means to re-invent the SAP solution and this can clearly jeopardize your project.

We decided to come back with this topic to the SAP Support team looking for a “magical solution” and they got it! One more time there was a solution on the SAP Note 1557975 - Poor Performance of Delta Load for FINANCIAL_DOCUMENT_FACT.

The SAP note clearly defines a scenario like ours and provides an ATL file to tune the delta load for the FINANCIAL_DOCUMENT_FACT. Again, after applying the solution provided the delta load worked perfectly.

As conclusion, I would like to mention that after many years working with different support teams I´m impressed with the capability and escalation levels in the SAP Support team. Like many other support teams you may have to push to get a solution but I don´t know many other support teams that can escalate your request up to have a discussion with the director of development of a product or provide you with solutions that fit perfectly to your environments.

That´s all folks! I hope these two tips help you to speed up your SAP Rapid Marts implementations. If you have any doubts please leave a comment below.

EspañolEnglish