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 <[email protected]> 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: [email protected] ARSlist: "Where the Answers
> Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
