5

I've been able to use this Metadata API built on APEX platform: https://github.com/financialforcedev/apex-mdapi

But it is working if I install this into the org, and user log into the org. WHat I want is to access the API using force.com Site, in which I pass on the session id via URL and session ID is readable from parameters and the metadata listing works for that outside org.

I've modified the MetadataService.cls file and make sure that Session ID is "not" UserInfo.getSessionId(), but is passed into the CreateService Function as input parameter and wherever I call CreateService I pass on the session ID from page parameters.

Earlier I was getting this particular error on the Visualforce Page exposed on Sites:

System.CalloutException: Web service callout failed: WebService returned a SOAP Fault: UNKNOWN_EXCEPTION: Site under construction faultcode=UNKNOWN_EXCEPTION faultactor=

To resolve this, I edited the Service Endpoint to the instance url of the Org whose SessionId I'm passing in this page.

But I'm receiving this error now:

WebService returned a SOAP Fault: INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session faultcode=sf:INVALID_SESSION_ID faultactor=

Does anyone know a way to make this Metadata API work on public sites?

Improve this question
2
  • 1
    Can you post the Apex Debug Log for your page, it should contain the SOAP request being made to the Metadata API endpoint, so that we can confirm the Session ID is being passed.
    – Andrew Fawcett
    Commented Sep 6, 2013 at 7:57
  • Thanks Andrew, could you post this up as answer :-), I'll mark it one. Actually it is not exactly an answer but it did pointed me to right direction. After tiring efforts of mine, I actually went in to do the dumb thing to Not to check if at all the sessId is being passed into the metadataService controller class, it was the cause, I debugged and knew the cause, I was passing the sessionId to Page but not the service controller instance, once I did the correction it worked from Sites page as well :-).
    – VarunC
    Commented Sep 7, 2013 at 8:10

1 Answer 1

Reset to default
6

It is always worth checking the Apex Debug log when making callouts, to confirm visually the SOAP XML request (which the platform dumps to the log) is passing what you expect from your code. Enable the Apex Debug Log and check the session Id is being passed correctly.

A debug log can record database operations, system processes, and errors that occur when executing a transaction or running unit tests. Debug logs can contain information about: Database changes HTTP callouts Apex errors Resources used by Apex Automated workflow processes, such as: Workflow rules Assignment rules Approval processes Validation rules

Improve this answer
2
  • Agree. I totally keep a check on debug logs, but the fact that it is hard to run debug logs for a Public site since there is no User to log debug for, it didn't stuck me :-), but then after you comment I got to run my page directly within org after login and ran a debug on that user to find out the fault. Thanks for pointing out :-) ...
    – VarunC
    Commented Sep 7, 2013 at 14:08
  • 1
    you can run debug logs for public sites salesforce.stackexchange.com/questions/1149/…
    – Shane McLaughlin
    Commented Nov 26, 2013 at 23:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .