As I recall, it is a regular old .ARM file, same as if you saved a mapping with the data import tool. The XML just instructs DDM to use a particular ARM file for the Form.
And in the .arm file, it only lists the field(s) that require manual mapping when their field-ID's don't match. So the DDM seems to have the mapping scheme of "map each field by matching field-id *and* map this other field(s) according to the arm file". Hope that makes sense. And like I said, this is a bit of a trip down memory lane, so if you install a recent version of migrator, you will get DDM with that install and you can inspect the files to confirm. -JDHood On Mon, Apr 24, 2017 at 6:48 AM, Jarl Grøneng <[email protected]> wrote: > ** > > See attachments > > Regards, > Jarl > > 2017-04-24 12:31 GMT+02:00 Misi Mladoniczky <[email protected]>: > >> ** >> Hi, >> >> In other words it actually points to the .ARM file for mapping. >> >> So how is this structured, do you get a set of config/mapping files for >> each supported version transition? >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs >> Find these products, and many free tools and utilities, at http://rrr.se >> >> >> April 24, 2017 10:01 AM, "Jarl Grøneng" <[email protected] >> <%22jarl%20gr%c3%b8neng%22%20%[email protected]%3E>> wrote: >> >> ** >> Hi >> This is a DDM instruction file, and you can see that the field mapping >> using an import-tool format. >> <data-instructions> >> <data enabled="true" source-form="TMS:Task" destination-form="TMS:Task" >> type="data" mode="search" merge-option="update" >> ignore-required-fields="true" ignore-pattern-matching="true" count="0" >> disable-related-workflow="true"> >> <qualification>PASS_QUALIFICATION</qualification> >> <unique-fields> >> <field id="179"/> >> </unique-fields> >> <ports enabled="true" list="LIST_PORT" fast="FAST_PORT"/> >> <field-mappings enabled="true" file="TMS_Task_PD8303_Mapping.arm" >> type="2"/> >> </data> >> </data-instructions> >> Regards, >> Jarl >> 2017-04-20 14:48 GMT+02:00 Misi Mladoniczky <[email protected]>: >> >> ** >> Hi, >> >> So RRR|Chive works in a similar way, where matching ids are the default, >> regardless if it is a custom field or not. Fields can then be >> mapped/skipped specifically. >> >> It sounds like a simple thing to generate rrrchive-config-files based on >> the mapping-files from DDM!? Any chanse of supplying me with a few >> DDM-config-files to allow me to check how much work it would take? >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs >> Find these products, and many free tools and utilities, at http://rrr.se >> >> April 20, 2017 1:49 PM, "JD Hood" <[email protected] >> <%22jd%20hood%22%20%[email protected]%3E>> wrote: >> >> ** >> As for custom fields, the in the 7.x version, the default DDM mapping was >> based on matching field IDs, unless a different mapping was specified. So >> as long as custom fields had the same field ID between the systems, the >> data would migrate correctly. >> >> So, with DDM migrating between two forms, it would map based on matching >> field IDs for all fields that were not mapped specifically. So if you >> looked at the mappings for the specifically mapped fields, it only listed >> the odd-ball fields that needed to be mapped because their ID's differed >> (presumably due to version changes). As long as custom fields had the same >> field ID between the systems (or if you manually edited the DDM mapping to >> include the custom fields if the ID's differed), the data would migrate >> correctly. >> Biggest issue I had with DDM is that it was slow, Slow, SLOOOOOOOW. >> Thanks, >> -JDHood >> On Thu, Apr 20, 2017 at 6:19 AM, Vinod Gaidhani <[email protected] >> > wrote: >> >> ** >> Thanks Misi, seems to be good and overcomes shortcomings of DDM. >> >> Vinod. >> >> On 20-Apr-2017, at 2:30 PM, Misi Mladoniczky <[email protected]> wrote: >> >> ** >> Hi, >> >> One big difference between DDM and RRR|Chive is that DDM just finds all >> records after the date/time you specify and transfer these records. >> >> RRR|Chive will pull all recordids and modify-dates from both system and >> then do transfer/delete as appropriate. No need to specify a date. >> >> Because of this it is easy to use to restore a system after, for example, >> testing. >> >> I have been playing with the idea of using the DDM mapping files in >> RRR|Chive, but have not come around to doing this. So you are pretty much >> on your own and need to do the mapping yourself. >> >> I am not 100% sure about this, but I think that DDM will not copy data on >> custom fields you have added yourself automatically. >> >> I have another tool I like to use when planning migrations to new >> application versions, and this is RRR|DefFieldDiff that will give you an >> excel sheet of all changed data fields. This makes it easy to find >> differences and plan your data massaging. >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs >> Find these products, and many free tools and utilities, at http://rrr.se >> >> >> April 19, 2017 2:39 PM, "Murnane, Phil" <[email protected] >> <%22Murnane,%20phil%22%20%[email protected]%3E>> wrote: >> >> We've used DDM and RRR|Chive successfully on various projects. Misi's >> tool is scriptable and very fast compared to DDM. DDM can schedule code and >> data migrations. Generally both require the Last-Modified date/time field >> to be accurate. Overall, I'd personally recommend RRR|Chive. >> >> >> HTH, >> >> --Phil >> ------------------------------ >> *From:* Action Request System discussion list(ARSList) < >> [email protected]> on behalf of Nicosia, Ryan J. CTR USSOCOM HQ < >> [email protected]> >> *Sent:* Wednesday, April 19, 2017 8:14 AM >> *To:* [email protected] >> *Subject:* Re: [Non-DoD Source] Re: need input about data migration >> after Upgrade >> I have to disagree. We used DDM with great success but it does require >> admin freeze on all deletion activities of your production environment. >> That said, there are ways to get around that as well but purging the form >> in question on your target server and telling DDM to just pull everything >> over. >> >> Once you get to the point where you are running DDM every few days, the >> errors are easy to identify and clean up and you can re-run a specific >> package as needed. >> >> Ryan >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) [ >> mailto:[email protected] <[email protected]>] On Behalf Of Mohamed >> Kamruzzaman >> Sent: Wednesday, April 19, 2017 5:50 AM >> To: [email protected] >> Subject: [Non-DoD Source] Re: need input about data migration after >> Upgrade >> >> Hi Amit, >> >> Agree with Vinod, you may want to look at alternate solution considering >> you are looking at migrating and cleaning your data. You will want to >> migrate over foundation, configuration and transactional data onto ITSM 9.x >> . This is an ideal time to clean up data, remapping Prod cats and Op Cats >> etc. and potentially archive some of the tickets that you no longer need. >> >> We use our Customer Move Tool (more info [CAUTION] >> http://www.alderstone.com/cmt) for the migration from previous ITSM >> versions to the latest, as we can migrate all modules data or a reduced set >> (including transformation and cleaning of data), depending on your >> requirements. In general we've been able to move entire data set within a >> day ensuring a smooth migration. Please let me know if you would like to >> talk about this in more detail or have any specific questions. >> >> Regards, >> Mohamed >> >> Mohamed Kamruzzaman. Alderstone.com +962776723269 | >> [email protected] | Skype: mkamruzzaman | LinkedIn: >> Mohamed-Kamruzzaman >> >> ____________________________________________________________ >> ___________________ >> UNSUBSCRIBE or access ARSlist Archives at [CAUTION] www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> >> ____________________________________________________________ >> ___________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
