create and manage object instances
Business objects can represent any
object related to the domain for which a developer is creating business
logic. A business object often encapsulates all of the data
and business behavior associated with the entity that it represents.
Each object is defined by its class, contained in an objectspace
and controlled by its lifecycle. Therefore, the
application schema designer must define the class
and the lifecycle
that will be used before users can create business objects. In addition,
the actor users
(users, teams and assignments) must be defined in OBEROn before
they can have access to the application.
When you create or reference an OBEROn object, you must indicate
its full name composed of three elements: the Class name,
the object Name and the Revision in the exact order.
The tuple C,N,R is unique and identifies uniquely an object
You can also optionally specify the objectspace in which
the object is held. This is necessary during the creation if the
user doesn't have an associated default
while it is useful to improve performance for the retrieval. Infact,
if the objectspace is specified, only the named objectspace needs
to be scanned to locate the object.
Creating a new Object instance
As said above, every object must have a class
associated with it. Since the classes have fields associated with
them, these fields appear as properties when the object is accessed.
The fields can then be filled in with specific values; if fields
are not specified when a business object is added or modified, the
default values (if any) are used.
The second element in a business object specification is the business
object name. This consists of a character string that will
be used to identify the business object being created and to reference
it later. You should assign a name that clearly identifies and distinguishes
Names are case-sensitive and spaces are allowed; the maximum length
While the class and the name are mandatory, the revision
must be specified only if the objects lifecycle requires the
revision label in order to distinguish it from other objects with
the same name and type. If it is not required you have to specify
an empty string (""). The ability to create revisions
for an object depends on the objects current stage in the
associated lifecycle. This revision label is either manually assigned
or automatically assigned if a revision
has been defined in the lifecycle.
create a new object instance by clicking the "Define
new Object" button from the "Domain Object Manipulation"
You can directly insert the object's basic data in
the creation form fields or select them from the application schema.
For example, you can looking for a class between those already defined
with the Context Design client. After the class is selected, you
can also retrieve the lifecycles that support this kind of
object's class according to the lifecycle definitions. To do this
simply click the "Reload class related lifecycles" button.
The object creation process is enabled if and only if the first
stage of the selected lifecycle allow the operation for the current
user on the base of his access privileges.
Additional fields like the description and the
holder are included in the creation form to specify general
information to about the object and the owner of the business object
Both fields are optional. OBEROn assumes the holder is the current
user if you don't specify a different one. On the other hand, you
must have also the change-holder access privilege to specify a different
holder for the object. This means that a user, if enabled, can directly
create objects for other users using the holder option. The holder
of an object can be assigned special access in the lifecycle. The
user who is assigned ownership of an object will have these special
An equivalent object creation OOQL
|object create 'SR_Help' 'HLP_0000001' '00'
|| description 'First help request'
|| holder 'test.user'
When business objects are created, they are given an
internal ID. As an alternative to Class Name and Revision,
you can use this ID to direct access the object. The ID is composed
of two parts: the first part of object ID refers to the objectspace
code, this means that when you move the object from an objectspace
to another the ID changes. The second part is a unique hexadecimal
code inside the given objectspace.
Modifying an Object
You can change or see the object basic properties,
double-clicking on the object in the list or selecting it and clicking
the "Basic Properties" button in the menu bar. To modify
the class, the name/revision, the description, the holder, the lifecycle
or the objectspace, a user should have the relative privilege activated
in the object current lifecycle
As seen earlier, you must assign a class to any object
being created. An objects class may or may not have fields
associated with it. If it does, you may assign a specific value
to them. For example, if you were to examine the definition for
the class SR_Help you might find it has fields associated
with it: some inherited from the parent class
and one specific called "SR_Rating".
You can edit or see the object field values, double-clicking
on the object in the list with right mouse button or selecting it
and clicking the "Fields" button in the menu bar.
If you do not assign values to fields, they remain
blank or their default is used if there is one. Not yet assigned field
values are marked with "X" symbol in the default column.
When you are specifying a value, be sure it is in agreement with
the field definition. In other words, only integer values are assigned
to integer fields, character string values are assigned to character
string fields, and so on. Also, if the field has a range of valid
values, the value you give must be within that range. In this case,
you can select a valid value from the proposed selection list. To
modify object field values, a user should have the edit privilege
activated in the object current lifecycle
An object edit OOQL
edit 'SR_Help' 'HLP_0000001' '00'
object edit 'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
object edit #00001-2BC91211
'New description for object'
|| field[SR_InterestedModule] 'VA'
Note: you can use the field clause to set the values
also in the creation OOQL commands.
Modifying the Holder of multiple Objects
change the holder for several object instances (if have the "changehoder" privilege on current object stage) by clicking the "Change Holder" button in the "Domain Object Manipulation"
Copying/Cloning an Object
After a business object is added and its values defined,
you can copy (or clone) the object if its current stage in the lifecycle
allows the clone privilege.
During the clone operation you can modify all basic parameters except
the class. You can also modify the values you want to change: if
you do not make any changes, the values remain the same as the original
business object with the new name you have assigned.
Generally if the lifecycle-stage is not forced, the stage for the
new object is the first in the assigned lifecycle sequence.
clone 'SR_Help' 'HLP_0000001' '00'
object clone 'SR_Help' 'HLP_0000001' '00' in 'SR_Space' create 'HLP_0000002' '00'
object clone #00001-2BC91211 create 'HLP_0000002' '00'
description 'Second help request'
Creating object revisions
The ability to create revisions can be enabled or not
depending on the objects lifecycle
and the current user framework. If for current stage in the object
lifecycle the "Revisionable" flag is set and the user
has the revise privilege then a new revision can be generated from
the object. During the revise operation you can modify all field
values and all basic parameters except the class and the name. Automatically
the new revision value is assumed as the next value in the revision
sequence specified by the revision
in the reference object lifecycle.
revise 'SR_Bug' 'RICH-I.0001300' '00' revision '01'
object revise 'SR_Bug' 'RICH-I.0001300' '00 in 'SR_Space' revision
object revise #00001-F38633EA revision '01'
description 'new revision for 0001300'
objectspace 'SR_Space' ;
Even though it is possible to create what looks like a new revision
by manually assigning a revision value with the create or clone
commands, the revise command should be used in order to maintain
revision history and keep track of the object revisions. Implicit
connections between the original object and its revisions may be
viewed in a Revision chain.