Performance of OO vs BOR as used in WF

[Mike Gambier]

Alon,
Go look at the RSWWDHEX_INTERNAL and find 'BPE' as a string. It's a classic example of how SAP has snuck in XI functionality into what used to be exclusively a Workflow deadline job. 
 
 

*- execute BPE deadlines  perform execute_deadline_bpe using    lh_queue                               changing l_count_bpe.  l_count = l_count + l_count_bpe.*- execute BWF deadlines  clear l_task.  call method lh_queue->set_filter( im_task = l_task ).  perform execute_deadline_bwf using    lh_queue                               changing l_count_bwf.  l_count = l_count + l_count_bwf. 
 
Now the same program has to do both. For obvious reasons I suppose since XI Business Process Management is supposedly non-dialog version of Workflow. No option, no choice. Can't skip the subroutine call even if we wanted to without a mod.
 
When I last saw XI, by the way, I was amused to see that they had hacked their own Workflow Builder and created a clone version (I kid you not) which prevented you from adding dialog steps to any BPE Workflow defintion. Literally it was presented as a special XI Workflow Builder with its own ridiculously long Transaction name! 
 
Pity they forgot to prevent SWDD from being used to change exactly the same definitions - the Trainer guy was so adamant that I couldn't add a Decision Task that I had to show him that it could be done by changing his own definition in front of him :) He then back-tracked and said it shouldn't be done that way...er...riiiight.
 
By the way, I've heard some nasty rumours about XI running at high volumes too, but that could be for lots of reasons and I doubt ABAP Classes are the cause there. Perhaps someone here knows different or could comment?
 
We have been commissioned to perform a 'technical upgrade' only. No reverse engineering. No surprises. No use of new functionality unless it is essential. So, ideally the plan is that our 'inflight' Workflow instances should wake up and not know anything has changed. 
 
Similarly a lot of our custom code that accesses SWW_CONTOB must also continue to work, so no OO container for us, at least to start with. God knows how hard it must be to query massive tables using WAPIs all the time? Anyone here tried?
 
As far as the 'persistence' thing goes, you may have noticed SAP have added new Version-Dependent and Version-Independent settings at the WF definition level. One of the dependent settings is called the Persistence Profile. It's the one that specifies which flavour of container a Workflow uses. 
 
By default it has a friendly 'Compatibilty Mode' setting which I think makes use of either of Containers deciding which one to use based on the release the WF Definition belongs to. The help text SAP gives on this settings says:

This setting is applicable to all workflows that were not created in this release. The data is stored in the conventional container tables. You can still execute your own programs that contain these tables.
 
This setting corresponds to the setting Structure persistence. You should check whether you can choose the setting XML Persistence. This enables you to benefit from the new container and improve the performance of the workflow execution.
We will be using 'Structure Persistence' everywhere to make our WFs always rely on SWW_CONTOB, at least for now. Even if we start using new definitions that come delivered as part of ECC 6.0.
Regards,
 
Mike GT


From: araskin at 3i-consulting.comTo: sap-wug at mit.eduDate: Thu, 20 Mar 2008 09:29:00 -0400Subject: RE: Performance of OO vs BOR as used in WF



Thanks Mikey. I am surprised about the XI stuff. While most sites wont worry about this I would guess that a lot of the high volume WF sites (like yours) would.
 
Can you share some of the main reasons why you guys plan to not use the OO container stuff? On my current project, I am contracting to SAP US so I may be able to get access to some of the internal SAP resources. I could possible raise this with them and see what they say.
 
What do you mean by tweak the WF persistence? Do you mean changing from XML to the old approach in the WF Header?
 
Alon


 



From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier [madgambler at hotmail.com]Sent: Thursday, March 20, 2008 5:59 AMTo: SAP Workflow Users' GroupSubject: RE: Performance of OO vs BOR as used in WF
Alon, We have no metrics yet but my gut feel overall is that the 'new' Workflow engine itself, which as you know is all based on ABAP Class objects, is likely to be slower and more memory-hungry then the 'old' 4.6c version, not faster. The number of instances involved to invoke a simple RFC FM call (which is what still happens when executing a Task in the end) is staggering when you debug through it all. Also, eventhough we do not use XI, the new Workflow code invariably tries to invoke BPE stuff (the Workflow part of XI) pretty much everywhere. Pity we can't set a flag somewhere in a config table and avoid this :( We don't plan to use the OO container to start with (for lots of reasons) but I do intend to tweak the WF Persistence profiles of a few of our definitions to see whether there's any improvement or impact. So, if I find anything out I'll be sure and post it here. By the way, I still have an OSS note outstanding about the Logical System name (SWW_CONTOB-LOGSYS) not being updated in the 'old' BOR Container table. We're pretty concerned about that as some of our instances are client-sensistive and complain if this field is blank.Regards, Mike GT



From: araskin at 3i-consulting.comTo: sap-wug at mit.eduDate: Wed, 19 Mar 2008 12:08:30 -0400Subject: Performance of OO vs BOR as used in WF


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

Everything in one place. All new Windows Live! 
_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox. 
http://www.searchgamesbox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080320/4fc815ec/attachment.htm