AW: Generel Design Question designing BOR-Objects

[Schmidinger, Heinz (Unaxis IT BZ)]

Tomasz,
 
in generel your suggestion is very near to my intention in the moment
specially concerning the needed methods. I havn't planned to to not
requested methods, on this branch I don't see a problem in the moment.
 
My indecision primary is the design of the properties:
Should I choose a design with obj.based properties for all handeld =
objects
or should I be restrictive with these properties.
 
I'm am uncertain whats the effects in deeper System-Levels because this
object will become (if I decide to go the first way you mentioned too) =
very
large and time-intensive.
 
greetings
 
Heinz
 
-----Urspr=FCngliche Nachricht-----
Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM [mailto:Tomasz.Zmudzin at nestle.com]
Gesendet am: Mittwoch, 27. November 2002 09:53
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: Generel Design Question designing BOR-Objects
 
Heinz,
 
if the requirements are not known now, don't build your solution to =
satisfy
them
 
Build something that will satisfy the immediate requirements:
- use object-based attributes as much as possible
- in the objects build only those methods that have business meaning --
refrain from putting "tweaks / hacks" as separate methods
 
and your development will scale nicely to the real solution when the
requirements will become clear. Build your target thing iteratively -- =
the
users will ask you for extensions when they will see something working
already.
 
Kind regards,
Tomasz
 
-----Original Message-----
From: Schmidinger, Heinz (Unaxis IT BZ)
[mailto:heinz.schmidinger at unaxis.com]
Sent: Wednesday,27. November 2002 09:42
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: Generel Design Question designing BOR-Objects
 
 
Hi Tomasz,
 
thanks for the start of discussion.
 
 
To the first input reg. behavior I am with you that it is hard to to a
decission, but relly this is the point whre I'm looking for this way to
discuss. I must say that the needs are not fully known at this time.
I intend to design an most flexible object because my expirence is that =
the
needs will grow very fast.
 
 
To you note reg. build-up time: You are right, the ECM-handeld objects =
are
to be aceesed in table AEOI an/or with good funct.modules. But in my
Transaction these Objects are in the minority. Most objects we catch =
are not
handled by SAP's ECM directly, but they are needed in the Bussiness =
Process
on the one hand. The other is that a 3 level project-releted =
ECM-structure
is build up wher SAP only supports 2 Levels (Unit and Packages). So the
access to ECM-related Objects takes not the time, the time is used to =
find
all ECM's for the 3 Levels and find additional Objects with secundary
access-path's.
 
At least such a typical structur which needs 30 seconds holds at about =
500
ECM's with 15.000  single Object leaves.
 
greetings
 
Heinz
-----Urspr=FCngliche Nachricht-----
Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM [mailto:Tomasz.Zmudzin at nestle.com]
Gesendet am: Mittwoch, 27. November 2002 08:46
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: Generel Design Question designing BOR-Objects
 
Dear Heinz,
 
it's not only about properties -- please check which behavior the =
object
should have, or how you'd like to use it. Without this information it's
pretty hard to decide on anything. What are you trying to accomplish?
 
Besides -- why is the build-up of the view taking so long? I know that
following the links between ECM-related objects can be quite amazing, =
but
this seems like a really long time...
 
Kind regards,
Tomasz
 
-----Original Message-----
From: Schmidinger, Heinz (Unaxis IT BZ)
[mailto:heinz.schmidinger at unaxis.com]
Sent: Wednesday,27. November 2002 08:31
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Generel Design Question designing BOR-Objects
 
 
        Dear Workflower,
 
        I'll design a customer Object for some Transaction-Types I have
implemented in our Bussiness Processes.
 
        Such a Transaction for Example is a Engeneering Lifecycle =
Workbench
which is a logical container filled in dialog with all objects needed =
by an
Engineer to do his daily work up to the logistical Actions.
        This 'container' is filled with at about 20 different logical
Objects (like BUS2002, BUS2054, DRAW, BUS1001, USR01, BUS2048, BUS2002, =
and,
and, and) in a predefined structure. In Dialog the build-up time for =
the
filled View may be up t o 30 seconds  and more.
        The actual bussiness needs for such a object are very poor but =
my
expirence says that after the first WF-based implementaions a move =
briskly
ahead will taken place.
 
 
        Basicly I see 2 ways for design :
 
        The First could be to design the Object only as the wrapper =
without
nearly none Properties or
        to design the Object with Properties containing all objects
mentioned above in the same structure like the dialog transaction.
 
        Personally I have a preference whioch way I should go but  I'm =
not
sure if it's the best way.
 
        So I'm very interested in our opinion and experience to this
questions.
 
        Thamks for the discussion ahead and Greetings
 
 
        Heinz