The Global Trading Imaging Application is a an imaging & document management solution that allows for cost effective and efficient storage, search, retrieval, and lifecycle management of U.S. Customs entry documents.
The system will provide the ability to:
• Receive documents from consolidators and brokers in electronic format.
• Process documents from consolidators and brokers.
• Scan & store documents received in paper form.
• Index documents based upon entry number and bill of lading number, purchase order number and commercial invoice number.
• Store documents received in electronic format.
• Define workflows around documents.
• Define varying levels of security access.
• Allow easy search and retrieval of documents.
• Define rules for purging of documents.
Technology
• Documentum Suite of Products 5.3 SP3
• Captiva Input Accel 5.3
• Websphere Application Server 6.1
• Oracle 10g
Best Practices
• Staging environment would be a smaller version of production to anticipate integration, product limitation etc crop up at the last moment.
• Used to generate custom log files on Content Server and Application Server to avoid “System Out” messages.
• Password encryption for the admin user credentials used by our framework components, customized webtop components.
• Reset users email id’s in Staging environment to dummy email id’s when the application is rolled out. This will avoid the system being send notification / escalation emails to real time users.
• When any code fixes or patches on Content Server, restart java_method server to take effect of new changes.
• Identification of unique / not null constrains used by documentum registered tables.
• Customized the Properties Page of Entry Packets (Folder) and GTI Documents to display the usable custom attributes to the user when viewed in the Webtop
• Customized the webtop and DA Theme to reflect Target Logo with the client’s choice of colors and shades.
• Customized the Advanced Search page to reflect availability of custom attributes alone for Searching in GTI.
• Verified availability, identified, tested and implemented of an image enhancement module with higher precision in Captiva Input Accel to support auto-orientation of images
• All customization changes made to the webtop and DA are sent across as new EAR files with proper build details for reference and deployment purposes
• All code changes made are consolidated in a GTIContentServer.jar and GTICommon.jar with proper build details for reference and deployment purposes.
• Target’s business users had requested removal of irrelevant options in Search,
Import and Page Preferences; all changes have been made by creating custom files, overriding the existing files in Documentum; hence, editing and removal of customizations would involve minimum effort spent over accessing, modifying or removing custom files in the webtop/custom and da/custom folders
Lessons Learnt
• In case of Auto-orientation of images using Captiva, we should use either PRIMEOCR or SCANSOFTOCR and not ImageUtility) since it is not reliable module.
• In case the Docbase is down / hanging, before restarting the Docbase, all running processes need to be killed manually to prevent re-occurrence of the same issue.
• In case a new Docapp is installed, all existing workflows need to be removed / stopped at the minimum from the Docbase before the changes can be tested; the workflow chooser in the Documentum export module of Captiva needs to be reconfigured for the changes to take effect.
• It was initially planned to use the default Work Queue Management module in Documentum for setting priorities on work items / tasks sent to different users, where an Admin User alone sets a priority on each Task, which shall remain until the end of its lifecycle; it was discarded and an explicit inbox customization was done to allow each user to set the priority of tasks available in his own Inbox, after acquiring them. After initial rounds of usage by business users, clients seem to prefer the Work Queue Management module where Admin Users set permanent priorities on Tasks, rather than the customized short-lived priorities
that expire once a work item leaves a user's inbox. Therefore, it is always important to explore the pros and cons of each alternate before implementing them in an application.
• The requirement of a User acquiring a Task before being able to perform any of the intended functionalities on the Task was not implemented initially, thereby leading to simultaneous access issues on the same task by users from the same User Group; After enabling and implementing the simple, default Documentum function of Acquiring Tasks, all such simultaneous access issues have been removed from the scope of issues.
• When performing a theme customization, in order to list a custom theme in the preferences page drop down, allowing the user to choose and use the Theme customizations, it was initially planned to create a custom app.xml file, where the new theme was added and the default theme was kept chosen. Issues were thrown across the application, disallowing creation of a custom app.xml (as it excepts us to customize all the related files referenced by the app.xml).
Finally, minor modifications were made to the app.xml inside webtop / wdk and was sent along with the custom webtop.EAR, solving the issue permanently.
• Whenever a new admin user is created in Documentum, the corresponding Alias Set needs to be attached to the user, so that all future activities configured under the admin user run without throwing irrelevant errors in the application console.
• Work item objects acquired from the workflow via code need to be closed in the execute method of the calling parent method and not inside any of the child methods, to avoid asynchronous processing of parent and child methods