Capital projects Unable to open/edit report templates

If you want to edit or change reports, let me give you some basic information which will help you customize them as per your choice.

Our report templates are based on jasper reports. For more information on jasper reports, refer to the following :

https://community.jaspersoft.com/wiki/jasperreports-library-tutorial

http://www.tutorialspoint.com/jasper_reports/

Our templates are populated via DQL queries in the template which are processed through a custom datasource(refer to the tutorials to understand better) that we provide to our template.

You can use the iReport designer to edit the report templates. The iReport designer version you have to use will depend on the version of the jasper reports jar that is being used in your setup.

To find out the jar version, look for "jasperreports" within the Documentum\<jboss version>\server\DctmServer_MethodServer\deploy\ServerApps.ear\DmMethods.war\WEB-INF\lib.

The version number stated there will determine what iReport Designer is compatible with EPFM.eg. jasperreports-3.7.4.jar will use iReport Designer 3.7.4.

To edit the template, you can export the template to any temp location. It will be exported in the form of a .ecsfr file. You can simply open this file using any archiving/compression(like winzip or winrar) tool to view its contents.

Look for the .jrxml file within the .ecsfr file.for eg. "Late-PendingTransmittals_001.jrxml". The .jrxml file is the report template which is populated with data.It is basically the design of the report.

It is this .jrxml file that you will need to edit using the iReport Designer.

The iReport designer will basically have to be used for designing the layout of the report. Refer to existing report templates to see how they use DQLs to populate themselves.

Once you've created a proper report template, package in a .ecsfr file(basically zip it using winzip/winrar and change the extension to .ecsfr), once this is done, import the report template.

XCP 2.0 Installation

Deploy xMS Agent on Apache Tomcat

This is part one of an additional guide to deploy the xms-server.war on a DIY Windows Environment. The next part describe the registration of an xCP environment manually.
If you are install xCP 2.0 on Windows you can download the compiled exe-package. The *.exe download package does not include the catalina.bat file, because the *.exe package installs tomcat as a Windows Service. The tomcat memory settings are set in the Apache Tomcat 7.0 Properties Application. The zipped package includes the catalina.bat file. The full requirements are listet on the D7 xMS preparation page.

1.      Stop Apache Tomcat 7.0 Services

2.      Copy the xms-server.war file in the Tomcat 7.0 webapps folder

3.      Rename the *.war extension to *.zip and extract the file and delete the original *.zip file afterwards

4.      Open cmd – the windows command center
navigate to \webapps\xms-server\WEB-INF

xcopy xms-agent-context.xml xms-server-context.xml

ensure that the xms-agent-context and the xms-server-context files are equal

<bean id="xmsServerConfigurator" class="com.documentum.xms.server.XmsServerConfiguration"> <!-- Whenever an xMS agent is being deployed, set applicationType to "AGENT_TYPE" --> <property name="applicationType" ref="AGENT_TYPE"/> </bean>

5.      Open the Apache Tomcat 7.0 Properties Application and set:
-XX:MaxPermSize=2048m

Apache Tomcat 7.0 Properties

6.      Start Apache Tomcat Services
wait >1 minutes until the xms-server is completely deployed

7.      check the deployment: http://<localhost>:<8080>/xms-server
port 8080 for non SSL / port 8443 for SSL connection

Testwebpage to check the xMS Agent and xMS registered environment

The heart of the xCelerated Management System version 1.0 are the xms-tools.

All files located in the bin folder of the xms-tools-1.0 package.

The tool include the Command Line Interface (CLI) , the xMS Agent, the xMS Server and some batch files.
The xms.bat is called CLI in the documentation and located in the mainbin folder. Ensure you have set thexms-server.properties file correctly (located in the folder config). The CLI is not only a small administrative command tool, you can display all environments (show-environments) or one in detail (show-environment-details –name test_xcp) , import and export the configuration, show/create/disable users and execute the deployment into the registed environment.

xMS Tools version 1.0
2013 © Mr.Crazyapple

The xMS Server is only available, if you have installed the vFabric tc Server in your VMWare environment.

The xMS Agent reffered to the xms-env-registration-ui.bat. In this user-interface you can add all your available Documentum components (eg.: Repository, CTS, CIS, BAM, etc). This Agent make your xCP Applications in your environment available.

This screenshot shows all the commands that are executed in the CLI.

The xMS Agent reffered to the xms-env-registration-ui.bat file. In this user-interface you can add all your available Documentum components (eg.: Repository, CTS, CIS, BAM, etc).

The manual registration is only necessary if you don’t use the xMS Server and the blueprint installation.

This Agent make your xCP application in your do-it-yourself-environment available.

If the utility is accessing the xMS Agent for the first time, it prompts you to set a password for the
default admin user. Use this password for subsequent access to the utility.

You do not have to create additional system accounts, because there can be only one SERVICE account per environment.

You can use the SERVICE_ENDPOINT system account type, if you want to create a generic account for use across several vDCs. SERVICE_ENDPOINT is specific to each environment, and you need to specify it in the environment profile XML file for each environment.

This screenshot was taken from the xMS Agent environment registration utility.

Register your environment manually. Create a new environment blueprinte file and register all the recommended Documentum components:
Repository: Content Server Ver.7.0
BAM: BAM-Server 2.0
App Host: Tomcat Server 7.0.29
Documentum Administrator: DA 7.0
Search: xPlore 1.3
BPS: Process Integrator 2.0
Content Intelligence Server: CIS 7.0
Content Transformation Server: CTS 7.0
(optional) Thumbnail Server 7.0

This screenshot displays the registration of the primary repository. You can add as many repositories you like.

Save your settings and restart the xMS Agent. Remember: the agent is part of the app server (Tomcat) webapps. Please restart the Tomcat services on your host windows server.
Wait until all webapps was successfully (re)deployed.

Documentum Disaster Recovery

When developing a disaster recovery architecture and plan for any enterprise application, two factors come into play: recovery time and recovery point.  Recovery time is the amount of time it takes to restore the system to working order.  Recovery point is the point in time for which the data can be restored.  These requirements must be gathered prior to developing a disaster recovery plan (and ideally, before developing the system infrastructure).  For a single service application (i.e. Relational Database), after the RT and RP values have been determined, implementing them becomes a straightforward affair.  However, for an application which is comprised of several, interdependent services (i.e. Documentum Content Server), each service must have a separate DR strategy, and the culmination of those strategies must meet the application’s RT and RP values.  Let us take a high level look at the services that comprise a typical Documentum application and what their inter-service dependencies are.

At the heart of any Documentum application is a relational database.  The DR strategy may be to use some vendor provided clustered database, to have a second database that syncs with the first, or to simply recover from a cold backup.  The Recovery Point of the database must be older (less current) than that of the content storage area to minimize the likelihood of content objects missing their associated content files.  This is a soft rule.  If, for the application, the metadata is high value and the content data is low value, this rule can be broken.

Next let us look at the Content Storage area.  Again, the most common DR strategies are clustering and replication.  As we mentioned earlier, the content storage area of a recovered system should be more current than the RDBMS.  This way, all content bearing objects will have their content available.  Note that when files are updated, they are versioned, and the old files are not overwritten.  When files are deleted, their associated content is not, until a file clean job is run.

In order for an Index Server to perform its duty, it must have a valid, up to date index.  In DR situations, this is not easy to grantee.  One method for dealing with DR for an Index Server is to simply restore the Index Server but not the associated index.  This will require the Index Server to re-index the content (and FT functionality will be limited during this time), but will alleviate concerns over validity of the Index.  Other strategies include restoring both the IS and the Index.  Realize that if the Index is more current than the Content Server’s Restore Point, it may have invalid indices (documents that do not exist in the content server).  If the Index is less current than the restored Content Server, documents may have been marked as being indexed, but not actually be indexed.  This can be mitigated by performing a re-indexing on documents that may have been added or modified during the delta.

Thankfully, Content Server and Application Servers are relatively stateless, and therefore can be restored to any point that has all of the custom code and configurations that coincide with the RP of the CS.  Simply starting the apps should suffice to restore the system to working order.

This post highlights the complexity of Documentum DR; the devil always lies in the details.  Do not try to implement DR without verifying the infrastructure architecture, installation and configuration procedures, and redundant hardware in other environments

Quickflow

Quickflow is a predefined workflow that doesn'texecute any actions on the document. It sends the document from oneperson to another. The Quickflow has been part of the Serverproduct since the first version of 4i. In previous versions ofServer it was not called Quickflow. The template name for theQuickflow is sendToDistributionList which resides in the Systemcabinet.

Here are some steps to identify the workflow that thedocument belongs to:
- Get the task name -- You can get the task name by lookingat the inbox or querying the dmi_queue_item table

- Once you have the task name, run the following queries:

select object_name from dm_process where r_object_id in(select process_id from dm_workflow where r_object_id in (selectr_object_id from dmi_package where r_package_name ='<name of thepackage>'));

The result will be the name of the workflow associated to thedocument. Nevertheless, the Quickflow will always use thesendToDistributionList workflow.

Captial Projects File -> new greyed out in Project Configuration area or unable create picklist and other config objects

There will be reason like

1.Permission issues

2.membership issues

3.Config types missed in Content Rules of the project config folder.

But in my case the I have seen funny and intresting issue with objectlist component which is hidden configuration.

You can not see any error messgae logs because it is not error.

In the object list component we have configured columns based on folder path for the projects like below

<scope

                                location="/PROJECTS/PTDR-ABC/04. Master Documents/01. PROJECT COMMUNICATION,

    /PROJECTS/PTDR-ABC/04. Master Documents/01. Forms,">

                                <component id="objectlist"

                                                extends="objectlist:eif/config/library/objectlist/objectlist_component.xml">

unfortunately  there was comma”,” before close scope tag <01. Forms,"> so we have remove it and system behaving as expected

How to set a repository as Global Registry

To enable a repository as a global registry after configuration, you must activate the 
dm_bof_registry user. 
To enable a repository as a global registry: 
1. Access Documentum Administrator in a browser and connect to the repository. 
2. Click Administration- User Management- Users. 
3. Locate the user named dm_bof_registry and click the Information icon. 
4. Verify that the user name attribute is set to dm_bof_registry. 
The value dm_bof_registry is required. 
5. Optionally, change the user login name to a new value. 
6. Change the user¿s password. 
7. Set the dm_bof_registry user¿s status to Active. 
8. Click Ok to save the user. 
9. During DFC installation on client machines, such as the Webtop or Documentum Administrator hosts, provide the user login name and password. 
This updates the dfc.properties file and enables that DFC installation to contact 
the global registry as required. 
10. To manually modify the dfc.properties file to designate a global registry repository 
and user credentials: 
a. On the DFC host, navigate to $DOCUMENTUM/config (UNIX or Linux) or 
%DOCUMENTUM%\config (Windows). 
b. From a command prompt, execute the following command to generate the 
encrypted form of the global registry user¿s password: 
java -cp dfc.jar com.documentum.fc.tools.RegistryPasswordUtils 
password_of_user 
where password_of_user is the global registry user¿s clear-text password. In 
step d below, you will need to enter the encrypted form of this password in 
the dfc.properties file. 
c. Open the dfc.properties file in a text editor. 
d. Modify the following attributes: 
dfc.bof.registry.repository=global_registry_repository_name 
dfc.bof.registry.username=user_login_name 
dfc.bof.registry.password=encryped_password_of_user 
where encryped_password_of_user is the encrypted password you generated in 
step b above. 
e. Save the dfc.properties file.

Documentum Cloning

Documentum cloning steps

First way
*****************************************************************
Copying a Docbase.
This approach does not use Documentum’s “dump” and “load” utilities, but rather standard file and database schema copies. Paraphrasing the installation guide’s notes, and using “source” to refer to the Docbase being copied, and “target” to refer to the Docbase that will receive the copy:

• NOTE: It is recommended that you use a clean, unused Content Server as the target. You will have to change the security keys to match the source Content Server, which would impact any existing Docbases on the target.

• NOTE: The same OS must be used for both the source and the target Content Servers.

• NOTE: On the target Content Server, the OS user that will own the copied Docbase must have the same username and password as the OS user on the source Content Server.

• Stop the source Docbase.

• Note the name and ID of the Docbase you will be copying. You can look at the Docbase’s server.ini file to determine its ID: $DOCUMENTUM/dba/config//server.ini à look for the “docbase_id” parameter.

• Copy the file $DOCUMENTUM/dba/secure/aek.key from the source Content Server to the same location on the target Content Server.

• On the target Content Server, login as the same OS user that owns the Docbase in the source Content Server. Go through the standard process to create a new Docbase. You must use the same Docbase name and ID as the source Docbase. If you are manually creating the Docbase DB schema, it would be a good idea to use the same data and index tablespace names as used by the source Docbase DB schema, to facilitate import (later step).

• Stop the target Docbase.

• On the source Content Server, zip or tar the entire Docbase directory: $DOCUMENTUM/data//

• Export the Docbase schema from the source database.

• Connect as SYSTEM to the target database, and drop the newly-created target Docbase schema.

• Re-create an empty target schema of the same name/password:
SQL> create user 
2 identified by 
3 default tablespace 
4 temporary tablespace 
5 quota unlimited on 
6 quota unlimited on 
7 quota unlimited on ;
SQL> grant connect to ;
SQL> grant create session to ;
SQL> grant create sequence to ;
SQL> grant create table to ;
SQL> grant create view to ;

• Import the source Docbase schema export file into your new target schema that you just re-created.

• Connect to the new target Docbase DB schema, check the following, and make updates to refer to the 

new target Docbase location rather than the original source location:

o select r_install_domain, web_server_loc from dm_server_config_s;
o select host_name from dm_mount_point_s
o select target_server from dm_job_s;
o select projection_targets in dm_server_config_r;

• Run the following SQL statement in the target DB schema so that all views get rebuilt:
update dm_type_s set views_valid=0;

• Update the directory path information in Docbase DB schema

Below sql statements are examples of updating drive letter from E to C. 

update DM_LOCATION_S
set FILE_SYSTEM_PATH=replace(FILE_SYSTEM_PATH, 'E:\', 'C:\')
where FILE_SYSTEM_PATH like '%E:\%'

update DM_MOUNT_POINT_S
set FILE_SYSTEM_PATH=replace(FILE_SYSTEM_PATH, 'E:\', 'C:\')
where FILE_SYSTEM_PATH like '%E:\%'

• Copy the zip or tar of the source Docbase filesystem over to the target Content Server, and unzip or untar it into the corresponding target folder $DOCUMENTUM/data//.

• Edit the target server.ini file ($DOCUMENTUM/dba/config//server.ini), and ensure that the preserve_existing_types key in the SERVER_STARTUP section is set to TRUE:

preserve_existing_types=T
• Save server.ini
• Start the target Docbase

**********************************************************************
Same steps in other language

Cloning a Documentum Server

Part I – Preparing the Target Environment
Create same users & groups on target machine
Create /etc/services entries on target identical to source (Unix only)
Install Oracle with different sid 
Create Oracle user same as source 
Create tablespaces, etc. for docbase owner same as source
Verify server.ini settings if tablespace names change
Transfer .profile for dmadmin and docbase owner from source and modify Oracle sid and home settings. (Unix only)
Install Documentum Server on target – same version and patch level as source
Create a local Docbroker on target
Create target Docbase with same properties as source
Docbase name
Docbase ID
Docbase owner
During installation, modify the server.ini to reflect changes in index_store tablespace and add: preserve_existing_types = T
Ensure target Docbase projects only to target Docbroker
Shutdown target Docbase
Apply appropriate server patch
Start target docbase to ensure patch applied successfully
Shutdown target Docbase
Drop all tables in target database schema (Have dba do this)
Sample script:
Connect oracleowner/password@sid
Spool drop_schema.sql
Select ‘drop table’||table_name||’;’ from user_tables;
Spool off
@drop_schema
Verify schema objects no longer exist in target database

Part II – Transfer the database and content
Run LogPurge, DM_Clean and DM_Filescan on source Docbase
Run State of Docbase on source Docbase
Inactivate all jobs on source Docbase if any are scheduled to run during cloning
Shutdown the source Docbase
Export all objects owned by database owner from source database (dba)
(exp oracleowner/password@sid owner=docbaseowner file=docbasename.exp compress=y)
Import data into target database (dba)
(imp oracleowner/password@sid file=docbasename.exp)
Through Oracle, update hostname in target database (login as docbase owner)
Update dm_mount_point_s 
set host_name = ‘newhost’;
Update dm_server_config_s
set r_host_name = ‘newhost’;
Update dm_server_config_r
Set projection_targets = ‘newhost’ where projection_targets = ‘oldhost’;
Update dm_type_s set views_valid = 0;
Update dm_job_s
Set target_server = ‘docbasename.docbasename@newhost’ 
Where target_server = ‘docbasename.docbasename@oldhost’

On source, navigate to $Documentum/data/docbasename/content_store_01. Issue a ls –R | wc –l to get file count. (Unix method, do something similar on Windows)
Tar and transfer everything in $Documentum/data/docbasename/content_store_01. This will include all content beginning with hex-docbase id folder and full text indexes in verity folder. (Unix method, do something similar on Windows)
Untar content on target server.
Navigate to $Documentum/data/docbasename/content_store_01. Issue a ls –R | wc –l to get file count and compare to file count from source. Make sure they match! (Unix method, do something similar on Windows)
Tar and/or transfer the following files/directories: (Unix method, do something similar on Windows)
$Documentum/dba/config/docbasename/checkpass.cfg
$Documentum/dba/config/docbasename/dm_check_audit_pws. chown to root and chmod to 6777.
Re-start source docbase and re-activate jobs

Part III – Activate the Clone
Startup the clone server!
Verify connectivity through iapi and idql
Edit dmcl.ini on local client or application server to point to clone host machine
Log into clone through DTC or Webtop.
**********************************************************

Please note that checkout objects will not get cloned .Make sure you execute api for unlocking the objects: unlock,c,r_object_ id

Run all the 3 jobs 1) dm_filescan 2) dm_clean and 3) dm_consistency checker and start clonning of docbase