Transport : Role Resolution and Responsibility Matrix

Thu Nov 7 09:17:54 EST 2002

Hello again,

Thank you for everyone's input.
For some reason, I did not receive Tamir's and Tomasz's e-mail reply, so I
am glad Jose's got to me with the thread.

I will be talking to the Basis team about this.
Right now they are maintaining HR information in PRD.
It would have been a good idea to have a copy of that in all master config
clients of the other systems.

I am still unsure why by just assigning Order Type_A to Position_B will
actually copy the relationships of Position_B from DEV to PRD.
If Position_B is new altogether, then that is another can of worms.
But Position_B already exists in DEV.
It just seems to me that the only transport for my change is a link in some
SAP table that says:
Element        Value            Assignment
Order            Type_A       Position_B

and NOT by moving relationships of Position_B as well.

Again, thank you one and all.
Gilbert Chong
Entergy, New Orleans

----- Original Message -----
From: "Jose Burgman [AST]" <jose.burgman at ast.co.za>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Thursday, November 07, 2002 12:20 AM
Subject: Re: Transport : Role Resolution and Responsibility Matrix

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 = 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"