Connect Business Object

Syntax

For example, you could have a business object that contains information about a particular course. That information might include the course content, schedule date, instructor, student list, cost, and so on. As each student enrolls in the course, you might create a business object for that student that includes the student’s background, experience, and personal information.

After a student record object is created, it stands alone with no relationships attached to it. However, if you view the course object, you might want to see the student objects associated with it. Also, if you view the student object, you might want to see the course objects associated with that person.

Use the Connect Businessobject command to establish the relationship between the business object containing the student record and the object containing the course information:

connect businessobject BO_NAME relationship REL_NAME | to   | BO_NAME [preserve]
                                                     | from |
[owner VALUE] [organization VALUE] [project VALUE]
[physicalid VALUE][logicalid VALUE]
[ATTRIBUTE_NAME VALUE {ATTRIBUTE_NAME VALUE}] [SELECT [DUMP] [RECORDSEP] [tcl] [output FILENAME]];

• BO_NAME is the Type Name Revision of the business object. It can also include the in VAULTNAME clause, to narrow down the search.
• preserve, if used, indicates that the connection should not update the modification date for that business object.
• REL_NAME is the name of the relationship type to use to connect the two named business objects. If the relationship name is not found or defined, an error message will result.
• ATTRIBUTE_NAME VALUEs indicates attributes assigned to the relationship you are creating.

The Connect Businessobject command has two forms: TO and FROM. The form you choose depends on the placement of the two objects you are connecting. You specify which business object will be associated with the TO end and which will be associated with the FROM end. For example, to assign a student to a course, you might use the TO form of the Connect Businessobject command:

connect businessobject Student “Cheryl Davis” Sophomore
	relationship “Student/Course Relationship”
 		to Course “C Programming Course” 1;

When this command is processed, it will establish a “Student/ Course Relationship” between the course object and the student object. Cheryl Davis is assigned to the FROM end and the C Programming course is assigned to the TO end. You can think of Cheryl as leading to the course object.

You also could think of the course as coming from the student object(s). In other words, you can define the same relationship using the FROM form of Connect Businessobject command:

connect businessobject Course “C Programming Course” 1
	relationship “Student/Course Relationship”
		from Student “Cheryl Davis” Sophomore;

When this relationship is established, Cheryl’s object is again assigned to the FROM end and the course is assigned to the TO end.

If you are defining equivalent objects, either object could be defined as the TO end or the FROM end. However, in hierarchical relationships, direction is important. With these relationships, you should consult the relationship definition before creating the connection. Otherwise, you might have difficulty locating important objects when needed. If you assigned the wrong object to the connection end, you will have to dissolve the relationship and re-define it.

Select and Related Clauses

Frequently, implementation code creates or modifies a businessobject or connection and then immediately needs to fetch new information from it. The select modifier is available so that data can be retrieved as output from the creation (including revise and copy) or modification command itself, removing the necessity to make another, separate server call to get it, thereby improving performance. In the case of add/modify businessobject, the specified selects are applied to the businessobject being created/modified. In the case of connect bus, the specified selects are applied to the connection being created. The output produced is identical to a corresponding print bus or print connection command.

When you add a Select clause to a connect bus command, the select applies to the connection being created and NOT to the objects on either end. For more information, see Select Clause.

The output produced is identical to a corresponding print bus command.

If these selects are used within a user-defined transaction, they will return data representing the current uncommitted form of the object/connection. The data is collected and returned after all triggers associated with the command have been executed, unless a transaction is active and a trigger is marked deferred, since in this case, the trigger is not executed until the transaction is committed, as shown below:

1) Larger transaction is started with any number of commands before the add/modify/connect command with the trigger.
    2) add/modify/connect transaction is started.
        3) Normal processing of access checking occurs.
        4) If it exists, the Check Trigger is fired.
        5) If Check blocks, then transaction aborts.
           If not, the Override Trigger is fired if it exists.
    6) The Event transaction is then committed regardless of an override or normal
       activity.
    7) If the Event Trigger has a non-deferred Action Program, it is executed.
   8) If the add/modify/connect command included a Select clause, the data is collected 
      and returned at this point, even though the creation/modification has not been 
      committed.
9) The larger transaction is committed if all activities and triggers succeed.
10) Finally, if the larger transaction successfully commits, and there is a deferred
    Action Program, it is now triggered. If the larger transaction aborts, deferred    programs are not executed.

Presumably, work would be done using the selected and returned data, between steps 8 and 9 above.