T-code
RSMNG
is useful replacement of former administration part of RSA1. It comes handy
also in case you do not prefer web environment (SAP BW∕4HANA Cockpit) based administration of BW/4 bases
systems. However, after some time of using it I realized it has its drawbacks.
Most annoying thing for me is its performance. This comes to picture in cases
when I do administration of an aDSO
object that has large (tens of thousands) number of data load
requests.
In
such case, it takes time (several minutes) to get into the administration
screen. The RSMNG t-code has following two filter options that have an
influence on how many request are displayed on the admin screen.
Filter by Time – options like Today, Yesterday and Today,
In the Past Week, This Month and Last Month, This Year and Last Year, Free Data
and No Time Restriction are available here to choose from. This screen is more
less the same as on Process Chain’s
log selection screen.
Filter by Status – OK, Error, Running and Deleted are data
load
request status to choose from.
In
case you used filter by time and set it to No Time Restriction position of a radio
button on object that has very few data load request - all is fine. However if
you meanwhile jump into another aDSO that has a lot of the data load requests
you will be waiting till all of them are read and the screen is finally
displayed. Therefore, this is the bummer.
There
is a database table that stores the setup of the RSMNG t-code. The table name
is RSDSO_MNG_DYNSET (ADSO manage:
dynamic user settings). The table is managed by Function Module RSDSO_MNG_SET_PARAM.
The FM itself is called from RSMNG framework build in ABAP class CL_RSAWBN_AWB.
I find myself in a position to change the table entries in case I realize my
settings are set e.g. to No Time Restriction and I run to the very large aDSO.
The
settings of the table are stored per a user. Means each user (column UNAME) running
the RSMNG t-code has its own settings. This is actually causing this issue that
if I set time filter to No Time Restriction value it is valid for all the aDSOs
I used in the t-code. To avoid situations like this it would be better if table
could store the RSMNG settings on particular aDSO (or IO objects as that can be
managed here too) level. However, at this time BW/4 2.0 SP06 it is not
supported.
There
are different tables that stores the RSMNG setup data per infoprovider:
RSDSO_MNG_DYNSET – for aDSOs
RSDMD_MNG_DYNSET – for InfoObjects
RSBOH_MNG_DYNSET – for Open Hubs
In a below pictures you can see how is the table columns mapping done against the particular
filter settings of the RSMNG.
No comments:
Post a Comment