Updating the synch objects as they are being saved would be the preferred approach as it would always be up to date.
Another possibility I see is with ARS 7.1 and multiple escalation pools: A new $UpdateSynch$ command that runs from an escalation based on your schedule. A separate escalation pool would be used for this one process so it wouldn't interfere with other escalations. This could be scheduled to run once a day, once an hour, etc. Stephen -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA Sent: Wednesday, August 15, 2007 9:37 AM To: arslist@ARSLIST.ORG Subject: Re: AR System Developer Studio Wishlists Well, this might get hairy. I believe that whenever you save a form, that it saves each object on that form, which would then trigger the syncing of the search database for each of those objects, essentially syncing the entire form each time you saved it. Some how it needs to be transactional just like the saving of at ticket. This would also make the admin tool faster as well. Modifying a filter or active link would not have any extra impact. My biggest request would be for us to be able just to sync one form at a time, or multiple. Select a list of forms, or all forms with a given prefix just like whenever you go to View Forms list in the current admin tool you can choose all forms, selected forms (up to 10 I think), or forms by prefix. Thanks, Gary Opela, Jr Sr. Remedy Developer Leader Communications, Inc. 405 736 3211 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, August 15, 2007 7:24 AM To: arslist@ARSLIST.ORG Subject: Re: AR System Developer Studio Wishlists I think the performance impact would be negligible to keep the sync search database up to date real time. Think about it, you are updating or deleting maybe a dozen records each time you modify an object... It might add a bit of time to bulk updates. Axton Grams On 8/15/07, Rick Cook <[EMAIL PROTECTED]> wrote: > Nice list, Matt. I would add one more to the third one - how about a tab in > each workflow object that shows every container in which it resides? It > would be nice to see whether an Active Link I'm looking at runs in a Guide, > since there's no obvious marking (apart from clues like no firing condition) > on those presently. And even if I know or suspect that an AL is in a Guide, > it's a pain to figure out which one it's in. > > And on the Related Objects stuff - while I share your desire to keep it real > time, without some restructured storage mechanisms for that data, the > performance impact would make it not worth it. > > Rick > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Tuesday, August 14, 2007 8:06 PM > To: arslist@ARSLIST.ORG > Subject: Re: AR System Developer Studio Wishlists > > How about they fix the stuff they already have? > > * Provide detailed, explanations for why each and every RFE is either: > Accepted, Rejected or Deferred. > > * Keep the Search DB up to date without a Sync process. (one object at a > time when the object is changed.) > > * Ability to add an object to a Packing List via a context menu in the Admin > tool lists windows. (And also from the individual object > windows) > > * Use the "Related Workflow" idea on all "objects". (Like for menus, views) > > * Ability to search for (or better have pre-indexed) hard coded string > values used in workflow. ( Qualifications, actions, etc...) > > * Improve the ability of the Admin Tool to actually update "container" > windows when new objects are created, or when the Names are changed of any > of the items in the container. > > * Integration to a server side Objects Source control system. (SVN would be > great, but anything that is not platform specific and hopefully open > sourced.) > > * provide packing lists for each and every application they sell. So that it > is "easy" to get a list of everything that is OOB and to verify that "all > the right stuff" was installed. > > * Improve the overall performance. Switching from action 1 to action 2 of an > active link should not require the client to cache all fields on the form(s) > involved every time the selected action is changed. > > > However... if we are in dream mode.... > > * STOP using names as the unique identifier for an ARS object. An internal > GUID would go a long way to making the whole development process easier. ( > Change a name and move it to production and it should stomp on the old name > of the object. ) > > * All ARS workflow should be runtime enabled. There should be no quality or > setting that a workflow action can do that can not be data driven at > runtime. > > * The ability to script and "plugin" a new action would be fantastic. > (and a registry for these things on the server) > > * A local field registry so that instead of just adding a "Character field" > you could add the "Foo" field.(That would have predetermined details, Field > ID, sizes, permissions, helptext, etc..) And if the registry is updated... > then all fields based on those registry fields would be modified as well > too. Increase the size of the Foo field from > 25 to 254 and they change on all forms with that field. > > * A "debug" mode that would allow all workflow logging but not actually do > any data changes to the DB. > > * A "check point" model for all data on the server. So that test data could > be established, testing performed and the data set "rolled back" > to that check point before the testing was performed. > > * The ability for any field to be "NOT logged" (as masked *** values) in all > log files. ( A setting on the field that can be applied to all field ID's, > Client side and server side.) > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > ________________________________________________________________________ ____ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
