'How to' Workflow Macro Question
Dart, Jocelyn
jocelyn.dart at sap.com
Thu Jan 20 19:01:16 EST 2005
Paul,
Complex attributes are a lot less performance expensive if you do some
"buffering".
Usually a simple IF statement in your attribute/method code to check if
the value has already been calculated is enough.
Be wary of people who claim "performance" as the only reason to do
things the hard way.
I've seen that so many times - and you always get caught in the end.
Rarely have I seen
REAL proof given of the additional cost measure on a system with a true
volume issue with other factors already eliminated or accounted for.
Usually people quote differences based on the fact that a minor amount
of overhead work happens in all cases - but usually that overhead is
saving you a lot of grief.
Hence yes I can compare a direct SELECT with a BAPI and say "hey there's
extra stuff happening!" but that doesn't mean this on its own is enough
to ditch a BAPI which will give you some guarantee of upgradeability,
buffering, enforcing of correct read sequence etc. over using a direct
SELECT statement which can leave you open to cruel and unusual problems
unless you understand everything that happens in the system to do with
that table and the thinking of the developers over the last x years or
so.
In most cases the volumes which you are actually working with mean
performance costs should not
be a major consideration in any case. A reasonsable assessment of what
volume you expect from your workflow on a per day basis and at peak
times gives some guidance as to whether you need to call on special tips
and tricks to handle the volume.
Most times the performance costs are minor compared to other costs such
as maintenance costs,
loss of opportunity to use new functionality costs, loss of performance
improvements by using standard buffers built into standard programs,
loss of performance improvements in standard programs (e.g. now the
virtual attribute is called twice, but next release that may change),
loss of audit trail/tracking/troubleshooting information,
upgrade costs - as the "old" method you use may be disallowed in the
next release (I've just been through
a bunch of support pack and release upgrades and have the scars to prove
it).
Nearly everywhere I see performance problems 8/9 times out of 10 a large
part of the cause is
badly written custom code - such as doing direct reads on large volume
tables like the change document tables
instead of using BAPIs and the like that often have buferring and
reasonability checks (like making sure you have
provided enough parameters) already built in.
So I'd advise you to code it the recommended way first - and use the
start conditions. Only move to check function modules if you have a
specific and measurable problem that can't be solved any other way. And
before you go to that length its worth putting a query into OSS checking
whether you have missed any other options you might call on to solve
your problem.
Hope that helps.
Regards,
Jocelyn
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Michael Pokraka
Sent: Thursday,20 January 2005 5:53 AM
To: SAP Workflow Users' Group
Subject: RE: 'How to' Workflow Macro Question
Ah... that is a good question. In theory, an attribute should only get
evaluated when it is read.
In practice however, I've found it to actually evaluate an object
attribute
twice on a 6.20 system: Once during instantiation and again when it is
queried.
So complex attributes can be bad.
On the other hand, sound design that's extensible, and where any
workflow
person can pick up what's going on is a good thing. Also, consider
whether
'expensive' is actually significant. If there are a handful of flows a
week for
something that takes 2 seconds, good design is preferred. If you're
creating
2000 documents/day that run a massive query, go with a check FM. You
might want
to consider overall design if it's really bad.
Cheers
Mike
--- "Rivera, Raul" <Raul.Rivera at absu.accenture.com> wrote:
> Thank you Mike & Jocelyn for your replies to this posting.
>
> You both suggested that I use an attribute for Start Conditions. That
is how
> we have used the start conditions for some of our workflows where the
> attribute being checked is a *real* property of the BOR object.
>
> The reason I have tinkered around with Check Function Modules is the
concern
> that creating an attribute for the purpose of evaluating complex start
> condition is "expensive". What I mean is that the code for your
attribute
> gets executed each and every time the object is instantiated in the
system
> -- whether by the workflow engine or what not. Is this a valid concern
and
> if so what are your thoughts?
>
> Thanks again,
> Raul
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
Behalf Of
> Dart, Jocelyn
> Sent: Tuesday, January 18, 2005 4:57 PM
> To: SAP Workflow Users' Group
> Subject: RE: 'How to' Workflow Macro Question
>
> Hi Raul,
> Firstly - I would always use Start Conditions (the new technique) in
> preference to check function modules (the old technique). If the
> conditions are seriously complex I sometimes use a virtual attribute
to
> work out the hard part,e.g. "ApprovalReqd" yes or no, and then include
> that in my start condition. Just a thought for another possible
> approach - but you know your scenario best.
>
> Secondly - to call an instance independent method, first create a
dummy
> object handle using the
> SWC_CREATE_OBJECT <object> <objecttype> <objectkey>
> statement but putting initial values e.g. space in your object key.
> You can then call your instance independent method correctly.
>
> Regards,
> Jocelyn
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
Behalf
> Of Michael Pokraka
> Sent: Tuesday,18 January 2005 8:16 PM
> To: SAP Workflow Users' Group
> Subject: Re: 'How to' Workflow Macro Question
>
> Hi Raul,
> Good question, something I've not had to do yet. Let us know if you
find
> out.
>
> However, a more elegant solution may be to use an attribute instead,
and
> evaluate that via start conditions. Either move the methods into
attribs
> or
> create a new one that calls the methods - depends on your design.
>
> This also makes it possible to move any potential hardcoding out of
your
> ABAP
> and into the condition; and the whole thing is easier to maintain
and/or
> add to
> in future.
>
> Cheers
> Mike
>
> --- "Rivera, Raul" <Raul.Rivera at absu.accenture.com> wrote:
>
> > Hello everyone,
> >
> > We are in 4.6c
> >
> > I am revising an existing custom workflow by moving most of its
> complex
> > start conditions from the workflow to a Check Function Module (FM).
> >
> > The 'start conditions' were built as a series of tasks and
conditions
> in the
> > WF that terminate the WF if a condition isn't met. As such, I would
> like to
> > REUSE the existing BOR methods in the Check FM.
> >
> > One such method is an instance INdependent synchronous method. For
> testing
> > purposes, I create an instance of the object, set the import
parameter
> value
> > and then execute the method (see the code snippet below). This
> approach is
> > ugly but it does give me the expected result.
> >
> > My question is
> >
> > How do you call an instance independent method from your check
> FM
> > without creating an object instance?
> >
> >
> >
> > SWC_CONTAINER container.
> > SWC_CREATE_CONTAINER container.
> >
> > * create an object instance
> > SWC_CREATE_OBJECT workItemObj 'WORKITEM' '000000599006'.
> >
> > * set the import parameter
> > SWC_SET_ELEMENT container 'Agent' initiator.
> >
> > * execute the BOR method
> > SWC_CALL_METHOD workItemObj 'ZGETAGENTORGUNIT'
> > container.
> > * read method export parameter
> > SWC_GET_ELEMENT container 'ErrorFlag' errorFlag.
> >
> > IF errorFlag EQ 'X'.
> > RAISE DO_NOT_START_WF.
> > ENDIF.
> >
> > Regards,
> > Raul Rivera
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
>
>
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list