And really... Why would anyone want to have to worry about network
path issues between every client and some external Web service host
anyway? Having the communications originate/terminate from/to the ARS
server seems like a much wiser approach to me. Having the client
connect to an external resource would add some real firewall/security
problems if you ask me.
They wouldn't.
I think what I'd like (as well as a LOT of other people would like)
is a WEBSERVICE set-fields action in an active link, that acts
exactly like the SQL set-fields action in an active link. You don't
see clients making direct sqlnet connections or what have you
directly to the DB in those cases, either for the same reasons.
This new function sounds promising, in fact, I can't wait to get the
opportunity to install 7.1 and play with it, but to be honest, what
you're describing sounds even MORE goofy than the situation now, of
having to basically have a dummy form, push your webservice args to
it, fire a filter to call the webservice, etc ...
I like Remedy and all ... but damn if they can't find a way to go
around your ass to get to your elbow in any given situation.
-Andrew
On Nov 1, 2007, at 8:15 AM, Carey Matthew Black wrote:
Not that I have seen. (as a direct path)
But what they added in 7.1 was a more general solution. A new "Filter
Execute on" condition called "Service" that can be triggered by a new
Active Link action.
So basically you can do a "null transaction" (no RDBMS data created)
via this "Service" operation. Thus you can have the ARS server make
the WebService call and the Active link action looks like the "Window
Open" action in so much as there are "Input" and "Output" mappings
from the local field to the "remote" Form at the start and end of the
"Service" operation. Sure this could be used to have a filter be
triggered to call a Web Service, but it could also be called to
perform any thing that filters could do. However it still requires a
filter to call the Web Service.
And really... Why would anyone want to have to worry about network
path issues between every client and some external Web service host
anyway? Having the communications originate/terminate from/to the ARS
server seems like a much wiser approach to me. Having the client
connect to an external resource would add some real firewall/security
problems if you ask me.
Not to mention that Active Links are really "optional" in the ARS
design. ( An ARS API client does not honor them unless you write a
whole lot of code on your own.) So, again, making these integrations
be server based makes much more sense to me.
( I see no "limitations". I see best practices being imposed for what
appear to be "good reasons" IMHO. )
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On Nov 1, 2007 7:55 AM, Grooms, Frederick W
<[EMAIL PROTECTED]> wrote:
Isn't that one of the new features of 7.1.0 (Calling webservices from
Active Links)?
On 11/1/07, Rakshit Bhandary <[EMAIL PROTECTED]> wrote:
**
Hi,
I have another query related to webservices. Is there a way to
call a
webservice directly from a Active Link?
Regards,
Rakshit
______________________________________________________________________
_________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
ARSlist:"Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
