As well you should test RE on development. Dan's got the right idea Remedy development / testing / prod environments. Sometimes things get out of hand though (say upwards of 8 environments!) Hardware is important as well - load balancers, server groups, etc. Whenever you change RE jobs you *should* test them in dev. If they are in error you can damage the production data and through not impossible it would be hard to get that data back. Now, to do test in development, "just" replicate some of your CI's relationships etc from the BMC.ASSET to whatever dataset you like - i.e. TOPO. You don't need the discovery tool there although, sure, it's a better test.. I use a Meta-Update script to replicate CIs & relationships from one dataset into another sometimes effecting attribute changes and sometimes manually changing some attributes. You can do this in a number of ways such as export / import, Meta-Update, or even manually. This will probably the biggest pain in your dev setup. You must also ensure that the recon jobs will match and not match CIs. That is: have a test plan to exercise the recon jobs for both positive and negative results so that you can verify that your jobs are working as desired. Use all the classes you will be using in production - especially if you have non-ootb classes. Use a lot of differing attributes according to the design of your jobs. "DatasetID" is an attribute in BaseElement and BaseRelationship. Make sure conditions in you test scenarios reflect conditions in production. For example if your discovery product does NOT set the Reconciliation identity (which it sounds like from you RE job description) ensure the CIs in the import dataset (TOPO) also has no Recon IDs set; similarly in the production DS (that on dev BMC.ASSET) as you would see the CIs in production. Note relationships must have a set recon id. So,if your discovery tool also stores relationships you may have * misidentified * CIs already. You don't say what release you're on. There are a few small changes from 7.1 to 7.6 in this area. Note also, that you will may to create the TOPO datasetid in BMC.CORE.CONFIG:Datasets (or something like that as my ITSM is not up right now). You can use the RE console to do so but this causes problems with moving RE jobs as the Dataset's datasetid (guid) will be different between the two systems and some records in RE jobs use this guid. So, these will either have to be modified or a filter can be added to the RE form in Q to look up the appropriate value (The RE jobs use this guid entirely redundantly but use it they do so it must be correct). As for the Sandbox that's a whole other story. I have open bugs on that which BMC will "address in a major release in the future" which is not 7.6 / 7.5. See discussions about 8 or so months last year on this list. search "Recon" "Sandbox" etc. Good luck. I found so may serious flaws with RE that I ended up not using it at all for my requirements which admittedly were not that simple. You should not run into these flaws with the straightforward thing you are trying to do. Cheers Ben Chernys
Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329 GMT + 1 + [ DST ] Email: <mailto:ben.cher...@softwaretoolhouse.com> ben.cher...@softwaretoolhouse.com Web: <http://www.softwaretoolhouse.com/> www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. <http://www.softwaretoolhouse.com/> <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kathy Morris Sent: March 23, 2010 6:14 PM To: arslist@ARSLIST.ORG Subject: Re: RE Jobs ** We have a development server for code changes. Do we need to use dev to test RE jobs (data changes?). I could see if Development modeled production. However our dev does not model prod because the foundation discovery pushes data to prod TOPO. Can we use the sandbox to test RE jobs? For code changes, patches, etc we use DEV to Prod. We are just not sure about the best approach for "data changes" made by the RE jobs. We want to be able to test the RE jobs. I need to build a RE job that adds CI's to BMC.ASSET and /or the sandbox. And I need to build a second RE job to update CI's where the host name = host name, and the bios serial # = serial #. We just do not want the data in production messed up as a result of the RE job. Isn't this what the sandbox is for? In a message dated 3/19/2010 9:53:52 P.M. Eastern Daylight Time, danielbl...@rogers.com writes: ** Afraid the bottom line is that Topo should be sending data to Dev. A Dev version of Topo. Two instances of the Topo system. How else do you test new versions, patches etc. without lighting a fire under your Prod system? There should always be a DEV, QA/Testing and Prod environment. (there could be a 100 post long diatribe from various quarters about what constitutes appropriate DEV, QA, Prod environments and how much the same they need to be to be considered a replicated environment at this point). Then there is the 4th, a Sandbox for testing out products, theories, things that may or may not end up on the path to production. However, there should always be those 3, same OS, Same DB, same ARsystem version patches etc. etc. you get the picture, QA/Testing should mimic the real Production Environment. In a big shop, QA/Testing should be the same hardware as Production. Haven't come up with a good argument why the others can't be virtual, and in theory there is good reason for them to be virtual. ..... Dan _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kathy Morris Sent: March 19, 2010 6:39 PM To: arslist@ARSLIST.ORG Subject: Re: RE Jobs ** Discovery is pushing data into Topo on our production environment. My concern is if we copy prod to dev, won't the data be different for the reconciliation jobs? The data is continually being updated Discovery pushing data into TOPO on Production. Discovery does not push the data into Topo on Dev. It just seems that the RE are so tempermental. I am concerned that Dev will have different data (without the updates from Discovery). Right now I know we are not connecting Discovery to Dev. In a message dated 3/19/2010 6:27:47 P.M. Eastern Daylight Time, tayl...@ldschurch.org writes: ** I would highly recommend building a dev environment. Setting up reconciliation jobs is not necessarily an easy task and is very error prone. Also, depending on how Discovery gets data into your production database, you may be able to have it feed both environments. If Remedy is pulling data (using AIE to transfer the data) into production, you can simply set up the same AIE jobs on your dev server for it to copy the same data into that environment. If, however, Discovery is pushing data into Remedy (less likely) then you'd have to look for other options. In fact, one other option might be to configure AIE to actually pull CI data from production. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kathy Morris Sent: Friday, March 19, 2010 3:56 PM To: arslist@ARSLIST.ORG Subject: RE Jobs ** Hi All, We do not have a CMDB dev environment. I need to create RE jobs. Is it better to copy BMC.ASSET into separate dataset, and run the RE job against the dataset copy to testing purposes. Or should we build a separate DEV environment and create the RE job? We also have only 1 Discovery Server that is connected to Production. So the CMDB development server would not receive any asset updates from the Discovery tool. _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
