Re: Web Service Insert error
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:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Tuesday, March 18, 2014 10:45 PM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, March 18, 2014 11:47 AM To: arslist@ARSLIST.ORG 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 wrentf...@stratacominc.com 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:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, March 17, 2014 11:18 AM 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
Re: Web Service Insert error
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:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Thursday, March 20, 2014 1:56 AM To: arslist@ARSLIST.ORG 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 jdso...@shyle.net 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:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, March 19, 2014 10:42 PM To: arslist@ARSLIST.ORG 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 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
Re: Web Service Insert error
You could get an error on soapUI if you encounter a filter validation error from workflow. I have had that happen. Unfortunately soapUI displays the error that is returned by the WS plugin. So it appears like it's a WS error when it actually isn't. It's one of the things I had wished when I got that error, that the plugin should have displayed the validation message from the filter rather than make it look like something went wrong with the WS processing. Unfortunately that is not the case. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, March 20, 2014 11:10 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error Since I think you said it bombs even when trying from SoapUI then you can eliminate the custom 7.1 system completely from the debugging. To verify you can look at the armidtier.log file on the Web Service Mid-Tier and see the XML being passed in. If you are logging to file I would stop and restart all log files on the host 7.6 system and re-run the test to get the error. Then I look in the SQL log file for the Insert (or Update) that failed. That will give you the form (T table) which you are pushing to. You should then be able to find the Push in the filter logs. Now if the error is happening on a child form (due to having a complex XML that creates parent and child records), and not from a Filter push action, things get trickier (Think of the Order and detail line items example. The detailed line items are what I am calling child records). Unfortunately the insert into the child records is only logged in the SQL log. I believe you said another developer used the child Short Description to hold a key to get back to the parent record. Is the mapping to the child Short Description the Request ID of the parent or another field in the Parent? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Wednesday, March 19, 2014 11:26 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error ** 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 -Original Message- On Mon, Mar 17, 2014 at 11:40 PM, Joe D'Souza 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 -Original Message- On Fri, Mar 14, 2014 at 10:37 PM, Joe D'Souza 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
Re: Web Service Insert error
What version are you on? I was on 7.6.04 on which I am quite certain it wasn't working that way. I was wishing it would have been designed to work that way and treat that error as a data string returned. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, March 20, 2014 11:55 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error I see the error from the Filter in the Fault String Say I create a new form FormA. Standard Fields only. I create a filter on FormA that fires on Submit. Run-If of 'Short Description' != My Special Text. Error Action; Error Num = 123456, Error Text = You typed bad data. I create a Web Service on FormA. Using SoapUI if I call the Create operation and pass in JUNK JUNK JUNK for the Short Description I see my filter's error number and text in the Soap Fault. soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (123456): ; You typed bad data/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;mywebserver/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Thursday, March 20, 2014 10:29 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error ** You could get an error on soapUI if you encounter a filter validation error from workflow. I have had that happen. Unfortunately soapUI displays the error that is returned by the WS plugin. So it appears like it's a WS error when it actually isn't. It's one of the things I had wished when I got that error, that the plugin should have displayed the validation message from the filter rather than make it look like something went wrong with the WS processing. Unfortunately that is not the case. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, March 20, 2014 11:10 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error Since I think you said it bombs even when trying from SoapUI then you can eliminate the custom 7.1 system completely from the debugging. To verify you can look at the armidtier.log file on the Web Service Mid-Tier and see the XML being passed in. If you are logging to file I would stop and restart all log files on the host 7.6 system and re-run the test to get the error. Then I look in the SQL log file for the Insert (or Update) that failed. That will give you the form (T table) which you are pushing to. You should then be able to find the Push in the filter logs. Now if the error is happening on a child form (due to having a complex XML that creates parent and child records), and not from a Filter push action, things get trickier (Think of the Order and detail line items example. The detailed line items are what I am calling child records). Unfortunately the insert into the child records is only logged in the SQL log. I believe you said another developer used the child Short Description to hold a key to get back to the parent record. Is the mapping to the child Short Description the Request ID of the parent or another field in the Parent? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Wednesday, March 19, 2014 11:26 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service Insert error ** 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 -Original Message- On Mon, Mar 17, 2014 at 11:40 PM, Joe D'Souza 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
Re: Web Service Insert error
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
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:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, March 18, 2014 11:47 AM To: arslist@ARSLIST.ORG 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 wrentf...@stratacominc.commailto:wrentf...@stratacominc.com 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, March 17, 2014 11:18 AM To: arslist@ARSLIST.ORGmailto: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.netmailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Friday, March 14, 2014 10:45 AM To: arslist@ARSLIST.ORGmailto: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
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 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
Re: Web Service Insert error
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
Re: Web Service Insert error
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
Re: Web Service Insert error
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.netwrote: ** 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
Re: Web Service Insert error
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:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, March 19, 2014 10:42 PM To: arslist@ARSLIST.ORG 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 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
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 jdso...@shyle.net 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: arslist@ARSLIST.ORG] *On Behalf Of *LJ LongWing *Sent:* Wednesday, March 19, 2014 10:42 PM *To:* arslist@ARSLIST.ORG *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 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
Re: Web Service Insert error
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:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, March 17, 2014 11:18 AM 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.netmailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Friday, March 14, 2014 10:45 AM To: arslist@ARSLIST.ORGmailto: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.orghttp://www.arslist.org 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
Re: Web Service Insert error
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
Unfortunately, Doug, we do need to map the field, because the developer who built the custom app re-purposed the Short Description field to hold a foreign key, without which the whole interface is pretty much useless. Yeah, I know... On Sat, Mar 15, 2014 at 6:15 AM, Blairing d...@blairing.com wrote: Rick, I have run into something similar recently on a 7.5 system. Take a look at the WSDL file and find a line for the Short Description field. If you auto-generated the file on the target server at some point (while building the web service you push to) you will probably find all the core fields there with a minOccurs=1, which makes them required in WSDL-speak. Even if that field is not included in the values you send or consume the minOccurs means it has to be present. We set the field to the text not used on the sending side but did not map it and that seems to work. Incidentally, we decided to use DSO to do something similar as that protocol allows for re-tries and returns. There is always more than one way to do it :-) Doug -- Doug Blair +1 224-558-5462 Sent from my iPad Air Auto-corrected typos, misspellings and non-sequiturs are gratefully attributed to Steve Jobs :-) On Mar 14, 2014, at 9:45 AM, Rick Cook remedyr...@gmail.com wrote: 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
Rick, I have run into something similar recently on a 7.5 system. Take a look at the WSDL file and find a line for the Short Description field. If you auto-generated the file on the target server at some point (while building the web service you push to) you will probably find all the core fields there with a minOccurs=1, which makes them required in WSDL-speak. Even if that field is not included in the values you send or consume the minOccurs means it has to be present. We set the field to the text not used on the sending side but did not map it and that seems to work. Incidentally, we decided to use DSO to do something similar as that protocol allows for re-tries and returns. There is always more than one way to do it :-) Doug -- Doug Blair +1 224-558-5462 Sent from my iPad Air Auto-corrected typos, misspellings and non-sequiturs are gratefully attributed to Steve Jobs :-) On Mar 14, 2014, at 9:45 AM, Rick Cook remedyr...@gmail.com wrote: 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
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
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
Re: Web Service Insert error
What about Filter and SQL logs? If it is coming from a Push action then these would be the place to find that info. I would start with SQL to find the error then back track to Filter Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Friday, March 14, 2014 9: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
Re: Web Service Insert error
Rick, Where is the error coming from. Is it coming on your 7.1 custom system when trying to consume the web service to populate the 7.6.04 system, or vis versa? On Fri, Mar 14, 2014 at 8:45 AM, Rick Cook remedyr...@gmail.com wrote: 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
I had Filter, API, and SQL logs on for a while, but the Filter logs had by far the best information. The others were just kind of redundant/useless. I will try turning on the mid-tier logging to see if I can catch something there. Rick On Fri, Mar 14, 2014 at 7:50 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: What about Filter and SQL logs? If it is coming from a Push action then these would be the place to find that info. I would start with SQL to find the error then back track to Filter Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Friday, March 14, 2014 9: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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
I would guess that you are pushing a NULL value which is overriding the field default. If you are not doing anything with the field try not including the field in the push. Mark -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 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Web Service Insert error
Rick Webservice plugin logs will show all the field values being passed which should lead you to next steps Thanks Regards Himanshu On Mar 14, 2014, at 10:45 AM, Rick Cook remedyr...@gmail.com wrote: 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
