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

Wed Oct 15 03:02:01 EDT 2003

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

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

Regards,

=20

Alon

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

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

=20

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.

=20

Would that not be a feasible separation of responsibilities?

=20

Best regards,

Tomasz

=20

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

=20

=20

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

=20

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

=20

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

=20

Greetings from sunny Madrid to the workflowers around the Globe,

Stephan

=20

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

=20

> One wonders where the "efficiency" is in using

> someone who doesn't know how to do workflow

> programming to do workflow programming?

=20

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

=20

Best regards,

Tomasz

=20

=20

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

=20

=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?

=20

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

=20

=20

=20

=20

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

=20

=20

Mark,

=20

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

=20

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

=20

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

for clean and elegant design..

=20

Best regards,

Stephan

=20

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

=20

Stephan,

=20

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

=20

Hope this helps.

=20

Cheers,

=20

Mark

=20

SAP UK

=20

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

=20

=20

Hi everyone :-)

=20

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

maybe received a solution I cannot find?

=20

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.

=20

How are you getting around this "feature"?

=20

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

=20

Thanks,

Stephan

=20

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

=20

Dear all,

=20

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

=20

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

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

=20

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

=20

Best regards,

Tomasz