Regular Form. Rick On Mar 19, 2014 7:42 PM, "LJ LongWing" <[email protected]> wrote:
> ** > > What type of form is the form that is calling the web service? > On Mar 19, 2014 8:32 PM, "Rick Cook" <[email protected]> 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 <[email protected]> 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: >>> [email protected]] *On Behalf Of *Rick Cook >>> *Sent:* Monday, March 17, 2014 12:18 PM >>> >>> *To:* [email protected] >>> *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 <[email protected]> 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:[email protected]] On Behalf Of Rick Cook >>> Sent: Friday, March 14, 2014 10:45 AM >>> To: [email protected] >>> 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"
