I’ve spent the majority of the last 2 days trying to get DA 6SP1 Patch Release to install properly on IBM Websphere 6.1.0.23. It had been a while since I’d last done the install, and I fell into the same traps as last time, forgetting where to set the class loader and so forth. After getting past these I was left with the application unhelpfully still showing a white screen and error messages that revealed (looking back) very little about the true nature of the problem. Having finally conquered the problem, I thought I would provide the steps necessary so that anyone else trying to get a WDK application working on Websphere as at least one more thing to try.

Grab a copy of da.war from the EMC Powerlink Download site.

• Unpack da.war and add the following files to a directory
• Put dfc.properties into WEB-INF/classes (As described in the deployment guide)
• ibm-web-ext.xmi & ibm-web-ext.xmi goes into WEB-INF – https://solutions.emc.com/emcsolutionview.asp?id=esg91105
• Find a copy of xml.jar on the Websphere App Server in ‘Websphere\AppServer\java\jre’ and put in ‘WEB-INF\lib’ - https://solutions.emc.com/emcsolutionview.asp?id=esg93106
• Install the application using the IBM Administration Console.
• Change the order the classes are loaded in by expanding the Applications node and click the Enterprise Applications node. Select the application called da_war (or equivalent wdk app). Click the Manage Modules link. Click the da.war link. In the Class loader order drop-down list, select the option ‘Classes loaded with application class loader first’ – https://solutions.emc.com/emcsolutionview.asp?id=esg93177
• You can then save and start the application.

The xml.jar file is appropriate for D6SP1 only, previous D6 versions have a slightly different set of instructions (see linked support note). Any feedback, corrections, suggestions greatly appreciated.

Having stepped away from trying to get Documentum running on linux, I’ve been working on bringing the permissions through into our custom Lotus Notes/Documentum client. At the moment when a user imports a document to a given folder it does no permission checking before the fact, just errors nastily when it can’t write the document. A short stop by Prasad’s blog gave me a query to start from.

SELECT i_all_users_names as users FROM dm_group
WHERE group_name IN (SELECT r_accessor_name FROM dm_acl
WHERE object_name IN (SELECT acl_name FROM dm_sysobject
                       WHERE r_object_id = '0c0xxxxx80009e16'))
ORDER BY i_all_users_names

This is superb, but it doesn’t actually go far enough. If I was to attach it to my application and tell it not to let me import anything into the folder if my name wasn’t on the list I wouldn’t be able to copy anything into my home cabinet. It enumerates the members of any group within the ACL but doesn’t deal with named users & also the owner.

This will give me a chance to show off what you can do with my ActiveDocumentum project. ActiveDocumentum is a working name for a JRuby gem written to provide functionality similar to what can be found in ActiveRecord, with the addition of repeating attributes and other DQL specific items. While the final code for the below function may end up being in Java or .Net. Doing it using ruby allowed me to very quickly scope out the logic of what would need to be done to get the permission that a user had on an object (NB: If there is a way to do this simply with DQL I’m not aware of it):

require 'config/environment'

def get_effective_permission(r_object_id, user = nil)
  return 0 if user.nil?
  folder = DmFolder.find(:first, :columns => "owner_name, owner_permit, acl_name", :conditions => {:r_object_id => r_object_id})
  current_level = 0
  if folder.owner_name.eql? user
    current_level = folder.owner_permit
  end
    acls = DmAcl.find(:all, :columns => "r_accessor_name, r_accessor_permit, r_is_group", :conditions => "object_name = '#{folder.acl_name}' ENABLE(ROW_BASED)")
    acls.each do |acl|
      if acl.r_accessor_name.eql? user
        current_level = acl.r_accessor_permit if acl.r_accessor_permit > current_level
      elsif acl.r_is_group.to_s.eql?('1') and not acl.r_accessor_permit.nil?
        group = DmGroup.find(:first, :columns => 'r_object_id, i_all_users_names', :conditions => {:group_name => acl.r_accessor_name})
        current_level = acl.r_accessor_permit if acl.r_accessor_permit > current_level and group.i_all_users_names.include?(user)
      end
    end
  end
  return current_level
end

r_object_id = '0c0xxxxx80009e16'

user = 'John Doe'

puts get_effective_permission(r_object_id, user)

As you can see the above function takes a user and returns the highest permission that they have, by checking if they’re either directly listed on the ACL or in one of the groups on the ACL. The bottom line is that with ActiveDocumentum I can write less lines of code for one off scripts that I have to create, and include complicated logic that is lacking in straight DQL scripts. I will be posting more details on this in the near future.

The following comes in very hand when you’re trying to troubleshoot authentication problems. Go into DA and find the Administrative Methods; there should be one called ‘SET_OPTIONS’  which allows you to put in trace_authentication and set it to true. All authentication attempts will then be logged to the docbase log.

A few notes:

• If you have a clustered setup you’ll need to make sure it gets turned on for both content servers (you can specify which you’re connecting to when you login)
• Make sure you turn it off when you’re done troubleshooting, it adds a performance overhead not to mention chewing up log space.
• Restarting the content server will cause it to turn off…to turn it off without restarting the content server just set it to false in the same place you turned it on.