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

Best Answer

  • Ciruli
    edited June 12, 2012 #2 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

  • Ciruli
    edited June 12, 2012 #3 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

  • kcrkarthik
    edited June 13, 2012 #4

    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

  • Julien.Fontaine
    edited June 13, 2012 #5

    A new wdk application ?

  • dnvhariprasad
    edited June 13, 2012 #6

    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

  • Julien.Fontaine
    edited June 13, 2012 #7

    Application builder, like the old one ??

  • 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

  • Ciruli
    edited June 13, 2012 #9

    Karthik -

    The new UI Framework is based on ExtJS.

    Dan

  • Ciruli
    edited June 13, 2012 #10

    No - it is a new framework based on ExtJS.

  • Ciruli
    edited June 13, 2012 #11

    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.

  • Ciruli
    edited June 13, 2012 #12

    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!

  • kcrkarthik
    edited June 13, 2012 #13

    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

  • 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?

  • Ciruli
    edited June 14, 2012 #15

    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

  • Ciruli
    edited June 20, 2012 #16

    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

  • MuhammadAli
    edited June 28, 2012 #17

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

  • jazuli14
    edited June 29, 2012 #18

    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

  • dnvhariprasad
    edited July 2, 2012 #19

    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.