Generel Design Question designing BOR-Objects

[Michael Pokraka]

Hi Heinz,
Since you're wondering, I've been involved in similar setups and would
suggest that any objects are included as attributes of your 'master'
object.
The design I'm talking about involved multiline attributes with objects,
some of which in turn contained sub-objects again, effectively forming a
whole tree structure.
Since objects are mostly just pointers to the actual data, there is not
a huge overhead involved in terms of amount of data. These references
are stored in sww_contob. In effect you end up with a 20-object workflow
costing you as much as a couple of 'normal' workflows (note: only
top-level objects are actually in the container).
There's some overhead for each WF already for the _workitem and
_evt_object entries - thus 20 container elements are equivalent to
20/3 = 6 workflows with 1 container object element. So now you can
consider if your WF runs only a few times per day versus others which
can number in their thousands, this becomes almost negligible.
 
HTH
Cheers
Mike
 
 
 
On Wed, Nov 27, 2002 at 10:20:22AM +0100, Schmidinger, Heinz (Unaxis IT BZ) wrote:
> Thomasz,
>
> thank's, that was an important input for me.
>
> I'm wonder what other collegous will contribute in to this discussion.
>
> heinz
>
> -----Urspr|ngliche Nachricht-----
> Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM [mailto:Tomasz.Zmudzin at nestle.com]
> Gesendet am: Mittwoch, 27. November 2002 10:15
> An: SAP-WUG at MITVMA.MIT.EDU
> Betreff: Re: Generel Design Question designing BOR-Objects
>
> If you go for flexibility / extensibility, use object-based properties.
>
> As far as I recall the properties will not be queried unless their values
> are explicitly requested, so run-time should not be an issue.
>
> Kind regards,
> Tomasz
>
> -----Original Message-----
>> From: Schmidinger, Heinz (Unaxis IT BZ)
> [mailto:heinz.schmidinger at unaxis.com]
> Sent: Wednesday,27. November 2002 10:04
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: AW: Generel Design Question designing BOR-Objects
>
>
> 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|ngliche 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|ngliche 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