Blog

10 Tips for Working with xCP

by | Apr 9, 2015 | Documentum | 2 comments

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.

tips for working with xCP

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.

Categories

2 Comments

  1. Scott Roth

    This is great insight, Lee, thanks for sharing it. It makes me think I should develop such a list for D2 as well.

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *