I understand. You might have success with one of the various projects I list below, but it entirely depends on whether the WSDL represents something that was written and the service code was written from it…or whether the WSDL is something generated from the service code. The former presents interfaces that conform to spec far more frequently and simply. The latter will do things that are possible in the spec, but don’t happen in WSDL-first services, which means that most WSDL parsers handle them poorly.

Here are all the toolkits I’ve tried before basically punting:

• elixir-soap/soap
• trbngr/Lyex
• polyfox/castile
• bet365/soap
• zdeneksejcek/soapex

Of these, bet365/soap is the most mature but hasn’t been maintained in years; polyfox/castile is promising but hasn’t been maintained in a long time; zdeneksejcek/soapex is really interesting but incomplete. None of them worked with any one of the four WSDLs I had to work with.

If yours is a simple enough service, you’d probably be better off building EEx templates for sending the requests and XML parsers for receiving the requests and calling the services with an HTTP client (most SOAP is over HTTPS, after all).

If it’s not a simple service…all I can say is good luck doing it in Elixir. SOAP is a technology that only works really well if you have relatively large engineering teams building the code tooling around the excessively complicated standards. The absolute best platforms/languages to develop SOAP services and clients are Java and C#—because the SOAP standards were mostly written by people who work at Oracle (and Sun before that), IBM, SAP, and Microsoft.

The truth is, I don’t want to write a SOAP client in Elixir—because I don’t want to use SOAP if I can avoid it, and that disdain also means that I’m not likely to maintain it (even the Ruby toolkit that I ended up using, soap4r-ng, hasn’t been maintained in a few years, but it’s a lot more mature than anything in Elixir/Erlang that does SOAP).

If you can, build a REST-to-SOAP service in a language that has good SOAP support. I have tried all of the various SOAP libraries in Erlang and Elixir and have yet to find one that can properly parse the WSDLs that I had to deal with (they all failed at some point or another)

I ended up using Ruby with soap4r (well, soap4r-ng), because neither savon nor lolsoap could handle the complexity of the SOAP service I used.

SOAP is a nasty piece of work because it’s fully object oriented and if your service was built system-first, rather than WSDL-first, you will have heavy object orientation and polymorphism to deal with and pretty much all of the Erlang/Elixir SOAP services that I played with failed.

If I have to deal with another SOAP service (I’m usually doing enterprise integrations, so it’s not unlikely), I will either do the same thing or build my own WSDL/WSSE/SOAP layer with the goal of open sourcing it, but that’s probably a year in the future at least. It’s a hard thing, because once we got started with the soap4r approach, we had our gateway and Elixir code implemented in about two weeks. It would have taken two weeks just to get a working WSDL parser for Elixir to handle the multiple WSDLs I had to deal with.

I love Elixir, but there’s no good answer to doing SOAP in Elixir at this point.

It’s what everyone should do. WSDL and SOAP were dead on arrival. They were born in some pretty dark times; people thought that imposing a huge and slow formal processes by organisations full of academics who have zero exposure to the real world was actually a good idea.

I’ve known a ton of Java devs back then (and I was one; talking about 2003-2009). At least 80% of them just made their own SOAP parsing and generating code and were done months before the others who insisted on using heavyweight libraries for it.