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

Wed Oct 15 02:54:45 EDT 2003

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