Theoretical question - WF Design
Kjetil Kilhavn
KJETILK at statoil.com
Thu Nov 10 03:11:41 EST 2005
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> 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] 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
_______________________________________________
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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20051110/2d338471/attachment.htm
More information about the SAP-WUG
mailing list