Rick,

 

The verbiage of the error "Error encountered while executing a Web Service"
suggests it is not a problem at the Filter. The Filter for the most part
should be fine, it is the Web Service plugin that is hating something.

 

Which specific log file are you looking at? You have to look at the AR Java
plugin log (the file that cannot be turned off). I cannot recall offhand the
exact name of the file, but it looks something like arjavaplugin.log. That
file contains a trace of every Web Service transaction that happens, be it a
success or failure.

 

Joe

 

  _____  

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Monday, March 17, 2014 12:18 PM
To: arslist@ARSLIST.ORG
Subject: Re: Web Service Insert error

 

** 

Joe,

Yes, that's one of the things that I checked early on, that we are mapping
the field all the way through the transaction process, and we are.

As to the version matching, we have this working in production, but a
relatively minor enhancement (mapping two additional new fields) has
apparently broken it in dev., and I can't figure out why.  At one point, the
Plug-in log said "java.net.ConnectException: Connection refused: connect",
but I got past that, and now it doesn't give an error.  The Filter logs are
what's showing that the Set Fields that calls the Web Service is barfing on
setting the first field it gets to - the Short Description field (which has
been re-purposed into a required foreign key field).

Rick

 

On Fri, Mar 14, 2014 at 10:37 PM, Joe D'Souza <jdso...@shyle.net> wrote:

Rick,

Are you mapping that default value in the filter that is consuming that web
service? If not yes that error would be expected when the XML is processed
by the web services plugin as that plugin has no idea if there is nor not a
default on a required field assuming that field is configured as required in
the Web Service.

Having said that, if that is not your case (that is you are mapping the
required field to a non null value), then please post the java plugin log
generated by the AR Server. That would capture the reason for the error if
it is at the Web Service plugin level.

Also, LJ has a valid question. Since you are on two separate versions on the
two systems that need to communicate, which system is trying to consume
whose service? I had recently ran into a issue where a lower version AR
System could not consume a 7.6.04 web service.. And BMC Customer Support
recognized that as an issue. Unfortunately, I do not remember what version
that lower version system was on but I can try to find out, I fear it was a
7.1 system.

Cheers

Joe



-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Friday, March 14, 2014 10:45 AM
To: arslist@ARSLIST.ORG
Subject: Web Service Insert error

I have two Remedy systems, a 7.6.04 ITSM box and a 7.1 custom one.  I have
two web services that allow a custom bare bones ticketing system on the
custom server to interact with the ITSM server, so that a record created
under certain conditions on one box will create a corresponding record on
the other.

There is a bit of custom code and configuration data in place to facilitate
all of that, and it seems fine.  The WSDL in the web service displays the
XML fine, as does SoapUI.  The problem is that when I attempt to actually
fire it, I get an error that the logs don't seem to capture at a fine enough
level of detail to help me find the root of.  The error, "Error encountered
while executing a Web Service", is complaining that Field ID 8 (Short
Description) is NULL, and therefore the record can't be saved (since it's a
required field).  That field has a default value in it in every form we use
in the process, and we even map that field between forms to ensure that a
value is being pushed, but the error continues.

Has anyone had a problem like this before, or can someone point me to the
next thing to try?  AR Error logs aren't showing anything, and the Plug-in
logs don't say anything useful either.

Rick Cook

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to