The way SOAP was implemented for SF D7 never really worked well, and was confusing for end users.
For D8, I think it makes more sense to allow the module to decide when to use SOAP, rather than delegating the choice to the end user.
SOAP and REST APIs serve different purposes and do not have equivalent feature sets, so we should not pretend that they're interchangeable. When SOAP module is enabled, it should take over things that it's good at - most prominently: batch push.
This is in Release Blocker right now, but could possibly be a 8.x-3.1 candidate.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | interdiff_9-11.txt | 294 bytes | chrisolof |
| #11 | salesforce-add-soap-client-2799421-11.patch | 7.16 KB | chrisolof |
Comments
Comment #2
chrisolof@aaronbauman Are you thinking the SoapClient service would be provided via an optional "salesforce_soap" sub-module or as a base-level service like the existing RestClient?
Comment #3
aaronbaumanThe more I've looked at this, the more I think a SOAP client would complement, not replace, a REST client.
The bottom line is that they're two different APIs, and they aren't interchangeable.
So, that said, I think it could be both a base service as well as a submodule.
If php-soap is available, SOAP could provide value in 2 different ways:
1) doing things more efficiently, more reliably than REST -- e.g. larger batch sizes
2) providing new things e.g. features, resources, functaionality that REST doesn't do
For my own needs, I haven't actually had need of either of these.
And REST is more simple and easy, so I've not spent any time on this.
I'm happy to discuss further if you have more thoughts
Comment #4
chrisolofOk I'll stick the service into a sub-module. In my project I occasionally need an API resource that is only available through the SOAP API, so simply having a usable SoapClient service would do the trick. I'll try and post a patch here soon.
Comment #5
chrisolofThe attached patch adds a new "Salesforce Soap" module. Enabling Salesforce Soap exposes a new SoapClient (salesforce.soap_client) service, which can be used to access the Salesforce SOAP API resources. I just tested it earlier tonight with success. Let me know what you think!
Wondering if we might want to split the efficiency improvements out into a separate issue. Personally, in my project, I don't need those efficiency improvements, but I do need the SoapClient to get at certain resources not available through the REST API.
Comment #6
aaronbaumanAgreed about opening a separate thread for efficiency improvements.
Minor issue: we might want to go with a forked version of the SOAP toolkit, since the official version is more or less unmaintained.
Have you reviewed any of the open PRs? Might be better off using Message Agency's or another fork where we have commit privs. https://github.com/messageagency/Forcecom-Toolkit-for-PHP
Let me know what you think.
Otherwise, this looks nice and lean and i'm happy to include it.
Comment #7
chrisolofNice! I didn't realize you guys had forked it. Yeah I had to go dev-master for PHP7 support in the official repo - and yes it feels like SF devs aren't really maintaining it anymore. It does, however, work - so there's that.
Would you be able to get messageagency/Forcecom-Toolkit-for-PHP up on packagist and cut a release for it? With that I could update the patch here to bring it in. I think it's probably better if we use a maintained Forcecom-Toolkit-for-PHP.
I also saw uuf6429/force.com-toolkit-for-php, but it could be overkill.
Comment #8
aaronbaumanAdded to packagist: https://packagist.org/packages/messageagency/force.com-toolkit-for-php
Also addded you as a contributor on the github project, in case you end up needing any of those outstanding PRs
Comment #9
chrisolofAwesome. I've updated the patch to pull in messageagency/force.com-toolkit-for-php instead of developerforce/force.com-toolkit-for-php. Let me know if you think this needs anything else.
We could eliminate the "minimum-stability": "dev" line in composer.json if you want to cut a release over in messageagency/Forcecom-Toolkit-for-PHP. Maybe v1.0.0?
Comment #10
aaronbaumanOK, i published v1.0.0 https://github.com/messageagency/Forcecom-Toolkit-for-PHP/releases/tag/v...
I looked through the package again to remind myself how utterly horrific it is, so i'm gonna be working on a 2.x branch which cleans it all up.
Comment #11
chrisolofYeah that's a pretty old and neglected codebase. Good luck in there!
And thanks for tagging the release - the attached patch pulls in messageagency/force.com-toolkit-for-php at 1.x. I'm setting this back to needs-review, but definitely move it back if you're aiming to merge this in with messageagency/force.com-toolkit-for-php 2.x in place.
Comment #13
aaronbaumanCommitted - thanks for your work!