Maybe not as elegant as a filter plugin but we use a Run Process to call a script (.vbs, bat, whatever) when we need to make functions (phone number format/validation is one).
Jason On Thu, Jan 12, 2012 at 1:24 PM, LJ LongWing <[email protected]> wrote: > ** > > On the ‘function’ note…it’s actually relatively easy to program that…with > a filter plugin…yes it steps out of Remedy, but Remedy supports it J**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Jose Huerta > *Sent:* Thursday, January 12, 2012 1:55 PM > > *To:* [email protected] > *Subject:* Re: Script Generation**** > > ** ** > > ** Remedy has one great advantage, it is very easy to create new easy > applications. It is as easy as creating them in MS Access. Also if you > follow a few rules, you don't need to care about concurrency, security, and > a lot of best practice that a Java or .Net developer must consider.**** > > ** ** > > As I published in my post: > http://theremedyforit.com/2012/01/three-layers-programming-technique-for-bmc-remedy-ars/ > , > Remedy forces you to follow best practices for programming.**** > > ** ** > > Have you tried to develop and application to be placed in a server farm to > provide service to hundreds of clients in Java? Even when using corporate > editions (like J2EE), it is a very confusing thing. concurrency, > transaction control, permissions, ... are a lot of things that the > programmer must consider when writing the code.**** > > ** ** > > When you write a PUSH action Remedy does a lot of things, not only > accessing the table and writing the result. So it can't be translated to a > single line of code. Execution filter phases control for instance is > performed at every step.**** > > ** ** > > As I stated before, if you change the remedy workflow model, then you > won't obtain Remedy, it will be another different thing.**** > > ** ** > > But I think that there are some places where scripting language (in the > style of VBA) can be usefull and don't compromise the robustness of the > model. For instance create functions that can be used in SET actions. In > Spain we have a personal ID number that contains a control letter. There > are functions that can check if an ID number is correct or has some error, > using this control letter. Programming this function in Remedy is almost > impossible. Programming it in VBA or javascript is very easy (and you have > a lot of code available on Internet). **** > > ** ** > > This script for functions could simplify a lot of complex Remedy workflows. > **** > > ** ** > > Regards,**** > > ** ** > > Jose M. Huerta**** > > http://theremedyforit.com/ **** > > **** > > ** ** > > ** ** > > On Thu, Jan 12, 2012 at 19:49, Pierson, Shawn <[email protected]> > wrote:**** > > 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"**** > > ** ** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > _attend WWRUG12 www.wwrug.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"
