Off-topic ABAP OO Workflow Object...

Thu Oct 16 18:08:50 EDT 2003

Hi Alon and those interested.

AS of 6.x you may have noticed an extra field next to Object and Method
and is the type of object. In 6.2 systems on BOR object is possible.
The option to enter ABAP OO is turned off. This was the "OLDER" version of running ABAP OO classes as objects I was referring to.
Since so much was added at the basis level I see very little chance for this to be back ported to 4.6.

A small number or controlled projects have used it.
I don't know which ones and its only via support from the development group. See OSS notes on Support if interested.

For the rest of we must wait until we have a 6.4 basis system.
That's not that far away. Not sure on the "official" dates but Im guessing end 2004. (disclaimer..blah blah...)

The bigger picture is looking awesome.
The new PC-UI and Web Dynpro ,
improvements in the Universal Workflow list,
and XI 3.0 using Business Process modelling.
BPM is WORKFLOW on STERIODS for the messaging hub.

The Workflow world is about to play a MUCH BIGGER ROLE than those
ignoring it may expect.

I personally expect that once we have 6.4 kernels, XI with BPM
and WEB-DYNPRO / PC-UI that workflow projects will represent
one of the best if not THE best chance for companies to provide
great, people centric tools that really do improve processes,
and add value to systems.

'Flowers Rule ! [not the pansy variety :-)]

Phil Soady
Senior Consultant - Business Technologies
Professional Services
SAP Australia
Level 1, 168 Walker Street, North Sydney 2060, Australia.
M   +61 412 213 079
E   phil.soady at sap.com

-----Original Message-----
From: Alon Raskin [mailto:araskin at 3i-consulting.com]
Sent: Friday, October 17, 2003 6:21 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Off-topic (Re: Great news: Container elements as structure in 6.2 0)

I agree with Phil. This change is truly an exciting one for us as SAP
Workflow developers. The possibility of implementing true polymorphic
behavior in our code should benefit our customers by promoting reuse and
ease of maintenance.

Phil, there are no plans to retrofit this to earlier versions of SAP?

Alon Raskin

3i-consulting Group

e: araskin at 3i-consulting.com

w: http://www.3i-consulting.com <http://www.3i-consulting.com/>

-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Soady,
Phil
Sent: Thursday, October 16, 2003 9:17 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Off-topic (Re: Great news: Container elements as structure in
6.2 0)

Oh... I was just starting to enjoy the thread .

My Extra info... AS of 6.4 ABAP OO classes are released officially

for use as the "object" behind a task. (With a mod it is possible
unsupported in 6.2).

Allowing All tasks to be based on ABAP OO instead of

weird (bc610) Macro programming.

This opens things up. The every changing skill set map will expect

ABAPers become ABAP OO aware to support workflow.

Time to take a look at BC401 ?

Cheers

Phil Soady

Senior Consultant - Business Technologies

Professional Services

SAP Australia

Level 1, 168 Walker Street, North Sydney 2060, Australia.

M   +61 412 213 079

E   phil.soady at sap.com

-----Original Message-----

From: Dart, Jocelyn

Sent: Wednesday, October 15, 2003 6:23 PM

To: SAP-WUG at MITVMA.MIT.EDU

Subject: Re: Off-topic (Re: Great news: Container elements as structure in
6.2 0)

Yes I think that's enough now...

Hopefully it's given some of the other SAP-WUGers who may not have had to
deal with this a little more insight into the great ABAP programmer versus
workflow programmer debate.

And I agree with you all - design purity is great but sometimes reality has
a nasty habit of messing with your head.

Madrid sounds lovely!

Regards,

        Jocelyn Dart

Consultant (SRM, EBP, Workflow)

and co-author of the book

"Practical Workflow for SAP"

SAP Australia

email: jocelyn.dart at sap.com

phone: +61 412 390 267

fax:   +61 2 9935 4880

-----Original Message-----

From: Zmudzin,Tomasz,FRANKFURT,Extern LG-DM
[mailto:Tomasz.Zmudzin at de.nestle.com]

Sent: Wednesday,15 October 2003 5:59 PM

To: SAP-WUG at MITVMA.MIT.EDU

Subject: AW: Off-topic (Re: Great news: Container elements as structure in
6.2 0)

Alon,

I would definitely agree with your advice -- just not in all scenarios. Just

consider a case in which the FM is not a three-liner, but a hook into a big

big development.

Hope this ain't going to start a holy war

-- yours,

Tomasz

-----Ursprungliche Nachricht-----

Von: Alon Raskin [mailto:araskin at 3i-consulting.com]

Gesendet: Mittwoch, 15. Oktober 2003 09:02

An: SAP-WUG at MITVMA.MIT.EDU

Betreff: Re: Off-topic (Re: Great news: Container elements as structure

in 6.2 0)

I have seen that sort of separation done quite a few times. The thing that

you have to watch for is efficiency. In the FM, the developer tends to

select all the data that they require but in the BOR instance, you have all

the data (usually buffered) already loaded. The obvious way around this is

to simply pass in all the data that they could need but that can sometimes

make for a very messy looking FM interface.

My opinion, is that the FM/BOR separation should only be done if it is

feasible/likely that the FM will also be called from other developments. If

you are doing it to 'save a couple of bucks' (by sending the FM coding

offshore) then you are simply making more work for yourself in the long term

in terms of maintenance/efficiency. I have seen it time and time again.

Regards,

Alon

Alon Raskin

3i-consulting Group

e: araskin at 3i-consulting.com

w: http://www.3i-consulting.com <http://www.3i-consulting.com/>

-----Original Message-----

From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of

Zmudzin,Tomasz,FRANKFURT,Extern LG-DM

Sent: Wednesday, October 15, 2003 7:55 AM

To: SAP-WUG at MITVMA.MIT.EDU

Subject: Re: Off-topic (Re: Great news: Container elements as structure in

6.2 0)

> "The point is where do you draw the line?"

How about:

1. The functionality you need is developed in ABAP by someone else -- but

encapsulated nicely in function modules. The ABAP developer does not touch

SWO1, but can test via FM testing, automate testing via CATT etc.

2. You do just the Business Object programming, just calling the function

modules & making sure the interface / value passing is right.

Would that not be a feasible separation of responsibilities?

Best regards,

Tomasz

-----Ursprungliche Nachricht-----

Von: Becker, Stephan [mailto:stephan_becker.ext at siemens.com]

Gesendet: Mittwoch, 15. Oktober 2003 08:15

An: SAP-WUG at MITVMA.MIT.EDU

Betreff: Re: Off-topic (Re: Great news: Container elements as structure

in 6.2 0)

Correct, Tomasz, I have no say in that as a freelancer, and guess what, I

don't even want to! That's one of the joys of being independent; you don't

have to acquire even more grey hair by worrying about circumstances and

decisions you might want and often need to take an active interest in as a

career-minded employee..

The actual situation is a bit different, with workflow knowledge spread so

thin that I have to concentrate on the absolute necessary, and "outsource"

all other stuff to colleagues..

Jocelyn, the efficiency lies in the fact that I just need to provide the

method frame, ie get stuff in/out of the container, and the pure-ABAPer does

the tedious bit in between, working with tables rather than objects..

I have actually done the RSEG with db attributes bit in order to replace the

admittedly inelegant structure-based solution -- although the latter looks

not so bad in a multi-level workflow with multiple dynamic parallel

processing steps ;-)

The point is where do you draw the line? To set up the whole shebang, I

would need BUS2081 extended by multiline object RSEG (new object, SAP still

doesn't deliver this, which seems strange), RSEG having a reference to the

PO, the PO item is yet another new development (beats me why this core

object still isn't there in 4.6C), and then we need EKES (vendor

confirmation), yet another new development, add to that new methods for

inbound delivery creation and populating BAPI tables to do a GR, and the

effort to create automatic inbound delivery and statistical good receipt for

third party business goes through the roof -- the structure solution took

less than half a day to set up, plus the programming for the non-workflow

stuff -> problem solved, customer happy, solution works and capitalises on

many of the design advantages of SAP Workflow, is stable and can be

maintained.. Again, sometimes the less elegant is the more practical, as

much as I hate to admit it, being a design purist at heart :-)

Greetings from sunny Madrid to the workflowers around the Globe,

Stephan

-----Mensaje original-----

De: Zmudzin,Tomasz,FRANKFURT,Extern LG-DM

[mailto:Tomasz.Zmudzin at de.nestle.com]

Enviado el: 15 October 2003 07:51

Para: SAP-WUG at MITVMA.MIT.EDU

Asunto: Off-topic (Re: Great news: Container elements as structure in 6.2 0)

> One wonders where the "efficiency" is in using

> someone who doesn't know how to do workflow

> programming to do workflow programming?

Sounds like Stephan's organization is praying to the god of outsourcing :-)

Have the design done onsite, the programming done elsewhere with lower hour

rates. In cases like this I could never make sense of it, but it's hard to

argue against beliefs -- much easier to "go with the flow"...

Best regards,

Tomasz

-----Ursprungliche Nachricht-----

Von: Dart, Jocelyn [mailto:jocelyn.dart at sap.com]

Gesendet: Mittwoch, 15. Oktober 2003 01:41

An: SAP-WUG at MITVMA.MIT.EDU

Betreff: Re: Great news: Container elements as structure in 6.20

Hi Stephan,

One wonders where the "efficiency" is in using someone who doesn't know how

to do workflow programming to do workflow programming?

Perhaps you could suggest a compromise? E.g.create an RSEG business object

with database attributes.  Any time you need virtual attributes and methods

the business object program calls function modules to do the actual work.

That way you minimise the amount of workflow programming code and maximize

the amount of ABAP code so that non-workflow programmers can still fix

problems. I've used this approach before at sites with minimal workflow

support.

Regards,

        Jocelyn Dart

Consultant (SRM, EBP, Workflow)

and co-author of the book

"Practical Workflow for SAP"

SAP Australia

email: jocelyn.dart at sap.com

phone: +61 412 390 267

fax:   +61 2 9935 4880

-----Original Message-----

From: Becker, Stephan [mailto:stephan_becker.ext at siemens.com]

Sent: Wednesday,15 October 2003 4:46 AM

To: SAP-WUG at MITVMA.MIT.EDU

Subject: Re: Great news: Container elements as structure in 6.20

Mark,

Agreed, that would be the preferred solution data-wise and in terms of

design, but organisationally and for efficiency reasons, I am doing the

workflow frame, and the method programming is done by someone unfamiliar

with the macro commands, let alone handling multiline virtual object

attributes across several levels of objects..

Also, from a maintenance point of view, simpler is better in many cases, as

workflow specialists are usually not kept around for long after go-live, and

it is then up to non-workflow programmers to fix method code..

It pains me to make this kind of argument, usually I am the first to argue

for clean and elegant design..

Best regards,

Stephan

-----Mensaje original-----

De: Griffiths, Mark [mailto:mark.griffiths at sap.com]

Enviado el: 14 October 2003 18:00

Para: SAP-WUG at MITVMA.MIT.EDU

Asunto: Re: Great news: Container elements as structure in 6.20

Stephan,

Rather than passing in the whole structure (which is stored elsewhere

anyway) have you thought about creating a new business object based on RSEG?

I have used this successfully quite a few times in conjunction with BUS2081

at the header level (e.g. use standard BUS2081 events and then use dynamic

parallel processing to start subflows for the line items (you could have a

multiline vritual object attribute for your RSEG object on a delegated

subtype of BUS2081).

Hope this helps.

Cheers,

Mark

SAP UK

-----Original Message-----

From: Becker, Stephan [mailto:stephan_becker.ext at siemens.com]

Sent: 14 October 2003 11:39

To: SAP-WUG at MITVMA.MIT.EDU

Subject: Re: Great news: Container elements as structure in 6.20

Hi everyone :-)

Has anyone tried to take this up with SAP for releases lower than 6.20, and

maybe received a solution I cannot find?

I am particularly interested in 4.6C, as I am trying to transfer an extended

structure (e.g. RSEG plus an XFELD) from the event to the workflow.

How are you getting around this "feature"?

I don't particularly want to hand over several structures; I need to

transfer the complete RSEG (invoice line item) plus one marker per line

item, and I do not really want to abuse an RSEG field, either..

Thanks,

Stephan

-----Mensaje original-----

De: Zmudzin,Tomasz,VEVEY,GL-IS/IT [mailto:Tomasz.Zmudzin at nestle.com]

Enviado el: 25 March 2003 09:21

Para: SAP-WUG at MITVMA.MIT.EDU

Asunto: Great news: Container elements as structure in 6.20

Dear all,

I'm so happy to have found it now that I need to share it with you:

In Enterprise (Basis 6.20), you can define container elements with reference

to business object types, table elements -- but also: **DDIC**STRUCTURES**!

Makes my life now much easier, and I believe solves several issues posted to

this forum within the last 4-6 months (e.g. you can have a multiline

container element with some predefined structure -- a clean and nice way to

pass your data).

Best regards,

Tomasz