Axton, My Web Services experience is only current through v6.3. ( Which is now EOL'ed. :( ) So maybe some of these ideas have been addressed partially or totally in 7.5, but I doubt it.
First I will divide this question it to two questions: Q1) What do you think about how ARSystem publishes WebServices? A1) Overall Grade: B. Major Areas that need improvement; * Error handling --> Log to ARS form --> To ARS Group (for real time notifications) * support for missing complex XML structures Improvement ideas: * Allow for one or more XSLT transformations before/after the WebService * Never allow for a break in functionality like what happened at v7.0.1. GRRRR. Which broke ARS connectivity from Mid-Tiers newer than "x" and ARS servers that were older than "x"(the same version). Q2) What do you think about how ARSystem consumes WebServices? A2) Overall Grade: C. Major Areas that need improvement; * "Advanced" mode for Set field from a Web Service - Support data driven Method, InputMap, and/or OutputMap values - Provide a way for an "Alias" to be used to "MAP" a WebService "URL" from ar.conf . ( To allow prod and dev to be coded [filter objects identical] the same but the ARServer points at different target URLs at runtime.) * Better fail/retry options. Maybe retry N times then throw the ARERROR. Maybe support "On fail call WebService 'other' instead" of ARERROR Maybe support "On fail call FilterGuide 'fGuide' instead of ARERROR * Allow for each consuming action to control the timeout for that external call. Instead of only having one global setting on the AR Server level let the action define a more restrictive value for that action. * Allow for one or more XSLT transformations before/after the WebService * Support the full XML standard without restrictions for some XML structures. Even if ARS can not publish all XML structures it should be able to consume them all. :) I am sure there are other ideas that have slipped into the void over the time I have used ARS WebService interfaces... but that is what comes to mind right now. Hope that helps. In general, I look forward to the day that all attributes of ARS workflow(AKA: every setting of every action) can be data driven. That will be a very big step forward for the platform. -- Carey Matthew Black BMC Remedy AR System Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Fri, May 8, 2009 at 10:26 AM, Axton <axton.gr...@gmail.com> wrote: > ** I wanted to get a feel from the group on some of the headaches and > limitations of the Remedy web services implementation. I've avoided the > interface, much like the palgue, since it was first adopted. I'm looking > for limitations when people interface bi-directionally with other > applications, performing operations like creating incidents, in relation to > things like not being able to support certain data types, not being able to > query certain outside webservices due to how they are structured, etc. > > Axton Grams > > 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. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"