Creating Relationships Between Entities in Different Object Stores

Content

The ability to create one-to-many “parent-child” reflective relationships between objects is one of the most powerful features of the Content Engine metadata model. The feature is used extensively in both system-defined classes and custom applications.

However, what is not common knowledge, is that such relationships are not limited to objects residing in the same object store but can span object stores. In other words, it is possible to create a relationship which allows the “child” objects to be in different object stores from their “parent”. This technote describes how to accomplish that.

We will first recap the steps to define an “ordinary” within-object store reflective relationship and then move on to how to adjust the procedure to create a cross-object store variant.

To do this we will consider a pair of classes named Men and Boys placed in a one-to-many relationship. In this scenario one man can have many nephews, but each nephew can have only one uncle. The procedure creates relationships between instances of documents, but any class type can be used.

1. Create a class called Boys.
2. Create a class called Men.
3. Right-click on Document Class and select New Association Property from the menu.
   
4. Complete the wizard as follows:
   1. Add a property called Uncle and add it to the Boys class
      
      
   2. Create a second property call Nephews and add it to the Men class.
      
      
      In this scenario since a boy can only have one uncle, but each uncle can have many nephews and the first association added a property to the Boys class, we set the relationship to Many to One.
      
   3. For this scenario, use the default dependency option: Independent.
      
   4. To enable relationships between objects in different object stores, select the “Allows foreign object” checkbox and identify the permissions required on the objects in the “other object store.
      
   5. Click Finish
      
5. The next step is to verify the required property templates have been added to the correct classes.
   1. Verify that the Boy class has a single-valued object property called Uncle.
      
   2. Verify that the Men class has a property called Uncle with no cardinality set.
      

Now that the definition of the relationship is established, specific instances of Men and Boys can be related by setting the Uncle property of a Boy instance to reference a specific instance of Men.

To test the setup

1. Add some documents that use the Boys class
2. Add some documents that use the Men class
3. Select one of the Men class instances and use the Copy Object Reference option in the Actions menu
   
4. Access the properties of one of the Boys documents and find the Uncle property
   1. Select the down triangle to the right of the Uncle field
   2. Select “Paste Object”
      
5. Repeat step 4 with another document in the Boys class, then look at the Nephews property on the related Men document, and you should see something like this
   

Once the Boys instances have been related to a given Men instance, the related objects can then be retrieved via the collection contained in the Nephews property of the Uncle instance.

To make a relationship which allows the Men and Boys instances to reside in different object stores, make sure you select the Allows Foreign Object store option (as we did in Step 4d) in the New Association Property wizard.

Notes

• The Allows Foreign Object can only be set as part of creating the association. It is not possible to “retrofit” a cross-object store capability to an existing relationship.
• The option Allows Foreign Object, as its name implies, allows an object from another object store to be set as the value of the property, it does not require that it be foreign.

Having completed the definition of the relationship in one object store, the Boys and Men classes must then be defined in any other object store which will contain participating instances of either class. The classes must be defined in a way that allows the classes and properties to be referenced by matching ids in each pair of Boys-hosting and Men-hosting object stores.

There are several ways this can be done

• After defining the classes and properties in one object store, use FileNet Deployment Manager (FDM) to export the class definition and property templates from the initial object store and import them into every other object store. Use the FDM option to maintain the GUIDs on the objects. With this process the primary ids of all the entities will be the same in each object store.
• Create the property templates and class definitions programmatically, ensuring that the Factory..createInstance methods are called with predefined ids, so that again, the primary ids of the entities will be the same for each object store.
• Use the manual procedure provided at the start of this technote in each object store. This will create the entities with different primary ids. Then use the aliasing mechanism to “align” the classes and properties across object stores.

The following procedure describes the aliasing mechanism required if you use the manual procedure to create the entities in different object stores. The procedure must be repeated in ACCE for each pair of participating object stores and for each of the four entities (the two class definitions and the two property templates). You will need to use multiple panes in the same browser session to complete the procedure.

1. From the first object store, open the entity in question, switch to the Properties tab and copy the entity's ID property value.
2. From the second object store, open the corresponding entity, switch to the Advanced tab, click to Assign an alias and paste the ID copied above.
   
   
3. Now reverse the process, copy the ID of the entity from the second object store and assign it as the alias for the entity in the first object store.

   If you have more than two participating object stores, at the end of the process each entity will have multiple aliases, one for each foreign object store.