Problems with transporting a workflow to another instance

[Lindsey Stead]

Thanks Dale,
I think my last reply got cut off, so incase it did I did want to thank =
you for your response. The problems with transporting problems happened =
due to 3 issues - the versioning I sorted out with the application of 3 =
OSSnotes, the task I transported using RHMOVE30 so it could recognise it =
was a general task and the role problem was an authorisation issue - =
apparently I have 'slightly' different profile in SBX than in DEV so if I =
transport a workflow that uses a role it can't activate under my userid.=20=
 
Anyway now I'm cooking! Lindsey
 
>>> dkdavis at us.ibm.com 02/11/02 12:12PM >>>
Hi Lindsey:
 
>From your memo, I am inferring that your workflow definition in SBX was =
not
activated previously and that your (AC) role is based on a function =
module?
If that is the case, was the function module transported  to SBX and has =
it
been generated?
I am not clear whether you changed the workflow to go to one user in SBX
by linking the step in the workflow definition to a userid or whether you
assigned the TS task to a user and left the link in the workflow definition=
 
step blank.  If you did either,  you need to relink the step in the
workflow definition to the role and retransport the workflow definition =
now
that you have validated that the role and the function module it references=
 
are there in SBX.
Also ensure that in SBX the agents linked to your TS task are possible
agents otherwise your role resolution will not work.
 
You might also want to run diagnostics against the workflow template using
tx: SWUD to ensure there are no additional hidden problems.
 
Regarding  your question on transport procedures:
 
For all new development we create workflow templates and standard tasks.
 
If there are PD org objects such as responsibilities, orgs  or positions, =
I
transport them and their relationships  before transporting the repository
objects that reference them.
 
Next I batch workflows that consist of WS andTS tasks, and linked
respository objects such as roles, business object types, function =
modules,
in the same workbench transport or set of workbench transports and
transport them after the org objects are imported successfully.
 
 
Note : For changes to existing WF tasks, I  transport the repository
objects such as business object types first, followed by the customizing
objects such as WF and T tasks that reference them.
 
 
Regards,
Dale Davis Jones
IBM / SAP Certified
Senior SAP Workflow & PP Consultant - SAP Practice
 
IBM Global Services
Phone: 919-543-7678
               T/L 8-441-7678
  Internet Address: DKDAVIS at US.IBM.COM
 
.......You can never discover new oceans unless you have the courage to
lose sight of the shore..........
 
 
Lindsey Stead <Lindsey.Stead at huskyenergy.ca>@MITVMA.MIT.EDU> on 02/11/2002
12:09:55 PM
 
Please respond to "SAP Workflow Users' Group" <SAP-WUG at MITVMA.MIT.EDU>
 
Sent by:    SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>
 
 
To:    SAP-WUG at MITVMA.MIT.EDU
cc:
Subject:    Problems with transporting a workflow to another instance
 
 
 
 
Hi everyone...
 
I have created a small workflow that sends a cash receipt  document for
confirmation to the relevant users inbox. The workflow is triggered  by FM
SWW_WI_START_SIMPLE and I use a role which calls a fn to work out which
user gets the message. This works perfectly in DEV, however I cannot get =
it
to  work in SBX  for testing. We are on 4.6B hotpackpack 10. I have
applied the OSS notes to handle any problems with versions of the =
workflow.
I  have looked at note 138411 that talks about the transport of PD objects
and and  I have used RHMOVE30 to create a transport for the PDWS( =
workflow)
&  PDTS(task) objects. I know it is the role that is the problem as I have
changed  the workflow to go to one user in SBX and it works. The role was
transported to  SBX and is there - how do I transport the link to it? Also
is there a certain  way we should transport non-sap delivered workflows?
 
Thanks to all..
   Lindsey Stead,
   Husky Energy
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20020213/bffa8d73/attachment.htm