Sure, I would love to read some of the documents you speak of for standardized best practices. At this point in the game all is beneficial.
-d David K Hill _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jason Miller Sent: Wednesday, December 26, 2007 5:40 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Change RFC Design Question I seem to remember a few articles that were written a few years back (ah how I miss the Tips and Tricks) that have some suggestions on customizing but not actual tech/white papers. I have included some links at the bottom that may help. I have also collected a couple of documents over the years regarding development standards that have guidelines to follow that will help your custom work stay custom and your OOTB work stay OOTB. I can send you a copy off line if you would like. By using these types of standards it makes it pretty easy to keep custom and OOTB separate. Generally speaking when you upgrade an ITSM app or even ARS the installer/scripts are looking for specific objects by name or ID (form name, workflow name, group id, etc). The installer/scripts will not recognize your custom work and will not directly touch it. Now that is not to say for instance that an OOTB field used in your workflow that "hooks" to ITSM will not change. Some ITSM patches have been known to delete a field and then recreate it as a different data type (I think I have only seen this on Display Only fields though so no data is lost). If this were the case your "hook" workflow may likely give you some kind of invalid data type error if you didn't manually fix your workflow (but this is what development environment and testing is for, right). Also there could be changes to fields that you may have used in the reserved range. Say if there is a change to the way field 112 works and you have that on your custom form for row level permissions, an upgrade could possibly change that field because it is in the reserved range. (Caution, occasionally OOTB ITSM fields do not stay in the reserved range). I would say a few of the most important rules to follow are: * Naming conventions. Custom built workflow should have some indication in the name that it is custom. I like the old prefix with + and * method I can easily get a list of all of my custom workflow by exporting a list from ARUtilities (however the ones with + tend to be troublesome in Excel until you add a ' in front of them) * Do not change the OOTB workflow other than to disable it. Make a copy to customize. A patch or upgrade may change/enable the original but will not overwrite your custom workflow. You would just have to disable the original after the patch/upgrade. Oh and you would want to see what was changed in the original, it may have fixed something. * Do not use the reserved field ID range except for where needed (ex. Field 112). It is very tempting to just copy the CTI fields from Help Desk because the menus all still work, etc but I would recommend building your fields and menus (you can copy the fields so the properties are the same just change field IDs before you save the first time). Typically an upgrade/patch change to say the CTI fields would look for the form HPD:HelpDesk and field 200000003, 200000004 and 200000005 but you never know when the day may come that the script just looks for these fields and does not care what form they are attached to because they are in the reserved range. Article from Doug Mueller regarding application upgrades: http://www.remedy.com/corporate/ron/volume02_issue01/english/article_03.htm The Tips and Tricks archive (maybe more good articles about upgrades and standards): http://www.remedy.com/customers/dev_community/Tipsarchive.htm Jason __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
