Yes. Rick On Mar 19, 2014 7:55 PM, "LJ LongWing" <lj.longw...@gmail.com> wrote:
> ** > > And Short Description is one of the field that's involved in the web > service? > On Mar 19, 2014 8:50 PM, "Rick Cook" <remedyr...@gmail.com> wrote: > >> ** >> >> 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_ >> >> _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"
