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

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

Ciruli

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

All comments

Ciruli

Hi, Kris -

Thanks for your question.

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

Dan

kcrkarthik

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

A new wdk application ?

dnvhariprasad

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

Application builder, like the old one ??

kristopher.kees@fmr.com

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

Karthik -

The new UI Framework is based on ExtJS.

Dan

Ciruli

No - it is a new framework based on ExtJS.

Ciruli

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

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

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

kristopher.kees@fmr.com

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

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

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

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

jazuli14

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

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.

MVK4LTI

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 ?

DCTM_Guru

@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.