LJ, I do feel your pain. :)
I think that in v7.1 (with the advent of Filter Error handlers) you could move the Web Service call to a filter all it's own and have it call an Error handler that does that for the user. My previous point is that as an "integration feature" such things should be specific to the integration feature. More to the point any integration feature should _expect_ that the needs for each integration type might be different than the needs for the overall workflow engine, or other integration types. (AKA: WebServices might require special integration needs that Run Processes, $PROCESS$, AR Plugin calls, Flashboard, etc.. need.) The way an integration is built into the overall workflow engine should deal with those details without conflicting with other integration methods. Which lead me to ask for "error handling" during consumes of WebServices action that is specific to the action/web service being consumed. -- 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 Mon, May 11, 2009 at 9:24 AM, LJ Longwing <lj.longw...@gmail.com> wrote: > That list reminded me about another one that bugs me. I don't like how when > an external webservice times out, the client tells you there is a problem > with the plugin server and tells you to contact your Remedy Administrator. > In this case, there is NOTHING wrong with Remedy, the issue is with the > external webservice not responding, but the only way to tell that is to > recreate the situation with logging on, then call the other team with the > log in hand. It would be nice if Remedy would say something like 'Unable to > contact web service at this target URI 'blah' > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Carey Matthew Black > Sent: Saturday, May 09, 2009 7:29 AM > To: arslist@ARSLIST.ORG > Subject: Re: Webservices > > 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" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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"
