Transport : Role Resolution and Responsibility Matrix

[Jose Burgman [AST]]

I had a similar question a while back. Here's the responses....
 
Jose
 
Start of quote
[Lets Qualify Agent here:
I assume we are referring to PD Objects (HRP1000)
You can transport these (Setting in T77s0) will treat changes as
requiring captured in a transport, much the same as config.  Useful =
PRIOR to go live.
However, if you are live and Maintain the Org structure in PRD
you must question the act of transporting such objects into the system.
 
You can even make settings to block import of PD objects.
This is often a good idea when people have a habit of transporting
things of unknown origin or content.
 
A good alternative it to use ALE, on message type HRMD_A.
TO send the org structure from PRD back to TST and DEV so you have the =
data
there.
Use Transaction PFAL to send Objects to connected systems.
Define the ALE model in BD64.
You can even do this on the basis of change pointers.
(BD50, BD61) and run RBDMIDOC.
 
 
 
Ideally you leave your PRD box as the source of (keeper of) originals.
 
NOTE if you send/transport an HRP1000 OBJECT into PRD and the object =
exists, it is OVERWRITTEN.
And that means it's relationships as well.
 
Double check the plan of what data is to be maintained where.
 
Cheers
 
 
Phil Soady
Senior Consultant
Business Technologies
SAP Australia
* : 0412 213 079
* : phil.soady at sap.com
 
 
 
 
 
-----Original Message-----
From: Tamir Pivin [mailto:TAMIRPI at cellcom.co.il]
Sent: Wednesday, 2 October 2002 6:23 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Transport of agents
 
 
I have the same problem of different number ranging between the system, =
now i restrict the task by using the expression org' unit in the step =
name, but since there r differences i can not use the same number, on =
the other hand i can not change it directly like i could in the WF tasks =
from the 3.1 version.( now i am on 4.6c) what can be done ? Tamir
 
-----Original Message-----
From: Zmudzin,Tomasz,VEVEY,GL-DS/DM [mailto:Tomasz.Zmudzin at nestle.com]
Sent: Wednesday, October 02, 2002 9:03 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Transport of agents
 
 
Jose,
 
The best thing is to face the facts:
- if the data is maintained in both systems, you're likely to have =
different objects being assigned the same number on both boxes. Of =
course there are number ranges etc -- but I guess  if you ask this =
question, setting them up has not been discussed thorougly.
- the transport of these object will clearly update =3D overwrite the =
table contents
- if the data is maintained in both systems separately, it still should =
be maintained SEPARATELY. Simply don't transport the agents and assign =
them in the other box. This may not necessarily be convenient in all the =
cases, but 'you cannot be half-pregnant', as one said.
 
Kind regards,
Tomasz]
End of quote
 
-----Original Message-----
From: Gilbert C [mailto:gchonsult at hotmail.com]
Sent: Wednesday, November 06, 2002 7:18 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Transport : Role Resolution and Responsibility Matrix
 
 
Good morning,
 
I had a bad experience with transports last week and it screwed up =
Production config.
 
One of the workflows uses role resolution to determine routing of work =
items.
For my change, if the service order is Type_A, then route to Position_B.
This was never built into the responsibility matrix, so I added that in.
When this was tested in Development, Position_B only had my ID.
In Production, Position_B has 10 users assigned to it.
 
When the transport made it to Production, all original users of =
Position_B were wiped out but my ID was there.
It seems that my transport has actually moved the user assignments from =
the Development system too.
 
Why did the transport include users when I only changed the =
responsibility matrix?
Was it incorrect for Development not to have the exact org structure as =
Production to begin with?
 
Thank you.
Gilbert Chong
Entergy, New Orleans
______________________________________________
 
"This information is intended only for the person or entity to which it is addressed and
may contain private, confidential, proprietary and/or privileged material and may be subject
to confidentiality agreements.
 
Any review, retransmission, dissemination, or any other use of or taking of any action in
reliance upon this information, by persons or entities other than the intended recipient,
is prohibited.
 
If you received this in error, please contact the sender and delete the material from all
storage media.
 
The company is neither liable for proper, complete transmission of the information contained
in this communication, any delay in its receipt or that the mail is virus-free"