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.

Best Answer

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

0

Answers

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!

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.

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!

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?

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!

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.

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.

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