Actually ... Active Links, Filters, And Escalations also already have ID(s) as well.
This goes back to the RFE I put in back when it was Migrator 3 to keep the ID the same across servers (and the fact that Migrator was doing it's work in Alpha order so sometimes workflow would fire in different orders between Dev, Test, and Production if you didn't watch your order numbers) Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David Sent: Wednesday, August 15, 2007 9:46 AM To: [email protected] Subject: Re: AR System Developer Studio Wishlists I could not agree more. I have always found it odd that I needed to delete Active Links, Filters, and Guides to make sure that I didn't have duplicate workflow if I renamed even one of them. Forms have a schemaid. Renaming a form automatically adjusts all the workflow associated with that form on the same server. Your idea takes that same concept farther and allows the transfer from server to server through the definition file. As you state, being able to execute a comparison of objects associated with form X on in development vs qa vs production would be so much easier. Dave -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Wednesday, August 15, 2007 10:22 AM To: [email protected] Subject: Re: AR System Developer Studio Wishlists David has the idea... but I will add a bit more to it since there appears to be some interest in the idea.... When an object is first created it would get its own GGUID (Guaranteed Global Unique ID) from the ARS server at that time and it would be "unchangeable" while the object exists on the ARS server. (Sure maybe you could do some funny stuff with a def/xml object file, but who would want to? Anyway..) And just to be clear.. .the GGUID should be part of the object and it would be retained if the object is moved from ARS server 1 to ARS Server 2 during an object Import process. So the value is only generated during _create_ time for the object. So a "Save As..." would produce a new object with a new GGUID. But a "Save" would not change the GGUID. If every object has a GGUID then it would be simple for application install verification to be automated to. ( Because it would become a list of GGUID's and a process to verify that all of them exist on the ARS server.) You could reaname the OOB object to "Didnot use-Foo" and the application verification stuff would still work. (Extra, or changed parts are ok. Missing parts are likely indications of problems.) And if you add one more layer to that... where the packing list/applications keep track of the "verification list" during object create/deletes then the OOB's would have a standard list and any customized OOB would have its own list. The lists could be compared and all missing OOB objects could be identified, and all new objects could be identified. Yes this stops short of a full Version control system, but it really should. All I want is identification of objects and not version control. However once identification is established then version control becomes much easier to tackle too. If every object has a GGUID then Source control systems would be able to deal with prod/dev/test systems in a sane way. And you could do things like diff objects that were renamed on dev/test/prod because the GGUID would tie them together. And I am sure there are other gains that can be made once you know that your looking at an object that was _created_ from server X. The GGUID's could be used like "Request ID" are used for data. They could be the pointers in the objects that point at each other. (Containers would not need names, they could use shorter, better indexes, less memory intensive values.) And just a bit of an idea about how the GGUID could be generated... How about a combination for the Support Contract ID and the Server key where the object was created. It could be encoded/encrypted so that it looks like garbage to us, but could actually tell BMC quite a bit about the source of the object if push came to shove. :) Heck it could even include the date/time that the object was created. ( It has always struck me as odd that objects do not have a Create date, but data records do.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 8/15/07, Shellman, David <[EMAIL PROTECTED]> wrote: > Hugo, > > I don't think Carey is asking for the ability to have duplicate names. > > Change the name of an Active Link or Filter on development requires that > you delete the original on production or you wind up with duplicates when > you move to production with def file. > > Using unique GUID would automatically rename the Active Link or Filter and > not cause it to be duplicated. > > Dave > -------------------------- > [EMAIL PROTECTED] (Wireless) > > ----- Original Message ----- > From: Action Request System discussion list(ARSList) <[email protected]> > To: [email protected] <[email protected]> > Sent: Wed Aug 15 05:08:38 2007 > Subject: Re: AR System Developer Studio Wishlists > > ** Hi Carey, > > Quite, a list but I'll just pick one :) > > > On 8/15/07, Carey Matthew Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > wrote: > > * 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. ) > > I'm not sure if I understand that. Would you like to have duplicate Active > Links for example which differ in functionality and GUID? To me that would > be development hell! > > Hugo ________________________________________________________________________ _______ 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"
