Great news: Container elements as structure in 6.20

[Dart, Jocelyn]

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