PUBLIC
Simplification List for SAP BW/4HANA 1.0 © Copyright 2019 SAP SE or an SAP affiliate company
The Simplification List for SAP BW/4HANA All rights reserved. 68
monitoring transaction (RSPM_MONITOR) that is integrated with all objects and processes in SAP BW/4HANA
using RSPM.
The Request Transaction Sequence Number (TSN) is based on a time stamp of the enqueue server with collision
number (23 digits with 9 decimals). It has a conversion exit to display the time stamp in local time zone.
Example: 99991231235959.000009900 (internal view of TSN), {9999-12-31 23:59:59 0000099 CET} (user
view of TSN). Request TSN has two navigational attributes: User (0AUSER) and Source of Data (0ASOURCE)
which are populated at creation time of the Request TSN and available as metadata in BW queries.
Planning scenarios do not use "open" (yellow) requests anymore. Each user transaction - a save of plan data - is
associated with its own Request TSN.
When converting from SAP BW to SAP BW/4HANA, the request metadata is converted automatically by the
Transfer Toolbox (for in-place as well as for remote conversions).
Before Revision 10 all requests of an InfoProvider, and all inbound delta DTP Requests in InfoObjects and Open
Hub Destinations were converted into new TSN based Requests (in a TSN Range starting with 01.01.1900 and
ending roughly in the year 1968).
With Revision 10 of the Transfer Toolbox a new optimized Request Transfer is introduced. This alternative
request transfer is based on a preliminary processing of the data in the InfoProviders before transfer. Thus,
compared with the old approach, it results in a reduced number of TSN based Requests in the resulting ADSOs,
InfoObjects and Open Hub Destinations.
Therefore, the optimized request transfer is between 5 and 100 times faster, depending on your system
(hardware, model complexity). This means that instead between 5 and 100 Requests per Minute, now between
500 and 1000 Requests can be transferred per Minute.
This also means that it is not necessary to reduce the requests before the transfer, only a reduced number of
requests will be transferred, which in turn will minimize the exposure to follow up problems in the life cycle of the
transferred requests.
In detail, this alternative procedure consists of the following:
Switching on the optimized request-transfer
With revision 10, in the selection screen of the start objects a toggle box "use optimized request transfer" will be
introduced. It will be switched off by default. Once the scope is collected, the flag can not be changed anymore.
New Checks and activities during the prepare phase
Inplace-Transfer
• all 3.5 DataFlows must be converted into 7.0 DTP based DataFlows
• all closed loops consisting of only delta DTPs must be interrupted:
o a closed loop may consist of an delta DTP having the same object as source and target. It may,
of course consist of multiple delta DTPs, in which one DTP extracts from the target of its
predecessor and the target of the last one is the source of the first one
o in each loop, one of this deltas DTPs must be logically deleted with the help of the report
RSBK_LOGICAL_DELETE_DTP
• all 'yellow' or 'red' requests, in all InfoProviders contained in the scope must either be deleted, or their
overall Status set to 'green'
• all delta DTPs, which have as source an object in scope and themselves are not part of the scope, must
also be logically deleted with the help of the report RSBK_LOGICAL_DELETE_DTP
• all active delta DTPs in scope must be executed. All source data must be transferred by this delta DTPs
prior to the transfer. This must be done also for DTPs extracting from the PSA of DataSources.