function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Suresh_SoftsquareSuresh_Softsquare 

Managed Package involving external system Integration

Hello,

 

We are in the process of building a managed package app to be placed in Appexchange. As per our current implementation, there is a integration piece which involves external system connecting to SFDC web service that we developed through Apex after a callout that we do from SFDC (like a two way integration). 

 

In order to connect to the web service, we need username & password+security_token of the org to authenticate to the web service. The problem is when we build this as a managed package that could be downloaded in any org, we need to get the credentials from the client who installs it in their org. We aren't sure whether requesting this in a package is acceptable. How do we handle this?

 

Anybody have idea on this? How does other composite apps in Appexchange handle the scenarios in which they need to access the SFDC web services API?

 

Thanks in advance,

Suresh.

Best Answer chosen by Admin (Salesforce Developers) 
aalbertaalbert

In the callout, why not pass the session id which can be used by the external system to do the callbacks?

 

I don't recommend requiring the password like that for both security reasons and also, what if the user changes their password? 

 

Or why not setup some kind of oauth flow on the external integration end so you can cache the oauth approval? For example, during the application configuration or setup, the admin grants your external service approval to make the API calls on their behalf. Then the callouts hit your web service and you can use the approved oauth tokens to make the api call backs. 

 

 

All Answers

aalbertaalbert

In the callout, why not pass the session id which can be used by the external system to do the callbacks?

 

I don't recommend requiring the password like that for both security reasons and also, what if the user changes their password? 

 

Or why not setup some kind of oauth flow on the external integration end so you can cache the oauth approval? For example, during the application configuration or setup, the admin grants your external service approval to make the API calls on their behalf. Then the callouts hit your web service and you can use the approved oauth tokens to make the api call backs. 

 

 

This was selected as the best answer
Suresh_SoftsquareSuresh_Softsquare

Thanks albert! I think passing the seession id would be a better option. Actually I have used this session id approach in another project for a different case and I'm wondering why this didn't hit my mind. Anyway now I got it and thanks again for your help.

 

Suresh.