Home Documentum

Migrating existing TaskSpace applications to xCP 2.0

I recently met with my organization's VP and he had some interesting questions for me about the upcoming xCP 2.0 product offering.  We currently have a basic TaskSpace application with customized UI, a few process templates, some custom methods code written in Java to execute business logic, a TBO and an SBO. 

We wonder, what kind of effort will be involved to move this application over to xCP 2.0 once it is made available?

Will there be any sort of migration utilities for this? 

Which components of the application will we be able to port over and which will have to be rewritten or reconfigured?

Will existing method and BOF code still work or will it need to be redesigned?

If anyone could shed some light on these questions, it would be greatly appreciated.  We are trying to plan our strategy for the next few years and how we integrate with each of the products.

Thanks in advance,

Kris

Tagged:

Best Answer

  • edited June 12, 2012 Accepted Answer

    Hi, Kris -

    Thanks for your question.

    First, I want to be clear about migration and timelines. When we release 2.0, we will not yet release migration tools (so you'll have some time to think about this). Our current plan is to release migration tools with 2.1, and 2.1 is currently planned for release in Q2 of next year.

    When migration tools do become available, some components will migrate very easily and some will require more effort. Your type definitions, for example, will essentially be unchanged. Process will migrate but will need some changes (especially with respect to performers and queues, because those aren't available in the offline build scenario). And UI will need to be recreated entirely, as we have completely deprecated TaskSpace and its WDK underpinnings in 2.0.

    As for the code: BOF code will function essentially as is. In order to import it in an xCP 2.0 project, you will have to package your Java code in a JAR and do some simple annotation to the code. We are deprecating methods, however -- that code will have to be implemented as BOF modules. By creating a single methodology for incorporating custom code we have simplified both the developer experience as well as deployment.

    I hope this helps -- but if it leads to more questions, feel free to ask!

    Dan

Answers

  • edited June 12, 2012 Accepted Answer

    Hi, Kris -

    Thanks for your question.

    First, I want to be clear about migration and timelines. When we release 2.0, we will not yet release migration tools (so you'll have some time to think about this). Our current plan is to release migration tools with 2.1, and 2.1 is currently planned for release in Q2 of next year.

    When migration tools do become available, some components will migrate very easily and some will require more effort. Your type definitions, for example, will essentially be unchanged. Process will migrate but will need some changes (especially with respect to performers and queues, because those aren't available in the offline build scenario). And UI will need to be recreated entirely, as we have completely deprecated TaskSpace and its WDK underpinnings in 2.0.

    As for the code: BOF code will function essentially as is. In order to import it in an xCP 2.0 project, you will have to package your Java code in a JAR and do some simple annotation to the code. We are deprecating methods, however -- that code will have to be implemented as BOF modules. By creating a single methodology for incorporating custom code we have simplified both the developer experience as well as deployment.

    I hope this helps -- but if it leads to more questions, feel free to ask!

    Dan

  • edited June 13, 2012

    Can you share some details on this statement: UI will need to be recreated entirely, as we have completely deprecated TaskSpace and its WDK underpinnings in 2.0.

    What is the new UI going to be?

    -karthik

  • edited June 13, 2012

    A new wdk application ?

  • dnvhariprasaddnvhariprasad Hari Prasad Dontu
    edited June 13, 2012

    xCP comes with application builder where we need to create UI on our own.  App builder helps us to create pages, master pages and widgets in order to build us the UI

  • edited June 13, 2012

    Application builder, like the old one ??

  • edited June 13, 2012

    Hi Dan,

    Thank you for the quick response.  I have a couple of followup questions for you.

    Are queues and performers being replaced in 2.0?  Can you go into more detail on how the new offline build scenario handles these two concepts?

    Kris

  • edited June 13, 2012

    Karthik -

    The new UI Framework is based on ExtJS.

    Dan

  • edited June 13, 2012

    No - it is a new framework based on ExtJS.

  • edited June 13, 2012

    Julien - it is not based on the old Application Builder (though I think you'll like it).

    It's an entirely new tool called xCP Designer. It's replacing Forms Builder, Process Builder, Composer, PRS, and the configuration portions of TaskSpace. It's the single tool necessary to compose, package and deploy an application in xCP 2.0. It works entirely offline (letting you use source control for your application), it uses Maven for library and dependency management, and it is based on Eclipse.

  • edited June 13, 2012

    Kris -

    Queues and performers are not being replaced; they're going to work much as they do now. However, queues and performers are created in the content server itself, not in the application itself. For example, because xCP Designer is a completely offline tool, you can't directly name a user as a performer -- being offline, xCP Designer doesn't have access to the users in the docbase! However, you can essentially create a "parameter" in your application that represents the user, and you can bind that parameter to an actual user at install time.

    Same thing for queues.

    Hope that helps!

    By the way, everyone: watch the Documentum Blog in the EMC community for many posts over the next few months giving details for all of this!

  • edited June 13, 2012

    I am aware of the new Designer tool, but not the change in UI framework.

    Does it mean that all the webapps would start using the new ExtJS-based framework (like, right now all the webapps are using wdk framework) from D7 or later?

    I dont think only XCP's UI and other webapps would use different frameworks.

    -karthik

  • edited June 14, 2012

    Daniel,

    One last question regarding Ext JS.  Will this framework allow developers to write custom code for heavy UI customizations similar to how we do with WDK in today's world?  How will it compare in terms of code customizability?

  • edited June 14, 2012

    Kris -

    We will allow for customization of the ExtJS -- you will be able to inject custom widgets and custom functions into your pages. So heavy customization will be possible...and using a non-proprietary framework!

    Dan

  • edited June 20, 2012

    Karthik -

    As of D2 4.0, it can expose Google Gadgets which can be developed in your UI technology of choice. In a future release, we will be investigating how you will be able to expose a UI composed in xCP into the D2 framework.

    Dan

  • edited June 28, 2012

    What will the ExtJS UI be consuming? the RESTFul APIs? what will be server side framework based on? Spring ? 

  • edited June 29, 2012

    Muhammad,

    The ExtJS will be consuming a set of RESTful services.

    These services are actually generated directly from the application you build. As an example, if you build a stateless process, 3 document types, and a couple of real-time queries, we will generate corresponding services: CRUD services for the document types, and invocation services for the process and query.

    We are using Spring heavily in our stack.

    Thanks,

    Ahson

  • dnvhariprasaddnvhariprasad Hari Prasad Dontu
    edited July 2, 2012

    xCP 2.0 is built on spring+ExtJS+RESTful services

    D24.0 is built on GWT (or GXT).

    So different products still using different frameworks.

    Moving forward, D2 may contain all other products integrated with it in the form of plugins.  This is purely my assumption.

  • Based on above discussion - good to know GUI need to be recreated. On TBO dont think will replace with Business events ? or TBO still works in latest version of xCP2.x or 16.x ?

    2nd How about process templates ? how to migrate process definition - process XML to be exported and imported into latest version ?

  • @MVK4LTI - I don't have an old TBO to validate this against, but with xCP 2.x, in order to effectively use custom types, they need to be "converted" to xcp custom type. Once this is done, I'm guessing business event will "override" any TBO behavior written for old custom type.

    Process template should be able to be migrated, since most of the differences in the UI, not backend stuff.

Sign In or Register to comment.