Smart Container demo available

Our intrepid Product Manager, David Louie, has posted a demo of Smart Container functionality. Enjoy.

The elements of a Smart Container

Smart Containers are templates for the repeated construction of composite objects. Objects within a smart container are linked by folder membership and/or dm_relations and can form an object graph. One of the objects within the template is identified as the primary object – this is the object returned by the factory method invocation.

What kind of objects can be composed? Let’s take a look.

• Documents. These are documents that already exist prior to the construction of the smart container being templated. If they already exist what are they doing in the template? In many use cases the introduction of a single object initiates a workflow that eventually results in a smart container and that document is often part of the smart container. For example, a claim document might be scanned or imported from the web and this document might form the basis of a claim folder with a predefined structure. This claim document then exists before the claim folder, but is part of it. This is one example of an existing document that might be part of a template. In this case its identity would be parameterized (see later).
• Folders. These are part of templates for similar reasons to Documents. A common example might be a pre-existing folder into which you want all the smart container instances to go.
• New Documents. These are documents that you want to be newly created for each smart container instance. You can establish document state such as attribute values in the template.
• New Folders. These are part of templates for similar reasons to New Documents.
• Templates. These define existing objects that are prototypes for a new document in the smart container. For example an empty PDF form – perhaps a questionnaire. A copy of the Template will be created in the smart container.
• Placeholders. Now we enter the ranks of the exotic. Placeholders are objects that have the potential to exist post-construction, but which will not be created at construction of the smart container. They are ghost objects. It is still useful for the smart container designer to be able to model their future presence and specify their location within the smart container. Post construction, placeholders are manipulated with a special interface (IDfSmartObject) available off the primary object. An example might be an approval document.

Templates can have parameterized elements. This is necessary to support parts of the template that can only be resolved at runtime (like the identity of the claim document mentioned above). You refer to runtime parameters within the template using a string substitution syntax – ${foo} resolves to the value of parameter ‘foo’ (the braces are required). At runtime, the values for parameters are provided by the invoker of the factory method in a Map.

Smart containers need to be anchored in a repository somewhere. By default, of course, any sysobject or folder will be created in the user’s home cabinet. If you want an explicit location then you can model this by including a Folder element in the template and linking the object(s) to it. If the folder to which objects are to be anchored is determined at runtime, then the identity of the Folder element would be parameterized. By the way, this is an example of when the root of a hierarchy is not the primary object.

That’s about the whole story. The rest is detail.

What’s a Smart Container?

In Documentum 6.5 release there is a new capability called Smart Container. What’s that about?

In many applications there is a need for the repeated construction of composite objects. For example, in a police application there might be an incident folder which contains a subfolder for affidavits, another for officer reports, perhaps a structured interview form. Typically you would program the construction of this composite structure by hand using DFC or DFS primitives. This can take considerable time and requires a strong skillset. Smart Containers offer a way to declaratively specify a template for such composite structures and provides a runtime factory that observes the declarative specification.

In Composer there is a graphical editor with which you can define your template (give it a try). The template is built in terms of objects and relationships. Once you have completed your template you can install it into the docbase using normal Composer install procedures. The result will be an instance of dmc_class whose content is an XML representation of the template. Attached to the object is an aspect that contains the logic to interpret the template. In effect it is a factory object.

In order to construct a new composite, as declared in your template, you would do the following …


IObjectFactory factory = (IObjectFactory) session.getObjectByQualification("dmc_class where object_name='myTemplateName'");
IDfPersistentObject myCompositePrimaryObject = factory.newObject();
myCompositePrimaryObject.save();


That’s it. There is no more code.

You get the primary object returned and all the others are linked (in folders or by dm_relations) according to your declarative template once you save the primary object.

IObjectFactory also has a signature that allows you to provide a Map of parameter values if your template is parameterized. Template parameterization is important to allow for runtime context – the identity of a Captiva-scanned initial incident report maybe.

The IObjectFactory interface is defined in the dmc_class.jar which you can extract from the dmc_class TBO module in the docbase.