<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
&nbsp;<BR>
Alon,<BR>
<BR>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&nbsp;a Workflow deadline job. <BR>
&nbsp;<BR>
<!--StartFragment --><!--StartFragment -->&nbsp;
<STYLE type=text/css>
SPAN {
font-family: "Courier New";
font-size: 10pt;
color: #000000;
background: #FFFFFF;
}
.L1S31 {
font-style: italic;
color: #0000FF;
}
.L1S52 {
color: #A52A00;
}
</STYLE>
<SPAN><SPAN class=L1S31>*-&nbsp;execute&nbsp;BPE&nbsp;deadlines</SPAN><BR>&nbsp;&nbsp;<SPAN class=L1S52>perform</SPAN>&nbsp;execute_deadline_bpe&nbsp;<SPAN class=L1S52>using</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;lh_queue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class=L1S52>changing</SPAN>&nbsp;l_count_bpe.<BR>&nbsp;&nbsp;l_count&nbsp;=&nbsp;l_count&nbsp;+&nbsp;l_count_bpe.<BR><BR><SPAN class=L1S31>*-&nbsp;execute&nbsp;BWF&nbsp;deadlines</SPAN><BR>&nbsp;&nbsp;<SPAN class=L1S52>clear</SPAN>&nbsp;l_task.<BR>&nbsp;&nbsp;<SPAN class=L1S52>call</SPAN>&nbsp;<SPAN class=L1S52>method</SPAN>&nbsp;lh_queue-&gt;set_filter(&nbsp;im_task&nbsp;=&nbsp;l_task&nbsp;).<BR>&nbsp;&nbsp;<SPAN class=L1S52>perform</SPAN>&nbsp;execute_deadline_bwf&nbsp;<SPAN class=L1S52>using</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;lh_queue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class=L1S52>changing</SPAN>&nbsp;l_count_bwf.<BR><BR>&nbsp;&nbsp;l_count&nbsp;=&nbsp;l_count&nbsp;+&nbsp;l_count_bwf.</SPAN> <BR>
&nbsp;<BR>
Now the same program has to do both. For obvious reasons I suppose since XI Business Process Management is&nbsp;supposedly non-dialog version of Workflow. No option, no choice. Can't skip the subroutine call even if we wanted to without a mod.<BR>
&nbsp;<BR>
When I last saw XI, by the way, I was amused to see that they had hacked their own&nbsp;Workflow Builder and created a clone version (I kid you not)&nbsp;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! <BR>
&nbsp;<BR>
Pity they forgot to prevent SWDD from being used to change <STRONG>exactly</STRONG> 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&nbsp;:) He then back-tracked and said it shouldn't be done that way...er...riiiight.<BR>
&nbsp;<BR>
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?<BR>
&nbsp;<BR>
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. <BR>
&nbsp;<BR>
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?<BR>
&nbsp;<BR>
As far as the 'persistence' thing goes, you may have noticed&nbsp;SAP have&nbsp;added new Version-Dependent and Version-Independent settings at the WF&nbsp;definition level. One of the dependent settings&nbsp;is called the Persistence Profile. It's the one that specifies which flavour of container a Workflow uses. <BR>
&nbsp;<BR>
By default it has a friendly 'Compatibilty Mode' setting which I <EM>think</EM> makes use of either of&nbsp;Containers deciding which one to use based on the release the WF Definition belongs to. The help text SAP gives on this settings says:<BR>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<EM>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.</EM><BR>
<EM></EM>&nbsp;<BR>
<EM>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.</EM><BR></BLOCKQUOTE>
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.<BR><BR>
Regards,<BR>
&nbsp;<BR>
Mike GT<BR>
<BLOCKQUOTE>
<HR>
From: araskin@3i-consulting.com<BR>To: sap-wug@mit.edu<BR>Date: Thu, 20 Mar 2008 09:29:00 -0400<BR>Subject: RE: Performance of OO vs BOR as used in WF<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding-right:0px;padding-left:0px;padding-bottom:0px;padding-top:0px;}
.ExternalClass EC_BODY.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>

<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=tahoma>Can you share some of the main reasons&nbsp;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.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=tahoma>What do you mean by <EM>tweak the WF persistence</EM>? Do you mean changing from XML to the old approach in the WF Header?</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=tahoma><FONT face=tahoma>Alon</FONT></FONT></DIV>
<DIV>
<DIV><FONT face=Tahoma size=2>
<P class=EC_MsoNormal><STRONG><B><FONT face=Calibri color=navy size=3><SPAN style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri"></SPAN></FONT></B></STRONG>&nbsp;</P>
<P class=EC_MsoNormal></P>
<P class=EC_MsoNormal><B><FONT face="Times New Roman" color=navy size=3><SPAN style="FONT-WEIGHT: bold; FONT-SIZE: 12pt; COLOR: navy"></SPAN></FONT></B></P></FONT>
<HR>
<FONT face=Tahoma size=2><B>From:</B> sap-wug-bounces@mit.edu [sap-wug-bounces@mit.edu] On Behalf Of Mike Gambier [madgambler@hotmail.com]<BR><B>Sent:</B> Thursday, March 20, 2008 5:59 AM<BR><B>To:</B> SAP Workflow Users' Group<BR><B>Subject:</B> RE: Performance of OO vs BOR as used in WF<BR></FONT><BR>
<BR>Alon,<BR>&nbsp;<BR>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&nbsp;ABAP Class objects, is likely to be&nbsp;slower and more memory-hungry then the 'old' 4.6c version, not faster.<BR>&nbsp;<BR>The number of instances involved to invoke a simple RFC FM call (which is what <U>still</U> happens when executing a Task&nbsp;in the end) is staggering when you debug through it all.<BR>&nbsp;<BR>Also, eventhough we do not use XI,&nbsp;the new Workflow&nbsp;code&nbsp;invariably tries to&nbsp;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 :(<BR>&nbsp;<BR>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.<BR>&nbsp;<BR>By the way, I still have an OSS note outstanding about the Logical System name (SWW_CONTOB-LOGSYS)&nbsp;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.<BR><BR>Regards,<BR>&nbsp;<BR>Mike GT<BR></DIV></DIV>
<DIV>
<BLOCKQUOTE>
<HR>
From: araskin@3i-consulting.com<BR>To: sap-wug@mit.edu<BR>Date: Wed, 19 Mar 2008 12:08:30 -0400<BR>Subject: Performance of OO vs BOR as used in WF<BR><BR>
<STYLE title=owaParaStyle>
.ExternalClass P
{margin-bottom:0px;}
</STYLE>

<DIV dir=ltr>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&nbsp;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.</DIV>
<DIV dir=ltr><FONT face="times new roman"></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face="times new roman">
<DIV dir=ltr><FONT face="times new roman">
<DIV dir=ltr><FONT face="times new roman"><FONT face="times new roman">Alon</FONT></FONT></DIV></FONT></DIV></FONT></DIV></BLOCKQUOTE><BR>
<HR>
Everything in one place. <A href="http://www.windowslive.co.uk/get-live" target=_blank>All new Windows Live!</A> </DIV></BLOCKQUOTE><br /><hr />She said what? About who? <a href='http://www.msnsearchstar.com' target='_new'>Shameful celebrity quotes on Search Star!</a></body>
</html>