Performance of OO vs BOR as used in WF

[Mike Pokraka]

Hi Rick,

To be truthful.... none. But then I have had some OO exposure in a pre-SAP
lifetime.

The two most important bits of knowledge are the principles of OO (why are
we doing this) and understanding workflow's OO quirks. Your old book
should do nicely for the first part; and for the second, getting your
hands dirty is about the best way to go about it. Of course the most
recent OO guide from SAP press would come in handy (planning to have a
look at it at ASUG), but our job is to avoid delving too deep into coding.

The OO forum on SDN still has relatively low noise levels with a few
knowledgeable folk on board.

Cheers,
Mike


On Mon, March 24, 2008 7:06 pm, Sample, Rick wrote:
> Hey Mike,
>
> We will be moving to ECC6 on our business side soon. With our HR move,
> we barely had time to stomp out conversion bugs much less roll
> the sleeves up and explore the new ABAP objects.
>
> I have an old ABAP Objects book collecting dust. But, when we get there
> I would like to have my resources available.
>
> What SAP OO books are on your self?
>
> Rick Sample
> SAP Business Workflow Developer
> Graybar, Inc.
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Mike Pokraka
> Sent: Friday, March 21, 2008 4:22 AM
> To: SAP Workflow Users' Group
> Subject: Re: Performance of OO vs BOR as used in WF
>
> Hi Alon,
>
> Short answer:
> OO has the potential to be a lot more efficient, but it's your
> responsibility to realize the potential.
>
> Long answer:
> The beauty of classes is that the answer to this question is in the
> hands
> of the developer. In a pure BOR vs OO context, there is very little
> difference in the internal WF code. Everything is accessed via Local
> Persistent Object References (LPOR).
>
> The difference is that BOR has a fixed overhead (SWC_CREATE_OBJECT) that
> you cannot change or control. With OO, the WF system simply calls
> BI_PERSISTENT~FIND_BY_LPOR. What you put in there is up to you. You can
> have a SELECT for each instantiation or you can implement a more
> efficient
> buffered instance management.
> You can even get really clever and pre-select data you need for other
> instances so that one SELECT serves multiple objects.
>
> Whilst the BOR instance management is reasonably efficient, it is still
> an
> old cludge to make a procedural language object oriented, so will
> defeinitely have some performance drawbacks that are not necessary or at
> the very least cam be avoided in some cases. e.g. it will always do a
> "SELECT *" for all DB attributes and the key table, whereas you can
> implement a "SELECT <fields you need>" in your OO class.
>
> Cheers,
> Mike
>
>
> On Wed, March 19, 2008 4:08 pm, Alon Raskin wrote:
>> I am curious if anyone has run any tests to see whether performance is
>> different when using OO container elements (class instances) as
> opposed to
>> BOR (object type instances). My gut feel is that OO would be faster
> due to
>> the reduced overhead of not using those BOR macros but I am curious if
>> anyone has actually done the comparison.
>>
>> Alon
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>