Theoretical question - WF Design
Susan R. Keohan
keohan at ll.mit.edu
Thu Nov 10 08:22:57 EST 2005
All,
Thank you very much for your feedback. It is greatly appreciated.
In my new effort (SRM 5.0), I am not doing line item approvals. My goal is to use the model of
WS14000133 and WS14000134, using the N-Step BAdi to determine the approvers (all the heavy lifting).
Start Conditions will be used, but cannot account for everything, as many approval steps depend on
what actions the previous approvers took (in our dreams, some approvers have the ability to
'restart' a new set of approvals, or resubmit to previous approver, if the cart was rejected).
So, *most* of the approver logic in the BAdi, then the need to evaluate post-rejection conditions,
coupled with a custom inbox (I know, I know, I know) and, no doubt, custom approval tasks (again, I
know what you are thinking). Enhancements to BUS2121, BUS2201, BUS2200, BUS4101, and creating a
generic object ZWFTOOL (thanks Mike!) to handle the common functionality behind the scenes (Reading
and writing from custom log files to determine rejection routing sequences, etc).
Happy WF-ing,
Sue
Kjetil Kilhavn wrote:
> One argument for putting more logic in the code is that (in my opinion)
> it is easier to maintain BOR object code than re-arranging a workflow.
> However, the BOR object leaves no trail, so for auditing adding workflow
> is better.
>
> In the latest solution I designed I used quite a few steps where the old
> solution hid stuff in the code. I like it because I can look at it and
> see more clearly what goes on than with the old "massive-methods"
> solution, and it will hopefully lead to fewer errors in the code as it
> becomes less complex - my BOR code is unfortunately not perfect. Making
> the workflow a little more complex also helps secure employment for at
> least one workflow developer in the company ;-)
>
> So ... you have probably guessed it by now ... it depends!
> --
> Kjetil Kilhavn, Statoil ØFT KTJ ITS BKS SAP Basis
>
>
> ------------------------------------------------------------------------
> *From:* sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] *On
> Behalf Of *Raju Omkaram
> *Sent:* 9. november 2005 22:58
> *To:* SAP Workflow Users' Group
> *Subject:* Re: Theoretical question - WF Design
>
> If WF log is critical then create a WF attribute long enogh to hold
> the condtion. This attribute can be filled out in the BADI per each
> condition that has been executed. In workflow create a step to
> display the attribute.
>
> This way you can see what conditions have been set in BADI also it
> will be easy to track the condition in question while keeping the WF
> simple and elegant.
>
> Raju
>
>
>
> On 11/9/05, *Mike Pokraka (WUG)*
> <wug.replies at workflowconnections.com
> <mailto:wug.replies at workflowconnections.com>> wrote:
>
> Hi Sue,
>
> Always a big question of keeping a balance between simplicity and
> visibility. I lean towards visibility. Spend that little bit of
> extra time
> in designing sensible subflows and you can cram quite a lot of
> stuff into a
> flow that still remains manageable.
>
> Another factor to consider is putting as much 'business'
> conditions in the
> WF as possible and hiding the techie stuff in code. Bear in mind
> that it may
> be business users looking at the logs, so hiding too much makes that
> useless. Oh, and it makes productive debugging easier to have
> stuff in the
> flow.
>
> Just my 2c,
> Cheers
> Mike
>
> -----Original Message-----
> From: sap-wug-bounces at MIT.EDU <mailto:sap-wug-bounces at MIT.EDU>
> [mailto:sap-wug-bounces at MIT.EDU
> <mailto:sap-wug-bounces at MIT.EDU>] On Behalf Of
> Susan R. Keohan
> Sent: 09 November 2005 19:55
> To: SAP Workflow Users' Group
> Subject: Theoretical question - WF Design
>
> Hello all,
>
> I am in the process of designing workflows for SRM 5.0 (Shopping
> Cart
> Release - using N-step BAdi, PO, etc.). My organization is very
> thin when
> it comes to workflow expertise. Therefore, I ask the
> following:
>
> Is it better to put conditions, branching, etc in the workflow
> itself, which
> exposes the conditions, but also complicates the flow, and would
> require a
> WF person to modify/maintain, or
>
> put a lot of effort into the underlying ABAP, the theory being
> that it would
> be easier to find an ABAPer who can maintain/modify the
> code. The drawback,
> of course, is that the conditions are not so visible.
>
> There's no right or wrong answer... just food for thought.
>
> Happy WF-ing,
> Sue
> --
> Susan R. Keohan
> SAP Workflow Developer
> MIT Lincoln Laboratory
> 244 Wood Street
> LI-200
> Lexington, MA. 02420
> 781-981-3561
> keohan at ll.mit.edu <mailto:keohan at ll.mit.edu>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> -------------------------------------------------------------------
> 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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
--
Susan R. Keohan
SAP Workflow Developer
MIT Lincoln Laboratory
244 Wood Street
LI-200
Lexington, MA. 02420
781-981-3561
keohan at ll.mit.edu
More information about the SAP-WUG
mailing list