Transport vs. DL/UL question

[Former Member]

I've not searched the forum...

Reason being I would appreciate a little guidance:-)

I've stopped the ability to upload and generate in qas to avoid profile naming colisions but now being told the project team need to upload as the can't do "millions" of transports due to time constraints.

Other S&A resource assigned extra role to override restrictions...

BS as far as I am concerned but I would like to hear others opinions (if any) around this please.

I'm holding ground for prd upload but what are your views on bypassing transports?

Cheers

David

Edited by: David Berry on Jul 21, 2011 9:28 PM

[Former Member]

Qas is okay, if the sid is correctly named and there is a golden dev client for roles.

If not, then you will have these problems anyway...

Prod I would only transport to and block UPloads via the application auths of the user there.

There is also a BADI function in the STMS which can check from roles in modifiable tp requests. It is very usefull and you can add several other checks with warnings to it as well.

However, if you allow uploads to Prod then it is useles to control role quality. They will also stop using the merge function and not maintain (and transport) su24 anymore.

Typically they start maintaining roles directly in prod and opening roles the with "read old status" only when they do so.

Avoid it like the plague...

But for qas if you are disciplined with parrallel maintenance aswell it is okay (depending on the org. issues). You will for examle encounter the topic of system copies and then access is lost in qas...

Cheers,

Julius

[Former Member]

if the SID is correctly named and there is a golden dev client for roles

I'm not sure - the profile (trunk) names are in roughly the same numbers ranges - i.e T-X123456790 in DEV QAS and PRD.

Creation and generation of roles appears to have been the norm with roles being created in DEV and uploaded to PRD and generated. I found a small number of collisions when I started to clean up the derived roles which had profiles at 'to be adjusted' in PRD. The reason for my locking down updates to PRD and QAS.

Looking at the previous posts regarding 50,000 number ranges between them ~I think this hasn't been considered but I'm not sure how to check the SID's at the moment.

Sorry for being stupid..

Cheers

David

Edited by: David Berry on Jul 22, 2011 11:49 PM

[Former Member]

T-X123456790

"T-" is a constant (see the FAQ thread to change it).

"X" 1st character of the SID.

"1" 3rd character of the SID..... so 2nd character is not considered, hence use the first character in the naming and tell basis not to create nor transport roles from client 000... (I can write a book about that, if you can spot the confusion aspect in client 000 of the SIDs ...).

"234567" is a sequencial number client specific from table AGR_NUM_2, however take note that same SIDs (1st and 3rd) can collide).

"90" is the authorization instance number in the role. "90" is quite an achievment.... which object is it?

Cheers,

Julius

[Former Member]

T-C is the current format for DEV, QAS and PRD

The next number in all is 1 and the number ranges are not set outside of a 50K spread which is why the process of DL UL to QAS (and also to in PRD for some roles) worries me

I've usually seen T-D, T-Q and T-P for other clients which is making this a little more difficult to spot the 'where were you built?'

Edit

"90" is the authorization instance number in the role. "90" is quite an achievment.... which object is it?

I'll have a further dig into this aspect!

D'Oh.This one's not relevant - I should have stopped at a shorter number as an example

Edit

been a long week ...

This is why I want to lock down the QAS and PRD to 'ZTEST' for the role and profile.

Cheers

David

Edited by: David Berry on Jul 23, 2011 12:26 AM

Edited by: David Berry on Jul 23, 2011 12:33 AM

[Former Member]

>> The next number in all is 1

Then you should reset the number ranges and perform a clean up, because transports will collide (typically from basis folks but they soon resort to SAP_ALL because their role attempts dont work...and "up stream" profile generation will reserve profile names) .

A clean up between the role data and the profile data seems to be needed. To be honest you might have to test everything if it has been going on for a while....in which case it is an opportunity to start from scratch.

If the customer has been using LSMW and ecatts then it is typically even worse.

I have even seen some resorting to DB field triggers....

Real pity...

--> Build solid single roles and transport them for testing. Only cheat in QAS if you are disciplined enough for parrellel maintainance.

Cheers,

Julius

[Former Member]

Well...

Merely an outsider watching the accident - wish a little "minority report" to save the day was available.

Isn't there a check list that should be followed during these processes so that everything is done correctly?

Edited by: David Berry on Jul 24, 2011 12:49 AM

I'm guessing that the check list is optional and based on user's own experience.

There is also a BADI function in the STMS which

I haven't dealt with these as far as I know...the simplest option is to stop bad practice befor having to resort to stuff I don't understand

[Former Member]

There is a program which checks for collisions, but it is in the import events of the STMS.

The problem with the STMS release BADI is that although it would be triggered before something goes wrong, the collision information is in the remote target systems where the role is heading toward. Unfortunately the TMSADM cannot read this information, and having many logon screens popup is not user-friendly either, and generally having system user RFC calls from DEV to QAS and PROD is not advisable.

I would go to AGR_PROF and USH10 in the systems and manually work out how many collisions there are and show the folks the risk of this with examples of collisions which have already happened (and that the users actually have the wrong access).

Cheers and good luck,

Julius

[Former Member]

I did the AGR_PROF checks after the first error came back and found 7 which would have caused further issues for my transports but I haven't heard of USH10 - I''ll check that on Tuesday!

[Former Member]

Note that on higher releases the historyof profiles was moved from USH10 to CDHDR. If you use report RSUSR101 you should be fine as it would consider this.

Take any created profiles from QAS and PRD as well as all clients other than your "golden DEV client for roles" and if they exist in AGR_PROF there then they will collide sooner or later.

Cheers,

Julius

[Former Member]

Hi Julius

Thankyou for the advice which is,as always - much appreciated.

I'll have a look at the CDHDR table to see how that relates to the AGR_PROF table I used in DEV, QAS and PRD. After the access was increased I saw around 50 new roles created in DEV and then in QAS with different (but not by enough) profile numbers.

I suspect that the client won't listen anyway..

Cheers

David

[Former Member]

We have a (verbal) agreement...

The number ranges need checking and then the SID's also need checking and then I can carry out a proper clean-up of the profile trunks.

Amen

Cheers

David

Edited by: David Berry on Jul 25, 2011 11:03 PM

[Former Member]

> BS as far as I am concerned but I would like to hear others opinions (if any) around this please

I concur. It sounds like typical last minute rush stuff and they are resorting to bodging to get things in on time. Could well be symptomatic of much bigger problems round the corner. Unfortunately I own this particular t-shirt (albeit a rather old one now).