Hi,
Is it possible to use Gatling when testing a service that takes requests of type application/soap+msbin1?
When I have run the recorder I have the binary request files in the request-bodies folder and the request body is filled using RawFileBody. The problem is that I need to change some parameters in the request using session variables.
Anyone has an idea or has some experience working with soap+msbin1 requests?
BR,
Gustav
Hi,
I don’t know anything about Microsoft specific formats.
Is this format text or binary?
If it’s text, with Gatling 2, you can use ELFileBody instead of RawFileBody and use Gatling EL syntax.
Cheers,
Stéphane
It is a binary format unfortunately.
BR,
Gustav
“application/soap+msbin1” is a MS specific format (so much for WS interop, reminds me of JAX-RPC…).
I seriously doubt you’ll be able to find an open-source, JVM implementation of this encoding, so I’m afraid you’re stuck with VisualStudio…
If you were to find such an implementation, please feel free to ping.
Regards,
Stéphane
WAPT load tool (pro version) claims to have full support for this special MSBin1 binary format, used for instance by Silverlight apps. The free version does not support this special plugin though.
http://www.loadtestingtool.com/silverlight-testing.shtml
LoadUIWeb load tool seems to offer some support as well?
“LoadUIWeb can decode .NET Binary XML (Binary XML and Binary SOAP). This means that with LoadUIWeb, you can perform load testing of applications that use these formats to communicate with web servers…”
http://loaduiweb.org/docs/generalinformation/supportedapps/ria/protocols/support-for-binary-xml-format.html
How can WAPT and LoadUIWeb manage this if msbin1 is Microsoft proprietary?
rgds Juha
Sorry, the term proprietary is maybe inappropriate. I don’t know if the format is under close license so you have to pay MS if you want to write an implementation, or if the specification is public.
In any case, all the implementations you mentioned are neither open source nor free.
And that makes sense:
- enterprisey
- not widespread non-interoperable protocol
- no open-source concurrent Java implementation
- implementation costs: MS licenses + learing curve for people with a Java/Linux background
Generally speaking, this is the typical drawback of using very specific protocols: very hard to test and generate lots of hidden/non anticipated costs.
For example, in my company, we have some Flex applications that used AMF (testing hell), and we migrated everything so the services now expose JSON (migration cost…).
IMHO, using this MS specific binary format was a bad idea to begin with