O$5.2 - Omnis Web Services - debugging

Paul Mulroney pmulroney at logicaldevelopments.com.au
Tue Aug 12 19:06:51 EDT 2014

Hi Rudolph,

Thanks for your message.  It's a bit disappointing to find out that Java Web Services isn't stable. It's one of the things I though would "just work".

We use a lot of TCP commands for a host of other interfaces to the package, and I downloaded SoapUI in the initial stages of development for this function, so it's definitely possible for us to rewrite the code to send the raw SOAP message and decode the response.  I was just hoping we didn't have to.

I'll try out the trace log thing - maybe that will have some more clues.

The latest thought is that it's a memory issue - it's possible to increase the amount of memory reserved for Java by using eg  -Xms512m in the JavaOptions to increase the memory allocated to Java to 512Mb.


On 13/08/2014, at 12:00 AM, omnisdev-en-request at lists.omnis-dev.com wrote:

> Hi Paul,
> Ok, so it seems you are using the Java interface to communicate with a web service. We did this as well, but it was never really stable, was not that easy to develop and distribute to the clients and we found a more flexible workaround.
> The following takes it for granted that you are accessing a soap web service. The basis for a solution would be to first install SoapUI
> http://www.soapui.org/
> http://sourceforge.net/projects/soapui/files/
> SoapUI is a tool which you can use to test web services. Once you get your web service working in SoapUI there is an option to display the RAW data that is the request sent to the web service server. In essence you can take this HTTP POST data/text, use Omnis text methods to build the soap XML that you send to the server, and then we use the WebWin component of Omnis to send the request to the web service. You could even use the native Omnis TCP commands to do this, but we found the WebWin stuff sufficient for our needs and allows us to access https services.
> The above took away the need to use Java to communicate with web services. Some web services however have really complex authorization mechanisms where you might be forced to use Java, but most can easily be called using the above mechanism.
> Regarding Brian's post regarding the trace log: sys(193) will return the contents of the trace log on the client. Perhaps the trace log on the client will give you more information why the Java stuff is failing.
> If you are interested I can post you our web service object in a library (Studio 4.3 non-unicode). Not pretty, but it works.
> Regards
> Rudolf

Why is the man who invests all your money called a "broker"?
Paul W. Mulroney                                                   We Don't Do Simple Pty Ltd 
pmulroney at logicaldevelopments.com.au        Trading as Logical Developments
www.logicaldevelopments.com.au			   ACN 161 009 374 
Ph: +61 8 9458 3889						   86 Coolgardie Street
Fax: +61 8 9458 2169                       			   BENTLEY  WA  6102

More information about the omnisdev-en mailing list