nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

XCP 2.1 Type adoption

VenkatDadeProject

I have created sub types of dm_document from XCP 2.0 project dm_document -->my_company_type-->my-type-->my_type1

--my_type2

I am trying to adopt those types in xCP2.1 project.I have set up connection broker settings as explained in xcp2.1.I can see only direct sub type of dm_document created through Composer not those type which were created from XCP.

Did you any one face this problem?.

As per the statement from the XCP2.1 documentation,you can see all the sub type of dm_document,dm_folder,dm_sysobject.I beleive no matter either it is created by XCP 2.0 or Composer or DA

Find more posts tagged with

Comments

bstephens

Are you using type migration feature by importing the types from composer project?

You should use type adoption feature for data interoperability.

Delete imported types from composer project and adopted the same types from the repository.

VenkatDadeProject

No.

The types are created by XCP2.0.Now I have to import into XCP2.1 project.The types are created with different name spaces.I have to import few types into XCP2.1 for different application and that will be different UI.

VenkatDadeProject

I have tried importing the types from Repository to Composer.Composer to xCP2.1

xCP2.0 (name space xyz)-->Repository------->Composer 7.1---------------------------------------------->xCp2.1.(name space xyz)

xyz_document(actual type name) (no value assistance populated in composer) xyz_xyz_document(actual type name)

xCP2.0---Repository----->xCP2.1

xyz_document types can not be adopted-not visible

Composer--->repository--->xCP2.1 (types are visible)

What is working is not way it is explained in white paper.Now EMC comes with different story for type adoption.

XCP types can be used only in XCP application not with other application.

XCP application can be best suited only for scan-store-retrieve application an example provided in demo.It is not applicable to different ECM use cases.

PanfilovAB


 What is working is not way it is explained in white paper.

What is the vendor of underlying database? Oracle? Could you post screenshot with type adoption dialog?


XCP application can be best suited only for scan-store-retrieve application an example provided in demo.It is not applicable to different ECM use cases.

Did you really think that xCP is a next ECM generation and, moreover, Case Management solution?

VenkatDadeProject

DB:Oracle.

xCP 2.x does not honour the entire data
dictionary, which includes value assistance, attribute label
internationalisation, constraints etc

as per documentation-

Even composer can import pick list from repository.DD for value assistance is tored in different place.I am still searching for how XCP manages the Data Dictionary but not inline with existing object model which we have seen so far.

If an object type is created in one project with specific namespace,there is no chance that it can not be used in another project in XCP. With current version of XCP, is not at all close to be called as Enterprise Content Management.It is just scan-store-retrieve model.It deprecates many ECM functions.It inherits one collaboration functionality out of box for annotation -no multile rendition viewing ,Not to view multiple versioning,version labels,lifecycle options.It incorporates BPM that is one advantage.

We can not import type labels between Composer created object type and in xCP2.1.

What is appearing in the screen shot is objects created in Composer.There are many objects type hidden which are created by XCP designer.

PanfilovAB


DB:Oracle.

This is bit strange that there are some visible subtypes, because in my case I wasn't able to import any custom type.

Check this: http://blog.documentum.pro/2014/04/30/type-adoption-feature-is-missing-for-oracle-docbases/

VenkatDadeProject

"to fix this issue add -Dxcp.hvs.support.enabled=true to xcpdesigner.ini."

I have already tried by adding the line in designer.ini still the same to me

VenkatDadeProject

Are those types which appearing in the screen shot in your blog are Composer created types or created from other XCP project either 2.0 or 2.1?

PanfilovAB

You are right, xcp designer also filters out xcp types. It uses following query to find types related to other xcp projects:


select installedobjectid from xcp_artifact_bundle enable (row_based)

I think the only way to achieve what you want is:

1. "hide" installed types by using following sql:


UPDATE xcp_artifact_bundle_r
   SET installedobjectid =
          REGEXP_REPLACE (installedobjectid, '(^|,)(03)', '\1ff');

COMMIT;

2. perform import

3. revert changes made in 1:


UPDATE xcp_artifact_bundle_r
   SET installedobjectid =
          REGEXP_REPLACE (installedobjectid, '(^|,)(ff)', '\103');


COMMIT;

But I have no idea what will happen after that, because you are going to import types from old project, and I'm sure that xcp designer is unable to import other settings related to adopted types.

VenkatDadeProject

This will not work for me after I revert it back.Ultimate requirement is any developer can interlope between object types and has to work the same.I am not sure it will be accepted based on system maintenance.

VenkatDadeProject

The another problem is XCP 2.1 is it adds additional name space to adopted types from Composer.It is another bug in the tool.

Import a type in composer from repository-->Import into xCP2.1 project.It adds additional name space of the project.If some one adopts the type by importing into Composer and the xCP designer,it will prepend the name space again.We can not go in this route.

PanfilovAB


Ultimate requirement is any developer can interlope between object types and has to work the same.

IMHO, xCP is not designed to share projects/artifacts among developers: one developer - one xcp project, moreover according to EMC, to create xCP project you should not have developers at all

VenkatDadeProject

That is an ideal situation.What I am practically seeing is one screen for each object type and one project.We can not interlope when we have to combine two object types to get search results and display eg.inter departmental business scenario.It is too far to reach the goal.