<div class="gmail_quote">
<div>I have used ABAP Objects for almost everything I have done for the last 3 years or more. So now, if I have to use a SAP Business Object it's only for the initial triggering/conditions then when I have a template started, I instantiate a Class to provide me with all the attributes/methods/events that I want.</div>
<div> </div>
<div>Started doing this as a self improvement, and it still gives me things to think about, but I think it's clearer than SAP Business Objects.</div>
<div> </div>
<div>The other benefit I see, at this client (large international commodity co), where there are multiple projects going on around the world building their own solutions for common processes on multiple development systems. 1 project delegates the SAP Business Object and then another project can't, so they would need to include their methods/attributes/events in the first projects delegation, then you get into all sorts of issues. (Best to keep separate) (or is that encapsulated)?</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">---------- Forwarded message ----------<br>From: "Mike Pokraka" <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>><br>
To: "SAP Workflow Users' Group" <<a href="mailto:sap-wug@mit.edu">sap-wug@mit.edu</a>><br>Date: Mon, 21 Feb 2011 10:34:07 -0000 (GMT)<br>Subject: Re: ABAP Objects - Percent of WF'ers using ABAP OO?<br>
Hi Rick,<br><br>I know what you mean! Some theories I can offer based on my experiences:<br><br>- Learning curve: Although OO requires far less specialist WF knowledge<br>than BOR, there are still quite a few rules to work by.<br>
<br>- Skillset: Many people learnt ABAP as a secondary skill to build better<br>workflows. They have a handle on BOR and - no disrespect intended - the<br>concept of relearning OO terrifies them. In some ways rightly so, BOR is a<br>
bit more forgiving for people just muddling through. OO on the other hand<br>benefits from better programming skills, with the upshot of better quality<br>solutions.<br><br>- Installed base: Much SAP-delivered and custom-built functionality is<br>
already contained in BOR. People see it as a huge task to switch to OO,<br>but this is really just a chicken and egg scenario because it's easy to<br>port BOR to OO *if* you have good knowledge of WF-OO. (Hint: The Book v2.0<br>
will help with this!)<br><br>For anyone sitting on the fence, I say: just do it! There's no need to<br>make it a major undertaking, just tackle one thing at a time. As a rough<br>guideline, anything new gets developed in OO and anything requiring<br>
changes is ported where practical.<br><br>Have fun,<br>Mike<br><br></blockquote></div>