Hi Thad, I use rrrChive a lot for the sort of thing you are proposing. It is a tremendous time saver and I love it.
I think if you are going down the path of synchronising the data in two servers that the request ID should also be synchronised. Many Remedy apps use the value of the request ID as data and I think it is a good idea to keep things simple and adopt a policy of never assuming that the request ID is not important. I got myself into trouble migrating AIE config data from one server to another (not using rrrChive) and found to my cost that request ID sync was very important. I usually move the group and user forms without rrrChive due to the sensitive nature of these forms. The user form could be kept up to date with a copy rather than a synctotarget though. Be very careful with synctotarget on the user form as if your own login has a different rerquest ID it might be deleted on the destination and then the whole process falls apart. I usually turn off merge operations as this can complicate the sync. Why not just move all of the related data at once? Modify and submit filters don't fire on the form that you are importing to but as I understand it if a merge does a push fields to another server then the modify/submit filters will fire on that form. >From my experience it is a pretty safe and reliable operation to sync two servers with rrrchive if you don't try and overcomplicate things. If you use synctotarget on all the data forms you need to transfer it works well. If you miss a couple of forms on your first pass then it is easy to just add them to the config file and run the sync again. It won't take long as it only copies the modified data on subsequent runs. If you want a different policy on certain forms (eg. you have updated a reference form with new data as part of development then exclude that form from the sync and deal with it manually) Good luck with it. Rod On 06/07/2009, Thad K Esser <[email protected]> wrote: > Sorry, forgot the details... > > ITSM 7.0.3 > ARS 7.1 > AIX 5.3 > Oracle 10g > > Thanks, > Thad Esser > Remedy Developer > "Did you ever wonder why we had to run for shelter when the promise of a > brave new world unfurled beneath a clear blue sky?" - Pink Floyd > > > > From: Thad K Esser <[email protected]> > > To: [email protected] > > Date: 07/04/2009 11:17 AM > > Subject: rrrChive and ITSM > > Sent by: "Action Request System discussion list(ARSList)" > <[email protected]> > > > > > > > I just recently started looking at the rrrChive tool, and it looks pretty > handy. I was considering using it to move some ITSM data, that the Data > Management Tool doesn't move, from one server to another. The target > server is a brand new install and basically only has out of the box sample > data. > > Near as I can tell, when using the "SYNCTOTARGET" transfermode, rrrChive > uses the Request ID field to indicate identical records. Does anyone know > if there a way to tell it to use other fields for that comparison? For > example, if I were comparing operational catalogs on two servers, its the > values in Tier1 through Tier 3 that say whether the data on the two servers > are the same, not the request id. > > I'm concerned that if I don't keep the request id's in synch for every > form, things will get ugly quick. And that possibility is made clear by > the necessity of the DMT, but alas, it doesn't move everything. > > The other question I had, is that if I use rrrchive to move support groups, > will the corresponding records on the Group form automatically get created? > I can look on Monday, but was hoping for a quick answer this weekend. > (does rrrchive trigger submit/modify filters, or only merge?) > > I know I'm in a dicey area, so any words of wisdom or "gotchas" type advice > is appreciated. > > Thanks, > Thad Esser > Remedy Developer > "Did you ever wonder why we had to run for shelter when the promise of a > brave new world unfurled beneath a clear blue sky?" - Pink Floyd > > > *IMPORTANT NOTICE: This communication, including any attachment, contains > information that may be confidential or privileged, and is intended solely > for the entity or individual to whom it is addressed. If you are not the > intended recipient, you should delete this message and are hereby notified > that any disclosure, copying, or distribution of this message is strictly > prohibited. Nothing in this email, including any attachment, is intended > to be a legally binding signature. > * > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" > > > > > *IMPORTANT NOTICE: This communication, including any attachment, contains > information that may be confidential or privileged, and is intended solely > for the entity or individual to whom it is addressed. If you are not the > intended recipient, you should delete this message and are hereby notified > that any disclosure, copying, or distribution of this message is strictly > prohibited. Nothing in this email, including any attachment, is intended to > be a legally binding signature. > * > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
