Thanks for suggestion. I know how to write a custom Java client to fire my SOAP request into the Web Service. Heck, I could do that from a script.
But that kind of invalidates the whole point of using soapUI, doesn't it ?
I would like to integrate my "large test" together with all the other tests I have in soapUI. If I can only use soapUI for small requests and have to use another tool for large requests then it will probably be better for me not to use soapUI at all. That would be a shame. It is a really good tool.
Let's recap:
All I really want is to take some XML (headers and all) and fire it into the Web Service without soapUI freezing on me.
My next test is to try and trick soapUI into doing what I want: soapUI saves project files in XML files (one big file per project) and inside that the contents of each request is defined in a CDATA enclosure. I'll try to use some kind of text editor to stick my XML in there, save the file and then try to load that project from within soapUI without opening the request itself so that soapUI doesn't have to display it in the editor .. which I'm sure would make it freeze.
But am I really the only one that are trying to use soapUI for something other than the normal kiddy stuff, i.e. request of 20 bytes ("What is current weekday?") and response of 20 bytes ("Today is Monday") ?. Real world is somewhat more complex than that.