Here's a rundown of my Salesforce Connect setup:

FIRST I was able to set up a Named Credential, using password authentication

  • API Name: MyAPI
  • URL: https://myapi:50000/b1/v2

SECOND I then created an External Data Source that leverages the above:

  • URL: callout:MyAPI
  • Format: JSON
  • Server Driven Pagination: checked

Salesforce successfully presents to me a Validate and Sync screen (a listing of my external system entities) - I'm imagining in order to render the choices on the screen, Salesforce must have somehow called out the the /$metadata endpoint, parsed the XML response (from this screen SF makes External Object definitions for whichever items I check-marked)

THIRD I can see the external objects that Salesforce creates. These look fully fleshed out with lots of fields defined, so I'm feeling good.

FOURTH I create a new Tab for one of my custom objects (i.e. External Objects) so I select my new Orders external object

FIFTH When I navigate to my new custom tab, choose to 'View all', it spins and spins eventually errors out

When I do some apex debugging, I can see that whatever SF apex logic is doing.. it tries to interact with my org, but it is NOT first going to my /Login endpoint. My external system, when I read it's docs, requires that you first get 'cookied' by visiting the /Login endpoint with a POST operation - from there it will respond with a Set-cookie header

I know how to make all this work with hand-rolled APEX code, but shouldn't this work with SF Connect? Or must I use a Custom Adapter for Salesforce?

To reiterate my problem, the debug logs show

  • attempt authenticate at: GET https://myapi:50000/b1/v2
  • then it correctly calls: GET https://myapi:50000/b1/v2/Orders?$count=true

But I need it to...

  • attempt authenticate at: POST https://myapi:50000/b1/v2/Login
  • and use cookied calls at: GET https://myapi:50000/b1/v2/Orders?$count=true

1 Answer 1

  1. I found a Andy Chiarelli's Reverse Proxy example in the form of dotnet WebAPI which I find familar to work with
  2. I pulled it down from his github and customized it to do the work of hiding my undesirable API complexity
  3. I now have a successful implementation which detects the GET request from Salesforce (which, if responding to the credential challenge, would also have a Basic Auth header), and transforms it into a POST request to /Login endpoint
    • Note in this screenshot, there is no “/Login” path shown in the initial request (address bar)
    • Nevertheless we see it delivered the cookie'd JSON response as if I had screenshot of my proxy in action

You must log in to answer this question.

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