[SOLVED] SOAP U2.0 call-out

Author: knut.dybendahl@gmail.com (Knut)

Here's a strange one; On a Win2008R2 (call this ServerA) , a 32 bit version of Uniface is installed - and a callout to a SOAP service is performed ok. Using the same executable, and running on a mapped network drive to a Win7 Enterprise pc works fine. Copy the installation from ServerA to ServerB, and the callout to the soap service fails with a -155. Run the executable from Server B on a Win 7 Enterprise - works fine.... Has anyone seen this before? It smells of a DLL being updated by the installation process - but I cannot see any differences in the DLL's (afaics). Cheers, Knut

5 Comments

  1. Hi, We have had several problems with different versions of "The Microsoft Visual C++ Redistributable Package". Nowadays we copy the files of "The Microsoft Visual C++ 2005 SP1 Redistributable Package" to the Uniface\common\bin directory to avoid that some other version of the package is used. Perhaps it has nothing to do with your problem, but check it out! Regards RogerW.


    Author: rogerw (roger.wallin@abilita.fi)
  2. Hi Roger, Thanking you - I did remember to run the Redistributable Package - but it might be version (uf version) specific. I'll check with the support guys here... Knut


    Author: Knut (knut.dybendahl@gmail.com)
  3. Ok - so here the reason.... Problem: ------------ When the usys path logical in the usys.ini file is defined as a relative path, a web service call-out fails with "WSDLException: faultCode PARSER_ERROR, XML Parser Exception297" error because file soapencoding.xsd cannot be located on a relative path to \common\usys in the wsdl locator url. Solution: No solution. Well, thank you Uniface.... Frown The soapencoding.xsd file is a Uniface file. Since I can map all other files in the USYS folder via a logical setting (relative .\ notation), and that includes udesc.urr and usys.dol, then the fact that it's only the SOAP connector being difficult, I kinda feel Confused. I know the manual states fully qualified path names - try a multi-site deployment with each PC having to run their own INI file since there are unique logical printers attached to each pc.... An ini file setting like this - "usys=.\usys2000\common\usys" - works perfectly for everything - except SOAP...


    Author: Knut (knut.dybendahl@gmail.com)
  4. Well, thank you Uniface... Cool USYS is an interesting variable - in fact (on Windows at least) you don't even have to define it... Uniface figures out where things are based on where you run Uniface from. The happy face comes from the fact I don't have to "name" my USYS variable, hence once I removed the USYS from the ini files (all of them) - the app continued to work, and even SOAP call out worked too!! Yay! Knut


    Author: Knut (knut.dybendahl@gmail.com)
  5. Hi Knut, Thanks for the info. As far as I remember Uniface has a fall-back mechanisms for the USYS directory (at least on Windows). If it's not defined then Uniface will try to find it relative to the USYSBIN directory (where the binaries are located). But one remark to your previous posting: I did a quick test here and I only can replicate the described SOAP error in case the USYS variable is pointing to an "incorrect" directory (i.e. the file soapencoding.xsd cannot be found there). In case I use a "valid" relative path for the USYS directory then the SOAP call out is just working fine. So I'm not really sure what is wrong here. Confused Hope this helps. Daniel


    Author: diseli (daniel.iseli@uniface.com)