Forum Discussion

pnataraj03's avatar
pnataraj03
Ideator III
6 years ago

Migrating the Configurations done using tp_block in ARAS Technical Documentation

Dear Team,

We have done bunch of configurations inside tp_block (ItemType) in ARAS Technical Documentation in our local environment.

We would like to migrate tp_block (ItemType) along with those configuration to another Development Environment in another server.

Someone told us, its not possible to do this; since tp_block is default ItemType created inside ARAS Technical documentation module and any changes/configurations made in specific local environment can't be migrated and overwritten to another Development Environment in another server.

Hence we need to manually redo the same changes/configurations in another  Development Environment in another server.

Please clarify and confirm this is correct.

If its not correct, please suggest how this migration of tp_block can be accomplished.

Thanks in advance.

6 Replies

  • Hi,

    what kind of changes to you have done? Added new properties? Manually redo additional properties would be even worse, cause the id´s doesn´t match and you cannot transfer data that might already exists in your dev database.

    From my POV it should be possible to import your tp_block modifications, you just needs a couple of dirty tricks. Can you explain what you have modified?

    • pnataraj03's avatar
      pnataraj03
      Ideator III

      Yes, I have added new properties like document language, document description, etc. also modified existing properties to make it unique and add sequence for document number.

      I would like to know those tricks and also I would like to know is there an in-built functionality to track the changes made to these properties with ARAS through versions/revisions? OR Should I track it offline outside ARAS?

      Please suggest.

      • angela's avatar
        angela
        Catalyst II

        As you mentioned, tp_block is a default ItemType that already comes with the default installation.

        Try this at your own risk and use a test data base for the first try to see if you really get the correct result. When it doesn´t work you may risk your main database. 

        You first have to discover, in which Package Definition the ItemType is stored. Than export this package definition with the export tool. Now open the folder and try to find the xml file that represents the tp_block ItemType. Throw everything out of the package definition that is not needed so only the tp_block xml element will remain. You can open the xml with a standard text editor. It should contain your customized properties. Then import the reduced import package to the new database.

        ItemTypes do not have a revision, so you cannot track the changes. It´s the only ItemType were I think it´s impossible to use revisions, cause ItemTypes represent real physical tables in the database. You could use the ItemType Definition Report to have a quick overview ItemType before/after modification. 

        What is your experience with multilanguage tech docs? I faced a couple of problems to add the translation of the technical documents when using multiple languages in parallel.