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

Thu Oct 16 16:21:02 EDT 2003

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.

=20

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

=20

Alon Raskin

3i-consulting Group

e: araskin at 3i-consulting.com

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

=20

-----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)

=20

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).

=20

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.

=20

Time to take a look at BC401 ?

=20

Cheers

=20

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

=20

=20

-----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)

=20

Yes I think that's enough now...

=20

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.

=20

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

=20

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

=20

=20

=20

=20

=20

-----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)

=20

=20

Alon,

=20

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.

=20

Hope this ain't going to start a holy war

-- yours,

Tomasz

=20

=20

-----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)

=20

=20

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.

=20

=20

=20

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.

=20

=20

=20

Regards,

=20

=20

=20

Alon

=20

=20

=20

Alon Raskin

=20

3i-consulting Group

=20

e: araskin at 3i-consulting.com

=20

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

=20

=20

=20

-----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)

=20

=20

=20

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

=20

=20

=20

How about:

=20

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

=20

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

=20

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

=20

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

=20

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

=20

=20

=20

Would that not be a feasible separation of responsibilities?

=20

=20

=20

Best regards,

=20

Tomasz

=20

=20

=20

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

=20

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

=20

Gesendet: Mittwoch, 15. Oktober 2003 08:15

=20

An: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

in 6.2 0)

=20

=20

=20

=20

=20

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

=20

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

=20

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

=20

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

=20

career-minded employee..

=20

=20

=20

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

=20

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

=20

all other stuff to colleagues..

=20

=20

=20

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

=20

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

=20

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

=20

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

=20

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

=20

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

=20

processing steps ;-)

=20

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

=20

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

=20

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

=20

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

=20

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

=20

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

=20

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

=20

effort to create automatic inbound delivery and statistical good receipt =
for

=20

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

=20

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

=20

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

=20

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

=20

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

=20

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

=20

=20

=20

Greetings from sunny Madrid to the workflowers around the Globe,

=20

Stephan

=20

=20

=20

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

=20

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

=20

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

=20

Enviado el: 15 October 2003 07:51

=20

Para: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

=20

=20

> One wonders where the "efficiency" is in using

=20

> someone who doesn't know how to do workflow

=20

> programming to do workflow programming?

=20

=20

=20

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

=20

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

=20

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

=20

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

=20

=20

=20

Best regards,

=20

Tomasz

=20

=20

=20

=20

=20

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

=20

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

=20

Gesendet: Mittwoch, 15. Oktober 2003 01:41

=20

An: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

=20

=20

=20

=20

Hi Stephan,

=20

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

=20

to do workflow programming to do workflow programming?

=20

=20

=20

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

=20

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

=20

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

=20

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

=20

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

=20

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

=20

support.

=20

Regards,

=20

        Jocelyn Dart

=20

Consultant (SRM, EBP, Workflow)

=20

and co-author of the book

=20

"Practical Workflow for SAP"

=20

SAP Australia

=20

email: jocelyn.dart at sap.com

=20

phone: +61 412 390 267

=20

fax:   +61 2 9935 4880

=20

=20

=20

=20

=20

=20

=20

=20

=20

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

=20

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

=20

Sent: Wednesday,15 October 2003 4:46 AM

=20

To: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

=20

=20

=20

=20

Mark,

=20

=20

=20

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

=20

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

=20

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

=20

with the macro commands, let alone handling multiline virtual object

=20

attributes across several levels of objects..

=20

=20

=20

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

=20

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

=20

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

=20

=20

=20

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

=20

for clean and elegant design..

=20

=20

=20

Best regards,

=20

Stephan

=20

=20

=20

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

=20

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

=20

Enviado el: 14 October 2003 18:00

=20

Para: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

=20

=20

Stephan,

=20

=20

=20

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

=20

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

=20

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

=20

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

=20

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

=20

multiline vritual object attribute for your RSEG object on a delegated

=20

subtype of BUS2081).

=20

=20

=20

Hope this helps.

=20

=20

=20

Cheers,

=20

=20

=20

Mark

=20

=20

=20

SAP UK

=20

=20

=20

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

=20

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

=20

Sent: 14 October 2003 11:39

=20

To: SAP-WUG at MITVMA.MIT.EDU

=20

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

=20

=20

=20

=20

=20

Hi everyone :-)

=20

=20

=20

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

=20

maybe received a solution I cannot find?

=20

=20

=20

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

=20

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

=20

=20

=20

How are you getting around this "feature"?

=20

=20

=20

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

=20

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

=20

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

=20

=20

=20

Thanks,

=20

Stephan

=20

=20

=20

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

=20

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

=20

Enviado el: 25 March 2003 09:21

=20

Para: SAP-WUG at MITVMA.MIT.EDU

=20

Asunto: Great news: Container elements as structure in 6.20

=20

=20

=20

Dear all,

=20

=20

=20

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

=20

=20

=20

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

=20

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

=20

=20

=20

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

=20

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

=20

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

=20

pass your data).

=20

=20

=20

Best regards,

=20

Tomasz