Regular Form.

Rick
On Mar 19, 2014 7:42 PM, "LJ LongWing" <lj.longw...@gmail.com> wrote:

> **
>
> What type of form is the form that is calling the web service?
> On Mar 19, 2014 8:32 PM, "Rick Cook" <remedyr...@gmail.com> wrote:
>
>> **
>> Thanks, Joe, I had forgotten about that file.
>>
>> I dug through it with renewed hope this morning, but it says pretty much
>> the same thing the Filter log said.  The Web Service bombs because of the
>> null field, but the last transaction above the error shows a value in the
>> field.  I can verify that the field in question is being populated right up
>> until the WS is fired, and that the mapping on the WS Create operation maps
>> the field from the last place it was populated into the staging form on the
>> destination server.
>>
>> I still have no idea what process is nulling the value from the field.
>> :-/  Stepping through the process...again...
>>
>> Rick
>>
>>
>> On Mon, Mar 17, 2014 at 11:40 PM, Joe D'Souza <jdso...@shyle.net> wrote:
>>
>>> **
>>>
>>> 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_
>>>  _ARSlist: "Where the Answers Are" and have been for 20 years_
>>
>>
>> _ARSlist: "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