5 Replies Latest reply on Aug 13, 2010 8:42 AM by Lara Hellman

    DesignTransfer - what gets moved and what doesn't?


      We are exploring the user of the Design Transfer tool.  We are at a loss of what it can do and what it can't do.  We are also a little baffled by what gets moved.  Since windows are attached to dbusiness objects, does the entire data object get moved?  What about the data attached to the business object?  Here is an example:

      I am updating an incident screen.  What gets moved in the design transfer?  The Designer document says "all of the user defined business objects, attritubes and queries are also exported".  I assume that attributes means fields.  What exactly does that mean?  Is the field layout getting moved or changed?  Is the data within that field getting moved?


      The designer document is somewhat lacking in explanation, etc of how the tool works.  Any information would be GREATLY appreciated.  (In class our instructor told us not to use the tool so we are getting mixed messages).

        • 1. Re: DesignTransfer - what gets moved and what doesn't?
          dmshimself ITSMMVPGroup

          DT does need some experience and the occasional bit of gentle encouragement, but it is very effective in the right hands.  I'm also aware it might get a bit of a revamp in the next major release.


          Anyone some thoughts from me .....


          DT doesn't take across data, apart from the contents of reference lists if you choose to do that.  It's main job is to take across structures - queries, processes, windows.


          If you select a window and allow DT to supply the dependant objects, then it does a decent enough job of finding all the attributes, queries and filters you might  have used.  But it does miss some things which you may want to hand edit in.  For example ...


          If you select a process, it will grab all the objects you need, but not the windows.  So make sure you add the windows you need.  It's often handy to add the relavent windows you have put in as this will pick up a lot of windows at the same time.


          Once objects have been selected, go to the object part of DT and tick all the attributes of those with a blue (!), except the one called deleted.  The deleted attribuet will be recreated for you (assuming the object is soft deleted) and you do not want to create it as part of DT as otherwise errors result.  The reason I suggest selecting all the attributes on the object is that is does no harm and you may well want to use something like group created by later on, even though you are not using it now.  Some attributes like creation date really do need to be there but unless they appear on a window or a query are not selected.


          Do the DT is secitons, don't try and do everything initially, esepcially while you are getting used to it.


          I also suggest leaving yourself in DT and importing into you new DB in another Console sesion.  That way if you are missing a window, you can add it and re-export. (Or export to another file)


          Be very careful if you have any calculations - especially in conditions in a process.  I'd take them off, transfer the process and rthen put them back on again.


          WebDesk versions of windows have to be re-applied, just create them and set them as default or change your rules.


          Default windows exported will become the new default window when imported.  This is quite handy as long as you know this is happening.


          Reference objects can be a bit fraught depending on your version.  Catageories I'd export using the action in category creation to do that.

          Ordered lists, go back to each ordered list and put the order back as it should be.


          If you are on 725, don't take any HTML formatted assignment/reminder messages acorss in the process. Stick to plain HTML.


          When designing a process, make notes about what you did as this makes creating a DT much easier.  If it's not one of your process you need to allow time for footling about.


          If you mod a window in 9say) dev, don't take that same window acorss to production.  Always make a copy of the window.  Not only is this best practise, but encourages DT to create the new window.  Ditto queries and Process


          Processes can be DT's across, but not changes to processes, so allow for hand editing of those new mail messages or extra small steps in a process to be done.  Or just say the change is enough to warrant having a new version of the process.    If you do the latter though, watch out for your license of active processes here though as if you need to have another one active, you need to make sure you have a spare license to do that now and forever.


          Some things cannot be DT'd so make sure all the ones you cannot transfer are well document so you can repeat their creation.


          When you DT in, practise on a dev system and document the steps.  Then when it comes to production you are just ticking off actions.  In the DEV system make sure it's easy to get a backup restored - a virtual environment is great.  You can then reherse the DT to make sure it's all smooth.


          Portal has no DT equivalent, so again document the changes.


          With versionable CI's, I recommend taking the non-versioned object across first and then the Windowsfor both non-versioned and versions.  It just seems to be smoother that way.


          More thoughts  from other people will no doubt be added in due course

          • 2. Re: DesignTransfer - what gets moved and what doesn't?
            Julian Wigman ITSMMVPGroup

            My findings in addition to Dave's:


            • It doesnt do the new Dashboards in 7.3 and later.
            • It does do Views OK (from my experience) but does seem to get confused with "View Selection Rules"  (the index oredr etc) though these are quick to do by hand so not a big deal.
            • It does do Calculations on process conditions now from 7.3.1 IF you have applied the patch for Problem # 4489
            • It also sort of does calculations on business objects too;  they certainly transfer across but i found that they then did not always work.  Open them up in in BO designer and copy them;  exit calc,  then add calc back and paste in and it then seems to work.  Maybe DT not quite ding quite all it needs to here.



            • 3. Re: DesignTransfer - what gets moved and what doesn't?
              Julian Wigman ITSMMVPGroup

              An update on my post:


              It now does do Business Object level calculations if you apply 7.3.2 patch P # 4913



              • 4. Re: DesignTransfer - what gets moved and what doesn't?


                We are running Touchpaper console 7.2.5 Helpdesk, I have tried using DT to copy a Business object layout to our test system.

                The live system created the xml file ok but when I go into DT on the test and "open export file" nothing appears to happen but if I try a second time it gives an error saying Item has already been added and it never appears under Business Objects? -- Help, newbe!!

                • 5. Re: DesignTransfer - what gets moved and what doesn't?
                  Lara Hellman SupportEmployee

                  Hi Charles,


                  This probably needs looking at by Support. If you haven't already, please raise an Incident with us.