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

Mon Feb 21 13:55:05 EST 2011

Hi Mike,

Sounds practical enough. Needed to ask to ensure I didn't miss something. 

Since I use very little SAP code in most BORs anyway, I 'initially' planned to just refactor what I needed when it was time. Then I started reading "ABAP Objects: Application Development from Scratch" and he was going over the topic with UML objects like ORDER a super class of SALES ORDER object, etc. That sounds more like a LSD or an internal SAP design than something required for my WFs. 
Nice overall ABAP OO book... maybe 20k foot view though. 

Thanks much all, time to go break something ...
Rick

p.s.
Still waiting for my boss to get me the book. "Practical Workflow for SAP (2nd Edition)" 

> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Mike Pokraka
> Sent: Monday, February 21, 2011 10:59
> AM
> To: SAP Workflow Users' Group
> Subject: RE: ABAP Objects - Percent of
> WF'ers using ABAP OO?
> 
> 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.) I looked at
> > many SWT* packages. They are mostly
> too simple to even think about
> > using for anything.
> > So how much BOR to push aside and
> what needs to be written from scratch.
> > Most of the BORs are really not
> complicate (when you have a couple
> > years under your belt) so re-writing
> BUS2032 is not 'really hard'.
> > What I still do not know is, does SAP
> have equivalents ABAP OO objects
> > to BORs. ? Like, is there already a
> ABAP OO of BUS2032? Or, is there a
> > class higher up called Orders that is a
> super class of Sales Order,
> > etc. Or do we have to build from
> scratch? (I am waiting for the book,
> > so if all answers are there, just tell me)
> >
> > For just me at this point, using the Agile
> approach sounds like best
> > approach. Design, write, test... refactor,
> write, test, refactor... etc.
> > After reading and some more reading, I
> am already thinking my classes
> > can be split out to more wide casting
> higher in the class hierarchy.
> >
> > You know, when I look at the WF SWT*
> packages, it looks like the
> > examples that were in BOR. An
> afterthought!
> > Rick
> >
> >
> >
> >
> >
> > I don't want to be in the very front
> crossing this river and get eaten
> > by the crocodile. And, I don't want to be
> all the way in the rear,
> > where the lions clean up the old and
> weak. I want to be somewhere in
> > the middle of the herd with the numbers.
> (I won't have to run fast,
> > just faster than <him> to avoid getting
> eaten alive.)
> >
> > From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On
> > Behalf Of Mike Gambier
> > Sent: Monday, February 21, 2011 5:56
> AM
> > To: sap-wug at mit.edu
> > Subject: RE: ABAP Objects - Percent of
> WF'ers using ABAP OO?
> >
> > Hi all,
> >
> > Mind if I chip in? Mike and I have been
> having a good old discussion
> > about this since we currently sit in front
> of each other (and since
> > our Production system just died I have
> some free time...).
> >
> > As most of us here are aware, ABAP
> OO is hard to avoid these days
> > especially if you're working on certain
> technologies, e.g Web UI.
> >
> > But I think that the overall number of
> BOR/Workflow savvy people who
> > are chossing to cross-train/upskill and
> learn ABAP OO stuff with a
> > view to building Workflow stuff using it is
> likely to be very low indeed.
> >
> > Ceratinly here for our client, the number
> is 0%. Zip, nada, rien.
> >
> > One of the biggest drawbacks to building
> SAP Business Workflow based
> > on ABAP OO concepts is that it is so
> damned hard to do so when there
> > exists the enromous temptation to fall
> back on tried and trusted BOR
> > techniques that are so much easier and
> cheaper to build and are known to work.
> >
> > Simply put, the benefits of making the
> switch don't stack up when you
> > are forced to build to the lowest
> common denominator, the humble ABAP
> coder.
> >
> > If SAP truly wanted to push Workflow
> developers away from BOR and
> > towards ABAP OO they would have
> defined a BOR '2' framework to show
> > the way, but they didn't and don't show
> any signs of doing so for that matter.
> >
> > Instead, they shifted their focus to the
> Java stack and started
> > selling SAP CE instead, which uses a
> 'proper' OO language rather than
> > ABAP OO. Of course now that Oracle
> has bought Sun (and is merrily
> > killing it), you never know, SAP may
> decide to stop investing in this
> > area entirely and we might see another
> shift in direction...
> >
> > And before anyone says it, no, I don't
> believe that ccBPM really
> > counts as an alternative - the idea of a
> 'dark' Workflow process
> > running on the ABAP stack of a PI box is
> just plain daft and in
> > practice it's routinely overlooked for
> serious volumes.
> >
> > As a result of this apparent modelling
> vacuum the following appears to
> > have happened as far as I can see:
> >
> > 1. Any ABAP OO Workflow stuff now
> ends up being boiled down to an
> > entry point for some sort of ABAP OO
> processing stuff rather than as
> > part of a full-blown end-to-end Business
> Process modelled using ABAP OO
> concepts.
> >
> > 2. Few people want to learn BOR stuff
> because it now appears to have a
> > short shelf-life and looks decidedly old
> school.
> >
> > 3. Only people like us are concerned.
> >
> > Regards,
> >
> > Mike GT
> >
> >> Date: Mon, 21 Feb 2011 10:34:07
> +0000
> >> Subject: Re: ABAP Objects - Percent
> of WF'ers using ABAP OO?
> >> From: wug at workflowconnections.com
> >> To: sap-wug at mit.edu
> >>
> >> Hi Rick,
> >>
> >> I know what you mean! Some theories
> I can offer based on my experiences:
> >>
> >> - Learning curve: Although OO
> requires far less specialist WF
> >> knowledge than BOR, there are still
> quite a few rules to work by.
> >>
> >> - Skillset: Many people learnt ABAP as
> a secondary skill to build
> >> better workflows. They have a handle
> on BOR and - no disrespect
> >> intended - the concept of relearning
> OO terrifies them. In some ways
> >> rightly so, BOR is a bit more forgiving
> for people just muddling
> >> through. OO on the other hand
> benefits from better programming
> >> skills, with the upshot of better quality
> solutions.
> >>
> >> - Installed base: Much SAP-delivered
> and custom-built functionality
> >> is already contained in BOR. People
> see it as a huge task to switch
> >> to OO, but this is really just a chicken
> and egg scenario because
> >> it's easy to port BOR to OO *if* you
> have good knowledge of WF-OO.
> >> (Hint: The Book v2.0 will help with this!)
> >>
> >> For anyone sitting on the fence, I say:
> just do it! There's no need
> >> to make it a major undertaking, just
> tackle one thing at a time. As a
> >> rough guideline, anything new gets
> developed in OO and anything
> >> requiring changes is ported where
> practical.
> >>
> >> Have fun,
> >> Mike
> >>
> >> On Fri, February 18, 2011 8:48 pm,
> Sample, Rick wrote:
> >> > Hi all,
> >> >
> >> > I scanned here and SDN WF blogs
> and I really don't see a whole lot
> >> > of
> >> OO
> >> > activity for WF. I am wondering if it is
> the learning curve,
> >> > staffing, budget, lack of interest, or
> other. Since WF developers
> >> > are about what
> >> ...
> >> > 1 of 50 ABAP'ers, I would assume
> the ABAP OO to be orders of
> >> > magnitude larger in number of posts.
> Just the opposite.
> >> >
> >> > Any numbers on what percent is
> using:
> >> > sticking with 4.6c BOR,
> >> > phasing in ABAP OO with WF for
> new projects and re-writes, (This is
> >> our
> >> > plan so far. Not implementing full
> BPM tools etc.) other BPM tools,
> >> > something else?
> >> >
> >> > Any of this data available from SAP
> with regards to who and how
> >> > many
> >> are
> >> > moving to <what?> Recent blogs on
> this subject? etc. etc.
> >> >
> >> > As always, you may contact me
> directly.
> >> >
> >> > Rick Sample | SAP Workflow
> Analyst/Developer
> >> > Rick.Sample at Graybar.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> __________________________________
> _____________
> >> > SAP-WUG mailing list
> >> > SAP-WUG at mit.edu
> >> >
> http://mailman.mit.edu/mailman/listinfo/sap
> -wug
> >> >
> >>
> >>
> >>
> __________________________________
> _____________
> >> SAP-WUG mailing list
> >> SAP-WUG at mit.edu
> >>
> http://mailman.mit.edu/mailman/listinfo/sap
> -wug
> >
> __________________________________
> _____________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> >
> http://mailman.mit.edu/mailman/listinfo/sap
> -wug
> >
> 
> 
> __________________________________
> _____________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap
> -wug