ABAP Objects - Percent of WF'ers using ABAP OO?

[Madgambler]

Mike, 

Interestingly that's where we disagree most. 

I don't believe it is in a client's interest to ignore any future adjustments of BOR functionality out of hand and branch out with an ABAP OO 'ported' version based on a snapshot of the current standard object. 

Unless, that is, they have good reason to assume the BOR object is unlikely to be changed and / or if it did they agree to consider the consequences and overhead of assessing any change and adapt their baseline accordingly. 

Granted BOR can hardly be considered as a very active area for development these days, but that being said SAP haven't come out and said they're done with it either.

Also I'm not really convinced you're essentially gaining much by shifting to ABAP OO unless you have very specific requirements with regards to dynamic behaviour that a delegated BOR object can't deliver. Being old school doesn't mean being incapable. 

And that for me is SAP's dilemma right there. They needed to introduce OO concepts to support XML container stuff and deal with correlation and abstraction with the advent of XI, now PI, especially to push Netweaver integration. 

But after they had achieved that in the ECC 6 upgrade there was little perceived need to replace BOR since it still functions perfectly well for many clients. 

And that's where the ambition and drive for change seems to have dried up. At least, from Walldorf anyway. 

Having said that, with enough tome, effort and resources I'm sure Workflow and ABAP OO are made for each other. And if enough 'homebrew' stuff is written it might eventually stir someone into action.

We live in hope and press on. 

Mike GT

Sent from my iPhone

On 21 Feb 2011, at 16:58, "Mike Pokraka" <wug at workflowconnections.com> wrote:

> Hi Rick,
> 
> If you have the time, feel free to rewrite, but usually I only do the
> needed bits as I go along. Porting BOR to OO to me falls under
> refactoring. If you have a good framework in place, it's hardly worthwhile
> working with BOR because most BOR methods can be ported in under an hour -
> time easily saved later on through easier debugging, testing,
> enhanceability, better coding standards, less macros/specialized
> knowledge., etc.
> It may take longer to port if you see it as an opportunity for improvement
> - which is usually the case :-)
> 
> Regarding OO versions of SAP's BOR objects, this is entirely up to each
> individual application team within SAP, since they develop and own the
> objects. e.g. ESS, MSS and a few other HR bits have been replaced by OO,
> but one of the newer HR components, LSO, has some dubious BOR objects that
> make me wonder how they got past QA.
> MM and SD is still mostly BOR. I think there is an OO purchase order
> class, but it's implemented as a local class so no good to you.
> 
> Regards,
> Mike
> 
> On Mon, February 21, 2011 1:52 pm, Sample, Rick wrote:
>> Hi Mike, Mike and all,
>> 
>> I bit the bullet and started a re-write using as much OO and new features
>> of WF (ECC6, like WF Program Exists, local events, etc.) as practical.
>> 
>> First, I had to relearn OO. I have a Java background, but was just getting
>> to the point of being productive before we switched to SAP. And that was
>> 10 years ago, so a refresher with ABAP OO and what's available out of the
>> SAP box was required.
>> 
>> Learned enough ABAP OO to fumble around, then how to muck around and make
>> something work with WF with some tutorials, "next" is to start the design
>> of my app.
>> 
>> That brings me to some critical decision points. (Remember, this is just
>> me. No team, business folks doing blueprinting, etc.)
>