Thats exactly why I prefer functional names over names that describe what exactly the AL does unless that AL is specifically doing that without being a part of a bigger function.
By functional names I mean if there is a set of AL's or Filters that run either as a guide or otherwise, that perform a specific function such as SetCustomerInfo or RetreiveUserData or whatever with a postfix of 01, 02, 03 to signify the number of AL's within that.. I have had time when I had to insert AL's or Filters in patches of the apps I build which I do by putting additional postfixes.. such as 01a, 01b. At some places I did have the luxury of renaming the AL or Filter to make way for new AL's or Filters. The biggest advantage of doing this is easily finding the piece of code you are after if you are trouble shooting a particular function that may be causing a problem.. Joe ________________________________ From: David Sanders <[email protected]> To: [email protected] Sent: Tuesday, March 24, 2009 1:39:12 PM Subject: Re: ITSM naming convention sucks Hi Doug In my opinion there are problems with trying to do too much with naming conventions for workflow. One of the principal problems is in applying enhancements to an existing application - if you add actions to an active link, do you change the name? If so, your delta definitions file needs to contain a disabled version of the object being replaced, and the new object with the new name too. I try to avoid this unless the active link actions are radically altered so that the existing name would be misleading. What do you do when an active link has 25 actions?? I see no point in trying to include firing conditions in the object name (window open, menu choice etc.) as these can be seen in the object list in the admin tool. In ESS active links tend to be named with abbreviations for <APP>:<FORM/SHR>-<btn>TextDescription<nn> where <nn> is a sequence number for related workflow if appropriate. They might also contain a suffix Nm/Dlg to indicate if that workflow is designed to run specifically for normal windows, or modal dialog windows. For filters, the only difference is to include the filter execution order like <APP>:<FORM/SHR>-620TextDescription<nn> where 620 is the execution order. This lists most filters in the order they will fire. In other words, we try to keep the naming convention as simple as possible while still giving useful information, but retaining existing object names where possible to make applying enhancements easier. As far as support is concerned, you break it and we'll help you fix it. Period. We normally set up copies of client's servers including any customizations so that we can easily troubleshoot issues with them. And support costs you no more for 2000 users than it does for 20 users - fixed price. David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== tel +44 1494 468980 mobile +44 7710 377761 email [email protected] web http://www.westoverconsulting.co.uk -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Tanner, Doug Sent: Tuesday, March 24, 2009 3:58 PM To: [email protected] Subject: Re: ITSM naming convention sucks Another reason to write/construct you own solution and follow best practices in naming conventions/documentation/etc. Been doing Remedy for 13+ years, logical naming of objects is important - Custom or OTB. Oh the days of Remedy - Your Business, Your Way! Doug Tanner Gidd how about you, how does ESS standardize naming conventions? -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Lyle Taylor Sent: Tuesday, March 24, 2009 11:50 AM To: [email protected] Subject: Re: ITSM naming convention sucks I don't think so. They will support the applications out of the box. They won't support customizations. If you break something with your customizations, they are not obligated to help you figure out how you broke it. They might, but they might not. They are also not necessarily obligated to help you understand their workflow, unless it relates to a documented integration point. Many of the whitepapers they provide are nice, but not strictly necessary. Understand that I would love it if BMC documented their systems better. I just don't think that the statement that it is necessary that they document their naming conventions, or the implied statement that they should document other implementation details, is correct. It would be great if they did, but they are under no obligation to do so. Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of David.M Clark Sent: Tuesday, March 24, 2009 9:36 AM To: [email protected] Subject: Re: ITSM naming convention sucks I think that paying for support says otherwise... except for that "easy" part. David M Clark Remedy Programmer/Analyst >>> Lyle Taylor <[email protected]> 3/24/2009 10:06 AM >>> Strictly speaking, ITSM is BMC's product, and they are under no obligation to provide us with any of the nitty-gritty details about how their application was written including any naming conventions used internally, etc. The fact that BMC allows you to customize the product doesn't mean they need to support you in that effort or to make it easy for you. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Coleman, Gavin Sent: Tuesday, March 24, 2009 3:56 AM To: [email protected] Subject: Re: ITSM naming convention sucks ** "In my opinion, ITSP followed some best naming conventions." Well considering that as far as know the naming convention is not explained anywhere in the ITSP or ITSM documentation, I can't see how you can believe that. Remedy allows you up to 80 characters to name workflow items, and it seems that ITSP and ITSM does not use all of these characters. My Active Link workflow has a naming convention as follows 1. Prefix for custom work (CC_) 2. Form abbreviation (NIM:) - New Incident Console 3. Execute on abbreviation (MRC - Menu Row Choice, Btn - Button, WL - Window Loaded). If more than one Execute on is specified, then the abbreviation I use is the most relevant 4. Name of Button, Table, Field etc (E.g. Btn_OpenIncidentTask) 5. Execution Order (-000-) 6. Details of Actions (OpenHelpDesk) Thus, we get CC_NIM:Btn_OpenIncidentTask-000-OpenHelpDesk If an AL or Filter is part of a Guide, then the suffix _GUIDE is applied. If the AL or Filter calls a Guide, then the suffix _CallGuide is applied. I'm sure other people have naming conventions, but if you are providing a product that is to be released to the general public, then surely publishing the naming convention in your documentation is ESSENTIAL. Just my £0.02 worth! Gavin Coleman Senior Analyst/Programmer Computacenter (UK) Ltd Services & Solutions Hatfield Avenue Hatfield, Hertfordshire, AL10 9TW, United Kingdom T: +44 (0) 1707 631662 E: [email protected] W: www.computacenter.com _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
