Rick,
Talking about setting fields to NULL (thank you William for leading us to that direction) I recall another possibility for that error. It can happen if there is some qualification in your code, that is causing a filter to return an error message to the user. I had on one occasion, after a WS creates an entry in a form, some of the values were pushed to another form, and a certain filter on that other form would return a data validation error back to the user running the transaction, as that filter was checking for that particular WS user and certain data on that transaction. As a result if I tried the same transaction using any other guest user and a WS testing tool like SoapUI, it ran smooth as a wheel after disqualifying the qualification on that filter. The error was happing only at the time the WS was called by the AR System using that configured AR System user. I completely forgot about that particular incident that happened in my development experience. Nothing was getting written to the error logs, as there was no system error happening. It was a workflow validation error that was supposed to be presented to the user running the transaction, which in this case was the WS User. The way I could reproduce that error from the user tool is log in to the user tool or the browser as the WS user, enter the exact same values that return that error in the transaction, and I got that filter error, which helped me tweak that filter. You could try doing something similar to trace what filters get executed and see if you can reproduce that error using the user tool or the browser. Getting that actual validation error message will open up a clue as to what is happening during the transaction at the ARS level. Hope this might be of some help to you. Cheers Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of William Rentfrow Sent: Tuesday, March 18, 2014 10:45 PM To: [email protected] Subject: Re: Web Service Insert error I wish I could remember the full details of that one - it was over three years ago. Sadly, I remember the timeframe because I shared an office with a co-worker who was killed in an accident at that time. I remember him looking at it with me. The thing we found was that we couldn't see the errors directly - the weren't returned to us through the web/WUT. We ended up finding it in the arerror.log if I remember correctly. I think if I was you I'd un-map one of the fields and see if it works. And then switch with the other. Say hi to the real killers when you find them :-) From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: Tuesday, March 18, 2014 11:47 AM To: [email protected] Subject: Re: Web Service Insert error ** That's a great thing to check, but I've already done the side-by-side check. All workflow is happening in custom forms, and in my re-check of the log files, there's nothing setting the fields to NULL that I can see. Just all of a sudden a field that was populated no longer is. I'll keep looking. Maybe I'll run into O.J., looking for who killed Nicole. :) Rick On Mon, Mar 17, 2014 at 2:39 PM, William Rentfrow <[email protected]> wrote: ** I had something like this happen once, and it was when something was being transferred through HPD:IncidentInterface_Create. Essentially there was a nested "Set Fields" and it wasn't finding a match. The workflow was set to set all fields to NULL instead of creating a No match error, so consequently the field in question would get set to NULL. My suggestion - log the working one and the non-working one, and compare to see if workflow is firing the same or if the two new fields are causing a lookup somehow that results in a "no match". From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: Monday, March 17, 2014 11:18 AM 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 _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"
