Re: Upgrade suggestion
Hi Ankita, If you can avoid using an OOTB field, that is best practice. Sometimes it doesn't make sense to build a new field when an OOTB field can handle the job. The biggest thing is to not modify existing workflow if you are in a pre-7.6.04 environment. If new workflow will conflict or is just a tweak to the qualifications, make a copy of it with some letters in the front indicating ownership and/or customization (eg. BMS-name of workflow object for Bristol Meyers Squibb if you worked there) and then disable the original workflow object (active link, filter, escalation, etc.). This way, any upgrades will pick up the original disabled object and if it needs to modify it, it will. You should always do a snapshot of your DB and a separate def of all non-OOTB forms, modified OOTB forms that have new fields or fields that have changed parameters (which I do not suggest as they may affect workflow to another form you are not aware of that carries the field or a join form you are not aware of), and of all non-OOTB workflow so you can import it into the new system post-upgrade. If you are working with a 7.6.04 version or later, then modify the object in the Best Practice view as an overlay and you will be fine with an upgrade. Upgrades won't mess with overlays. Hope that helps and good luck! On Friday, June 13, 2014 3:53 AM, Ankita Pankaj ankita.panka...@gmail.com wrote: ** Hi All, What is the best practice while doing development adding new fields in the form or analyze existing fields to utilize. Reason for asking this question: I am little confuse if I have utilized existing fields for my use and as the creator of the field is BMC, they can utilize it in future release. In further releases, If BMC has added new workflows around that field and I have also written some workflows , so during upgrade how it will impact my functionality around that field? Thanks in advance -Ankita _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
Re: Upgrade suggestion
1. If the purpose of the field is simply to be used as a buffer and store temporary values, we should add/reuse a display only field. In such cases, reuse is a better option, provided the field is not used for any other operation in the same transaction. In case if there is no free field, you can add a new one , since it adds no extra column to the database. But just make sure you create those fields in custom mode, so that there is no impact during upgrade. 2. If the field need to contain a record, then we should always create a new 'custom' field rather than using an old one. BMC can any time remove that field from the forms or change its value. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ars Lister Sent: 13 June 2014 21:48 To: arslist@ARSLIST.ORG Subject: Re: Upgrade suggestion ** Hi Ankita, If you can avoid using an OOTB field, that is best practice. Sometimes it doesn't make sense to build a new field when an OOTB field can handle the job. The biggest thing is to not modify existing workflow if you are in a pre-7.6.04 environment. If new workflow will conflict or is just a tweak to the qualifications, make a copy of it with some letters in the front indicating ownership and/or customization (eg. BMS-name of workflow object for Bristol Meyers Squibb if you worked there) and then disable the original workflow object (active link, filter, escalation, etc.). This way, any upgrades will pick up the original disabled object and if it needs to modify it, it will. You should always do a snapshot of your DB and a separate def of all non-OOTB forms, modified OOTB forms that have new fields or fields that have changed parameters (which I do not suggest as they may affect workflow to another form you are not aware of that carries the field or a join form you are not aware of), and of all non-OOTB workflow so you can import it into the new system post-upgrade. If you are working with a 7.6.04 version or later, then modify the object in the Best Practice view as an overlay and you will be fine with an upgrade. Upgrades won't mess with overlays. Hope that helps and good luck! On Friday, June 13, 2014 3:53 AM, Ankita Pankaj ankita.panka...@gmail.commailto:ankita.panka...@gmail.com wrote: ** Hi All, What is the best practice while doing development adding new fields in the form or analyze existing fields to utilize. Reason for asking this question: I am little confuse if I have utilized existing fields for my use and as the creator of the field is BMC, they can utilize it in future release. In further releases, If BMC has added new workflows around that field and I have also written some workflows , so during upgrade how it will impact my functionality around that field? Thanks in advance -Ankita _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
Re: Upgrade suggestion
Thanks for replies, I got it what I was looking for :) On Fri, Jun 13, 2014 at 8:47 PM, Gadgil, Abhijeet abhijeet_gad...@bmc.com wrote: ** 1. If the purpose of the field is simply to be used as a buffer and store temporary values, we should add/reuse a display only field. In such cases, reuse is a better option, provided the field is not used for any other operation in the same transaction. In case if there is no free field, you can add a new one , since it adds no extra column to the database. But just make sure you create those fields in custom mode, so that there is no impact during upgrade. 2. If the field need to contain a record, then we should always create a new ‘custom’ field rather than using an old one. BMC can any time remove that field from the forms or change its value. *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Ars Lister *Sent:* 13 June 2014 21:48 *To:* arslist@ARSLIST.ORG *Subject:* Re: Upgrade suggestion ** Hi Ankita, If you can avoid using an OOTB field, that is best practice. Sometimes it doesn't make sense to build a new field when an OOTB field can handle the job. The biggest thing is to not modify existing workflow if you are in a pre-7.6.04 environment. If new workflow will conflict or is just a tweak to the qualifications, make a copy of it with some letters in the front indicating ownership and/or customization (eg. BMS-name of workflow object for Bristol Meyers Squibb if you worked there) and then disable the original workflow object (active link, filter, escalation, etc.). This way, any upgrades will pick up the original disabled object and if it needs to modify it, it will. You should always do a snapshot of your DB and a separate def of all non-OOTB forms, modified OOTB forms that have new fields or fields that have changed parameters (which I do not suggest as they may affect workflow to another form you are not aware of that carries the field or a join form you are not aware of), and of all non-OOTB workflow so you can import it into the new system post-upgrade. If you are working with a 7.6.04 version or later, then modify the object in the Best Practice view as an overlay and you will be fine with an upgrade. Upgrades won't mess with overlays. Hope that helps and good luck! On Friday, June 13, 2014 3:53 AM, Ankita Pankaj ankita.panka...@gmail.com wrote: ** Hi All, What is the best practice while doing development adding new fields in the form or analyze existing fields to utilize. Reason for asking this question: I am little confuse if I have utilized existing fields for my use and as the creator of the field is BMC, they can utilize it in future release. In further releases, If BMC has added new workflows around that field and I have also written some workflows , so during upgrade how it will impact my functionality around that field? Thanks in advance -Ankita _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
Re: Upgrade suggestion
Roger, We're doing the same thing now and we successfully tested the following scenario (from 7.0.1 to 7.5 P6): Build the new server(s) with version you want to go to (SQL 2008 and ARS 7.5). Back-up your existing server. Perform an upgrade-in-place of SQL Server 2003 to 2008 and apply updates, patches, etc. Perform an upgrade-in-place of ARS. You now have a system on your old server that matches the new server (same database and ARS version). Back up the database on the old server. Restore it to the new server. Tweak SQL Server permissions changed during the restore (verify Remedy account is dbo). Fire up all of the services. Craig Carter Information Technology Manager, RSP -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nall, Roger Sent: Wednesday, December 08, 2010 9:30 AM To: arslist@ARSLIST.ORG Subject: Upgrade suggestion ** ARS 7.1 patch4 SQL2k WIN2003 We are going to be upgrading to ARS 7.5 patch 7 and SQL 2008 at the same time. All hardware will be new. I am looking for suggestions on how to handle the change in ARS and SQL at the same time. Any help would be appreciated. Thanks, Roger Nall Manager, SA Business Intelligence/Remedy Desk Phone: 972-464-3712 Mobile: 973-652-6723 Helpful Links: | Reports http://bi.eng.t-mobile.com:8080/InfoViewApp |SA_Suggestion Box http://saintake.t-mobile.com/ | SA_Trouble Ticket http://natweb.eng.t-mobile.com/sites/TTWeb/CreateTicket.aspx | _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
Re: Upgrade suggestion
First of all - I'd recommend considering (if you haven't already) going directly to 7.6.03. We just did a lot of testing on 7.5 - and there is good stuff there too - but 7.6.03 is even better in many respects. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nall, Roger Sent: Wednesday, December 08, 2010 10:30 AM To: arslist@ARSLIST.ORG Subject: Upgrade suggestion ** ARS 7.1 patch4 SQL2k WIN2003 We are going to be upgrading to ARS 7.5 patch 7 and SQL 2008 at the same time. All hardware will be new. I am looking for suggestions on how to handle the change in ARS and SQL at the same time. Any help would be appreciated. Thanks, Roger Nall Manager, SA Business Intelligence/Remedy Desk Phone: 972-464-3712 Mobile: 973-652-6723 Helpful Links: | Reports http://bi.eng.t-mobile.com:8080/InfoViewApp |SA_Suggestion Box http://saintake.t-mobile.com/ | SA_Trouble Ticket http://natweb.eng.t-mobile.com/sites/TTWeb/CreateTicket.aspx | _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
Re: Upgrade suggestion
Hi, I have done this many times myself using the following procedure: 1. Install a clean new version of the AR Server on your new machine 2. Export/import def-files 3. Use rrrChive to move all data from your old machine to the new machine 4. Test the new machine 5. Do a SYNC-operation using rrrChive 6. Set your old server in admin-only-mode and turn off escalations 7. Do another SYNC with rrrChive 8. Swithch your users to the new machine (change a dns-entry?) The last two steps should take no more than 30 minutes or so if you plan well. This is the total time that your system needs to be offline from your users. It also gives you ample time to do thorough testing. Another benefit is that the time to revert back to the old machine if something goes wrong is zero. RRR|Chive download and configurator: https://www.rrr.se/cgi/rrrchive/main This config should should do the trick: source_server= production source_user = Demo source_password = target_server= newprod target_user = Demo target_password = target_disabledeletefltr = YES target_disablemergefltr = YES multipleforms= * splitsearch = YES transfertype = SYNCTOTARGET logfile = AUTO progressbar = YES Another good tool for finding data differences between the old and new System Forms are rrrDefFieldDiff: https://www.rrr.se/cgi/tools/main#rrrDefFieldDiff Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * 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. ARS 7.1 patch4 SQL2k WIN2003 We are going to be upgrading to ARS 7.5 patch 7 and SQL 2008 at the same time. All hardware will be new. I am looking for suggestions on how to handle the change in ARS and SQL at the same time. Any help would be appreciated. Thanks, Roger Nall Manager, SA Business Intelligence/Remedy Desk Phone: 972-464-3712 Mobile: 973-652-6723 Helpful Links: | Reportshttp://bi.eng.t-mobile.com:8080/InfoViewApp |SA_Suggestion Boxhttp://saintake.t-mobile.com/ | SA_Trouble Tickethttp://natweb.eng.t-mobile.com/sites/TTWeb/CreateTicket.aspx | ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
