Service Manager
This is the latest version of the help for Ivanti Service Manager 2018. If you cannot find some of the features described in the help, you may be using an older version of the application. To upgrade the application, click here.To view the help for the latest version of Service Manager, click here
Using Relationships
•Viewing Relationships for a Business Object
•Adding a Relationship to a Business Object
•Using an Entity Relationship Diagram (ERD)
•Using Direct Relationships in a List
•Example: Hiding Related Items in Closed Status
About Relationships
•About Using Link Fields in Relationships
About Relationships
A business object relationship lets two business objects collaborate. More specifically, it lets the records included in the business objects work together. In a relationship, business objects can belong to other business objects or simply be associated with other business objects.
Each relationship contains these business objects:
•Parent business object: This business object is the center of a relationship with one or more child business objects. Only a master business object can function as a parent business object.
•Child business object: This business object is the supplier of additional data to a parent business object.
For example, the Incident business object can have a relationship with the Notes business object so that you can track notes pertaining to a specific incident. Because the incident is a master business object, it becomes the parent to the notes, the child business object.
When you add a relationship to a business object, you must specify the exact internal reference name, as specified by the Internal Reference Name parameter.
You cannot create any new relationships that have a null reference name. See About Empty Internal Reference Names for more information.
About Link Fields
The system links records in a relationship through a constraint that specifies how records find each other. In most cases, a relationship uses the standard constraint, a parent link field, which is included in the child and stores the RecID of the parent. Sometimes a special constraint is required or an additional constraint is needed in the parent. In these cases, a relationship relies on a link field.
A link field is a special system field that stores the RecID of a record. It also stores a category for identifying and linking records in a business object relationship. When you create a master-child or standard-child business object, the system creates the parent link field for you.
About Using Link Fields in Relationships
Starting in Service Manager Release 2016.2, the behavior for how link fields are used within relationships has changed. You can no longer use a link field with a many-to-many relationship. In most cases, the HEAT Service Management Release 2016.2 upgrade will locate any relationships that are defined in this manner, and will adjust them so that they will continue to work as they did in Release 2016.1. We recommend that you correct these relationships to work correctly before upgrading to any subsequent releases.
The link behavior was changed because the combination of a link field and a many-to-many relationship does not make logical sense, and therefore cannot be properly supported by the system. The link field needs to point to a record in the related business object. Many-to-many relationships do not point directly to the other business object; they use an intermediate table that tracks the links between the two business objects. Configuring a link field on a many-to-many relationship was allowed in previous versions, therefore, customers who have configured this scenario are experiencing unexpected behavior by the system.
The new behavior may cause errors in upgraded environments. In certain instances, you may have defined a link field relationship, but after upgrading to Service Manager Release 2016.2, that relationship disappears, because the relationship was a many-to-many link field relationship. One example of this is the KnowledgeLink field in the Incident business object. Previously, the relationship and binding fields were populated but after the upgrade, they are unpopulated and the system does not allow you to change them. This is as designed, because we no longer support the many-to-many relationship for link fields, because we updated the link field relationship to only allow relationship matching directly to another business object.
You cannot represent a many-to-many relationship with a single key value. A link field can only contain one RecID, but for a many-to-many relationship there can be several RecIDs. For example, employees can be members of several different teams and teams have multiple employees. This is a many-to-many relationship with many RecIDs (each employee has a RecID). In the past, you could create a relationship between one of the employees and many teams and store it here; however, that was incorrect because no one RecID was correct to enter here. In this release we are removing the ability to incorrectly create and use relationships in this way. To handle this properly, you must create a new relationship that is either one-to-one or one-to-many. You can then set the relationship and binding fields for this relationship.
One example of correctly creating a link field relationship is the escalation watch relationships for the Incident business object. There is one general relationship defined that is one-to-many called IncidentAssociatedEscalationWatch and then there are four other relationships defined with link fields that are one-to-one, called IncidentAssocClosingEscWatch, IncidentAssocResolutonEscWatch, IncidentAssocResponseEscalationWatch, and IncidentAssocWaitingEscWatch.
Relationship Types
•Contains: The child business object belongs to, and is dependent on, the parent business object. The system loads, saves, and deletes the child business object with its parent business object. These relationships are listed under the Relationships tab.
•Associates: The child business object is related to the parent business object, but does not belong to it. The child business object is independent. These relationships are listed under the Relationships tab.
Contains and Associates Relationship Types
•Named: These relationships are system driven relationships used specifically in the Configuration Management Database (CMDB). They are used by the CI Map to qualify relationships in either direction, and to qualify how they are related. They cannot be created in the application. They are listed under the Named Relationships tab for the Incident business object and the CI business object.
•Embedded: You can extend contains and associates relationships to become embedded relationships. An embedded relationship is a special relationship where the child business object is embedded into the parent business object to display one special child record. You always embed a single business object into a parent. The single business object can be a member of a business object group.
For example, you can embed the Address.Phone business object into the Employee business object so that a home phone (one special record) displays on a contact record. You can also embed the entire address group, that is, all of the Address. business objects, such as Address.Email, Address.Mail, and so on, into the Employee business object to display phone numbers, mailing addresses, and email addresses.
•Normal: If a relationship is normal, the primary key is part of the parent business object and the foreign key is part of the child business object.
Relationship Cardinality
Cardinality refers to the number of business objects on each side of the relationship. The following describes the relationship cardinality:
| Notation | Each Parent Business Object is Related to | Each Child Business Object is Related to |
|---|---|---|
| 1 : 0...1 | 0 or 1 child | 1 parent |
| 0...1 : 1 | 1 child | 0 or 1 parents |
| 0...1 : 0...1 | 0 or 1 child | 0 or 1 parent |
| 0...1 : 0...N | 0 to any number of children | 0 or 1 parent |
| 0...N : 0...1 | 0 or 1 child | 0 to any number of parents |
| 0...N : 0...M | 0 to any number of children | 0 to any number of parents |
Some examples include:
One-to-many: One contains many or one contained in many. For example, one employee (parent) can have many incidents (children). Or one alert (parent) can be sent to many employees (children).
One-to-one: One associates with one. For example, one employee (parent) has only one service level agreement (child).
Many-to-many: Many associates with many. For example, an employee (child) can be a member of more than one group business object (parent).
Many-to-one: Many associates with one. For example, an employee (child) can be a member of just one department (parent). If a relationship constraint is set to many-to-one, the system does not allow you to delete the parent business object because then the relationship would no longer be many-to-one (it would be many-to-none). For example, if an employee has a relationship with a department, the system does not allow you to delete the department, because there are many employees associated with it.
Groups in Relationships
Groups can be part of a relationship, and can function as a parent or as a child. How they function depends on whether the group is a master or standard group.
Viewing Relationships for a Business Object
1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.
2.Open a business object.
3.Click the Relationships tab. The system displays a list of the relationships for this business object.
| Field | Description |
|---|---|
| Relationship Name | A unique name without spaces or special characters. |
| Display Name | The name that appears to users. |
| Cardinality | The cardinality of the relationship between the business objects. See Relationship Cardinality. |
| To Business Object | A relationship has two business objects. One is the current business object. This specifies the other business object in the relationship. For example, if the current business object is the Release business object, and the value under this column is Change, the relationships is between the Release business object and the Change business object. |
| Binding |
The relationship type. Can be one of the following: Associated: Makes the current business object related to the child business object so that if you delete the current business object, the system does not delete the child business object. Contains: Makes the current business object the parent business object in a parent-child relationship. If you delete the parent business object, the system deletes the child business object that is specified in the relationship. |
| Through Fields | Specifies the constraint fields that relate the business objects. |
| Condition |
An additional restriction that both records must satisfy for them to be related. Business objects are considered to be related only if the condition is evaluated as true. |
Adding a Relationship to a Business Object
1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.
2.Open the business object to be the parent business object.
3.Click the Relationships tab. The system displays a list of the relationships for this business object.
4.Click Add new.... The system displays a list of business objects.
5.Select the business object to be the child business object. The system displays the Relationship's Details page.
6.Enter information into the fields.
| Field | Description |
|---|---|
| Relationship Details | |
| Designer Name | The name of the relationship. The system enters a dummy value when you first create the relationship. You can change this name; however, after you save the relationship for the first time, you cannot change this value. |
|
Display Name |
The relationship name that is displayed in the UI. You can change the name that the system displays in the UI, but that does not change the actual (designer) name of the relationship. |
|
Internal Reference Name |
The exact, internal reference name for this relationship. You set this value when you initially create the relationship. However, after you save the relationship for the first time, you cannot change the value.
This name is part of the relationship key name and the other object relationship key. You use this name in expressions when you refer to other business objects. We recommend that you make the name compact and meaningful because there can be several relationships between the same two database tables.
To set the value, click not set and enter a value. |
|
Relation to |
The related business object. The system automatically populates this field based on the business object that you selected in step 5 above. |
| Relationship Key | Specifies the name of the relationship. You use this name in expressions when you refer to other business objects.
The system automatically populates this field and you cannot change it. It is in the format <relation_to>#.<internal_reference_name>. |
| Other Object Relationship Key |
Specifies the name of the other object relationship. You use this name in expressions when you refer to other business objects.
The system automatically populates this field and you cannot change it. It is in the format <business_object>#.<internal_reference_name>. |
| Direction |
Specifies the direction of the relationship, either normal or reversed. Can be used for troubleshooting.
The system automatically populates this field and you cannot change it. |
|
Relationship is Audited |
Specifies if the relationship is to be audited. The system automatically creates an entry in the audit history log when the relationship is used to link or unlink related business objects. See About Accessing the Audit History. |
| Full Text Search Enabled |
Enables the relationship to be included in full-text searches. For queries to return related business objects, at least one field in the business object and related business objects must be enabled for full-text search.
|
| Prevent Delete when Linked Objects Exist |
Shown only if the value of the Direction field is set to Normal. Prevents you from unexpectedly deleting linked business objects, which could cause problems. When checked, you cannot delete an instance of the business object type that contains the relationship definition if one or more related business object links exist. This setting only applies to one side of the relationship.
For example, IncidentAssociatesChange is a many-to-many relationship. The Incident business object definition contains a relationship definition for IncidentAssociatesChange. The Change business object definition contains a reverse relationship definition for IncidentAssociatesChange. If you check Prevent Delete when Linked Objects Exist for the Incident business object but do not check that field for the Change business object, when an incident is linked to a change, you cannot delete the incident until the link is removed. However, you can delete the change without first removing the link. |
| This Business Object |
Defines how many parent business objects are permitted relative to the child business object (cardinality). |
| Zero or one |
Specifies that a parent record in this business object either has a zero-to-one or a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child). |
| Exactly one | Specifies that a parent record in this business object has a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child). |
| Zero or many | Specifies that a parent record in this business object either has a zero to many or a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children). |
| Many | Specifies that a parent record in this business object has a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children). |
|
One of the following: Primary Key (if normal direction) Foreign Key (if reversed direction) |
The primary key (if this is a normal relationship) or the foreign key (if this is a reversed relationship). The system automatically populates this field, but you can overwrite it. |
| Binding Type | |
|
Associates with |
Makes the current business object related to the child business object so that if you delete the current business object, the system does not delete the child business object. |
|
Contains |
Makes the current business object the parent business object in a parent-child relationship. If you delete the parent business object, the system deletes the child business object that is specified in the relationship. |
| Use Link Table (for many-to-many relationships) |
Read-only, and only used with many-to-many relationships. Defines how the data is passed between records. In a many-to-many relationship, two business objects are considered related when the appropriate record containing RecIDs of two business objects exists in a link table. If this option is selected, you can use the default Fusion Link table, which contains standard constraints called parent link fields (housed in the child and store the RecID of the parent), or you can enter another database table to be used as a link table. |
|
Related Business Object |
Defines how many child business objects are permitted relative to the parent business object (cardinality). |
| Zero or one | Specifies that a parent record in this business object either has a zero-to-one or a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child). |
| Exactly one | Specifies that a parent record in this business object has a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child). |
| Zero or many | Specifies that a parent record in this business object either has a zero to many or a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children). |
| Many | Specifies that a parent record in this business object has a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children). |
|
One of the following: Foreign Key (if normal direction) Primary Key (if reversed direction) |
The foreign key (if this is a normal relationship) or the primary key (if this is a reversed relationship). The system automatically populates this field, but you can overwrite it. |
| Relationship Attributes | |
| Commonly Used |
Not used. |
|
Is Asymmetric |
Specifies if the relationship is asymmetrical, which means that there is no reverse relationship.
The system automatically populates this field and you cannot change it. |
|
Condition |
Adds a condition as an additional restriction, combining fields from the current business object and functions from the functions folder. The business objects are considered related only if the condition is evaluated as true. To create a condition, click none. The system displays the Expression Editor. Select the fields or functions and click Save. To delete a condition, delete it from the Expression Editor and click Save. For an example, see Example: Hiding Related Items in Closed Status.
NOTE: If you add a condition to a relationship, it works in addition to, and not instead of, any other conditions that may be set for the business object. You can also set conditions by using filters for child tabs, by using visibility expressions, and more. |
| Group object type selector |
Specifies the child type, based on the parent type. Used when the related business object is a group object.
You can specify a field in the parent business object that dictates the child business object type. For example, you can use a field on the Incident parent business object to specify the type of form shown. The child business object must be in one of the child tabs on the business object user interface. When the type field changes, the child business object type changes, using matching values where possible. If there is no child business object, the system automatically creates a new one using the original type. If the type field value cannot be matched to a child object type, the system removes the child business object link. |
| Update fields |
Copies data from the field specified for this business object to the field specified for the related business object when they are linked. Click the add icon
Starting in Service Manager Release 2016.1, the system automatically synchronizes the Only when field is empty and Overwrite defaults, but preserve user edits fields to be symmetric within a relationship and its reverse relationship. Any potential non-symmetric values are corrected as part of the Service Manager Release 2016.1 upgrade so that if you check a property value, the system also checks the counterpart value in the opposite relationship. |
| Set field |
The field in this business object that contains the information to be copied. The system automatically lists a field, but you can change it by selecting a value from the drop-down list. |
| To <related business object>'s field value | The field in the related business object where the information is copied to. Select a value from the drop-down list. |
| Only when field is empty |
Only copies the data to the field in the related business object if that field is empty and if there are no business rules defined to populate this field.
NOTE: If you check this option and have already checked Overwrite defaults, but preserve user edits, the system automatically unchecks Overwrite defaults, but preserve user edits. You cannot check both options. |
| Overwrite defaults, but preserve user edits | Only copies the data to the field if the field contains a default value, but does not copy the data to the field if there have been any changes made.
NOTE: You cannot check this option if you checked Only when field is empty. To check this option, first uncheck Only when field is empty. |
| Update <related business object>'s fields |
Copies data from the related business object to this business object when they are linked. |
| Set field |
The field in the related business object that contains the information to be copied. The system automatically lists a field, but you can change it by selecting a value from the drop-down list. |
| To this object's field value | The field in this business object where the information is copied to. Select a value from the drop-down list. |
| Only when field is empty |
Only copies the data to the field in this business object if that field is empty and if there are no business rules defined to populate this field.
NOTE: If you check this option and have already checked Overwrite defaults, but preserve user edits, the system automatically unchecks Overwrite defaults, but preserve user edits. You cannot check both options. |
| Overwrite defaults, but preserve user edits |
Only copies the data to the field if the field contains a default value, but does not copy the data to the field if there have been any changes made.
NOTE: You cannot check this option if you checked Only when field is empty. To check this option, first uncheck Only when field is empty. |
| Link objects referenced in fields |
Links the field to the related business object whenever a user selects this business object. For example, if you link the team field from the related business object to this business object, whenever a user selects this business object in a form, the system automatically populates the form with the value of the team field from the related business object.
To add a field, click the add icon |
| Link objects referenced in <related business object>'s fields |
Links the field to this business object whenever a user selects the related business object. For example, if you link the team field from this related business object to the related business object, whenever a user selects the related business object in a form, the system automatically populates the form with the value of the team field from this business object.
To add a field, click the add icon |
to add a row for specifying data to push from this business object to the related business object. For example, you can push the priority of an incident (this business object) to the task (related business object).7.Click Save. The system validates the values that you entered and if there are no problems, saves the relationship.
Deleting a Relationship
Some business object relationships are locked to prevent the modification or removal of items that the system requires. Your customization level determines which relationships you can delete.
To implement definition changes in your live system, create and commit a definition set containing the modifications. Ensure you have rights to create and commit definition sets.
Relationships have dependencies that, upon deletion, can be broken. For example, a task can no longer be assigned from an incident if the relationship between the incident and the task is deleted. Ensure that you are comfortable with deleting the relationship and have properly prepared for its deletion.
1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.
2.Open the parent business object.
3.Click the Relationships tab. The system displays a list of the relationships for this business object.
4.Click the delete icon 
at the end of the row of the relationship to remove. If the icon is grayed out, you cannot delete this relationship.
The system removes the relationship.
Was this article useful?
The topic was:
Inaccurate
Incomplete
Not what I expected
Other
Copyright © 2018, Ivanti. All rights reserved.