Guillaume, I will agree that ever since 'Remedy' sold out the first time to make it owned by someone else, the drive for 'Remedy as a platform' has diminished if not entirely died. I have built my career around Remedy and don't want to see the platform die as a platform...but that's truly not up to me.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Guillaume Rheault Sent: Thursday, January 12, 2012 4:48 PM To: [email protected] Subject: Re: Script Generation Shawn , I need to chive in because I think everybody that has replied to the threads is missing the point, except you. You got it. When you state that BMC seems to be going away from AR System as a development platform, I think you are almost right: I do not think that BMC has ever really intended for AR System to be a development environment where third parties can build their applications on ARS and sell them. Case in point: you may remember the deployable applications in version ARS 6.0 (if my memory serves me well) had the ability for a license key to be entered. Therefore, the application would run, but without the license key the end user (the customer) could not view or update the objects in the application with the admin tool. Well all that stuff was done away with and scrapped in ARS 7.0 (if my memory serves me right). That feature was marketed by then by BMC as a step in the direction for allowing third parties to build their applications, and possibly sell them in what was referred to as the BMC MarketPlace (if I remeber well). Well that whole thing fell apart. Since then, I have not heard anything to suggest that BMC is even considering that again. Therefore all these wishes about better version control, scripting and such, are really not that important if BMC does not really make the ARS a development platform that would be used for applications other than ITSM, or for custom modules developed at customer sites that complement the ITSM suite. Sure it would make the life of the Remedy administrator/developer easier, and BMC is taking steps into that direction. But that is not enough. There is the issue of licensing. If I was going to develop applications from scratch and sell them to the public, I would not consider doing that with AR System at all. 8 years ago when the license-able deployable application was conceived in ARS 6.0, I really considered that, but the issue then was always that customers need to still pay an ARS server license key and ARS user licenses, in addition to whatever they would pay for your app. So I was waiting for BMC to see what was the next step. And the next step was to kill that feature and the market place concept. It seems to me ARS and ITSM/RKM/SRM/CMDB/ITBM need to be considered as a whole nowadays, because whatever new features need to be developed in those apps/suites, that will force new features to be developed in ARS. But I don't think new ARS features will be conceived for their own good/merit. You correctly point this out in your reply. So that's why in my previous replies, I believe that it is not accurate anymore to compare ARS by itself, with other programming languages or development frameworks. I would say it is more accurate to compare the ARS ITSM suite (with all the modules SRM, RKM, SLM, etc) with the equivalent suites from the competition, mostly HP, CA, IBM and service-now. -Guillaume ________________________________________ From: Action Request System discussion list(ARSList) [[email protected]] on behalf of Pierson, Shawn [[email protected]] Sent: Thursday, January 12, 2012 1:49 PM To: [email protected] Subject: Re: Script Generation 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:[email protected]] On Behalf Of LJ LongWing Sent: Thursday, January 12, 2012 9:56 AM To: [email protected] 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:[email protected]] On Behalf Of Pierson, Shawn Sent: Thursday, January 12, 2012 8:38 AM To: [email protected] 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:[email protected]] On Behalf Of LJ LongWing Sent: Thursday, January 12, 2012 9:19 AM To: [email protected] 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:[email protected]] On Behalf Of John Baker Sent: Wednesday, January 11, 2012 4:02 PM To: [email protected] 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" ____________________________________________________________________________ ___ 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"
