The SLM data is the one place where I had trouble moving records from 7.1 to 7.6 using rrrchive, mainly because of differences between the versions and the related workflow. Specifically, the records related to service targets could not be moved that way because of (a) differences between SLM 7.1 and 7.6.x, and (b) the fact that those records are related to actual workflow - z filters - that are built on the fly. In the end, I ran an upgrade on a copy of the 7.1 system because of the problems with SLM. After that, I was able to keep all of the transactional SLM data current along with Incidents using rrrchive to move data from the production 7.1 server to the test 7.6.x server in the following tables:
SLM:Measurement SLM:EventSchedule SLM:MilestoneLogging SLM:RuleActionNotifier SLM:SLACompliance SLM:SLAComplianceHistory Using cfg files like this: source_server = <fqdn> source_user = Demo source_password = <password> source_form = SLM:Measurement source_tcp = <tcp port> target_server = <fqdn> target_user = Demo target_password = <password> target_form = SLM:Measurement target_tcp = <tcp port> target_disablemergefltr = YES target_disableaudit = YES qual = onlyfields = COMMON transfertype = SYNCTOTARGET logfile = 7SLM/log/copy_SLMMeasurement.log loglevel = INFO progressbar = YES On the Incident side, I was moving these: HPD:Help Desk HPD:WorkLog HPD:Help Desk Assignment Log HPD:Associations HPD:HelpDesk_AuditLogSystem HPD:Template HPD:TemplateSPGAssoc ...using equivalent .cfg files, called from a batch file: rrrchive 6Trans\copy_broadcast.cfg rrrchive 6Trans\copy_broadcastSPGassoc.cfg rrrchive 6Trans\copy_kms_session.cfg rrrchive 6Trans\copy_hpdhelpdesk.cfg rrrchive 6Trans\copy_hpdworklog.cfg rrrchive 6Trans\copy_hpdassignmentlog.cfg rrrchive 6Trans\copy_hpdassociations.cfg rrrchive 6Trans\copy_hpdhelpdeskauditlogsys.cfg rrrchive 6Trans\copy_hpdtemplate.cfg rrrchive 6Trans\copy_hpdtemplateSPGassoc.cfg ...using .cfg files like this: source_server = <fqdn> source_user = Demo source_password = <password> source_form = HPD:Help Desk source_tcp = <tcp port> target_server = <fqdn> target_user = Demo target_password = <password> target_form = HPD:Help Desk target_tcp = <tcp port> target_disablemergefltr = YES target_disableaudit = YES qual = skipfields = 301389275, 301655000, 301655100, 301702700, 302065400, 302065500, 302065600, 302065700, 302258732, 302258733, 302258738, 302258742, 302258746, 302269413, 940000011, 940000012, 940000013 transfertype = SYNCTOTARGET syncmaxdeletedpercent = 0 logfile = 6Trans/log/copy_hpdhelpdesk.log loglevel = INFO progressbar = YES NOTE: Most of the time I use the onlyfields = COMMON construct, but skipfields was more appropriate for this form. When I am making the initial migration from the 7.1 server to the 7.6 server I normally run each rrrchive transfer individually, then check the results in the form and review the logs. After the initial migration, I run the batch files for blocks of data (Groups, Foundation, People, Notifications, Transactions, SLM, Kinetic) to keep the test server data current with the production server. If you want to create test tickets and escalations on the new server and still keep the data current from production, you have to set higher NextIDs on most of the Help Desk tables that you are syncing plus HPD:CFG Ticket Num Generator and HPD:IncidentInterface_Create, as well as the first three SLM tables I listed. I am rebuilding these scripts and re-validating every Regular table between my production 7.1 system and a new 7.6.03 system right now to prepare for a new migration - which will also involve applying 7.6.03 Patch 001 (i.e., 7.6.04) when it is released, so I should have some fairly complete documentation of the process when finished. Right now, it is still evolving, and I will need to solve the whole SLM problem one more time. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jiri Pospisil Sent: Tuesday, January 11, 2011 3:42 AM To: [email protected] Subject: Re: RRRchive for upgrade ** ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Please Read The Disclaimer At The Bottom Of This Email ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Don or anybody else, Did you use rrrchive for migrating ITSM data with SLM service targets associated? I am especially interested if anybody migrated Incident data and related SLM service targets. Or if you only migrated the Incident data and let the service targets be created by the workflow on the target server. Any suggestions would be greatly appreciated. Jiri Pospisil Remedy Specialist LCH.Clearnet<http://www.lchclearnet.com/> From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of McClure, Don Sent: 07 January 2011 22:34 To: [email protected] Subject: Re: RRRchive for upgrade ** Anne, A number of the forms related to Company, Region, People, Location and others should probably NOT be copied as SYNCTOTARGET . This mode removes 7.6.X-related info which should probably not be molested (would tend to contaminate GUID assocations which gets very messy). Any form containing target records which should be maintained is a strong candidate for export/import rather than rrrchive--we have not yet found another method of maintaining subject GUIDs, and usage trials with re-written GUIDS did not work well at all. Of course, this is an ITSM implementation; a basic ARS with custom workflow may be a different matter. Also--we have utilized rrrchive extensively, but when 'multipleforms' is specified as a parameter, it is with an explicit form list. We have not yet extended trust to these API-calls being able to properly handle the form list with search, grab-next-match, copy, repeat--the single-pass wildcard for multiple forms failed on its first usage in our environment. We found usage much more expedient to generate our current implementation: this instance contains one form-specific configuration file per record-set to be copied, then hand-assembled into batch files which copy records in a sequence which Chris Strauss and I analyzed carefully before automating this process. Another parameter we set is 'onlyfields = COMMON' to avoid trying to write data to nonexistent fields (or attempt to copy data from improper sources). I hope this information helps-YMMV. Don W. McClure, P.E. CITC Call Tracking Administration University of North Texas dwmac @ unt . edu From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Ramey, Anne Sent: Friday, January 07, 2011 4:09 PM To: [email protected] Subject: RRRchive for upgrade ** I'm doing a three step install/upgrade process: Export/import the DB to new machines Upgrade Remedy on new machines Put New machines into production If I'm going to push data from an old system to a new system using RRRchive to capture the difference between the export and the go-live, I really need the data from all regular forms. I even want to capture all new users and groups, etc. It looks like a multipleforms = * splitsearch = YES transfertype = SYNCTOTARGET Will do this. Has anyone done this successfully? It makes me a little nervous Anne Ramey *********************************** E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ************************************************************************************************* This email is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of LCH.Clearnet Limited and/or LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail and notify [email protected]. LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet Group accept no liability, including liability for negligence, in respect of any statement in this email. The contents of this email are subject to contract in all cases, and LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment save where confirmed by hard copy. Cet e-mail et toutes les pièces jointes (ci-après le "message") sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, merci de le détruire et d'en avertir immédiatement [email protected]. LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre de ce message à moins qu'il n'ait fait l'objet d'un contrat signé. LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA. Recognised as a Clearing House under the Financial Services & Markets Act 2000. Reg in England No.25932 Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, Chambre de Compensation conformément au Code Monétaire et Financier. ************************************************************************************************* _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
