Washing With SOAP: Part 1

This post only applies to Legacy Version 3 of the API

If you have ever integrated your organization’s application(s) or database(s) with an external data source, chances are you used a web service, or even multiple web services.  These generally come in two flavors: SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). Search around on the Internet and you’ll find plenty of advocates for one or the other.  When you get right down to it though, both are equally adept at getting a job done, i.e. getting your system to talk to another system. In the case of Bronto, we provide an API in the form of a SOAP web service.  Visit our API documentation for more detailed information.

First Things First: Setting Up API Permissions In Bronto

To make use of the Bronto service, you will need to create a Bronto user in your account with API access. To enable API access for a user, go to Home->Users and click on a user or the edit pencil icon to the right of the user. Once you are on the Edit Permissions page, make sure that API Permissions are enabled on the Other tab.

Getting Familiar With SOAP

SOAP services use XML as their language, and HTTP for the transmission of the messages.  They also “advertise” what operations are available in a file called a WSDL (Web Services Definition Language).  If this sounds complex and painfully hard to program, fear not, because the essence of how to use a SOAP based web service is this: send it a message that tells it to do something, and wait for the response.  When you get around to integrating with your system, you will generally do this in the programming language of your choice (most of the popular languages provide methods to call SOAP services).  If not, you can always resort to constructing the XML messages and sending them over HTTP, just like any other request for a web based resource.  But what do these XML messages look like, and how would one use a SOAP service without knowing a bunch of programmer mumbo jumbo?

Getting A SOAP Testing Tool

Simple actually.  Use a SOAP testing tool that’s independent of your programming language.  Web service documentation is great, but you really care about what that service does with your data, so why not jump in and start using the service right away.  A good testing tool is great for learning the ins and outs of a web service before you even start writing code.  It will also be your best friend when something goes wrong and you’re not sure if the problem is in your code, or is just the way the web service functions. Most testing tools, such as soapUI, which is freely available for download, allow you to generate the XML messages for a web service by parsing its WSDL. With soapUI, all you will need to do is create a new project and point it at the Bronto WSDL. A tool like soapUI allows you to utilize and test out a web service without worrying about any coding details.  This is useful before, during, and after the development process. Once you have explored the operations that the web service provides and feel comfortable with how they work, you can do some coding yourself or try out some of our sample code on http://api.bronto.com.

Sound good so far? Interested in learning more? Stay tuned for part 2 of this blog post series on SOAP. Next time we’ll look at what the SOAP requests and responses look like for some of the more commonly used operations. Until then, go ahead and explore the API yourself, no programming required.

Alex Durzy
Support Engineer at Bronto

Related posts:

1. Washing With SOAP: Part 2 This post only applies to Legacy Version 3 of the...
2. Washing With SOAP: Part 3 This post only applies to Legacy Version 3 of...
3. Have Logs Will Travel This post only applies to Legacy Version 3 of the...

Tagged as: API Legacy Version 3, soap, web service, wsdl, xml