4

Unlike MetadataAPI the ToolingAPI APEX class still refers to version 30. Please note this question is not about ToolingAPI itself, but about the APEX wrapper class project to make ToolingAPI available for native apps from within APEX. In order to use it for Lightning components, it would be great to update this to the current version 32.

Are there any plans to do so in the near future? Are there any major challenges to overcome on the way to this update? Are you looking for contributors / maintainers in order to do so?

I will start to look into it on my own. There are some mandatory changes and just setting TOOLING_API_URI to '/services/data/v32.0/tooling' is not enough to make the old functionality work. Also I'll update my question here with any further conclusions.

Also for version v30 I have a couple of recommendations for patches I've done so far. I started to use it at v29 and needed to make some small changes:

  • to update ApexPages, I patched class ApexPageMember (details and github-issue)
  • to update ApexComponents, I patched class ApexComponentMember (same issue as for ApexPages)
  • to update Trigges, I patched class ApexTrigger (changed type for tableEnumOrId from Id to String)
  • to retrieve syntax information about constructors, I patched class SymbolTable (changed type for constructors from Symbol[] to Constructor[])

In parallel to this question, I'll try my best to provide my suggestions also as issues on github.

Any insights on the future of ToolingAPI.cls are appreciated.

11
  • 1
    Maybe you should file an issue on that github repo. You can do that here: github.com/afawcett/apex-toolingapi/issues. You could then reference this question, if you'd like one of the contributors to that project to comment here.
    – pchittum
    Dec 1 '14 at 0:03
  • 1
    Did so already github.com/afawcett/apex-toolingapi/issues/20 - so far I made good progress with patching and I'll provide my working version to anyone who's interested.
    – Uwe Heim
    Dec 1 '14 at 1:53
  • 1
    @AndrewFawcett : for me MetadataAPI works fine (but very slow) for Lightning. But I found a super fast approach using PATCH ToolingAPI calls via JavaScript as described here: salesforce.stackexchange.com/questions/57616/… - I'm going to provide examples and a tutorial for it on my blog. In the meantime I can provide code snippets or insights to anyone on request. As Doug Chasman said in the link above, they did something really different and I would say the result is lightning fast! :-)
    – Uwe Heim
    Dec 4 '14 at 14:27
  • 1
    My team is investigating the issue that @AndrewFawcett has run into. I was not the dev that grabbed the case/bug from the queue but I am checking with him now on status/progress etc. I suspect this is usage error but nothing jumped out at me and the error he is getting is not very helpful. Dec 4 '14 at 20:13
  • 1
    OK - no progress on this one so I have just grabbed it and am starting to dig now. Dec 4 '14 at 20:21
1

I have created a GitHub issue to track the update to API 32.0, but am of course open to contributions if some progress has already been started. :-)

Background to process of updating it. Myself and co-author James Loghry chose to go the REST API wrapping route originally, because the WSDL contains so much polymorphic types the Apex to WSDL tool doesn't support. However the implication of this decision is its not as quick to upgrade as the Apex Metadata API (which although still needs some tweaking currently does not need no where near the same amount the generated Tooling class would need).

Thoughts on switching to SOAP as part of the upgrade... Basically the approach we took originally and may take again to upgrade now is to leverage the fact that the types that do get generated from the WSDL to Apex process are similar enough to the JSON structures to act as a starting point to be pasted into ToolingAPI.cls and stripped from some of the XML metadata data. That said, i am interested in if we could revisit using the SOAP version of the Tooling API, by leveraging the fact that Apex to WSDL is now open source and we can potentially fix the issue that prevented us using the SOAP API in the first place. Also we've discovered that the REST API is not bulkified, so you end up using a lot more API calls.

2
  • 1
    I had here salesforce.stackexchange.com/questions/57534/… a longer discussion with @DanielBallinger. He provided there a ToolingAPI.cls created with his FuseIT (more the SOAP approach). I mixed that manually with your old v30 and the resulting Mixup did even work for me, at least somehow. I really like the REST style. So if maintainable, I would prefer it over SOAP. But since we have no PATCH in APEX, the fastest methods may be not usable - at all. And there again comes JavaScript with PATCH...
    – Uwe Heim
    Dec 4 '14 at 19:41
  • re: Making a PATCH call form Apex, does applying ?_HttpMethod=PATCH to the Tooling API REST endpoint not work then? Dec 4 '14 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.