Relationship Guidelines and Restrictions

Follow these guidelines when configuring MBOs and enterprise information systems (EISs) used in relationships.

Relationship Guidelines
Guideline Example
These examples use SQL Anywhere to illustrate how to properly configure the EIS so delete operations behave as expected
  • Example one consists of two MBOs:
    Address: addr_id, street, city, country 
    
    Employee: emp_id, name, addr_id (foreign key references Address.addr_id)

    The MBOs have a relationship defined, for example, a composite, uni-directional, one-to-one relationship:

    Employee(Parent) --> Address(Child)

    At runtime, if you delete Employee, SAP Mobile Server attempts to delete the child Address first, which fails because of the Employee.addr_id-to-Address.addr_id reference. For the delete operation to perform as expected, the addr_id foreign key must be defined in the EIS database as on delete set null to enable deletion.

    This requirement applies regardless of the type of relationship defined between the MBOs.

  • Example two also uses the Employee and Address MBOs in a relationship that has mutual references:
    Address: addr_id, street, city, country, 
    emp_id(foreign key references Employee.emp_id)
     
    Employee: emp_id, name, addr_id(foreign key references 
    Address.addr_id) 

    You must set both foreign keys in the EIS database as on delete set null or on delete cascade, regardless of the type of relationship you define for Address and Employee, or neither of them can be deleted.

If the foreign key in a relationship points to a char(n) column, and it is the only column in the table, use the rtrim(column name) function in the MBOs column definition

This example has a relationship defined as:
States(Parent) --> Sales_region(Child)
Sales_region contains one column named Region with a data type of char(7). The MBO definition should be:
SELECT rtrim(region) as region 
FROM sampledb.dba.sales_regions

MBOs used in a relationship must belong to the same Synchronization group

MBOs in a relationship need to share the same synchronization characteristics for proper synchronization of all MBOs within the relationship, therefore verify that all MBOs are in the same synchronization group.

By default, all MBOs in a relationship are assigned to the same cache group

You can assign different cache groups to MBOs within a relationship, however, doing so generates a warning message. You may want to, for example, separate cache groups with different cache policies for a sales MBO, which changes frequently, that has a relationship with the catalog MBO, which changes infrequently.

SAP Mobile WorkSpace does not support Circular relationships

Do not create circular relationships that work from parent-to-child then, eventually, back to the parent. For example:
A relationship that includes three MBOs: A, B, and C, where
A----->B----->C----->A
is not supported.

Composite relationship (composite graph) behavior

  • A child object refers to its parent via a foreign key reference from the child to a primary key value in the parent. When modeling your relationships, choose load parameters carefully to load children based on which parents are in the cache, so that foreign key references can always be resolved. At runtime SAP Mobile Server must be able to resolve foreign key references. A poorly modeled relationship could have MBO instances pointed to by foreign keys that have not been loaded into the cache. Examples include:
    • A composite parent that hasn't been loaded which results in the child not being inserted into the cache because composite orphans are not allowed – a child MBO can have multiple parents (many to one), but only one parent can have a composite relationship to the child:

      In a composite relationship, when one child MBO does not have a synchronization parameter, and has multiple parents, each of which has a synchronization parameter, the child inherits synchronization behavior from both of the parents. If a composite relationship does not exist, SAP Mobile WorkSpace randomly selects a parent through which the child synchronizes. SAP recommends that you define one parent MBO as the composite parent to avoid unintended behavior. For example:

      There are two one-to-many relationships: A<--->>C and B<--->>C. Both MBOs A and B have a synchronization parameter while MBO C has none. In this case, one of the relationships should be a composite.

    • An MBO modeling error where the relationship reference cannot be resolved results in an error message. For example:
      • The SAP Mobile Server log indicates a Null foreign surrogate key value where a child in a non-composite relationship points to a non-existent parent MBO, which could indicate that the MBO is a child in two separate relationships (one composite and one non-composite) and load parameters are improperly configured:
        Serious performance and data integrity issues may ensue. 
        Consider modifying/re-sequencing cache definitions and/or load queries 
        to ensure relationship integrity in the cache.

      • SAP Control Center error log:
        Composite parent not found
  • If a parent MBO's primary key is auto-incremental and you want to perform multi-level insert operations, then the relationship must be composite. Otherwise the child MBO can only be created on an existing parent MBO.
  • When Composite is selected, all child operations are performed through the parent.
  • MBOs in a composite parent/child relationship where the child is loaded into the SAP Mobile Server cache without a parent (composite orphans) are not supported. For example, a composite relationship between department(parent) and employees(child) that attempts to load employees for which there is no corresponding department is not allowed at runtime. In this scenario you could change the model to use a non-composite relationship or change the MBO model so the application always loads the parent entities before the children.
  • Foreign key attributes are updated automatically when setting a related parent/child object. Do not directly update the child's attribute (row) identified by the foreign key.
  • Multi-level insert (MLI) operations require composite relationships.
  • A composite graph should not span multiple load groups if loading from a structure-oriented EIS.
  • A composite graph should not span more than one endpoint definition.
First/subsequent MBO relationship behavior
Multiple MBOs created from a single operation result:
  • Subsequent MBOs as child entities (if the relationship mapping is based on a subsequent MBO load argument) are supported, and the relationship is treated the same as a relationship on an attribute, meaning it does not affect MBO loading.
  • Relationships from subsequent to first MBOs where the relationship mapping is based on the load argument of the first MBO are not supported.
Local business objects
  • A relationship between two local business objects that does not have a primary key set is invalid.
You cannot create relationships between local business objects using a composite primary key.
Multi-level insert operation behavior

Multi-level insert operations do not support unidirectional one to many relationships – newly created rows in the child MBO do not display prior to synchronization in a unidirectional one to many relationship. To view details prior to synchronization from the device application, go to the pending operations screen.

Automatic setting of primary keys

Relationships require all primary keys on the source or target MBO (source or target depends on the relationship type) to be referenced in the relationship. If you design a relationship that does not include all the primary keys, a warning prompt allows you to decide whether to automatically set reference attributes to primary keys, and unset the unreferenced attributes primary keys. If you select Yes, SAP Mobile WorkSpace automatically sets the primary key, if not, SAP Mobile WorkSpace maintains the existing primary key setting, and displays a validation message according to the relationship rules.

Personalization key and default value removed from child parameter.

When creating a relationship from an attribute of a parent MBO to a load argument of a child MBO, the personalization key and default value cell of the load argument is disabled, and the personalization key and the default values, if any, are cleared, since those values are not used to load the child's value from the EIS at runtime.

It is a modeling error to have multiple relationships with the same set of links (every link has the same source and target attribute), for every relationship type (one-to-one, one to many, many to one, bidirectional, or composite), and generates a validation error.

For example, a relationship exists between customer and salesorder MBOs as: customer->id to salesorder->cust_id. The MBO developer cannot create another relationship using the same link: customer->id to salesorder->cust_id. Instead, either change the link or add new links to create the second relationship.