A few years ago I started a project with a new customer. When I was granted access to their DEV, QA, and PROD environments I was given a bookmark file that contained all of the URLs I would need to manage and administer their systems (for example: DA, Webtop, and various D2 applications).
Generally, these URLs are not too hard to remember, but there are subtle differences in their construction across the three environments (e.g., port numbers and host names). This list also contained some not-so-easy to remember URLs like the xPlore Index Agent and the DFS WSDL location. I was impressed; this simple bookmark file saved me a lot of time not having to compile it myself. But I wanted more…
This bookmark file saved me time when I needed access to a web application, but it didn’t help with,sshscp, or rdp access to the servers. For those protocols I needed to use putty, WinSCP, and mstsc (Remote Desktop Connection) respectively, which meant I had essentially four lists of host names\URLs per environment – that’s 12 lists with over a hundred hosts and URLS! I’m sure there are dozens of solutions to this problem – some probably even contain password management, but here is my simple, bare-bones solution to this problem, in an environment where I had limited Desktop control.
I created a simple Word document (see Image 1) that contained tables with all the application URLs and host names I needed to access. I then saved this document as a ‘Web Page, Filtered’ HTML document to my Desktop. I opened the HTML file in my browser and made it my default homepage (see Image 2). Now I have instant access to these URLs and hosts from either the browser or the Desktop.
Creating URLs for the web applications (e.g., Webtop, DA) was simple. Creating links for the,sshscp, and rdp host names required a little trickery. Somehow I needed to associate the,ssh://scp://, and rdp:// protocols with their respective clients (putty, WinSCP, and mstsc). Fortunately, JJ Clements had already figured this out and published two very clever little batch files that solved the problem nicely (rdp and ssh/scp).
[My only caveat with using these batch files is that you may need to alter them slightly depending upon where you installed putty and WinSCP, and whether you can write to your C:\Windows directory.]
Image 1 – Word document
Image 2 – HTML document
Now I have one place from which I can access all of the applications and hosts I need to manage. I created one document for each environment (DEV, QA, and PROD) and linked them together. (This allows me to fit all of the links on a single page without having to scroll). Since a Word document is the storage location for all the URLs and hosts, it can easily be updated and shared among project teams.
This article was originally posted on dm_misc blog.
Currently, I am finishing up an EMC xCP project, and I would like to leave behind some tips I have had to discover the hard way. Hopefully, this will save you some time during your xCP project.
Tip #1 – Have Well-Defined Use Cases
I know it is usually a requirement for all projects, but for xCP you really need to know what the user experience is going to be before jumping into xCP configurations. Spend extra time on the planning, and you may keep yourself from having to undo/modify a lot of configurations.
Tip #2 – xCP is Not Webtop or D2!
This has been the biggest issue thus far with the current project. The experience the users desired was not process oriented; rather they wanted a CMS front-end. For well-defined business processes, xCP works as expected. In fact, we have a separate xCP project that is going well because it is process oriented. Trying to make a full-featured CMS front-end using xCP, however, will reveal what will be many future enhancements for xCP. If you are simply looking for a CMS front-end, and you have limited time to get the job done, consider EMC’s other alternatives like Webtop or D2.
Armedia, in being a vendor-neutral company, has also used Generis CARA to fit our client’s needs. CARA is a third party CMS front-end/business rules engine that integrates with Documentum, Oracle WebCenter, and Alfresco. So consider your alternatives carefully based on your use cases (hint rule#1), and your requirements.
Tip #3 – Make Certain your Object Model Definitions are Complete Before Configuration Begins
You will save yourself a lot of aggravation if your model is set in stone. xCP does a great job helping you out upon page creation, however, any time after creation modification of the model will require manual changes or recreation of pages. By the time you have created your custom pages, you will not want to change your model. (You can change the model of course. You’ll simply wish you didn’t have to.)
Tip #4 – Work on the Import Fragments Before Any Other Pages or Fragments
The Import Fragment page is called by the ‘Default Import Document’ Action Flow. If you happen to research the ‘Default Import Document’ Action Flow, you will see it looks for a fragment with a name ending in ‘_imp’. The Import Fragment of an object type will contain most, if not all, of your business logic for creating a document type. Once this page is complete, it can be duplicated for the ‘Default Import New Version’ Action Flow.
Tip #5 – There is a Difference Between, and Need for, ‘_imp’ and ‘_chk’ Pages
I thought it would be a good idea to change the ‘Default Import New Version’ Action flow to use the ‘_imp’ pages instead of the ‘_chk’ pages. As soon as I did this I started to realize the ‘Import New Version’ really needed different business logic on the pages. When you perform an import your model is empty so you don’t have to deal with business rules until the user enters data. When you import a new version, your model and associated fields will contain pre-populated data. This, for me, required thinking about some of the events that are triggered. These events, of course, tended to conflict with the ones I had in place. So I had to go back and use the ‘_chk’ pages as intended. They were still duplicates of the ‘_imp’, but with minor changes as compared to making complex rule changes to the ‘_imp’ page.
Tip #6 – Take Advantage of Custom UI Events
With xCP 2.1, you can create custom UI Events. The additions of the events have been helpful. In my instance, I created a custom UI Event to keep track of the validation rules and populate a message to the users. For every show/focus/change event, I published a custom UI Event called ‘Required Field Change’. The event contained a message string and a field name string. By having this Event published, and triggered, I could populate a value display field with the event’s message.
Tip #7 – Use the Process Debugger Before Pulling your Hair out
When you start working with processes, and you will make certain your process is running properly before trying to launch it from a page. Here the developers of xCP provided a very nice debugging tool that allowing you to test the process without the need to deploy and call it from a page. By using this tool you ensure issues you encounter along the way are not blamed on the process itself.
Tip #8 – Use a Hidden “Debug” Column Box to Track Complex Validation Rules
I was given this tip, and I will share it with you. Like most Input screens, your business rules will require some complex validations. In order to track these rules, I set up a “Debug” column box, which I keep hidden based on roles. Within the “Debug” box, I have a series of value display fields all set as a Boolean field. Each of these value display fields contains a rule by which I validate a particular field by. I then have one overall value display field that is set to true once all of the other boxes are set to true. These value display fields also helped me drive the ‘Required Field Change’ event in tip #6. As long as the display value fields were false then the warning message remained visible to let the user know what was wrong with the input given.
Tip #9 – Don’t Start Deleting the Buttons xCP Gives You
When creating a new View/Edit/Import Page or Fragment, xCP will set up an array of buttons you may or may not desire the users to have access to. Instead of deleting the button, however, simply set the ‘Hidden’ attribute to ‘true’. You may find the button a pain to rebuild later if you decide you needed it. Once everything is working like you want it, and you want to improve performance/size, then you can consider removing the button. (However, a button and process definition on a page really isn’t doing anything to hinder performance and doesn’t take up much space. Check to see if the process is triggered ‘On Load’ so it doesn’t execute unnecessarily, but that is all you need for performance.)
Tip #10 – Be Willing to use Plug-Ins
Remember, xCP is first a framework to build a custom Documentum Web Application with. Therefore the core functionality within xCP is basic. You will find yourself writing custom widgets to perform a particular task or you can look into the list of plugins to help solve a particular problem for you. The plugins found on EMC’s support site have many features already created that you may be looking for.
Providing content in users’ native languages is becoming the expected norm. It is not uncommon for banks, credit card companies, insurers, government agencies, and manufactures to provide licensing agreements, rules and regulations, warranties (e.g., John Deere), and forms (e.g., IRS) in multiple languages – both online and in print.
These documents are usually available at an organization’s brick and mortar office, or contained in their online library, and are available for users to download. Producing and managing documents in multiple languages can be expensive, tedious, time-consuming, and prone to staleness.
For example: What if the “source” document changes, how do these changes ripple through to the rest of the translations? What if one of the translations needs to be “tweaked”, how do you keep its version in synch with the source document? With a content management system like Documentum and an integration with a language translation service like Lingotek, the process of producing and managing multi-language content can be simplified.
Lingotek is a translation services company whose translation management system lends itself well to integration with content management systems like Documentum. Lingotek provides a completely online environment for submission, management, and exchange of documents for translation.
They offer numerous out-of-the-box workflows to accommodate many translation needs, including machine translation only, machine translation plus editor, and translation with multiple reviewers. Once a document has been submitted to Lingotek for translation, your translators can access and process the document in Lingotek’s cloud-based Translation Management System (TMS). When translations are completed, they are flagged as such and returned to the originator, in their original format and style.
The following video demonstrates a solution for creating and maintaining multiple translations of content in a Documentum repository. The solution uses the inherent content management capabilities of the Documentum Content Server to manage content, versions, and relationships among documents and leverages the Content Server’s infrastructure (specifically, Service-based Objects, asynchronous jobs, and external database tables) to integrate with Lingotek for the production of translations.
Lingotek offers a comprehensive RESTful API that integrates easily with Documentum to provide a seamless solution for the production and management of multilingual content.
See what you think.
Is this an integration that could benefit your company, department, or organization? Leave us a comment, we’d be happy to discuss it with you.
Webtop has been Documentum’s flagship user interface (UI) since its introduction in Documentum v5 (circa 2003) and has an enormous worldwide install base. It’s built upon solid (though dated) technology, methodology, and standards. It’s also built upon/with a solid API (the WDK), which allows developers to do ANYTHING with Webtop – including replacing it completely with a custom UI.
One of my favorite features of Webtop is that it does EVERYTHING. In fact, this is often the reason many end users (i.e., customers) don’t like it – it’s overwhelming. More often than not, we disable and hide capabilities and features in Webtop to make it more palatable for end users.
So, with all of this capability and installed user-base, you’d think EMC would enhance/upgrade/extend their flagship UI, right? Instead, they end-of-life it (Support for v6.7 SP2 ends April 2015. This was recently extended to Dec 2018 with the release of Webtop v6.8.) and are replacing it with one of two new clients: D2 or xCP.Worse, they provide no clear technical migration path from Webtop to either D2 or xCP and provide no clear criteria to choose one client over the other.
I know, I’ve heard the same guidelines that you have: if the application is “document-centric” it should move to D2; if the application is “process-centric” it should move to xCP. Well, it’s never that easy. Many of our customers have applications they target for development of D2 (or xCP) because it meets one of these guidelines. However, once it is deployed, they started looking at the next (and the next) application to convert/rewrite/develop.
Often these next applications contain elements better suited for the other platform. Now they have a problem: they want to build all of their applications on the same platform to minimize maintenance and maximize their investment, but they are stuck trying to force-fit an application’s requirements into a platform’s misaligned capabilities (or lack of capabilities). If they had remained with Webtop, they could achieve both types of applications (i.e., document-centric and process-centric) on a single platform. Of course, you lose the “no code” configurability of D2 and xCP and trade it in for full-blown Java development with Webtop.
As I mentioned before, out-of-the-box, Webtop does EVERYTHING. The thing that gripes me the most about xCP and D2 is that out-of-the-box they do NOTHING. Nothing! After installing the client you still have a long road ahead of you just to see your cabinets and folders, and create a few objects in the Docbase.
Out-of-the-box, Webtop works. Why doesn’t EMC invest in “Web 2.0-ifying” Webtop? They could rebuild it on Spring, using jSON and Ajax, DFS, REST, or whatever the framework de jour is. And, provide a migration path from the “classic” Webtop to this new creation. Many of these technologies provide the “configuration” conveniences they are striving for in D2 and xCP.
For example, look at what Armedia is doing with its ArkCase Management System. ArkCase is repository neutral and offers a UI that is elegant, responsive, and highly configurable while using current Web 2.0 technologies to achieve the highest level of re-usability and abstraction. Or take a look at CARA by Generis. CARA is a Webtop/D2 alternative and is gaining rapid acceptance for its elegance, flexibility, ease of use, and adaptability. Are these examples of what Webtop should be, could be?
Come on EMC, revive Webtop and restore it to its flagship status. Don’t just limp it along with periodic maintenance releases and force your user base onto D2 or xCP when they don’t need to or want to.