• State Verified Answer
  • Replies 5 replies
  • Subscribers 48 subscribers
  • Views 3294 views
  • Users 0 members are here
Options
Related

Moving Folder across Servers via API

Nikku

Is it possible to move folders across different Servers via API?

We have a Test Server and a Production Server, our goal is to create a utility which will allow a user to move a folder from test -> prod via API. I just don't know if it's possible.

Thanks,

Nikku
Rate translation
×
Suggest better translation
×
  • 0
    With ISHRemote, you can create a script that holds two sessions (source and target) and then use get cmdlets with source session to extract content and then push them to the target target session with the set cmdlets.

    Just remember not to do all the extracting first and then all the pushing, because you are limited by PowerShell process' memory.
  • 0 in reply to Alex Sarafian
    Hi Alex,

    I've had this idea in mind. Thank you for clarifying :)
  • 0
    Would it be any folder type or just a subset (e.g. modules, illustrations)? Would you recreate all versions of all objects?
  • 0 in reply to Joakim Nybäck
    Hi ,

    The case will be to move a folder which contains different folder types (Publications, Maps, Topics, Images,etc) to the Production Server.
    If moving is not allowed the I will be needing to recreate all the versions of all objects. However, in this case, i'm a bit concern for instance:
    1. A particular map is referencing a topic which is located in different folder in the Test Server. If a move the folder containing the map to the Production Server what will happen to the topic being referenced?
    - Is there a way for me to download all the references locally, fix the reference and move it to the Production Server?

    Thanks.
  • 0 in reply to Nikku

    Hi @Nikku,

    As to your observation regarding references to objects in other folders, there is per se no need to "fix the reference". In the default case, the object in question is referenced by a GUID, and in which folder it resides does not matter (if you move stuff around in the folder tree things will still work just fine).

    You are correct in that there is no guarantee that everything you need to successfully publish a publication actually resides in a certain folder. Really the only way to address that is to start from the Maps folder, parse each map recursively to ensure you have enumerated all objects. Next you would have to parse all of the objects to ensure you move over all conref targets. But you can find the information you need more conveniently from metadata fields, too. The notes below are from my mindmap, so check the offical documentation to ensure you get what you expect. Of course, for each object that needs to be moved over all versions and languages (potentially) need to be addressed. When you move over an object, it does not matter if you create version 3 first, then version 2 and so on, as long as there are no clashes.

    Observations on metadata fields

       FISHHYPERLINKS

           these are <XREF> @href attribute values

       FISHLINKS

           these are @href attribute values e.g. on

               @conref

               <topicref>

       FISHTARGETS

           elements with @id attributes - which can serve as link targets

           includes the id of the current module

       FISHFRAGMENTLINKS

           the topicid#rootelementid part of a conref target

    Variables need to be resolved, too. I.e. you also need to ensure any publication resources are moved over.

    Publications will give you the most exercise, for sure. You have to recreate the baselines. You have to set the resources. The publishing context, <features> XML stored in FISHPUBCONTEXT, need to be copied over.

    Fore sure there are more issues than I could think of just now off the top of my head. 

    I would appreciate it if you let us know how you get on with this. Always interesting to know what others are tinkering with.

    Joakim