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 , the objectspace 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 inside OBEROn.
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 objectspace , 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 the object.
Names are case-sensitive and spaces are allowed; the maximum length is 128.
While the class and the name are mandatory, the revision must be specified only if the object’s 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 object’s current stage in the associated lifecycle. This revision label is either manually assigned or automatically assigned if a revision rule has been defined in the lifecycle.

Users can create a new object instance by clicking the "Define new Object" button from the "Domain Object Manipulation" client.

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 respectively.
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 access privileges.

An equivalent object creation OOQL command might be:

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.

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 stage .

As seen earlier, you must assign a class to any object being created. An object’s 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 stage .

An object edit OOQL command might be:

Note: you can use the field clause to set the values also in the creation OOQL commands.

Modifying the Holder of multiple Objects

Users can 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" client.

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.

Creating object revisions

The ability to create revisions can be enabled or not depending on the object’s lifecycle stage 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 rule in the reference object lifecycle.

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.