Tuesday, September 24, 2013

Workflow unavailability does not work if the user who is setting delegation of her/his tasks to other user has 'User Source' attribute set to LDAP

Symptoms
Workflow unavailability does not work if the user who is setting delegation of her/his tasks to other user has 'User Source' attribute set to LDAP.

Steps:
- Create User1 with 'User Source' set to LDAP.
- In Webtop, log in as User1 and go to Inbox.
- Select 'I am currently unavailable. Please direct my tasks to ...'.
- User1 does not get any error but Webtop does not respond. A blank screen is shown and browser status line says 'Done'.

Following previous steps,  setting 'User Source' to Inline Password  it works fine.

Cause
This problem is thrown if LDAP users are not configured properly, basically if the following attributes in the user's object do not contain correct values:
user_ldap_dn
user_login_domain

Resolution
About user_ldap_dn, this cannot be empty and should be the user's location in LDAP, for example 'CN=Users,DC=tssupport,DC=emc,Dc=com'. LDAP Administrator should provide this information.
 
About user_login_domain, this should be the name of the LDAP configuration object dm_ldap_config. If you have not created the object dm_ldap_config you can do so by following instructions in Support Note esg93181: How to create a LDAP config object via API. After that, then set up user_login_domain to a correct value in iAPI:
API>retrieve,c,dm_user where user_login_name='username'
API>dump,c,l
API>set,c,l,user_login_domain        
SET> <object dm_ldap_config>
API>save,c,l  

Delegate API to reassign a workflow taskto another user

If you are the assigned user of a workflow task,you can only reassign the task if the performer_flag for thecorresponding dm_activity is set to 1 or 3. However, if you areworkflow supervisor or a user with either Sysadmin or Superuserprivileges you can use the Delegate API to reassign a workflow taskto another user.

delegate,c,<workitem_id>,<user_name>

The user_name can be either a user name or a group name. Ifthe user_name is a group, only one member of the group can acquirethe dmi_workitem. The server will reassign the dmi_workitem andchange it's status to dormant.

Note that the dmi_workitem must be in the acquired statebefore you can delegate it to another user. If it is not you canuse the Acquire API as follows:

acquire,c,<workitem_id>

You can check the r_runtime_state attribute of thedmi_workitem to see what it's current state is.

Monday, September 23, 2013

Lists information about all the currently active sessions and a user-specified number of historical sessions

Syntax 

EXECUTE show_sessions

Arguments 

SHOW_SESSIONS has no arguments.

Return value

SHOW_SESSIONS returns a collection. Each query result object in the collection represents one currently active or inactive repository session. The properties of the objects contain information about the sessions. The properties returned by SHOW_SESSIONS are the same as those for LIST_SESSIONS.

SHOW_SESSIONS returns information about currently active sessions and historical (timed out) sessions. The information for each session is identical to the information returned by LIST_SESSIONS. The maximum number of historical sessions returned by SHOW_SESSIONS is determined by the parameter history_sessions in the server’s startup file (the server.ini file). There is also a startup parameter, called history_cutoff, to define a cutoff time for the history sessions. For example, if history_cutoff is set to 15 minutes, then SHOW_SESSIONS will not return any historical sessions older than 15 minutes.
For a description of the server.ini file and the parameters you can set in it, refer to the Content Server Administration Guide.

Note: You can use SHOW_SESSIONS to obtain the process ID if you need to shutdown or kill a session or server