Using the ApexCSIAPI that backs to Force.com Console to pull data

Question

When the Force.com/Developer Console is open and checking for updates I can see it polling the server with Ajax POST calls to https://instance.salesforce.com/_ui/common/apex/debug/ApexCSIAPI.

Has anyone examined these requests and the corresponding responses (JSON?) to see if they can pull data or perform actions that aren't otherwise available via the official APIs? I'm interested in any documentation or examples of calling it from code.

One of the important post back parameters is "action".

E.g.

1. action: POLL seems to be used for checking for new log messages and is passed with a number of alreadyFetched parameters with Log Ids (key prefix 07L) that have already been loaded.
2. action: COMPILE with a bodies parameter containing JSON for the class id (key prefix 01p) and apex body.

I'm aware that if this isn't documented anywhere officially it wouldn't be considered supported and Salesforce would be free to change it as they please and make breaking changes.

Answer 1

The goal is to completely move the Developer Console over to the Tooling API. There have been a lot of updates to the Tooling API since the last answer on this question, so here is some updated information to help with debugging and compiling on the platform.

Poll:

---

Instead of using the ApexCSIAPI, use the Tooling API to query for the information you want.

For example, assuming you are using javascript and have a query method, something like the following will work to check for updated information.

var records = query("SELECT Id, StartTime from ApexLog ORDER BY StartTime DESC");
var time = records[0].StartTime;
//Poll every 2 seconds for new logs
setInterval(function() {
    records = query("SELECT Id, StartTime from ApexLog WHERE StartTime > "+time+" ORDER BY StartTime DESC");
    if (records.length > 0) {
        //Do something with the new logs
        ...
        //Set the new time for polling
        time = records[0].StartTime;
    }
}, 2000);

Even better, you can also use the Streaming API instead!!! Just use the system topic "/systemTopic/Logging".

For example, using CometD: http://www.salesforce.com/us/developer/docs/api_streaming/

comentd.subscribe("/systemTopic/Logging", function(data) { 
    // do something with the log id
});

Compile:

---

Now you can compile with the Tooling API as well by using container members (this is what the developer console uses now). There are some code examples at http://www.salesforce.com/us/developer/docs/api_toolingpre/api_tooling.pdf

There is also a system topic for container members, so you don't need to poll for them: "system/ContainerDeployStateChange".

Other:

---

You can also execute anonymous in the Tooling API.

The few things that the Developer Console is still using the ApexCSIAPI for is parsed log artifacts and related entity information. These most likely will be moved over at some point in the future.

Is there anything else I missed? Let me know in a comment and I will update this answer.

Answer 2

We are working on making a publicly available tooling API for accomplishing these kinds of tasks.

The ApexCSIAPI does not have an architecture that makes it suitable for public consumption because it lacks an infrastructure for versioning. This is not an issue for the developer console, since its always served out of the same version as the ApexCSIAPI version it consumes, but those building their own tools will naturally want to use an API that uses our extant conventions for insuring their code won't break when we kick out a new release.

We are incrementally transitioning from the ApexCSIAPI to the public tooling API over the course of the next few releases: eventually this ApexCSIAPI will disappear entirely.

Answer 3

I have been building a new force ide and initially tried to use ApexCSIAPI from a visualforce page to carry out IDE related actions with no luck. I've been told this API may be publicly available in the future.

Alternatively you can actually compile Apex from Apex by getting the Apex WSDL (setup->develop->APIs->Apex WSDL) and generating Apex from it.

Answer 4

So the poller is the first step, when you click on a particular log item it will generate multiple requests to SF

https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870820&log=LOGID&extent=steps&page=1&start=0&limit=25 https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870834&log=LOGID&extent=sourceLines&page=1&start=0&limit=25 https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870851&log=LOGID&extent=methods&page=1&start=0&limit=25 https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870852&log=LOGID&extent=frames&page=1&start=0&limit=25 https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870853&log=LOGID&extent=heap&page=1&start=0&limit=25 https://cs9.salesforce.com/servlet/debug/apex/ApexCSIJsonServlet?_dc=1345208870854&log=LOGID&extent=statics&page=1&start=0&limit=25

these all return json, which you can parse and represent however you want. notice that it breaks down into the following sections:

• steps
• sourceLines
• methods
• heap
• frames
• statics

Also there is an offset, so paging is probably required as well for larger logs.

The _dc attribute is something extjs generates to make requests unique and is pretty much irrelevant.