Workflow Configuration

Tue May 1 11:51:44 EDT 2007

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