D2 notes





https://webapp.opentext.com/piroot/edccl/v200400/edccl-agd/en/html/jsframe.htm?admin-c-configmatrix-organizing

  •  D2 API libraries are deployed to the JMS directory on the content server host

            Documentum/ Jboss/ server/ DctmServer_MethodServer/ deploy/ ServerApp.ear/ lib



Understanding Matrix Context Precedence

It is important to understand how the enabled configuration is processed in the matrix contexts (columns) from left to right.

The order of the context in the matrix is crucial because it establishes an order of precedence. When conflicts between configurations exist (for example, two or more configurations apply to a selected document or to the same user), the one associated with the left-most context in the configuration matrix takes precedence. It does this by performing DQL queries to match elements with the properties of the contexts from left to right. This precedence rule spans applications.

Best practice is to place the most specific contexts to the left and more general contexts to the right.

The “Default” context is the column at the farthest right of the matrix, and it acts as a catch all. For example, in a configuration where there are both group or type contexts, certain configurations may be bound to only those contexts so enabling them in the Default context would allow users to see additional configurations. When a user logs in, the matrix is analyzed and processed for only types involved in dm_user/group and not content related types. So if a Workspace or Widget config is bound to a type rather than a group it may not show the expected configuration enabled in the matrix.

Mapping a property page to a default context can cause the default property pages to be overridden by the matrix configuration. You can create your own property pages for users and groups. For example, you can create a user type and map a property page to that type that shows the customized property page for users.



Any change to the configuration matrix in D2–Config requires the contexts cached in the D2 App Server to be refreshed. 

This can be done from Tools -> Refresh cache in D2–Config for which the D2 URL needs to be added in the Clients URL section of Tools -> Options.


Configuring Contexts

  1. Navigate to Go to > Context from the menu bar.

  2. Click New to create a context.

If you want to create a child context that inherits the properties of an existing context, select a context and click Create from. 





A D2 Dictionary is a collection of key values and one or more sets of descriptive labels, used to provide value assistance to the end user. Dictionaries help end users by defining choice sets for property values, generating autonaming patterns, and providing input assistance during advanced searches. The choice sets ensure that uniform terminology is used across the context. As a result, it is possible to:

  • Increase the likelihood of a property being filled out by an end user.

  • Reduce labeling errors such as extraneous spaces, inconsistent plurality, and so on.


You can use two types of dictionaries:

  • Static values such as the category of a document, which is a fixed property.

  • Dynamic values such as property of an author that is accessed using a DQL query for existing users.


Dictionaries are used in the following configuration components:

  • Property pages for combo lists, labels, and so on.

  • Creation profile for type and attribute selection.

  • Autonaming for alias or languages in naming content.

  • Autolinking for using Properties labels for content placement.

  • Search mapping for input assistance during advanced searches.

  • Column mapping for use of labels and languages.


Configuring a Dictionary

  1. Navigate to Data > Dictionary from the menu bar.

  2. Select one of the options for creating a dictionary.

    If you want to create a child dictionary that inherits the properties of an existing dictionary, select a dictionary and click Create from. Understanding Parent and Child Configurations contains more information on child configurations.

    Click Restore dictionary to open a specific version of an existing dictionary.

    Click Import to import a table as a dictionary.

  3. Fill out the form as described in the following table:




If the dictionary is modified, restart the Application Server for the changes to be reflected in D2 Client.


--------------------------------------

You can use the Dictionaries widget to import or export dictionary data in the form of a CSV, Excel, or XML file. 



To import large dictionaries, use the D2JobImportDictionary job. This job helps avoid performance related problems when you use D2 Client or D2–Config for importing large dictionaries.

----------------------------------------------------------------------------------------------------------

A D2 Taxonomy is a set of values in a tree hierarchy, driven by D2 Dictionaries. 

D2 uses taxonomies in the property page to allow the display of values available for series of attributes. Like dictionaries, taxonomies help end users by defining choice sets for property values, generating autonaming patterns, and providing input assistance during advanced searches. The choices sets ensure that uniform terminology is used across the context. As a result, it is possible to:

  • Increase the likelihood of a property being filled out by an end user.

  • Reduce labeling error cases such as extraneous spaces, inconsistent plurality, and so on.




Configuring a Taxonomy

  1. Navigate to Data > Taxonomy from the menu bar.

  2. Select one of the options for creating a taxonomy.

    If you want to create a child taxonomy that inherits the properties of an existing taxonomy, select a taxonomy and click Create from. Understanding Parent and Child Configurations contains more information on child configurations.

    Click Restore taxonomy to open a specific version of an existing taxonomy.

    Click Import to import a table as a taxonomy.

  3. Fill out the form as described in the following table:





Configuring Register tables

Data > Register tables
provide all the fields
Name
Description
Application
Permission

Comments

Post a Comment

Popular posts from this blog

Virtual Documents in Documentum

Image
  What is a Virtual Document Simplistically speaking Virtual document is a document that can contain another documents . After reading the above statement first question that might arise to all is if it can contain documents how is it different from a folder? Let me make few bullet points about Virtual Document here, which will clear most of the confusions that you might have about virtual documents.   ·   A Virtual Document is a Document which can contain the type or the sub type of SysObjects  with an exception given below ·   A Virtual Document cannot contain any folders or cabinets, or any sub types of these. ·   A Virtual Document object may or may not have a content (dmr_content) attached to it but a folder or a cabinet will never have any content attached to it. Though most of the time a Virtual Document might not be having a Content file attached to it. ·   Any Object type that extents from SysObject can be converted as a Virtual Document. The ...
Read more

Using Java reflection to reduce Code and Development time in DFS

  Java reflections are one of the most powerful API’s of Java Language, this can be used to reduce code significantly. Most of the Current Enterprise application consists of different layers and they  use Value objects to transfer data from one layer to another. An inefficient way of using getters and setters of the attributes of Value objects can increase code and development time of application. Effective use of reflection can reduce code and development time significantly. So let’s take a Scenario,  I have an Object type MyObjectType extending from dm_document with 50 additional attributes, so dm_document as of Documentum 6.5 has 86 attributes adding additional 50 attributes that means we have 139 attributes for this object type. Consider a standard Web Application using DFS behind which needs to manipulate (add or edit) instances of this object type, The Service needs to add all these attributes to the  PropertySet    of the  DataObject  repre...
Read more

Few Important Object Types in Documentum

    Documentum is an Object Oriented Content Management Systems. Everything in Documentum is considered as Objects, This includes all the things that user manipulates, or the content server saves. From the User to Document, everything in Documentum is different type of Object. The whole Object types in Documentum has been structured in a Hierarchal model. Means All the Attributes from the super types are extended to the sub types. In other sense the attributes of Super types are visible and accessible from the Subtypes.   Lets see some of the important and most commonly used object types here.    Note: This is just to give an insight of Documentum Object model. Please read Object Reference Manual for very detailed information on All Object types and its attributes. Persistence Object  This type is the super type of all the object types that are saved in Documentum. Each time user creates an object instance of Persistence object type they are objects stored ...
Read more