Workflow Configuration
Alon Raskin
araskin at 3i-consulting.com
Tue May 1 11:49:15 EDT 2007
Just to further add to what Mike had said, keep in mind number ranges for HR org Objects which may be created in the two dev systems.
Alon
________________________________
From: sap-wug-bounces at mit.edu on behalf of Mike Pokraka
Sent: Tue 5/1/2007 10:20
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10227 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20070501/0f9815c1/attachment.bin
More information about the SAP-WUG
mailing list