One other development tool we have just stared is to create a template
form. We have had a spreadsheet of common fields, IDs and ID ranges that
are used in shared workflow. We have started creating these common field on
the Template form. That way when we need a field we just copy it and link
that form to the shared workflow.
Here is what we use for our field ID ranges. It may be a bit on the Anal
side (I didn't believe in worrying about the field IDs until just a few
years ago). If I am looking at a field ID of 600017x I know that is a
field that contains data and is shared no matter if I am looking at it in
the db, a def file or in the Admin tool. A new feature of the Dev Studio
lets you sort by field ID in one of the properties panes so you can look at
your fields in groups by their ID.
*Range Type* *Starting* *Ending* *# of Fields* Data Fields (Saved)
600010001 600016999 6998 Shared Data Fields (Saved) 600017001
600018999 1998 Temp
Fields (Display Only) 600019001 600019699 698 Shared Temp Fields (Display
Only) 600019701 600019999 298 Trim/page/button/column 600020001 600026999
6998 Shared Buttons Trim/page/button/column 600027001
600029999
2998 Views 600100000 N/A
If I remember correctly there are some OOTB field IDs that enter these range
(I think on CMDB or maybe Asset).
I hope this info help some.
Jason
On Wed, Feb 18, 2009 at 12:51 PM, Jason Miller <jason.mil...@gmail.com>wrote:
> We have created our own change tracking form for the specific changes being
> made to Remedy. We tie all of the changes to a Change Request (using ITSM 6
> Change Tracking) which has the details regarding who requested the change,
> justification, etc. Here is a link to a screen print.
>
> http://screencast.com/t/xmwhb7E2T
>
> The Operation and Object Type have looks up behind them so you just need to
> type "cre" in the Operation and it will auto complete to CREATE and move the
> focus to the Object Type field. There you can type "fil" and it will auto
> complete FILTER and set the focus to Object Name. It does take little work
> to document all of the change but you get into a groove with ALT+TAB between
> the User tool and the Admin tool to cut and paste data. It is really
> helpful having the history of changes as between point A and point Z.
> If you query by Change ID and Migrated to PROD = "No", as things are move
> to production you set the flag to "Yes" and hit enter in the Migrated Date
> field to fill the $/TIMESTAMP$. They you just hit F5 to refresh your
> query for an updated list of what needed to be migrated is left. Also there
> is Crystal Report that goes with it so you can document all of the changes
> made for a release and use it as check list if you want to do it on paper
> instead of updating the records as you go.
>
> The next step that I been thinking about is to compare the documented
> changes for the day with the Server Events and schedule a report or take an
> action if something was modified and not documented. This may be a bit
> easier with the new version control features in ARS 7.5? Then again that
> may also obsolete some of what we are doing, I haven't really looked into it
> yet.
>
> Jason
> On Tue, Feb 17, 2009 at 9:42 PM, strauss <stra...@unt.edu> wrote:
>
>> **
>>
>> 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
>>
>> 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___
>>
>> __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"
