AW: Attributes as object types

Mon Mar 11 04:11:32 EST 2002

Hi everyone,

as far as I am aware, the instantiation of object attributes has not =
changed
in principle since 3.0, but I am of course willing to be convinced
otherwise. I don't think an "initial object attribute" behaviour was =
ever
part of the SAP Workflow design. Maybe Alan can shed some light on this =
from
the product management perspective.

Design-wise, I fully support Mark Griffith's point of view: =
Object-oriented
design warrants that you can not create an instance of a non-existent
object, that would be a contradiction in terms and would break the =
design of
any engine, however good that may be.=20

Greetings,
Stephan

-----Urspr=FCngliche Nachricht-----
Von: Sander van der Wijngaart
[mailto:Sander.vanderWijngaart at avelon-it.com]
Gesendet: Sonntag, 10. M=E4rz 2002 20:29
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: Attributes as object types

Dear Alon,

I totally agree! In the several workflow projects I did this annoying
phenomenon forced me to create several 'double' attributes: several =
with
data fields and when not initial one with the data object. I had to
check in the workflow during runtime to see if I could use the object
attribute....

Solving this problem would be a great improvement for next releases! I
can't remember, nor check, if this problem occurs in versions before
4.6. Did anyone had this problem before the 4.6 version?

Regards,

Sander van der Wijngaart

Avelon B.V.
Visit us at www.avelon-it.com

-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
Raskin, Alon (Soliance)
Sent: vrijdag 8 maart 2002 15:38
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Attributes as object types

Hi Mark,

At this point I would like to remind you who has beaten England in most
of the Cricket matches in recent history. No wonder we are considering
becoming
a republic.....   :)

There is no doubt that your solutions are valid however they are all
work arounds. I would need to find every attribute that uses
exit_object_not_found   and redefine it. That's simply not doable.
What's
worse is that I am pretty sure that in versions 4.0 of Workflow this =
was
not an issue. This behaviour has only come up recently.

Alon Raskin
Workflow Advisor - Soliance
(xtn. 3183)

 -----Original Message-----
From:   Griffiths, Mark [mailto:mark.griffiths at sap.com]
Sent:   March 08 2002 8:29
To:     SAP-WUG at MITVMA.MIT.EDU
Subject:        Re: Attributes as object types

May I suggest that you only use Database Object Attributes if you are
dealing with mandatory fields, or ones you know will always be
populated? For fields where you are unsure if there will be a value you
could use a virtual attribute and do some checking before you
instantiate the object.

Alternatively, if you must use a database object attribute then create =
a
new delegated subtype of the object and redefine the existencecheck so
it doesn't use EXIT_OJECT_NOT_FOUND.

All these complaints about marvellous functionality from a couple of
Australians, and you guys call the English 'Whingeing Poms' ;-)

Cheers,

Mark

SAP UK

-----Original Message-----
From: Raskin, Alon (Soliance) [mailto:ARaskin at cps-satx.com]
Sent: 08 March 2002 14:14
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Attributes as object types

Peter I am glad that you brought this up. I raised this With SAP as an
OSS as I argued that it is totally valid for an object to be INITIAL =
and
the workflow should not error. What's worse here is that you cant even
check whether an object is initial because (as you said) the Check
Condition errors! I personally believe SAP has made a big mistake by
implementing this.

What's worse is that if attribute exits using the macro
exit_object_not_found or exit_property_not_found then the workflow will
also error. Yet SAP themselves deliver attributes which use those
macros. Does that mean they are off limits for Workflow? It just =
doesn't
make any sense.

I like Stephan Becker's solution of adding both to the dictionary field
and object type as the attribute. It seems like a valid solution (I
haven't tried it yet) but it feels a bit like a work-around. I just
don't understand why SAP would do this.

(I feel better now)

Regards,

Alon Raskin
Workflow Advisor - Soliance
(xtn. 3183)

 -----Original Message-----
From:   Roehlen, Peter [mailto:PRoehlen at powercor.com.au]
Sent:   March 08 2002 1:44
To:     SAP-WUG at MITVMA.MIT.EDU
Subject:        Attributes as object types

Hello workflowers,

I'm seeking some guidance from anyone who has come across the following
problem:

When we add a new attribute to a business object type, we usually try =
to
make the 'type reference' of the attribute itself an 'object type'.  An
object type as the type reference is typically a lot more useful to
workflow designers than just the field value; doing this can often meet
the needs of future workflow templates as well.  For example: if =
someone
asks me to add the 'Superior Functional Location' as an attribute to
business type ZBUS0010, "Functional Location", I would automatically
make the new attribute reference an object type (in this case it would
also be ZBUS0010) rather than just reference the ABAP dictionary field.

The ease with which a regular attribute can be made to reference an
object type is a tribute to the SAP designers, however when we do this
there is often one problem that continually crops up: If the field =
value
for the attribute is initial - ie with no value - then the object
reference is 'nothing'.  This causes workflow templates to terminate if
you use the attribute in a Condition step.  If, however, the attribute
references the ABAP dictionary field then the initial value causes no
problem.

One work around is to have two attributes for each field, one
referencing the appropriate object type and the other the ABAP
dictionary field.  This is pretty ugly though.

Has anyone got any thoughts on the above?

Peter Roehlen
Team Lead - SAP Technical & Development
Powercor Australia Ltd
0409 950 263

**********************************************************************
Powercor Australia Ltd. This email and any file attachments are
confidential and intended solely for the use of the individual or =
entity
to whom they are addressed. If you have received this email in error
please tell us immediately by return email and delete the document.
**********************************************************************