SOAP Web Services Tool

[Scott H]

Ryan,

I am way out of practice with PHP and I rely on workbench these days
quite a bit. Back in the day, I wrote this post
http://sfdc.arrowpointe.com/2008/12/05/calling-apex-web-services-from-php/
that discusses connecting to SOAP web services using the PHP toolkit.

I wanted to suggest a simple little tool be added to the workbench to
allow for the testing of Salesforce web services over SOAP. Apex web
services have been able to be exposed over SOAP for some time now, but
testing them is really difficult. I was hoping there could be a page
in workbench to help this out. Even if it made the user enter stuff
like web service name and method name. Maybe it could handle the bulk
of the nitty gritty SOAP and WSDL stuff?

The hardest part of it is figuring out the URL to connect to.

Just a thought.

[Ryan Brainard]

I had thought about doing something like this before, but never
implemented it because I started using SoapUI (http://www.soapui.org/)
when I needed to work with arbitrary WSDLs for testing and
troubleshooting. With the new Apex REST (beta) feature (http://
www.salesforce.com/us/developer/docs/apex_rest/index.htm), there might
be some renewed interest in making a new tool like this, but I know
people have successfully used the REST Explorer in Workbench for this,
so not sure if there's something that needs to be dedicated for that
either.

If something like this was implemented, how would you envision the UI?
Would you just upload a WSDL and have freeform text to manipulate the
SOAP messages (a la SoapUI), or something more wizard-like with forms
to create the requests? Also, would you want Workbench to
automatically add on the SOAP header for authentication as the logged
in user?

I went ahead and put this feature on the backlog (http://
code.google.com/p/forceworkbench/issues/detail?id=543), but not sure
if and when I'll get it. I'm interested to see how much interest there
is from the community. Also, if anyone else would like to work on this
feature (it is open source after all!), that'd be good.

Thanks,
Ryan

On Sep 16, 9:37 am, Scott H <scott.hemme...@arrowpointe.com> wrote:
> Ryan,
>
> I am way out of practice with PHP and I rely on workbench these days

> quite a bit.  Back in the day, I wrote this posthttp://sfdc.arrowpointe.com/2008/12/05/calling-apex-web-services-from...

[Richard Tuttle]

I may pick this one up. I like the idea of being able to drop a WSDL
for an Apex web service or a SoapUI similar interface specific to
either the partner or a specific enterprise WSDL.

The question I'd poster before tackling this is what can we stand to
gain more than the free version of SoapUI (aside from the fact that I
hate soapUI on Windows). So far the thought is we could make it
easier to test Apex web services as we'll already have a token
available for API purposes.

-Richard

On Sep 17, 7:37 pm, Ryan Brainard <ryan.brain...@gmail.com> wrote:
> I had thought about doing something like this before, but never
> implemented it because I started using SoapUI (http://www.soapui.org/)
> when I needed to work with arbitrary WSDLs for testing and

> troubleshooting. With the new Apex REST (beta) feature (http://www.salesforce.com/us/developer/docs/apex_rest/index.htm), there might

[Ryan Brainard]

The main benefits I see:
- Simplified authentication. The SessionHeader could automatically be
constructed using the active session in Workbench.
- API version in endpoint would be controlled by the Workbench
setting.
- Additional headers (e.g. DebuggingHeader) could be added and be
controlled by Settings. Just like the Apex Execute feature.
- Depending on how the UI is built, instead of just having freeform
SOAP requests, the WSDL could be parsed and form fields could be
automatically displayed, and responses could be displayed in "tree
view" instead of raw SOAP. Of course, having the raw XML would be nice
too, but doesn't need to be default.
- If you want to be fancy, you could do something where the backing
Apex class could be updated directly from Workbench. This is getting a
little into IDE territory, but could be interesting.

Let me know if you do end up picking it up.

--Ryan