Richard, The point of API interfaces is actually reduced flexibility....not really the point, but a byproduct. That reduced flexibility is actually a 'good' thing though. Remedy, in the way that it works now has absolutely no enforced structure. That lack of enforced structure allows you to literally 'do what you want'...which is extremely flexible, but extremely hard to support and optimize. When you setup API interfaces to a system, you harden them and make them less flexible, but because of the defined contract between the publisher and consumer you have extremely reliable results. Because of this reliability you can guarantee results and ideally scalability, and because of this contract you increase interoperability.
Additionally, when you add to this contract, versions of the API...it in theory allows you to upgrade from ITSM 10 to 11, but you aren't required to upgrade your integrated app, because your integrated app can continue to communicate with your ITSM Suite on the 10 version of the API and will continue to function EXACTLY the same as it did when you were actually running that version. That's the theory at least :D -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent: Wednesday, November 02, 2011 9:46 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments Good to hear David! Here is a suggestion off the top of my head. Perhaps to help with one of Axton's (and my) beefs, the concept of versioned interfaces, you could add a reserved field for forms used as "interfaces" to implement versioning. Then add checking of this field into the workflow objects such that, workflow only fires if the versions match, or something to that effect. Perhaps a combination of fields, one to hold the version number and another to indicate if it is specific to the version or applicable to lower versions as well or the lowest version number supported, etc? That would allow you to share workflow between interface versions where appropriate, and even perhaps have workflow with the same name, but different version and also to have workflow specific to a particular version, thereby implementing something with similar results to Inheritance. I'm not sure that additional API calls would need to be defined as that could result in reduced flexibility, however the interfaces would need to be tightly documented. Cheers! Subject: Re: Request for Comments From: "Easter, David" <david_eas...@bmc.com> Date: Wed, 2 Nov 2011 10:00:02 -0500 ** Just a quick comment - later versions of ITSM applications do have interface forms that are expected to be used to interact with the applications. These are used mainly by web service queries, but would be appropriate for any external communication into the application. Those forms are the recommended interaction point for external applications and insulate such programs from the version-to-version changes in the underlying forms. Please do continue the discussion - the ideas being expressed can certainly enhance and improve upon the architecture - but wanted to make sure folks know that the apps are already headed in this direction. -David J. Easter Manager of Product Management, Remedy Platform BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. ____________________________________________________________________________ ___ 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"
