No I meant triggering the WS from a display only form. I do not think you can build a WS on a Display Only (DO) form.
What I had done is created a dialog box to search for available time slots kind of a thing from another scheduling system, triggered a WS from that dialog box by faking a submit on the DO form. LJ had asked what kind of form was calling that WS. So I responded it is possible to call a WS from a DO form. Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Thursday, March 20, 2014 1:56 AM To: [email protected] Subject: Re: Web Service Insert error ** 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_ _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"
