Packages & Application components

[Dart, Jocelyn]

Stephen, FYI if you use SWDM and ask for "local objects" on the Extras tab (as opposed to "own local objects") it gives you all custom workflows/tasks defined in the system anyway.  Which in itself is one of my key reasons for using SWDM.  So there's no particular need to use a package or even a task group to collect all custom workflows for that reason.
 
Strictly speaking the workflows should go in the same package as related functionality.  However I agree that many workflows are cross application and it makes sense to use a single package to hold those workflows and I have often done it that way myself. However on site I also have usually seen the "all custom stuff in one package" approach.
 
Most customers don't really bother with proper package separation in my experience.  However, getting your packages set up sensibly is much more important if you are a partner or third-party software provider who is selling additional solutions to customers.
 
Rgds,
Jocelyn
 
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Becker, Stephan
Sent: Wednesday,28 July 2004 2:52 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Packages & Application components
 
 
I use CA for all WF as then I can see just the custom stuff in the SWDM
overview, and have it all together.. Very practical reason that you could
also achieve using task groups, but why the extra effort?
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]
Sent: martes, 27 de julio de 2004 18:20
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Packages & Application components
 
Hmmm, I suppose one reply in nearly 4 weeks does constitute the opinion of
the majority :-)  I guess the reality is that most people don't bother with
separating functional areas into packages.
 
I would agree with you, and have only had this discussion yesterday. Once
again I'm faced with a 'everyone else just uses the same dev class for
everything' situation however, so it's back to a single dev class for all
workflow stuff for this project.
 
Thanks for the feedback.
Cheers
Mike
 
Kjetil Kilhavn wrote:
> I try to put it in the same development class as the other solutions in
> that area. For instance, say we have made a solution for individual
> development plans and they want a workflow for that. I would find it
> natural that the workflow was put in the same development class as the
> other code for individual development plans. Of course this is not always
> possible, but at least I think it is the ideal solution. The development
> class should contain related solutions.
>
> Different workflows don't really have anything more in common than
> different function modules or different programs using batch input. No-one
> would think of putting all those in the same development class just
because
> they use a certain technique.
> --
> Kjetil Kilhavn
>
>
>
>
>                     Michael Pokraka
>                     <workflow at quirky.me.        To:
> SAP-WUG at MITVMA.MIT.EDU
>                     uk>                         cc:     (bcc: Kjetil
> Kilhavn)
>                     Sent by: SAP                Subject:     Packages &
> Application components
>                     Workflow
>                     <Owner-SAP-WUG at MITVM
>                     A.MIT.EDU>
>
>
>                     28.06.2004 19:31
>                     Please respond to
>                     "SAP Workflow Users'
>                     Group"
>
>
>
>
>
>
> Hi all,
> I've a small opinion poll: Does anyone actually use different packages
> (development classes) & application components for their workflow
> development? If so, what strategy do you use?
> I haven't seen that much 'real' use of packages / development classes - WF
> tends to just use one package and that's the end of it.
> In order to get custom WF's into the application hierarchy however, one
> would have to create and assign packages for each WF that's in a different
> area (SD, MM, FI-AP etc...). Another approach would be to assign WF's to a
> dev class / package belonging to the module specialists rather than have
> any
> workflow-specific ones.
> Does anyone follow either of these strategies? Is it worth the effort just
> for the benefit of being able to find the flows via the application
> hierarchy?
>
> Any thoughts appreciated,
> Cheers
> Mike
>
>
>
>
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of
the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and
delete
> this message.
> Thank you.
>
>