Bei der Extraktion von Umlagerungen ins BW mithilfe der DataSource 2LIS_03_BF werden durch die BAdI-Implementierung WRMA_BW zus鋞zliche Datens鋞ze erzeugt. Bei der R點k黚ertragung dieser Datens鋞ze in das aktuell bearbeitete Datenpaket kommt es zu ziemlich langen Laufzeiten.

Weitere Begriffe

RMA, Retail-Method-of-Accounting, Stock Ledger

Ursache und Voraussetzungen

Die Business Function ISR_RETAIL_RMA ist aktiv. Die Erzeugung zus鋞zlicher Datens鋞ze ist f黵 die RMA-spezifische Bestandsbewertung von Umlagerungen erforderlich. Je nach Customizing – OLTP-IMG des BW Einstellungen f黵 anwendungsspezifische DataSources (PI) -> Logistik -> Einstellungen IBU Retail / CP -> Umlagerungsverkaufspreis definieren – kann sich die Anzahl der extrahierten Datens鋞ze bei Umlagerungen um einen Faktor bis zu 3,5 vergr鲞ern. Allerdings ist die Laufzeit der BAdI-Implementierung unverh鋖tnism溥ig hoch.

L鰏ung

Mit ECC 6.04 SP05 und ECC 6.05 wird die Performance in dem beschriebenen Fall deutlich verbessert. Eine Vorabkorrektur ist beigef黦t.
Weiterer Hinweis: Die in den Steuerungsparametern zur Daten黚ertragung eingestellte maximale Datenpaketgr鲞e kann bei der Erzeugung zus鋞zlicher Datens鋞ze auf Grund von Umlagerungen nicht ber點ksichtigt werden. Setzen Sie also diesen Parameter bei der Definition des InfoPackage zur DataSource 2LIS_03_BF im BW gegebenenfalls herab, um der RMA-spezifischen Verarbeitung Rechnung zu tragen.

Related:

1. Data loading performance/Admin. data target, many requestsSymptom You have a data target into which many requests...
2. AS/400: Performance settings for R/3Symptom AS/400: Setting system values for R/3 and BW operation...
3. Performance and parallelization of HTTP requests in browserSymptom The Internet Explorer and Firefox browsers open only few...

You have a data target into which many requests have already been loaded (scale 10000) or for which you expect a large number of requests in future.
Loading data or activating requests for an ODS object and/or displaying the request list in the administration of the data target slows down over time.
Other terms

RSSELDONE, RSLDTDONE, RSREQDONE, package, time out, RSMONICDP, RSICCONT,
RSREQICODS, RSSTATMANPART, RSSTATMANPARTT, RSSTATMANSTATUS,
RSSTATMANREQMAP
Reason and Prerequisites

You have a data target with a large number of requests.
Since certain information of all requests is required in a data target for the actions described above, a relatively large number of entries must be read and processed in different tables.
As a result, the processing times become longer and longer.
Solution

1. You can alleviate the situation to some extent by tuning. According to Note 48230, some of the database statements can be accelerated by parameter changes. See also Note 601612.
The following is an alternative option:
2. The idea here is to load the data of the affected data target (referred to from now on as A1) into one copy, so that you now only have one large request in this copy. Proceed as follows:
a) Create an identical copy A2 of your data target A1 with all data flows (update rules, connections to the export DataSource of the data target).
b) If A1 is used as an InfoProvider (for queries): Create a MultiProvider that contains both InfoProviders A1 and A2, or change existing MultiProviders containing A1 so that they contain A1 and A2 with the same characteristic and key figure identifier to ensure that consistent reports are still possible when the MultiProvider is used for processing. Copy the queries from A1 to the MultiProvider (for example, using transaction RSZC). Components into which these queries are embedded may also need to be adjusted accordingly (for example, Workbooks or Web Applications).
c) Create an update rule from A1 to A2 with the identical assignment of the characteristics and key figures.
d) Stop all delta updates in the source systems which affect A1.
e) Load any deltas that are still in the source system into A1.
f) If A1 is an ODS object, activate all requests that have not been activated yet.
g) Update all requests that are not yet updated from A1 into connected data targets (if available), but not do not update them into A2 yet.
h) Load all data from A1 to A2 with a full upload without selection criteria.
i) As soon as all the data has been loaded successfully from A1 to A2, completely delete the data in A1.
j) Perform a delta initialization for the connected DataSources for A1 without data transfer (if they are DataSources that supplied A1 in the delta method).
k) Switch on the delta updates in the source system again and supply the empty A1 data target with the deltas again.
l) In future, the connected data targets must be supplied from A2. For this you must carry out a delta initialization (as described for step j)) without data transfer for the connected data targets from A2 and load into these data targets from A2 in the future.
m) Execute steps d) to k) each time the performance of the A1 data target becomes too slow.
Note the following: You can continue to supply the data targets behind data target A1 from A1, if you cannot wait when supplying the downstream data targets, until the data is in A2. However, then you must supply all new data targets with an Init simulation once the A1 data target content has been fully deleted.
We recommend that you carry out this process once a month or once a week. However, if you were to do this on a daily basis, it is unlikely that the A2 data target would ever contain too many requests.

Related:

1. Performance 2LIS_03_BF bei RMASymptom Bei der Extraktion von Umlagerungen ins BW mithilfe der...
2. AS/400: Performance settings for R/3Symptom AS/400: Setting system values for R/3 and BW operation...
3. Performance and parallelization of HTTP requests in browserSymptom The Internet Explorer and Firefox browsers open only few...