I am kind of a nut about this since 7.x came out. Fields: Custom numbering in a predictable range. Generally when customizing an existing form I start with something like 600100200 for the field ID's. Using this method you can easily run a simple SQL search on the form and field table to determine what your custom fields were: For field names I use BMC's naming convention which is pretty well documented. I do not remember if they only give this out to partners or not. If you can't find it let me know. For workflow and forms I use a special multi-tenancy way of naming. It's pretty straight forward. If I am customizing original workflow I disable the original and never modify it. Then I rename it with the Business Name:Operating Company Name or abbreviation: then original name. So an Active Link named HPD:DoSomeStuff for XYZ Corp's HR customer/tenant might get named XYZ:HR:HPD:DoSomeStuff. Cumbersome? Maybe. Useful? VERY - especially when you can narrow your view by prefix to find workflow specific to certain tenants. I do this now even if the system is not planned to be multi-tenancy because you never know.... When making new workflow it's similar - I take the form prefix (if one exists) or invent one if necessary for new forms. The result is the same as the above. When I create brand new forms from scratch I do not worry about numbering the fields. An entirely custom form should never need have it's fields differentiated from base product fields. The only area I really run into a hitch philosophically is modifying base product active link guides or filter guides. You can either 1.) Choose to disable, copy, rename, and modify the calling Active Link/filter, copy the entire guide, disable all the base product workflow, copy it, rename it, re-enable it, and customize the active link/filter in question, or 2.) Disable the active link/filter in question, leave it in the base product guide, add the new customized active link/filter, and document the heck out of it. I pragmatically chose #2 and stuck with it based on what mood I was in that day. William Rentfrow
Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com <blocked::mailto:wrentf...@stratacominc.com> 715-410-8056 C 715-592-5185 O ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of bruce sisk Sent: Tuesday, February 17, 2009 6:30 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy Development Best Practices ** A little used feature of the Remedy admin tool is the packing list feature. I work within the packing list or workspace. I add the existing workflow or forms to be modified to a packing list. After I have completed development, I export the contents of the packing list to a def file and use migrator to import just the differences. After that, I zip up the def files and the results from migrator. If required in your environment, you could check this zip into a source control solution. For new fields, especially if you are adding a new field to an OOTB form, you definately want to use a custom fieldid range. It can be anything you want...but you have to get in the habit of doing it. The reason this is valuable, you could then develop an sql query like the one below that could be used to search the fields table for fields in the range. I run this from ARUtilities... select f.fieldid, f.fieldname, a.name, CASE WHEN datatype= 2 THEN 'Integer' WHEN datatype= 3 THEN 'Real' WHEN datatype= 4 THEN 'Character' WHEN datatype= 5 THEN 'Diary' WHEN datatype= 6 THEN 'Selection' WHEN datatype= 7 THEN 'Date/Time' WHEN datatype=10 THEN 'Decimal' WHEN datatype=11 THEN 'Attachment' WHEN datatype=12 THEN 'Currency' WHEN datatype=13 THEN 'Date' WHEN datatype=14 THEN 'Time' WHEN datatype=31 THEN 'Trim' WHEN datatype=32 THEN 'Button' WHEN datatype=33 THEN 'Table' WHEN datatype=34 THEN 'Column' WHEN datatype=35 THEN 'Page Field' WHEN datatype=36 THEN 'Page Holder' WHEN datatype=37 THEN 'Attachment Pool' WHEN datatype=42 THEN 'View' ELSE 'UNKNOWN' END AS FIELDTYPE from field f, arschema a where f.schemaid = a.schemaid and ((f.fieldid like '85%' AND f.fieldid > 536870912) or (f.fieldid like '185%' AND f.fieldid > 999999 AND f.fieldid < 20000000)) order by f.fieldid desc Notice the 85% and 185% (global fields)...these are the field ranges I use. Bruce Sisk BFS Enterprises -----Original Message----- From: Ray Palla Sent: Feb 17, 2009 4:33 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy Development Best Practices ** Generally speaking Steve; The best method is to disable the OOB workflow and then do a Save As... Renaming to your custom nomenclature. Modify and enable the new workflow. You can then save a .def file of your new workflow to import (if needed) following a new patch or upgrade. Often following an upgrade your old OOB workflow will be re-enabled, so a .def of those is usually a good idea to keep track of them and allow you to compare any modification made by the update. As far as naming convention... Some people put the company name (ABC) at the front of the old name, but I find it's easier to find them alongside the original code if the company name is added to the end. For field IDs I let the system pick it unless I'm using the field in multiple forms and want continuity across them. Everyone has a different way of assigning their own IDs. I've seen some separate ranges for each specific field type, while others just go with a large group that is not in the Remedy reserved range. To each his own. I find that there is little gained by either approach and tracking them is time consuming. Have fun; R ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Steven Iocco Sent: Tuesday, February 17, 2009 3:10 PM To: arslist@ARSLIST.ORG Subject: Remedy Development Best Practices ** Hi folks. Just wondering what practices some developers are using for custom code and enhancing ootb workflow. IE, field ID's in a non reserved range, New workflow easily identified perhpaps by the company name etc. My real big dillemma is modifying existing workflow. Does anyone have some best practices for modifying existing workflow so that in the event of an upgrade pitfalls can be avoided or at least anticipated? Thanks Steve __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ________________________________________ PeoplePC Online A better way to Internet http://www.peoplepc.com __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
