Although field 8 wouldn't be required on a DO form so if it were a DO form and field 8 was erroring because of a null value it would indicate an issue with a push field action to a regular form not the WS itself. Alas it is a Regular form...
Jason On Wed, Mar 19, 2014 at 10:42 PM, Joe D'Souza <[email protected]> wrote: > ** > > That really should not matter. I have called a WS in the past from a > Display Only form by 'faking' a submit operation via a Push Field action to > it. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *LJ LongWing > *Sent:* Wednesday, March 19, 2014 10:42 PM > > *To:* [email protected] > *Subject:* Re: Web Service Insert error > > > > ** > > 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_ > _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"
