John, On your reply: a) That is still a challenge with scripts scattered across different servers - even with source control b) You would not be able to customise the output into the format you need for a specific purpose. The "show references" functionality is not as flexible or extensible as a sql statement. c) If you read my sentence on scripts for this point again, you'll see I referred to flexibility - not if it can or can not be done. My point here was that (even though scripts themeselves are much more flexible as you rightly pointed out than filters or active links) the electronic generation of documentation about scripts is a bit rigid and not as flexible or extensible as a sql statement. d) Ever migrated (or re-deployed a copy of) an application based on scripts spanning across multiple servers (code and data all at once)? it's a lot easier, quicker and more reliable to backup and restore a single database. If BMC does consider your suggestion to rather compile scripts, I would suggest that they are indeed stored in a DB to make migration much less of a pain. We will lose the performance benefit if AR server checks out code live-on-the-go from another system. e) It is "a bit bizarre" to suggest that "There's no useful purpose for permissioning code between different users" - it cuts out finger-pointing and politics between developers and in certain environments like certain governmental orgs, you have to use permissions to comply to job segregation and security policies. f) Although source control systems goes a long way to centralize access to code, it does not guarantee unauthorised code changes with scripts scattered across different filesystems.
I agree that an ITSM 7.6.4 implementation has become a bit heavy for a desktop to handle (esp. on RAM), but all serious enterprise-class systems have sadly gone that way over the years...but BMC can "remedy" this to an extent (please excuse the pun) by optimising the code for the OOTB modules. One idea that your suggestion have sparked in my mind is that it would possibly be nice to have a tool that can look at Remedy code and generate a Java app/code from that. This will allow ARS to be used as a rapid prototype modelling tool for Java projects...? If, coming from a Java programming background for instance, you still prefer using scripts, that's ok, Remedy has the ability (albeit limited) for you to do that in certain instances, like using the filter scripting library (See https://communities.bmc.com/communities/docs/DOC-63) (as I've used in the past myself), web-services or even run-process actions executing your local scripts, but I would still argue that the way ARS handles it's own "code" has it's benefits and it's place under the sun and that we need not change ARS in this regard. Best Regards, Theo -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Baker Sent: 13 January 2012 13:53 To: arslist@ARSLIST.ORG Subject: Overlay and Applications Theo, > Lastly, To answer your question "can anyone think of a disadvantage with > taking workflow from the schema and into scripts?: (a) Or you can use one of a million tools, such as grep. (b) Yes, they do. Any good plugin to Eclipse or whatever will have a "show references". (c) Yes, they do. It is a bit bizarre to suggest you can't document scripts, when they are infinitely more flexible. > Furthermore. (d) If that is a serious concern, they can be stored in a database. However, it's really not hard to copy a package (a single zip file) between different AR System instances when you deploy an application. Or tell AR System to check it out of svn/git/etc. (e) There's no useful purpose for permissioning code between different users. If you want to allow user input, that's what the database is for - to hold user/application specific information. Comment about viruses is bizarre; this is how the rest of the world operators, so I don't see why it's a concern to ARS. (f) I refer you to a source control system. I'm afraid I can only bring you back to my original point: Storing workflow code as scripts makes far more sense, brings AR System into a new world where it can make use of the countless source control systems and tools available to everyone else, and can be achieved without changing the UI. Since I started this discussion, I've thought of another superb advantage. Once the workflow isn't stuffed into the scheam, AR System will be far more efficient. A standalone AR System instance should be able to run on a desktop machine, connect to a database, and read local workflow scripts. One can finally develop a solution without having to negotiate for control of workflow with others in the team. This single change would vastly reduce costs for BMC when developing ITSM, assuming there is more than one person working on the product. John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
