Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

UST12: not all entries moved during import

Former Member
0 Kudos

Hi there,

Today I faced the issue below.

When comparing a single role from Dev with QAS system via SUIM it showed that role in QAS does not contain some auth objects whereas they existed in PFCG/AGR_1251 (after transport was imported into QA). As far as I know SUIM uses UST* tables for reporting. I checked UST12 table (the only UST* table the transport consisted of) and found that indeed some objects were missing for certain profiles.

transport logs for Import phase into QA showed entries like that:

3 entries for UST12 imported (100V_VBAK_AATT-ED78820508A*).#

0 d / 0 i / 0 u / 4 = 100% ucf UST12 #

4 entries for UST12 imported (100V_VBAK_VKOT-ED78820508A*).#

3 entries from UST12 (100V_VBRK_FKAT-ED78820500A%) deleted.#

0 entries from UST12 (100V_VBRK_FKAT-ED78820500A%) deleted.#

0 d / 0 i / 0 u / 3 = 100% ucf UST12 #

3 entries for UST12 imported (100V_VBRK_FKAT-ED78820512A*).#

3 entries from UST12 (100V_VBRK_VKOT-ED78820500A%) deleted.#

0 entries from UST12 (100V_VBRK_VKOT-ED78820500A%) deleted.#

0 d / 0 i / 0 u / 3 = 100% ucf UST12 #

3 entries for UST12 imported (100V_VBUK_FRET-ED78820510A*).#

8 entries from UST12 (100ZERU_BUKRST-ED78820500A%) deleted.#

0 entries from UST12 (100ZERU_BUKRST-ED78820500A%) deleted.#

Newer transport that changed other objects of this role did not contain "deleted" entries in transport log for UST12 table, only "imported' ones. After moving this to QA, UST12 was "synced" with AGR* and SUIM comparison report works as expected.

What is a reason for TMS to not import all entries for UST12 but to delete some?

I tend to think this could happen again and confuse those people using SUIM for security changes controls in our organization.

I checked recent notes regarding SUIM reports but it looks like they have been implemented already.

Thanks in advance,

Igor

1 ACCEPTED SOLUTION

Bernhard_SAP
Employee
Employee
0 Kudos

Hi,

possibly changes have been performed to the role in DEV after it had been inserted into the transport. In contrast to normal transports role transports behave a bit different at the moment. Only after you have finished your changes and generated the profile you should insert the role into a transport.

As per your description it would have been sufficient, to generate the profile in QAS to have the current profile again. At generation the AGR_data is put into the USR/UST*-tables.

To avoid further inconsistencies after role transport you should strictly follow the standard procedure for transporting roles (create the transport only after finishing any updates to that role).

b.rgds, Bernhard

3 REPLIES 3

Bernhard_SAP
Employee
Employee
0 Kudos

Hi,

possibly changes have been performed to the role in DEV after it had been inserted into the transport. In contrast to normal transports role transports behave a bit different at the moment. Only after you have finished your changes and generated the profile you should insert the role into a transport.

As per your description it would have been sufficient, to generate the profile in QAS to have the current profile again. At generation the AGR_data is put into the USR/UST*-tables.

To avoid further inconsistencies after role transport you should strictly follow the standard procedure for transporting roles (create the transport only after finishing any updates to that role).

b.rgds, Bernhard

0 Kudos

Bernhard,

Thanks for your answer.

> Hi,

> possibly changes have been performed to the role in DEV after it had been inserted into the transport. In contrast to normal transports role transports behave a bit different at the moment. Only after you have finished your changes and generated the profile you should insert the role into a transport.

As far as I understand during transport release it takes current "snapshot" of the tables for Roles/profiles, so any changes made to the role after transport was created but until released would be put into that request, right? This seems proved to be true as PFCG/AGR_1251 contained correct values in QAS. So, the problem is that during release of transport not all needed tables related to user/role management are "pictured" and put into the request i.e. some tables (UST*) are "pictured" only when role is being put into request, correct?

> As per your description it would have been sufficient, to generate the profile in QAS to have the current profile again. At generation the AGR_data is put into the USR/UST*-tables.

Well, when changes to the role are moved new profile is generated automatically in the target system, therefore values from AGR* should populate UST* tables? Or I am missing something..

> To avoid further inconsistencies after role transport you should strictly follow the standard procedure for transporting roles (create the transport only after finishing any updates to that role).

Will do. Many thanks for the valuable info.

Igor

0 Kudos

>

> {quote

> > Hi,

> > possibly changes have been performed to the role in DEV after it had been inserted into the transport. In contrast to normal transports role transports behave a bit different at the moment. Only after you have finished your changes and generated the profile you should insert the role into a transport

>

> As far as I understand during transport release it takes current "snapshot" of the tables for Roles/profiles, so any changes made to the role after transport was created but until released would be put into that request, right? This seems proved to be true as PFCG/AGR_1251 contained correct values in QAS. So, the problem is that during release of transport not all needed tables related to user/role management are "pictured" and put into the request i.e. some tables (UST*) are "pictured" only when role is being put into request, correct?.

This is a common rumor......

Please read: https://service.sap.com/sap/support/notes/571276

Ther exists already 1 discussion about this fact in this forum....

>

>

> > As per your description it would have been sufficient, to generate the profile in QAS to have the current profile again. At generation the AGR_data is put into the USR/UST*-tables.

>

> Well, when changes to the role are moved new profile is generated automatically in the target system, therefore values from AGR* should populate UST* tables? Or I am missing something..

Well only, if you use the procedure mentioned above.

US*-table content is only created when generating the profile. So if you have more data in AGr-tables, the profiles are not actual.

b.rgds, Bernhard