‎2016 Jun 17 12:30 PM
Hello Friends, We have come across a situation where transport gets overwritten by some other transport and we lose the changes done in the roles. For Example :- Suppose if Role1 has been changed and transport have been generated Say TR1 and the same role has been changed after some time and TR 2 has been generated. Now During production transport, TR2 has moved first and then TR1 goes. Now changes are overwritten. What can be the possible solutions to overcome this? One solution we came across is:- Checking SE03 Transport Organizer for the same role. If there are two transport then we would need confirmation from the change owner that when will his transport go and then we can transport the latter changes. Please let me know if there is any other solution as well
Message was edited by: Mili Airen
‎2016 Jun 17 1:26 PM
Mili,
The solution to this problem is for the security developer to not send transports out of order. Before you start to make a change to role, verify that there are no transports in flight for that role, and that the date and time stamp on the role is the same in PROD as in DEV and Test. If there is a stale transport of the role that never made it to PROD, confirm it before creating a new transport.
Gretchen
‎2016 Jun 17 1:26 PM
Mili,
The solution to this problem is for the security developer to not send transports out of order. Before you start to make a change to role, verify that there are no transports in flight for that role, and that the date and time stamp on the role is the same in PROD as in DEV and Test. If there is a stale transport of the role that never made it to PROD, confirm it before creating a new transport.
Gretchen
‎2016 Jun 17 1:49 PM
Hi Gretchen, This is similar as SE03, right where we check if a role is include in more then 1 transport request and if that request is in modifiable state..
‎2016 Jun 17 4:39 PM
Hi Mili, SE03 would help only if the person who made the change to role ahead of you created the transport request for his change. If he did not yet create transport request and you use SE03 you might think that yours is the only change and go ahead with moving your transport to Production. The end result being that you also moved the changes made by the person to the role ahead of you.
As Gretchen suggested, the best practice is to make sure that the role is same in Dev and Prod even before you make the change. This can be done my checking the date and time stamp of the role in Dev and Prod or by comparing the role in Dev with Prod using SUIM-> comparison of roles across system. If you find that the role in Dev is not same as in Prod, stop making your changes until you find out the reason. It could be someone making the change and sitting on it without creating transport, or it could be that the role is in test environment still being tested and not yet made to Prod. If it is the second case check with the change owner and co-ordinate with him on moving both your changes to Prod.
‎2016 Jun 20 8:58 AM
Any other method we can avoid this?? I just want to know are there many methods thru which we can avoid such things.
‎2016 Jun 23 10:39 AM
Mili
I know every one has discussed about SE03
First and Foremost. you have to identify how many teams are working under Role development.
Proper communication needs to be in place between the "Role development" teams, when ever a role change is requested.
you could also maintain "Long Text "section in role description with date , time stamp and user who has done the last changes
Cheers
Pavan M
‎2016 Jun 23 3:24 PM
Hello Pavan, We had created a role change document which was accessible for everyone who makes changes to the role. There is used to maintain what role has been changed, what are the changes, when it is changed, who has changed it, ticket number, transport request number and where the changes are right now. Since this a manual task sometime it happens that due to some urgent request few fellow forgets to add these details which lead us to problem. So i was trying to finding out is there any other method to overcome this.