What I was doing was calling an SB+ process from within the program and that is what caused the non-action.
Bruce -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill Haskett Sent: Monday, May 10, 2010 1:39 PM To: U2 Mail List Subject: Re: [U2] Soap error question What? You can't make a SOAP call to a U2 program if that program has a CALL in it? Bill Lunt, Bruce said the following on 5/10/2010 11:53 AM: >> Sorry for the delay in my response, I was out of the office for the last >> week. >> >> It turns out that the problem was that I was calling a subroutine in my >> program and that doesn't work with soap. So, I included the subroutine's >> logic into the Basic program and it works now. >> >> Bruce >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Joshua Gallant >> Sent: Monday, May 03, 2010 11:33 AM >> To: U2 Users List >> Subject: Re: [U2] Soap error question >> >> I haven't worked a ton with SOAP requests but figured I'd throw this out >> there any how... >> >> Do you have a permissions error preventing a write? It seems most of >> what you've mentioned that's working are just reads but the one that >> write is failing. >> >> - Josh >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Lunt, Bruce >> Sent: Friday, April 30, 2010 6:13 PM >> To: [email protected] >> Subject: [U2] Soap error question >> >> Hi All, >> >> >> >> We have a strange result happening with a simple soap service call and I >> was >> hoping someone has seen this problem or something like it before. >> >> >> >> We have 3 different soap calls: SSN.VERF, SSN.VERF.SUP & SSN.SUBMIT. >> Each >> program has 2 inputs: CUST.NO & SSN and 1 output: VERIFY. >> >> >> >> The first one: SSN.VERF is a program on UniData that accepts Cust.No & >> last-4 of SSN. The program then reads the customer record and validates >> that >> the last 4 of that customer's SSN match the 4 digits sent in the >> transmission. If they match then it returns a 1 in the variable called >> VERIFY. Otherwise, it returns a 0 (zero) in VERFIY. >> >> >> >> SSN.VERF.SUP: Is for supervisors to send the whole 9-digit SSN and have >> it >> verified as well with the same VERIFY variable being passed back. >> >> >> >> SSN.SUBMIT: Is for adding the SSN to the customer's record if it does >> not >> already exist. It checks for the existence in the record and in the >> cross-reference file and returns 1 if the update was successful and zero >> otherwise. >> >> >> >> Now for the problem: SSN.VERF & SSN.VERF.SUP both work as expected. >> SSN.SUBMIT appears to work when it is for an invalid entry (the SSN is >> already on file) but whenever a valid SSN is entered for a customer with >> a >> blank SSN field it fails with a strange error message, like this: >> >> >> >> <soapenv:Envelope >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >> >> <soapenv:Body> >> >> <soapenv:Fault> >> >> <faultstring>Exception: Internal Web Service Server >> Error</faultstring> >> >> <detail> >> >> <UniSOAPException> >> >> <error>Exception: Internal Web Service Server Error</error> >> >> </UniSOAPException> >> >> </detail> >> >> </soapenv:Fault> >> >> </soapenv:Body> >> >> </soapenv:Envelope> >> >> >> >> Can anyone suggest how we could debug this problem? Is there a way to >> capture whatever it is that is freaking out the soap process? >> >> >> >> TIA, >> >> Bruce Lunt > _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
