You make a good point in highlighting the issue with the guides Also I would like to highlight that when workflow is shared, the complexity increases, and sometimes significantly...
-Guillaume -----Original Message----- From: Action Request System discussion list(ARSList) on behalf of strauss Sent: Wed 02/18/09 12:42 AM To: arslist@ARSLIST.ORG Subject: Re: Remedy Development Best Practices Great summaries of customization best practices! The only thing I would add is on the documentation; you need two different kinds of docs: 1. Functional descriptions of each feature added or modified, and all fields and/or forms added or modified, all OOTB workflow disabled and replaced with custom workflow, and all new, completely custom workflow or objects. Basically, everything you changed and why you changed it in a given functional module. Include details on any back-end integrations that are mostly custom code since they probably touch at least one OOTB form or module. Add to this document as you build new customizations. 2. Patch recovery lists by item type (form, field, active link, filter, etc.,) in the order that they must be restored after the last patch is applied. Includes OOTB workflow that must be inspected for BMC modifications in case you have to add those changes to your customized objects, that then must be re-disabled (yes, there are some in ITSM 7 patch 007 versus 006). Then list the customized objects that have to be checked, especially forms and views since you typically will not have renamed those from their OOTB version and most of the patches will overwrite them or at least replace some of their views; you will have to add your custom fields back to the updated views. Basically a checklist in the order you need to execute it to restore your customizations after any ITSM patch, especially some of the supplemental patches like 9002 that will even wipe out BMC integrations like RKM. If you customized any OOTB ARS components (password management filters, reports, e-mail integrations) you will need the same sort of checklist for these as well. Build these documents while cleaning up after a test patch on a copy of production; you will need them in order to minimize your down time when patching production (and to avoid missing something). The ITSM 7 patches are huge, and unless you are 100% OOTB you will need a plan to clean up after them. Remedy Migrator will pay for itself ten-fold when you have to do this. If all you have is production and development, patch development, then use migrator to restore the customizations on development from production, documenting it all as you go, then patch production and restore the customizations on production from development using migrator and the checklist. Good luck! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of William Rentfrow Sent: Tuesday, February 17, 2009 11:09 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy Development Best Practices ** 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___ __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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
