EMC Documentum - xCP 2.x Troubleshooting

1© Copyright 2015 EMC Corporation. All rights reserved.
xCP
Troubleshooting
Ahmed Ezzat

Agenda
 Before logging a service request
 Common issues
 Stateless and Stateful Process Execution
 Supported ways to change a process template
 Migrating applications from xCP 1.x to xCP 2.x
 Type Adoption limitations and issues

Before logging a service request
 Check Knowledgebase (http://support.emc.com/search): You can search our
Knowledge Base from service center, this is the same Knowledge Base used
by Support representatives.
 Check Documentation: Refer to
– xCP Release Notes for information regarding the supported environment for xCP environment
components.
– xCP Deployment Guide for information regarding deployment of xCP environment.
– xCP Designer Help for information on how to use xCP Designer and description for each component
of xCP Designer and how to use it.

Gather products version information
 Content server version, patch level and Content server OS
 Database server version
 Process Engine version and patch level
 Process Integrator version and patch level
 xCP Designer version and patch level
 xMS agent version and patch level
 xCP runtime application server version

Gather products logs
 Docbase log (<docbase_name>.log) under %DOCUMENTUM%dbalog
 Java Method Server log (server.log) under
%Documentum%<jboss_version>serverDctmServer_MethodServerlog
 Process Engine logs (bpm.log and bpm-runtime.log) under
%Documentum%<jboss_version>serverDctmServer_MethodServerlogs
 Process Integrator logs (bps.log and bps-all.log) under %Documentum%logs
 xMS agent logs (archive logs folder) under
<application_server_home_dir>webappsxms-agentWEB-INF
 xCP runtime application server logs

Gather BPM dfc traces
 If the issue is happening while running a stateful process instance, enable
DFC tracing on the BPM application on the JMS by adding the following
parameters to the dfc.properties under
%DOCUMENTUM%<jboss_version>serverDctmServer_MethodServerdeploymentsb
pm.earAPP-INFclasses
dfc.tracing.enable=true
dfc.tracing.verbose=true
dfc.tracing.include_rpcs=true
dfc.tracing.mode= standard
dfc.tracing.include_session_id=true
dfc.tracing.file_prefix = dfcbpmlog

Gather BPM dfc traces
dfc.tracing.print_exception_stack = true
dfc.tracing.timing_style=date
dfc.tracing.date_column_width=12
dfc.tracing.date_format=HH:mm:ss.SSS
dfc.tracing.max_stack_depth = 10
dfc.tracing.max_backup_index = 1
dfc.tracing.max_file_size = 100MB
dfc.tracing.dir=<Choose an existing directory for log files>
 After reproducing the issue, gather dfc traces and disable dfc tracing by
changing the following parameter
dfc.tracing.enable=false

 If the issue is happening while running an inbound activity, enable DFC tracing
on the BPS application by adding the following parameters to the
dfc.properties file under <application_server_home_dir>webappsbpsWEB-
INFclasses
dfc.tracing.mode= standard
dfc.tracing.file_prefix = dfcbpslog
Gather PI dfc traces

Gather PI dfc traces
dfc.tracing.timing_style=date
dfc.tracing.date_column_width=12
dfc.tracing.date_format=HH:mm:ss.SSS
dfc.tracing.max_stack_depth = 8
dfc.tracing.include_session_id = true
dfc.tracing.max_backup_index = 5
dfc.tracing.max_file_size = 100MB

Gather xCP application dfc traces
 You can also enable DFC tracing within xCP application by adding the following
parameters to the dfc.properties file under
<application_server_home_dir>CustomConf
dfc.tracing.max_stack_depth=-1
dfc.tracing.include_rpc_count=true
dfc.tracing.mode=standard
dfc.tracing.print_exception_stack=true
dfc.tracing.file_prefix = dfcxcplog

Gather xCP application dfc traces

Provide sample application or steps to reproduce the issue
 Provide a sample application that reproduce the issue, this will help on solving
the service request more quickly
 Alternatively, you can provide the steps required to reproduce the issue in an
application created from scratch
 You can also provide the main application, but normally this may take longer
time than the previous two options. Because full applications depend on a lot
of required steps that are needed in order to be able to deploy these
applications in our internal environment

Gather Fiddler traces
 If the problem is a UI issue, it would be very beneficial to provide fiddler
traces, you can gather fiddler traces using the below steps
1) Open the browser and delete browser cache. Most browsers provide shortcut Ctrl+Shift+Delete to
open the dialog to clear the browser cache.
2) Start Fiddler. Ensure that “File -> Capture Traffic” is on.
3) In the browser type the application login URL including “?nominify” option. For example:
http://apphost:port/AppName/signin.jsp?nominify
4) Perform required steps to reproduce the issue.
5) Once it is reproduced, save the Fiddler traces (Save -> All Sessions) to “.saz” file.
Note: It is very important that browser cache is cleared even before the login page is loaded.

Gather HTTP Archive(HAR) file
 Sometimes there are some regulations that prohibit the installation of new
software like Fiddler on the required environment. In such cases, Google
Chrome can be used to capture the network traces as following
1) In Chrome, hit the sign in URL with nominify(example:- For example:
http://apphost:port/AppName/signin.jsp?nominify)
2) Open the browser developer tools by hitting F12.
3) Go to 'Network' tab and click on 'All' if not already selected.
4) Right click on the refresh button on the browser and select 'Empty cache and hard reload'. This will
take care of clearing the cache.
5) Login to the application and perform the steps.
6) Select the entire network calls using Ctrl+A. right click and select 'Save as HAR with content'
7) Save the file in HAR format.

 Issue: Sometimes while redeploying xCP application, the redeployment
operation lasts for ever and it never gets completed successfully nor it fails.
 Solution:
1) Stop the application server instance that hosts the xCP application
2) Recheck the following Java options for that application server
▪ -XX:MaxPermSize=512m
▪ -XX:+UseParallelOldGC
▪ -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n
▪ -Dlog4j.configuration=<application_server_home>bamlog4j.properties
3) Set Initial memory pool of the application server to 1024 MB and Maximum memory pool to
2048 MB.
4) Start the application server and redeploy the application
Common Issues
xCP 2.x applications redeployment issues

 Issue: When redeploying an xCP 2.x application, sometimes the redeployment
completes successfully. However users can’t access the application, as it has
been deleted from the webapps folder of the application server.
 Solution: Make sure that context tag opening in the context.xml under
<application_server_home_dir>/conf directory is as following:
<Context antiJARLocking="true" antiResourceLocking="true">
Common Issues
xCP 2.x applications redeployment issues

 Question: Can xMS reside on the same application server that will host xCP
applications?
 Answer: No, xMS agent can’t be deployed on the same application server that
will host xCP applications.
 Reason: xMS can’t reside on an application server that have the context tag
opening in the context.xml under <application_server_home_dir>/conf as
following:
<Context antiJARLocking="true" antiResourceLocking="true">
This will cause xMS Agent to lose newly updated information in the
registered environment after each application server restart.
Common Issues
xMS agent Installation Restrictions

 Issue: After application redeployment while trying to use the Preview mode,
application developer got the following error message while trying to access
the application through Preview mode
HTTP ERROR 404
Problem accessing /<application_name>/reloadcontext. Reason:
Not Found
Powered by Jetty://
Common Issues
Preview mode is not working after application redeployment

 Solution:
1) Close xCP Designer
2) Delete the folder
<xCPDesigner_root>Applications<application_name><application_name>targetm2e-webby
3) Open xCP Designer
4) Open the application in the Preview Mode
Common Issues
Preview mode is not working after application redeployment

 Issue: Some documents are not getting loaded in xCP Viewer however there
are a lot of other documents that are getting previewed properly.
 Solution: Refer to Configuring xCP to Interact with CTS section in xCP 2.x
Deployment Guide to check the exact steps to configure xCP to interact with
CTS. This will enable the xCP application to send real-time requests for CTS
to process.
You should perform this configuration after you deploy the xCP application.
This configuration is required only when you provisioned the target
environment manually.
Common Issues
Documents are not getting loaded in xCP Viewer

 Drag and Drop works only for HTML5 browsers so it wont work for IE9.
 Drag and drop should be enabled for the widget.
 Drop action should happen on the folder node. If a document is dropped on
another document or object, it will be ignored.
 Import Action Flow should be configured for the folder type and ‘Invoke Action
Flow on Drag And Drop’ option should be checked.
 Right click on that folder on content tree or result list and check if that context
menu option for import appears.
Common Issues
Drag and Drop troubleshooting

Common Issues
Drag and Drop for Outlook Messages configuration
 Starting from xCP 2.2, Drag and Drop from Outlook allows you to drag and
drop messages from the Outlook mail client to an application widget. The
following steps needs to be done in order to be able to use this feature.
1) Install MailApp.dar
2) Import msgtf.messagetypefragment-1.0.0.jar to the xCP application
3) Create Content UI | add Mdmo Message Aspect [msgtf] type fragment
4) Create Page Fragment for the Content UI created above

Common Issues
Drag and Drop for Outlook Messages troubleshooting
 If the Drag and Drop from Outlook feature is still not working, you can check
the following
1) Check if client plugin is enabled.
2) Check if you are able to drag and drop other types of files from desktop.
• If you are not able to drag and drop files from desktop, drag and drop might not be enabled on that widget
3) Check if Applet is loaded correctly.
• Check Server Side Configuration to Ensure that HTTP session of browser is available to the Applet
• Check XCP Applet logs:
o Go to Control panel -> Java ->
o Advanced Tab -> Debugging -> Select “enable Tracing”/”enable logging”/”show applet lifecycle exceptions”
o Advanced Tab -> Java Console -> Show Console
o Open browser and access the application.
o Do operation which is causing any issue
o Capture the logs in Java console

 A stateless process runs synchronously as a single transaction by session
user. It is executed by the user logged into application and not by the
performer configured on any activity. The synchronous transaction commits
only at the end of the process. If an error occurs during the process, the
entire process fails.
 A stateless process cannot have manual activities, timer settings in activities,
inbound Start From activities, inbound Wait For activities or trigger conditions
(or events) in activities.
 The executor of the stateless process runs all activities in the stateless
process. It overrides the performer set in the Execution tab of the system
activities.
Stateless and Stateful Process Execution
Stateless Process Overview

 When User initiates a “Stateless process” in the xCP application, the Stateless
process is executed as following:
1) An HTTP request is sent to the xCP Application which is running on the application server (Tomcat/
tcServer). xCP Application parses the HTTP request and communicates with the Content Server
over DFC.
2) Executed by the Stateless Process Engine residing within the Application Server. The state of the
Object is changed and the user should be able to view the resultant state.
Stateless Process Execution

 When User initiates a “Stateful process” in the xCP application, the State-full
process is executed as following:
1) An HTTP request is sent to the xCP Application. xCP Application parses the HTTP request and
communicates with the Content Server over DFC.
2) Since this is a State-full process, the request is forwarded to the Process Engine which is running
in the realm of the Method Server
3) The Process Engine executes the task
4) The Process Engine sends back the response to the Content Server
5) The state of the process is changed
6) If there is any other automatic activity in the stateful process, the task is executed by Process
Engine and the process state is changed
Stateful Process Execution

 Changing the process template definition by adding or removing new process
variables, will make running workflow instance tasks inaccessible to the end
users once the process is redeployed. Users will not be able to acquire or
complete existing activities.
 If there is any running workflow instances at the time the updated process is
redeployed, it wouldn't be possible to change the process template definition
updating process data without versioning the process.
 This is due to that the runtime instance will not have the correct process data
in order to render the task successfully in the User Interface.
Supported ways to change a process
template

 In order to make change to the process template definition, You need to
consider one of the following options:-
• Option One
1) Complete all the workflow instances
2) Made the changes to the process template (without versioning)
3) Redeploy the xCP application
4) All new workflow instances will have access to the required data
• Option Two
1) Version the process in xCP designer
2) Make the required changes to the newly versioned process and process UI pages
3) Redeploy the xCP application
4) The existing instances are not affected as they will use the original process and process UI.
All new workflow instances will use the new current version of the process template
Supported ways to change a process
template

Migrating applications from xCP 1.x to
xCP 2.x
 It’s not possible to migrate xCP 1.x applications to xCP 2.x. This is because
the architecture of xCP has changed dramatically between versions 1.x and
2.x.
 However you can develop an xCP 2.x application to mimic the xCP 1.x
application then use the same types used in the xCP 1.x application. This is
done through type adoption, the xCP 2.x application is adopting the types
created in the xCP 1.x application.

Type Adoption limitations and issues
 Application namespace can’t be the same as the adopted types prefix.
 Type can be adopted to only one application.
 Issue: In xCP applications, for every object model created in xCP Designer, it
would create a type with application namespace as prefix for the type name
in repository during application deployment.
However it wouldn't prefix the adopted type's name with application
namespace as altering type name is not feasible and it beats the purpose of
interoperability (as the type name will be completely different). And it would
register the adopted type to artifact bundle in the repository.
Adopted type and application bundle always has one to one mapping. When
type is adopted to an application whose namespace is same as type's prefix,
it would treat as normal type created through xCP Designer. And this will
cause deployment failure.

 Solution:
1) Remove the application artifact bundle with the namespace same as the prefix of the adopted type
from the repository.
2) Create a new application with a different namespace
3) Adopt the type to the new application
4) Deploy the new application

 Issue: After adopting an object type to xCP application, when a user try to
import or create any object through DA or any client for a sub-type of the
adopted type, the import/creation failed with the following error:
ERROR [http-bio-8080-exec-9]
com.documentum.webcomponent.library.contenttransfer.importcontent.UcfIm
portContainer - WARNING: unexpected error occured
DfException:: THREAD: Timer-18; MSG: ; ERRORCODE: ff; NEXT: null …
 Solution: Adopt all the sub-types of the super-type to the xCP application.

 Issue: Can't adopt any sub-type of a super-type that has been already
adopted to the xCP application
 Solution: Un-adopt the super-type from the xCP application and adopt the
super-type and its sub-types together to the xCP application through these
steps
1) Close xCP Designer
2) Execute the following DQL query:
select r_object_id, artifacturn, installedobjectid from xcp_artifact_bundle where namespace =
'<namespace>' where <namespace> is the application namespace
3) Save the returned ID and determine the index of the super-type in artifacturn and
installedobjectid fields

4) Update the xcp_artifact_bundle object to remove the reference for the super-type in the artifacturn
and the installedobjectid fields using the following DQL:
Update xcp_artifact_bundle object
Remove artifacturn[<index>]
Remove installedobjectid [<index>]
where r_object_id = '<xcp_artifact_bundle_id>'
Where <index> is the index of the super-type in artifacturn and installedobjectid fields from the
above step and <xcp_artifact_bundle_id> is the r_object_id from the above step.
5) Open xCP designer again, it shows that the super-type and all its sub-type are available for
adoption.

EMC Documentum - xCP 2.x Troubleshooting

EMC Documentum - xCP 2.x Troubleshooting

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to EMC Documentum - xCP 2.x Troubleshooting

Similar to EMC Documentum - xCP 2.x Troubleshooting (20)

Recently uploaded

Recently uploaded (20)

EMC Documentum - xCP 2.x Troubleshooting