xCP2.0 Tidbits from Momentum DevCon 2012

Here are some interesting tidbits I gleaned while working through the xCP2.0 hands-on sessions at Momentum DevCon.  My impression of xCP2.0 is very favorable.  The xCP Designer looks nice, functions well (though not always intuitively), and produces very good applications.  The goal — as it has been for some time — is “compose, don’t code” applications.  xCP2.0 goes a long way toward making that a reality for the masses, not just for simple applications.  We talked through what we thought were some corner cases during the sessions and in most cases, we determined what needed to be done could be accomplished with the tools in xCP and the xCP Designer without coding.  There were some exceptions, but not many.

Here are some important bullet points I recorded during the conference:

  • Because the source files are all just XML files, they can easily be controlled with a source code control system.
  • xCP Designer is a completely off-line modeler, meaning you don’t need to be connected to a repository to develop an application, and when you change or delete objects, you are only affecting your local hard drive.
  • There is absolutely no use of WDK in xCP2.0.  xCP applications use extJS, JavaScript, Java classes, REST web services, and HTML5.
  • xCP2.1 will include migration tools to help move xCP1.x applications into xCP2.x.  This does NOT include the UI, which will need to be recreated from scratch.  Ouch!  Note that in xCP2.0 you can’t import object models, workflows, anything, these will all need to be recreated until the migration tools are released in xCP2.1.
  • xCP2.0 has unified the expression language used everywhere in the environment.  Yea!
  • xMS is used for deployment of applications regardless of whether VMware is used or not.  xMS does a great job of deploying files to the application server that constitute the UI, and objects to the repository that constitute the DAR.  UI pages, actions, etc. are converted to RESTful web services, class files, and JSP and deployed as WAR files to the application server.  There is no more middle-layer framework like there was in TaskSpace for rendering the UI.
  • xCP2.0 produces applications that are very fast.  Some of this speed can be credited to general performance improvements in the D7 core platform.
  • Uninstalling an xCP2.x application is possible, and the procedure will be published as a white paper in Q1 2012.  Eventually a tool will be produced to uninstall xCP2.x applications.
  • Composer is still the tool of choice (the only choice?) for creating and installing BOF objects.
  • xCP2.0 does not handle virtual documents and there is no plan to ever support them.  Most virtual document structures can be modeled in xCP using relationships.
  • Per- and post-installation routines will be handled by the xCP2.1 installer (xMS).
  • Stateless processes called from the xCP2.0 UI run on the application server, not in the Process Engine on the Content Server.  Stateless processes called from a stateful process run on the JMS.
  • xCP2.0 does not use the UCF.  All content transfer is native HTML5 transport.  This means on checkin, you must specify the file to checkin, Documentum will no longer magically know where it resides.
  • No Single Sign On support in xCP2.0.
  • No hot key support in xCP2.0, which means it will not be 508 compliant.  It is planned for xCP2.1.
  • xCP2.0 has 6 well designed extension points which will likely allow you to do anything you can imagine inside the framework.   POJOs can be used in stateless processes (without including DFC interfaces), custom auto activities, custom functions and expressions, 3rd-party DB drivers, JavaScript custom widgets, and themes.
  • xCP2.0 is shipping without the Process Builder debugger.  Bummer! , that was an awesome and useful tool.  It should resurface in xCP2.1, and EMC is trying to develop an application-level debugger.  The new xCP Designer does have a Problems tab (like most IDEs) that can catch a lot of design-time errors.
  • xCP2.0 applications and DA cannot run in the same instance of the application server due to JAR conflicts.  BTW, Tomcat and TCServer (commercial Tomcat) are the only supported application servers for xCP2.0.

About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

2 Responses to xCP2.0 Tidbits from Momentum DevCon 2012

  1. Ahson Ahmad (xCP Product Manager) says:

    Thanks for the post. I scanned through it and this one caught my eye: “Like TaskSpace, you are still restricted to one application per repository.”

    I don’t think this was a limitation for TaskSpace but it is definitely not a limitation at all for xCP 2.0. You can run as many applications as you want on one repository!


    • Scott says:

      Ahson, thanks for the comment. I thought this was the conclusion of the discussion we had Thurs right before the closing session. Glad I heard it wrong. I will amend the post.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: