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

[Sample, Rick]

Hi Mikes,

>From all I have read, and that's quite a bit. BOR was never intended to be the model for object oriented design. And indeed states that in its own SAP Help files. "The BOR object model will be integrated into ABAP Objects in the next Release by migrating the BOR object types to the ABAP class library." http://help.sap.com/saphelp_nw2004s/helpdata/en/c3/225b5654f411d194a60000e8353423/frameset.htm
Sounds fairly straight forward to me. But as of yet, not so integrated. 

My reading / translation, all standard BORs will be rolled up into ABAP Objects, ported over with something like cl_BUS2032. 

Hate to sound like the kids in the back seat, asking if we are there yet, but this is exactly the answers (direction) I am seeking. Where we going, when, how long will it take to get there, will there be ports (as stated in the help file), standards for mixing the two, etc. 
I understand, some have confidentiality clauses. (Just tell me. I promise, I won't tell anyone)

Any recent official word from SAP on this subject? If we know, we know. If we are still winging it (SAP that is) and checking the wind direction, that's cool too. I understand, it's a BIG ship. But I am sure there are several others that would start if better direction from SAP. 

As far as BOR goes, anyone who will work in our WF dept, MUST have BOR experience at this point in time. That's not going away any time soon because of all the BOR code that we have developed. And until I am 100% confident that I can bang out something quick in ABAP Objects, if a high priority comes down the pipe line, it will most likely be written in BOR. 

Rick


> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Madgambler
> Sent: Monday, February 21, 2011 12:48
> PM
> To: SAP Workflow Users' Group
> Cc: SAP Workflow Users' Group
> Subject: Re: ABAP Objects - Percent of
> WF'ers using ABAP OO?
> 
> 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.)
> >
> 
> __________________________________
> _____________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap
> -wug