Thanks David, Rick and Misi... you have given me the clear direction that I was seeking. Larry
On Feb 1, 2011, at 5:04 PM, Rick Cook wrote: > ** David is, as usual, spot on. Overlays are not put there for us to have > any sense of invincibility or impunity when altering OOB forms or workflow > that we under other circumstances would (or should) know better than to > alter. It is a means to protect additions that may conflict with FUTURE OOB > functionality. That it also gives one the ability to protect against having > customizations to PRESENT forms and workflow is an incidental increase in > power that we should work hard to wield carefully. > > It is, in a nutshell, like developing in Remedy (or C, for that matter). The > best thing about it is that you can do anything you want. The worst thing is > that you can do anything you want. > > Rick > > On Tue, Feb 1, 2011 at 3:48 PM, Easter, David <david_eas...@bmc.com> wrote: > ** > Overlays is the most important feature that you should never use. J > > > Rick is correct. Overlays enforces best practices, but you should still > consider the broader implications of modifying something vs. extending. > Simply put, the basic best practice rules should be: > > > 1. Don’t modify or extend anything. Use the product OOTB. > > 2. If you can’t use the product OOTB, *add* to the existing structure, > don’t modify it. Extend it by adding fields, forms, workflow, etc. that do > not directly impact existing functionality > > 3. If and only if your situation cannot be solved either OOTB or > through extending the product should you consider modifying existing objects. > > > If you find yourself with #3, that’s where overlays really helps. Overlays > will create a copy of the object for you, identify it as a modified object > (i.e. an overlay) and ensure that the origin object remains just as BMC > shipped it to you. During run time, your overlaid object is the one that the > server uses. In fact, the server does a little bit of magic behind the > scenes to ensure that any calling API or workflow that uses the original name > (i.e. the BMC object name) is redirected to your overlaid object. That way > you don’t have to change guides, API programs or other calling > applications/workflow. > > > -David J. Easter > > Manager of Product Management, Remedy Platform > > BMC Software, Inc. > > > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as a > spokesperson, liaison or public relations representative for BMC Software, > Inc. > On Feb 2, 2011, at 2:46 AM, Misi Mladoniczky wrote: > Hi, > > The main problem with adding fields to the User- or Group-form is that the > data need to be entered, and sometimes modified. > > 1. Each time a User record is modified, that user will have all > definitions recached (arf/arv files on the Windows client) > > 2. Each tim a Group record is modified, ALL users will get the definitions > recached. It will also trigger a server-side recache of the definitions. > > If you look at your API-logs and find a lot of ARExport()-calls, you > should suspect that you have this kind of problem in your setup. > > I recommend that you go for the join-form solution. > > Best Regards - Misi, RRR AB, http://www.rrr.se > > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook > Sent: Tuesday, February 01, 2011 01:31 PM > To: arslist@ARSLIST.ORG > Subject: Re: Preserving customizations with overlays and custom objects > > > ** LG, from what I know of the overlay functionality, you are correct in your > assessment of its impact on customizations in an upgrade situation. It is > designed to allow you to choose which customizations to protect during the > upgrade. As to the User form, while you COULD alter it, I still don't think > it would be a good practice to do so if you are using the ITSM suite. If you > have all custom apps, that might be a different story, but probably not, > because of the caching issue you referenced. > > Rick > > On Tue, Feb 1, 2011 at 3:08 PM, L G Robinson <n...@ncsu.edu> wrote: > > Hi Folks, > > Back in the days of ARS 4.mumble, I developed a help desk application for my > organization. At that stage of my development experience, I did not > understand the issues surrounding modifying Remedy objects such as the User > and Group forms. In my ignorance, I added fields, changed permissions and > moved stuff around on the User and Group forms. I got lucky when we > transitioned to ARS 5.1.2 and I simply imported all of my stuff to the new > server. It worked! > > Now I am more experienced and I understand the reasons why you don't modify > the User and Group forms. As part of my plan to transition to 7.6, I had > planned to create a form of my own to hold my additional fields and I would > present them to my users through a join between my form and the User form. > [You may remember that I ran into a slight problem with having too many > "special" fields from the User form on my join form.] I figured this would be > the best way to proceed since I was making very minimal changes to the User > form. > > Now, as I read the "What's New in ARS 7.6.04" I see a description of the > "Preserving customizations with overlays and custom objects". On the face of > it, this sounds like it is designed to allow one to make changes to a > BMC-supplied form such as the User form and still be relatively immune to > collisions and upgrade problems. > > So I have two questions: > > - Am I understanding this new feature correctly and is it now an "ok > practice" to modify the User form if I use the Overlay feature? > > - Is this the "best practice" method for accomplishing what I am trying to do? > > As a side discussion, are there performance issues with one method over the > other? I recall in the back of my mind that updates to fields in the User > form cause the User Cache table to be updated. Is that true and is it a > performance issue? I presume it would still be true when using the Overlay > method and not an issue when using the join method. > > I have already made a small time investment in implementing the join-form > method but I am willing to scrap it in favor of the Overlay method if that is > the way to go. I still want to do something similar with the Group form so > now would be a good time for me to decide which way I should proceed. > > I appreciate any guidance you might have on these questions. > > Thanks. > Larry > > Larry Robinson n...@ncsu.edu > Office of Information Technology > NC State University 919-515-5432 Voice > Raleigh, NC 27695-7109 919-513-0877 FAX > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
