BOR and Perfmance

Mon Jul 26 02:11:49 EDT 2004

Rather than commit work and wait or 5 seconds delay, if you have a WAS (6.20) system consider using the work item conditions instead - i.e. do not start work item until condition is true...
Jocelyn

-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Soady, Phil
Sent: Wednesday,21 July 2004 12:56 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: BOR and Perfmance

My view.... if you are interested...

A) If virtual attributes are programmed properly...
ie change of object onsidered,  then all should be fine.
Clean macros etc are useful.

Virtual attributes or even the auto code gen  db ones are
declared as  globals and passed via macros to FUGR SWCD.
So while you have aN OBJECT HANDLE the fugr is still loaded
so it can return your attributes.

Few bother to code methods properly. :-( (im lazy too)
The macors are just abap code, worth a look around in <object> and <cnt01>
plus the FUGR SWCD if you want to know more.
Set a break point or even run an SE30 trace.
You will see how it works.

b) Commits and methods, ....
if you are calling out of control LUWs
I would also wait for the dust to settle before going on
  (ie = commit and wait).  Always some risk here but there are tricks. ie
retry restart code that can be added to a redefined method with a commit work so it can be robust. Nonetheless to be avoided if possible.

c) 5 second delays helping...
The update was pending (most likely), in a separate unit of work, so the wf which can NOT see the DB records of an uncommitted transaction, reads the old version.  Wait x seconds allows the asynchronous method to complete... most of the time....VERY ugly  bug waiting to happen ;-( I had to solve this one at customer once.  I ended up using 1 min waits and the event queue.

If your code/WF is dependent on the result, you may need to use commit and wait.

The dependent update design issue? Take a look at what is required when and re-asses the code and workflows. Follow on methods access the same data are
a trap when asynch changes are involved.
Redefined methods with waits or waits in the WF is a way forward.

There are a number of tricks... enqueue before use, a method call to read and verify data is posted etc.  There has been much written in the WUG on this topic over the years...
Take a search of the archives.

eg use of wait events and have an event trigger when the update is complete.

good luck and happy macroing.

Phil Soady
Senior Consultant
Business Technologies
SAP Australia
M  +61 (0) 412 213 079
E  phil.soady at sap.com

-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Easin Muttaqi
Sent: Tuesday,20 July 2004 11:13 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: BOR and Perfmance

Hi

I am sharing my experiences.

Recently, I have developed a number of WFs based on BUS2088, BUS2007,
BUS2038, EQUI, DRAW etc. objects. The WI recipient is supposed to change the
status (system, user or document) which then determines the next action to
be performed, if any, or return to the recipient. In number of cases, even
after changing the status it returned to the recipient without performing
the required action. Then again when the Order (or document) was saved
without changing the status (as the status was changed in the prior save)
this time the desired action was performed.

Consequently, I introduced a '5-seconds-delay Task' after the 'Edit Task'
and then checked the status. This has resolved my problem.

My conclusion is that if there is a data base update then the system
re-instantiate BOR but probably based on some indicator which is activated
only after data base update and this indicator activation process is
performed asynchronously after the DB commit.

Introducing the '5-seconds-delay Task' has solved my problems in all the
workflows.

Regards.
Easin Muttaqi
SAP IS-A&D - Saudi ARAMCO
-----Original Message-----
From: SAP Workflow [mailto:owner-sap-wug at MITVMA.MIT.EDU] On Behalf Of Mark
Huffman
Sent: Monday, July 19, 2004 10:57 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: BOR and Perfmance

Hi Alon,

If I am troubleshooting some very bad method code where the original
programmer tries to do several different things inside of one method and has
commits all over the place, what would you recommend? Often this type of
code is assoicated with intermittent (and sometimes frustratingly so)
runtime problems.

As for your original issue, I was under the impression that you could not
rely on a database refresh eg. the instance is resused as you put it, if for
example attribute values were updated, and you always needed to force a
refresh to be sure that you were reading the latest data.

Mark
----- Original Message -----
From: "Alon Raskin" <araskin at 3i-consulting.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Monday, July 19, 2004 3:09 PM
Subject: Re: BOR and Perfmance

> Hi Mark,
>
> I am all for the use of swc_refresh_object. I am a bit surprised about the
> COMMIT WORK AND WAIT though because I was under the impression that it was
a
> cardinal sin to do a COMMIT WORK inside a method (since the Workflow
> sub-system does one for you). I would be interested in hearing what people
> have to say about that one.
>
> What I was trying to find out in the previuos post is whether an instance
> lives is reused in subsequent steps of a workflow or is it re-instantiated
> every time? From what I gathered from Michael, as long as the advance with
> dialog flag is checked then the instance is reused (which is good).  I
hope
> this holds true for tasks that are running under WF-BATCH in background?
>
> Alon
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Mark
> Huffman
> Sent: 19 July 2004 20:02
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: BOR and Perfmance
>
> Alon and Mike,
>
> I have done a lot of production support jobs in the past few years and in
> general have often used swc_refresh_object SELF to tidy up custom methods
> that were making timing assumptions and causing errors.
>
> These days I try to avoid using 'commit work and wait' in background
posting
> methods, but sometimes resort to that as well, especially where the code I
> am trying to troubleshoot has commits sprinkled all through it.
>
> Mark
>
>
> ----- Original Message -----
>> From: "Michael Pokraka" <workflow at quirky.me.uk>
> To: <SAP-WUG at MITVMA.MIT.EDU>
> Sent: Monday, July 19, 2004 1:39 PM
> Subject: Re: BOR and Perfmance
>
>
> Hi Alon,
> I think in theory if 'advance with dialog' works then it would also retain
> the object instance.
> In practice however it just goes plain weird. I had an issue on 4.6c with
a
> virtual attribute that didn't have a 'CLEAR' after the 'DATA' statement.
Not
> strictly necessary one may think...
> WRONG! The attribute was used in the inbox description. Displaying it and
> then clicking on another workitem which DIDN'T have a value for that
> attribute would show the previous item's attribute value. So somehow it
was
> buffered across instances when using the inbox.
> I asked OSS about the theory/mechanics behind this without much success.
>
> Could I also add to the original question the idea of a Persistent Object
> Reference in this context... does that improve buffering or make it worse?
>
> Cheers
> Mike
>
> Alon Raskin wrote:
> > Hi Everyone,
> >
> > I trust that everyone had a good weekend.
> >
> > One of the nice things about the BOR is the buffering approach that it
> > provides. When you first access a Dictionary attribute, the whole
> > record
> is
> > retrieved and stored in a structure so any subsequent accesses to
> Dictionary
> > attributes do not result in a call to the DB.
> >
> > My query is: Between two steps of a workflow, are all the BOR object
> > instances re-instantiated? I got the feeling that they were but was
> unsure.
> > If that is the case then doesnt that defeat the whole purpose of the
> > buffering approach?
> >
> > I look forward to your thoughts/comments.
> >
> > Alon
> >
> >
>
>