Workflow Configuration

Tue May 1 12:32:41 EDT 2007

Sherie,

We have multiple development codestreams and at go-live the SWU3 number 
range setting was overlooked. Consequently we had overlapping Workflows and 
Tasks with the same IDs as time went on and people developed new stuff. This 
caused havoc when we eventually merged the codestreams, for example when we 
implemented maintenance releases or mini-projects.

The 'new' versions of the Workflows and Tasks simply overwrote the 'old' 
versions with some impressively disastrous consqeunces. For example, 
existing instances of Workflows tripped up with nasty feedback errors when 
they attempted to call Tasks that had been replaced with completely 
different versions (using completely different objects).

In the end I had to determine the overlap, change the SWU3 settings for our 
dev environments immediately (so '950' for Fix on Fail environment, '951' 
for Maintenance Release, '952' for Projects, etc.), clone the 'new' stuff to 
reincarnate them with new IDs and transport the clones across asap.

A few SWETYPV settings had to be amended too to take account of the WF ID 
changes.

Quite a mess but we learned our lesson.

By the sounds of it your 'Support' environment is running in parallel with 
your baseline development environment, is that right? Presumably you bug fix 
in support (for speed?), transport from there into production but follow 
that up with a development code fix afterwards? If so then you may end up 
with redundant Tasks and Workflow versions in production if your SWU3 number 
ranges in your support and development environments are different, but they 
wouldn't do any harm apart from possibly confusing your support people a 
bit. The only issue I'd worry about is the possibility of introducing human 
error when copying the support fix across to your development environment 
when filling in the blanks (e.g. manually changing binding definitions).

Of course if you transport your support changes down to your development 
system as well as up to your production system then the SWU3 settings being 
different shouldn't be a problem.

Mike GT

>From: "Munday,Sherie J." <MUNDAYSJ at airproducts.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: Workflow Configuration
>Date: Tue, 1 May 2007 11:51:44 -0400
>
>Mike,
>Thanks for the insight.  You have piqued my curiosity!  How does that work? 
>  If you create a WS910xxx in dev and move to production and then you have 
>to make a change for support... Is the ws910xxx in your support system?  In 
>other words, does the system allow numbers outside the range you have 
>specified, it simply uses that number range when creating new tasks?  If 
>you need to create a new step in support do you end up with a TS911 in your 
>WS910?  Do you repeat the build in Dev with a TS910...and then when Dev 
>overwrites your support, will it replace the TS911 with the TS910?
>
>You are correct that we have had quite a bit of effort in keeping any new 
>tasks created in Prod Support in synch with the numbering sequence in Dev.  
>Fortunately there are only two of us in development.  However I am always 
>looking for improvements!
>
>Regards,
>Sherie
>
>Sherie Munday
>Workflow Developer/Analyst
>Air Products & Chemicals, Inc.
>
>
>-----Original Message-----
>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of 
>Mike Pokraka
>Sent: Tuesday, May 01, 2007 10:20 AM
>To: SAP Workflow Users' Group
>Subject: RE: Workflow Configuration
>
>Hi Sherie,
>
>I would disagree here, because *especially* for scenarios where you have 
>two dev systems feeding into one it's critical to have different number 
>ranges. You may have been fortunate so far but if you have a team of 7 
>workflow developers working the same landscape the numbers can easily get 
>messy.
>
>My strategy is something like 910 for ECC, 911 for ECC support, 919 for ECC 
>Sandpit (hey you may want to do a manual transport at some point),
>920/921/929 for HR, 93n for CRM and so on.
>
>Just my thoughts...
>Cheers,
>Mike
>
>On Tue, March 13, 2007 4:55 pm, Munday,Sherie J. wrote:
> > PB,
> > You really want to number based upon your release strategy.  We use
> > 901 in our HR system and 902 in our ERP system so that when we see a
> > workflow number we automatically know in which instance it resides.
> > We keep these same prefixes for both DEV and Prod Support (the only
> > two systems in which we develop).  The reason we do this is so that
> > regardless of which path we are currently on the workflow will have
> > the same number when it reaches prod.  For example:
> >
> > *
> > 	In Dev we create workflow #90200037 and move it through Integ and QA
> > into Production.
> > *
> > 	Later our Dev to Prod path is closed for changes and only used for a
> > new Release project.  Perhaps we need to make a quick change to the
> > #90200037 design by adding a subflow.  We would make our change in
> > ProdSupport.  We create the subflow in both Dev and ProdSupport using
> > the same number sequence #90200038, and add it to #90200037.  The
> > ProdSupport workflow is quickly moved into production.  The Dev
> > workflow is a good representation of what is in production so that any
> > testing or Release changes are kept in synch.  Eventually when the
> > Release is moved into production, the Dev workflow will replace the
> > ProdSupport workflow, but the numbers remain the same.
> >
> > Thus whether you want to use the same prefixes or different ones
> > between systems would depend upon your own company's landscapes and
> > release strategy.  This just happens to be what works for us and keeps
> > life "simple".
> >
> > Best Wishes,
> > Sherie
> >
> > Sherie Munday
> > SAP Workflow Developer/Analyst
> > Air Products & Chemicals, Inc.
> >
> > ________________________________
> >
> > From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> > Behalf Of praveen rajendran
> > Sent: Tuesday, March 13, 2007 9:47 AM
> > To: SAP Workflow Users' Group
> > Subject: Re: Workflow Configuration
> >
> >
> > Thanks for the info Ronen...
> > but I've have couple of doubts in this...
> > I've maintained the number ranges like this, in the development system.
> > 999 for DEV
> > 900 fro QA
> > 910 for PRD
> > Is this ok to do this just in Development system or should i also do
> > this in QA and PRD???
> >
> > Secondly,
> >    when I use report program RHMOVE30 to create transport request for
> > my Org structure, Is that enough if I transport Organization Unit in
> > top hierarchy and will those Org Units and positions below
> > automatically included into that request or should I add each Org unit
> > one by one into the request???
> >
> > Regards,
> > PB
> >
> >
> > On 3/8/07, øåðï ôå÷ñ <ronenf at paz.co.il> wrote:
> >
> > 	Hello,
> > 	For the number prefix: there is no real need to maintain this in your
> > QA & PROD environment since you probably won't be doing any
> > development in those environment. you can transport the prefix setting
> > from DEV to those systems just in order to get a "green traffic light"
> > in transaction SWU3 in those systems.
> >
> > 	Regarding org units and positions: you can use report RHMOVE30 to
> > transport your org. structure between systems. the reason you don't
> > get a change request prompt each time you modify your org. plan in dev
> > is probably because the 'transport link' for HR objects is deactivated
> > in your DEV system.
> >
> > 	Cheers,
> > 	Ronen
> >
> >
> > 		-----Original Message-----
> > 		From: sap-wug-bounces at mit.edu [mailto: sap-wug-bounces at mit.edu
> > <mailto:sap-wug-bounces at mit.edu> ] On Behalf Of praveen rajendran
> > 		Sent: Wednesday, March 07, 2007 10:47 PM
> > 		To: SAP Workflow Users' Group
> > 		Subject: Workflow Configuration
> >
> >
> > 		Hi,
> > 		  We are implementing workflow for our company. We did initial
> > configuration, Prefix number config and stuffs. We are using 999 in
> > development system, should we use the same in QA and production system
> > also?????
> > 		We have created simple organizational structure with various
> > positions and users assigned to the positions. how to transport this
> > Organization structure to QA and PRD systems?? Coz, we don see any
> > transport requests for this.. even it didn't ask for saving in
> > transport request when we created it. After transporting, will those
> > position numbers be same as Position numbers in QA and subsequently
> > PRD??? Because we have directly used these postions as agents in
> > workflow tasks... Are we going in right track??? What can be other 
>issues we might possibly run into???
> > 		Thanks for your help...
> >
> > 		Regards,
> > 		   PB
> >
> >
> > 	_______________________________________________
> > 	SAP-WUG mailing list
> > 	SAP-WUG at mit.edu
> > 	http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
> >
> >
> >
> >
> >
> > --
> > Thanks and Regards,
> > Praveen Rajendran
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
>
>
>--
>Mike Pokraka
>Senior Consultant
>Workflow Connections
>Mobile: +44(0)7786 910855
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug

_________________________________________________________________
The average US Credit Score is 675. The cost to see yours: $0 by Experian. 
http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE