• Replies 10 replies
  • Subscribers 139 subscribers
  • Views 2016 views
  • Users 0 members are here
Options
Related

Copying a publication between Tridion environments?

Ann Jensen

Hi,
We need to copy publications from our production env to our gamma env. I am familiar with the following process
1. Select publication in Content Manager
2. Select Reports link
3. Select Show Report followed by Export Publication
4. Download contents of exported publication and use Content Importer to import it

Customers are experiencing a large number of errors during conversion phase using Content Importer.

Is there a better procedure that they can follow to achieve copying a publication and its content between Tridion environments?

Thanks in advance,
Ann
Rate translation
×
Suggest better translation
×
Parents

  • 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
  • in reply to Naoki Hirai

    This is an interesting thread seeing how different groups go about this. I don't have an answer to the original post from 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.  - have you taken a look at the Export Publication process that Ann describes in the initial post? I follow that process and to '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?
  • in reply to Nigel Lock

    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.
Reply Children
  • in reply to Kendall Shaw

    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
  • in reply to Kendall Shaw

    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