Tuesday, April 2, 2013

How to change the user_name of a dm_user

In a Documentum repository users are uniquely identified by the user_name attribute. Being a key, the user_name value is used in related objects (for example: owner, r_modifier, r_creator, r_lock_owner, etc.) stating that this user performed an action on this object.
In certain cases we need to change the user_name value: for example when we want to create a new user, but an old one (perhaps deactivated) already exists with the same user_name.
Being a key, we can't simply update this value, you won't even be able to modify it on user property screen. Here are the ways to accomplish this:

1. Manual renaming
There's a simple tool called Reassign User which invokes the dm_UserRename job (Renaming users - how dm_UserRename job works explains how this job works):
a. (Optional) Create a new user with the user_name you want to rename the old user to.
b. Open DA, go to Users node in browsertree, find the desired user, right click on it and choose Reassign User. On the opened page enter/select the new user, select the option to run the reassign job now (and change other settings if required).
c. (Optional) As soon as the dm_RenameUser job has completed, you can remove the original (old) user if it's not needed anymore.
Note that you can skip the creation of a new user and just enter the new user_name on the Reassign User page, it will handle the modification of user_name itself.

2. Automatic renaming
If we want to rename many users, the manual approach would be really annoying, so as usual we turn to some DFC coding.
Renaming users in DFC is quite straightforward, it's enough to call the rename method:
 IDfUser user = session.getUser("userA");
 user.renameUser("userB", true, false, true);
 user.save();


Here's the method description from the API:
void renameUser(String userName,
                boolean isImmediate,
                boolean unlockObjects,
                boolean reportOnly)
                throws DfException

    Renames this user. If this is a new user, the attribute value is set. If this is an existing user, this method invokes a job to rename user.
    Parameters:
        userName - user name to be set or renamed to (existing user)
        isImmediate - Detemines if the job should be run immediately or run on schedule.
        unlockObjects - control if the objects should be unlocked when renaming user. If this is a new user, this parameter does not take any effect.
        reportOnly - control if the job created is to report or actual rename. If this is a new user, this parameter does not take any effect.

How to register and unregister types for indexing

Documentum uses fulltext indexing to enable search on all document properties as well as its contents.  How does fulltext indexing work?
Indexing is performed by a dedicated server (FAST, xPlore, etc.) that polls the queue of the fulltext user. In order to index certain (sub)types of documents, you must register certain events of these types for index user. Thus when a registered event occurs on a document of the registered type, a queue item is created in the fulltext user's queue, which consequently is processed by the Fulltext indexing server, by indexing the document. The events to register are those that usually change the object metadata and/or content: dm_save,dm_readonlysave,dm_checkin,dm_move_content,dm_destroy

By default, (in previous versions of Documentum) all dm_sysobject types and its subtypes are registered for indexing. Usually you don't need all the dm_sysobject to be indexed, so before registering your custom types, you should unregister the dm_sysobject first. You can do that by running the following API script, being connected with the fulltext user (dm_fulltext_index_user):
(Note: if you don't know the password for dm_fulltext_index_user you can generate a login ticket by running following API with a superuser: getlogin,c,dm_fulltext_index_user Read more details about this trick in: How to login to the repository with a ticket).

API for unregistering indexing:
unregister,c,[TYPE_ID],dm_save,,F
unregister,c,[TYPE_ID],dm_readonlysave,,F
unregister,c,[TYPE_ID],dm_checkin,,F
unregister,c,[TYPE_ID],dm_move_content,,F
unregister,c,[TYPE_ID],dm_destroy,,F

[TYPE_ID] is the r_object_id of the dm_type object
Note: If you have more Index servers, you should have an index user for each, so run the unregister script for each user.

You can also do that by unchecking the 'Enable Indexing' checkbox on dm_sysobject type properties in DA.

You can register a custom type for indexing in 2 ways:
1. By executing the following API script, with the fulltext user (dm_fulltext_index_user):
register,c,[TYPE_ID],dm_save,,F
register,c,[TYPE_ID],dm_readonlysave,,F
register,c,[TYPE_ID],dm_checkin,,F
register,c,[TYPE_ID],dm_move_content,,F
register,c,[TYPE_ID],dm_destroy,,F


[TYPE_ID] is the r_object_id of the dm_type object
Note: If you have more Index servers, you should have an index user for each, so run the register script for each user.

2. Manually, by using DA: Open Types node in browsertree, find the desired type, open its properties and check the 'Enable Indexing' checkbox.

To check which types are currently registered for indexing, use the DQL:
select name from dm_type where r_object_id in (select distinct registered_id from dmi_registry where user_name='dm_fulltext_index_user')

Friday, March 22, 2013

D2 - Configuring Lifecycles

D2 does not use Documentum standard Lifecycles (dm_policy objects), it comes with a new paradigm so we should be careful to details because it doesn't work as we are used to.
As the D2 interface and functionality is not very customizable, much of our custom logic (actions) can be attached to Lifecycle states. That's why it's important to know and exploit the potential of D2 Lifecycles.

A D2 Lifecycle is defined as any other configuration module, in D2-Config application, configurations being saved in a d2_lifecycle_config object.
After creating a new LC configuration, create the states, specify the first (start) state, select if actions should be executed on start and optionally an alternate attribute holding the current state (by default it's a_status). For each state you have the following configurations:
1. Entry condition: a condition that can be applied on a list of items:
 a) VD Children: checks target state of Virtual Document children (if current item is a VD)
 b) Checked by Method: you can specify a (custom) method that (can get some arguments) will perform required checks
 c) On group: Checks if current user is in the group specified either in free text (as a constant), either saved in a property, or part of a Dictionary.
 d) On linked document: checks if the linked document is in the specified state.
 e) On property: checks performed on the value of an attribute
 f) On rendition: checks existance of a rendition
 g) On uniqueness: runs an existing uniqueness check
 h) Permission: checks if current user has the specified minimal permission on the object.
For each option you can specify a message that will be displayed as a warning in case of condition is not met (and the object will not enter this state).

2. Actions: are executed when the object enters the current state. Possible action types:
 a) on VD children: applies the selected state on VD children
 b) Apply autolink, autonaming, parameters, security : applies the corresponding configuration(s) module(s) that is enabled for the active context.
 c) Apply method: runs the specified method (standard or custom) with optional arguments
 d) Change linked document state: changes the state of the linked documents (you must specify relation type and direction)
 e) Change other versions state: changes the state of the other versions of the current object
 f) Copy repeating property: copy the values from one repeating property to another (with modes: remove all existing, append, insert before)
 g) Make version: creates a new version (version type is selected) of the object
 h) Manage distribution: launch or stop the specified distribution configuration
 i) Send in Workflow: starts a Workflow with current object as attachment (select workflow configuration, name, notes)
 j) Send email: send emails according to the selected mailing list
 k) Other types: Mark, Unmark Set property, Set repeating property, Snapshot, Work offline, Remove other versions, Rendition request

NOTE: It's important to add an action 'Set property' for attribute a_status with value equal to current LC state, because D2 does not update it automatically when object enters a new state, but only on the first state (don't ask me why :\)
As you see the range of pre-configured actions is pretty big, but if none of it fits your requirements, you can always create a custom method and call it by using the action type 'Apply method'.

3. Next state: specify which is the next(or previous) state and the following settings:
 a) Type of transition: promote, demote, suspend, resume, restart
 b) Dialog box: a property sheet configuration, which will appear after you start transition, allowing you to view/update required attributes
 c) Action to perform (Checkin, Export file, Insert PDF): action that will be performed when transition occurs
 d) Trigger event for transition: the event that will automatically trigger transition to this state
 e) Menu label: Label that will be displayed on the transition menu item - this is mandatory, otherwise the menu item will not be displayed
 f) Confirmation message: A confirmation message that will appear in a popup forcing the user to confirm the transition
 g) Other settings: Electronic signature/Intention required, Intentions dictionary

NOTE: If you won't specify a menu label for state transition, the corresponding (context) menu item will not be displayed and you won't be able to transition to next state.

4. Transition condition: conditions that can be performed on different items (like the entry conditions). If the condition is not met, the specified message is displayed and transition does not occur.

Things to remember:
1. The extended permission 'Change State' on an object does not impact D2 Lifecycle transitions (unlike standard LC where this permission is required), so you must add this constraint manually in LC configuration if required.
2. For each LC state add an action 'Set property' for updating attribute a_status with new status (it's not done automatically)
3. For each next state specify the Menu label (otherwise the menu item for this transition will not appear in the LC menu)

D2 - Using dependent fields on property sheets

D2 offers 2 ways of defining dependent fields on property sheets: Taxonomies and DQLs.

1. Taxonomy

D2 Taxonomy configuration
To use a taxonomy, you must first configure (in D2-Config) N Dictionaries, then a taxonomy with N levels corresponding to N fields/attributes. For each level of the taxonomy specify the corresponding dictionary and desired values.


On the property sheet add the dependent fields (dropdownlists), then for each specify the type (Taxonomy), choose taxonomy name, the corresponding level and previous/next properties that must be updated when current field is changed. If no values are selected, the dependent fields will contain all the values from the corresponding Dictionary.
Here's a simple Country-City dependency:
D2 property attribute taxonomy typeD2 property sheet dependent attributes

2. DQL

D2 property sheet refresh dependent attributesOn the first (master) attribute configuration add the dependent attributes in the field: 'In case of modification, reinitialize the following controls'.


On dependent attributes select type: DQL, then enter the DQL:
select dependent_attr from some_type where '$value(master_attr)'='' or master_attr='$value(master_attr)'
D2 property sheet attribute DQL
If you don't want to populate the dependent attribute until the master attribute is selected/entered, exclude the DQL clause: '$value(master_attr)'=''

D2 Query Forms - add dynamic filters to the DQL

D2 client version 4.0 does not include an advanced search, only quicksearch and query forms being available. (Advanced search was added in version 4.1).
Query forms however are not very powerful, because you must set a static DQL query based on values entered or selected on the associated property page.
If we define a property sheet with 1-2 attributes which are always populated, the DQL is quite trivial.
But what if we want a more generic query form, with multiple fields (filters) which are optional? How to specify in a static DQL which filters should be used (and skip the empty ones)?
You can do that by using a query like this:
select * from custom_type where ('$value(attributeA)'='' or attributeA='$value(attributeA)') and ('$value(attributeB)'='' or attributeB='$value(attributeB)')...and ('$value(attributeN)'='' or attributeN='$value(attributeN)')

So if attributeA field from the propertysheet is empty, the clause '$value(attributeA)'='' will return true, the second part being meaningless; if it's not empty, the second part will be evaluated filtering results by the value entered for the attribute.
In a simmilar way, you can also use other operators: >, <, like, etc. (but keeping unchanged the first part - check for empty string).

Now let's see what happens with Date fields. We must convert the string value into a Date:
('$value(attrDate)'='' or attrDate>date('$value(attrDate)','mm/dd/yyyy'))

But if the string is empty, the resulting DQL clause will be:
(''='' or attrDate>date('','mm/dd/yyyy'))
and this will fail because empty string can't be converted into a Date.
There's a workaround for that: define and use default values (for example: $TODAY, $NOW) for Date attributes.

Thursday, March 21, 2013

D2 Installation Troubleshooting

During D2 installation there are some steps you should pay attention at, while others are not described in the installation guide.
Below you will find some notes and issues faced during installation of D2 product.
I Back-end installation on the Content Server
1. Stop all Documentum services before the instalations.
2. If you're upgrading D2, delete the preferences objects (DQL: delete d2c_preferences objects) and remove the poi*.jar files from ServerApps.ear lib folder.
3. While installing D2 libraries for the Content Server and JMS, enter a correct path to the ServerApps.ear lib folder on JMS (for Dctm 6.7 SP1 it does not contain APP-INF), as well as the path to the DFS SDK of same version as your CS.
4. Remove from the ServerApps.ear lib folder the following jars: itext.2.0.2.jar, xercesImpl-2.7.1.jar
(optional: if a recent patch has been installed for the CS, replace the dfc.jar from ServerApps.ear lib folder with the newer one)
5. Check and add (if not done by installer) the D2.jar file location to the CLASSPATH environment variable of the server hosting the CS.
6. Configure logback.xml file (which contains logging settings) from ServerApps.ear/[APP-INF/]classes folder. Note: In Document 6.7 SP1 the classes folder is created by the installer directly in ServerApps.ear folder, though it is normaly present in ServerApps.ear/APP-INF folder. Most probably it's a bug, so I suggest to copy the newly created xml files (after log configuration) from ServerApps.ear/classes to the ServerApps.ear/APP-INF/classes folder.
7. For DARs installation: if using Dctm 6.6 and later in the installation wizzard select 'Do not install DocApp/DAR', just select a path for extraction and consequently install the dars (D2.dar, D2Widget-DAR.dar) manually with DarDeployer. For version 4.1 install also CollaborationServices.dar (also on global repository if it's not the same one).
If your installation owner is not 'dmadmin', create an installparam file with following content:
<?xml version="1.0" encoding="UTF-8"?>
<installparam:InputFile xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:installparam="installparam">
    <parameter key="dmadmin" value="my_install_owner"/>
</installparam:InputFile>

Use this installparam file during DARs installation.

8. Create registered table for auditing:
register table dm_audittrail_s (event_name string(64), user_name string(32), time_stamp time, object_name string(255), string_1 string(200), string_2 string(200), string_3 string(200), string_4 string(200), string_5 string(200))
update dm_registered object set object_name = 'D2 Audits', set owner_table_permit = 1, set group_table_permit = 1, set world_table_permit = 1 where object_name = 'dm_audittrail_s';


II Front-end installation on Application Server
1. After extracting the webapps with the installer, configure the following files per application:
 a) D2-Config:
    - Path: D2-Config.war\WEB-INF\classes
    - Files: D2-Config.properties, dfc.properties, log4j.properties (add if missing), logback.xml
 b) D2-Client:
    - Path: D2-Client.war\WEB-INF\classes
    - Files: D2-Client.properties, dfc.properties, logback.xml
 c) D2FS (not present in 4.1):
    - Path: D2FS.war\WEB-INF\classes
    - Files: dfc.properties, logback.xml
 d) D2:
    - Path: D2.war\WEB-INF\classes
    - Files: applicationContext.xml, logback.xml (+ 4.1: logback-base.xml, D2FS.properties, dfc.properties)
 * Note: URL of D2FS in applicationContext.xml (not required for 4.1) must contain the host name, not localhost (because this URL also serves as download URL for files)
2. Widget View plugin configuration:
a) If you don't find Widget plugin jars in the package, launch the D2—Widget-Install.jar installer to deploy the jars to some location
b) Copy in \D2-Config\WEB-INF\lib the libraries: D2-Constants.jar, D2-Widget-API.jar (in addition D2-Widget.jar in case of patch 02)
c) For versions previous to 4.1: Copy D2-Widget-Plugin.jar to D2-Config\WEB-INF\classes\plugins
(Note: Weblogic does not locate correctly the plugin jar when relative path is specified, so you have to deploy the jar to external location and specify full path in D2-Config.properties, for example: D:\EMC\D2\plugins\D2-Widget-Plugin.jar)
d) For versions previous to 4.1: Add the path to the plugin in \D2-Config\WEB-INF\classes\D2-Config.properties: plugin_1=plugins/D2-Widget-Plugin.jar (or full path to jar location for Weblogic)
Note: In version 4.1 the plugins are included and configured by default in D2-Config (however if Weblogic does not find them, use an external path as shown above).

III Common issues

Issue 1 - Error while installing the DAR file: Owner object (user OR group) 'dmadmin' not found in the target repository
Solution:
As described above, create a file nodmadmin.installparam with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<installparam:InputFile xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:installparam="installparam">
    <parameter key="dmadmin" value="my_install_owner"/>
</installparam:InputFile>

On the DarDeployer interface, under DAR Details, click Browse next to Input File, and select the nodmadmin.installparam you've created.

Issue 2 - File transfer fails in D2
Solution: Check the D2FS URL in the \D2\WEB-INF\classes\applicationContext.xml - it should use the server name, not 'localhost'.

Issue 3 - Tomcat PermGen Space error
Solution: Add/modify the following Java option in your Tomcat environment: -XX:PermSize=256m -XX:MaxPermSize=512m

Issue 4 - D2-Config menus do not show all items (not sized correctly)
Solution: Configure Internet Explorer as follows:
  - Allow popup windows
  - Allow windows to resize by script without size or position constraints
  - Allow the browser to use tabbed browser settings when encountering a popup window

Documentum D2 Overview

Documentum D2 Overview...