LJ, I agree that you can do this to an extent within Remedy (although I don't agree with plugins for most things because it takes code outside of Remedy just like using stored procedures.) When I was consulting, I remember one application using some stored procedures within the database, some Perl on the server called from filters, and I even had to build some VB 6 code in DLLs called via OLE within the Windows User Tool. Supporting that system would have required someone with decent SQL, Perl, VB 6, and AR System development skills. Even then, it would have been difficult to troubleshoot had something gone wrong.
Anyway I know you weren't arguing in favor of using plugins necessarily, and I do agree with you about the benefits of being able to edit Remedy objects via a text interface. I was just trying to point out that I think SharePoint is closer to that model than anything else out there right now. While there are downsides to SharePoint as Axton pointed out, I think it's a step in the right direction from a development standpoint. BMC seems to be going further away from AR System as a development platform, so I don't see them really putting much more effort into expanding AR System functionality except when forced to. I suspect that the only reason for the Overlay functionality, for example, was because BMC wanted to move more people to Remedy On Demand, and the Overlays meet the requirement of 1) having standard OOtB applications that BMC controls and upgrades all at once, at and 2) at the same time allowing the flexibility to modify the applications to meet your business needs. I really don't think that AR System as a development platform is their focus at all except as a way to modify and extend the OOtB suite. Thanks, Shawn Pierson -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, January 12, 2012 9:56 AM To: arslist@ARSLIST.ORG Subject: Re: Script Generation Remedy has this ability too....called plugins. You can build filter plugins in Perl, Java, C....I'm sure a few others that I'm not familiar with. With the API model, you can build entirely custom clients that do wondrous things. All if this is wonderful and great and all....but I think what John was talking about was not the ability to extend Remedy...but the ability to turn what is currently records in a DB into some form of industry recognized script/code. How many times have you had to answer the question of 'how many lines of code would it take to implement this feature' with a 'it's not like that' type of answer. I would love to be able to have the ability to create a filter (just like I do today) and then be able to export that to 'code'....not a def, not an xml def...but actual code that could be read somewhere. Granted, that code wouldn't be able to be executed by anything other than the Remedy server engine....but it would at least be code that could be read by Remedy and generated by Remedy...but also coded OUTSIDE of Remedy if you wanted to, but still read by Remedy. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Thursday, January 12, 2012 8:38 AM To: arslist@ARSLIST.ORG Subject: Re: Script Generation LJ, Having worked some with SharePoint, I've seen how it could be advantageous to build an ITSM suite completely on that platform rather than using AR System. There are even tools that can be used within Visio to make workflow. Granted, to do the really complex stuff you need to be a .NET developer, but I've seen the direction Microsoft has been trying to push into and it's what AR System used to be geared for -- letting non-programmers quickly build enterprise applications. The only downside I see is that if you give enough people permissions to build things, I.T. will end up with the problem that Access caused where non-I.T. people made unwieldy databases with impractical forms that they then tell us to support. At least SharePoint has a permissions model. In any case, I think that it does great by allowing the full gamut of allowing end users to create simple forms and workflow, while highly skilled .NET developers can create highly complex, feature rich applications. Unfortunately, Sharepoint itself is not cross-platform so it wouldn't work for BMC, but I'm really surprised that Microsoft hasn't released more applications that sit on top of Sharepoint at this time. The only OOtB Sharepoint based application I've used has been Project Web Access, but even that requires you to build some of your own stuff and use Microsoft Project in order to interact with the schedule. Still, I've seen some good third party stuff, and I think Sharepoint is probably a great tool to learn as a side project for anyone that prefers to focus on the development aspect of Remedy rather than ITSM administration. This may sound like I'm a big fan of Microsoft, which I'm not, but I am impressed that they turned what started out as essentially web-based blog software into a diverse platform for web sites and applications. I just wish something similar that was cross platform and extremely popular existed. Thanks, Shawn Pierson -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, January 12, 2012 9:19 AM To: arslist@ARSLIST.ORG Subject: Script Generation John, I'm changing the topic as to not hijack the original thread. You bring up an interesting thought. I was involved with a discussion with MicroFocus (parent company of Borland, maker of SilkTest) regarding their test generation application...it's a simple point/click interface, but you can, if you choose, export the test script to any number of 'known' languages including .net and java. Once in the script form you can modify, edit, do anything you really want...but when it comes back to executing the script, you run it through their 'agent'. The SilkTest 'server' is really just a license management process to ensure you are not using more licenses than you have purchased....so...this takes us to the concept you just discussed The power of Remedy is it's point and click interface to do things...one of the strongest up and downsides (at the same time) is the central development environment. While this central dev environment (the remedy server) allows for a lack of 'merge' problems....the fact that the code is stored only in the DB, and isn't easily manipulated outside of the GUI makes it sometimes hard to do things like merge.... So I agree....if BMC modified Remedy to function so that everything is still point and click easy to create the code, but allowed the option of exporting the code to a standardized format like Java, then allowed modification of that code at that level....and of course would need to be imported back in to validate the changes were good.... Yea...I could totally see using Remedy like that. :) -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Baker Sent: Wednesday, January 11, 2012 4:02 PM To: arslist@ARSLIST.ORG Subject: Overlay and Applications Hello, I do wonder when the time will come when base/overlay/etc are replaced with the simple concept of a script. Converting existing workflow to a script is easy and much of the work has already been done, ie converting client side workflow to Javascript already exists in the Mid Tier. Writing a server side workflow (filters/escalations/etc) to Javascript is entirely feasible. Once we find ourselves using Javascript, everything will run (far) more quickly, AR System (with ITSM) would not require 1Gb of memory and 30 minutes to start, and a simple source control system can be used to merge the BMC base application with a client's changes. I've not met an AR System admin who can't fiddle with some script, so perhaps AR System 8 should be the day BMC bite the bullet, eject the current model and move to simple text based scripts: function my_active_link(): if field(123) = "abc": # Push value of field 456 on this form to another push_fields(456, "Target form", 987) set_fields(123, "X") else: change_label(9000, 'New value of my label') set_read_only(9000, True) Alright, so I prefer Python to Javascript but I suspect most ARSlisters can follow the above. 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" Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. ____________________________________________________________________________ ___ 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" Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
