I'm using a special output format which is similar to the DITA XML output format to copy a publication between TD environments. The DITA XML output format has following two issues when it is used to copy a publication.

1. Variables will be resolved
2. File name of each object is very long (i.e. it consists of an object name, GUID, version, language, and extension)

Regarding the issue 1, it's possible to change the setting from the Output Format Properties. The Advanced / Resolve variables check box decides whether it resolves the variables or not. Regarding the issue 2, our special output format generates files that have only GUID as file names. When Content Importer imports pair of .xml and .met files, the object name will be set according to the FTITLE specification in the .met file.

In addition, when you copying a publication between different environments, you have take care following things:

1. Account names that were specified to Author, Reviewer, and so on
2. Object versions

If the account list is identical between environments, no issue will arise. But if there are any differences, it's better to overwrite the properties that are related to the account. Regarding the object version, you have to decide whether creating objects with initial versions or keeping versions. 

Hope this helps you.

Naoki

This is an interesting thread seeing how different groups go about this. I don't have an answer to the original post from Ann Jensen but wanted to share how I tackle the use of case of moving content from one Tridion Docs environment to another in case others out there had the same question.

From my perspective at RWS, when I need to receive customer publications from their Tridion Docs system, so that I can import into a Tridion Docs demo or workshop environment, I always go the Export Publications route. This has the advantages of the DITA content being exported, rather than published, meaning that the content still contains any conditions, variables, linked reuse, etc. and can therefore continue to be authored more easily in the target system. As the other responses to this thread indicate, if you use the DITA XML output, this is a publish action so conditions, variables etc. are resolved during the publishing process. This is a useful tool, but not one I would choose to use for the purpose of transferring content from one Tridion system to another. Naoki Hirai - have you taken a look at the Export Publication process that Ann describes in the initial post? I follow that process and to Kendall Shaw's point, use the "without conversion" option from Content Importer as the content has already been in a Tridion system.

For the original post, the logged errors from Content Importer would be expected using the Standard import option since you are taking content already GUID-ized for Tridion (as they were exported from Tridion) and then you are trying to convert them again for use with Tridion. The "Standard" option is designed for DITA XML content that has never been in Tridion and needs GUIDs assigned, while the "without conversion" option is designed for the use case of moving Tridion content between systems. However, Ann is saying that she can't use that option since she have the Post Conversion XSL to include in the process. Perhaps others with experience of this particular use case can advise further?

This is an interesting thread seeing how different groups go about this. I don't have an answer to the original post from Ann Jensen but wanted to share how I tackle the use of case of moving content from one Tridion Docs environment to another in case others out there had the same question.

From my perspective at RWS, when I need to receive customer publications from their Tridion Docs system, so that I can import into a Tridion Docs demo or workshop environment, I always go the Export Publications route. This has the advantages of the DITA content being exported, rather than published, meaning that the content still contains any conditions, variables, linked reuse, etc. and can therefore continue to be authored more easily in the target system. As the other responses to this thread indicate, if you use the DITA XML output, this is a publish action so conditions, variables etc. are resolved during the publishing process. This is a useful tool, but not one I would choose to use for the purpose of transferring content from one Tridion system to another. Naoki Hirai - have you taken a look at the Export Publication process that Ann describes in the initial post? I follow that process and to Kendall Shaw's point, use the "without conversion" option from Content Importer as the content has already been in a Tridion system.

For the original post, the logged errors from Content Importer would be expected using the Standard import option since you are taking content already GUID-ized for Tridion (as they were exported from Tridion) and then you are trying to convert them again for use with Tridion. The "Standard" option is designed for DITA XML content that has never been in Tridion and needs GUIDs assigned, while the "without conversion" option is designed for the use case of moving Tridion content between systems. However, Ann is saying that she can't use that option since she have the Post Conversion XSL to include in the process. Perhaps others with experience of this particular use case can advise further?

It there is no conversion, then I think you could run XSLT on .met files to achieve something similar to what the post-conversion xslt does.

Something I do to clone a publication on the same system, is to run a program that "reguidizes" the DITA and adds status and author metadata to the .met files before importing without conversion.

Hi Nigel,

From users point of view, copying a publication using the publication export file is not practical.

I often copy publications from the production environment to the test environment to debug stylesheets, translation workflow, or investigate issues. As the result there are many publications in the test environment and objects in the publications have various statuses. If the copy destination environment is clean, copying a publication using the publication export file will work. But that's not our case. When I copy a publication from PROD to TEST env, I always re-GUID objects. In order to use re-GUID objects, Standard import is required. And to use the Standard import, DITA files must be valid as a local DITA file set. Therefore, I use the publication output generated by our special output format.

HI Kendall,

That sounds exactly like what I need to do. I do need to re-GUIDize and currently the Post Conversion XSL (provided to me by predecessor) is required to add some metadata fields.

Would you be willing to share some elements of your script that applies these updates to your exported publication files? (cheeky I know but I am desperate)

Best regards,

Ann

Thanks for explaining more details of your specific use case Naoki. 

Hi,

Progress - I have taken the post processing XSL and applied that separately to all the .MET files exported via Export Publication.

I then tried to import this collection of XML and MET files using Content Importer without conversion. I saw that this still requires a Filemap.xml which I previously generated via first step of conversion. I added this to the folder containing all .XML and .MET files and specified this folder location for the Conversion output / Import input folder field.

I am now getting the following errors which I don't understand

The FieldValue "Topic type" cannot be returned, because it is not initalized.

Can anyone advise on how to resolve these last errors?

Thanks in advance,

Ann