Salesforce 不同的 WSDL 文件以及何时使用
我正在开发一个 salesforce 功能，我们试图将自定义类中的单个 Web 服务方法公开给“合作伙伴”，以便他们可以生成潜在客户。
该类/方法已经创建/测试并且按预期运行，因此我们正在致力于实现。
我一直在仔细研究 Salesforce 的所有 Web 服务文档和菜谱，但我看到的所有内容都只讨论使用企业或合作伙伴 WSDL 文件，这将使他们获得比我认为应该需要的更多访问权限。
如果我导入从类本身生成的 WSDL 文件，我可以访问这些方法，但我似乎找不到任何登录方法（使用它们的示例作为参考）。
我这里有两个基本问题。
- 我真的需要授予对我的实例的完全访问权限才能公开单个方法吗？
- 我需要提供的最低限度是什么？
I am working on a salesforce feature, where we are trying to expose a single web Service method in a custom class to a "Partner" so they can generate leads.
The class/method has been created/tested and functions as expects, so we are working on implementation.
I have been poring over all of Salesforce's Web Service documentation and cookbook recipes, but everything I see only talks about using either the Enterprise or Partner WSDL files, which would give them more access then I believe should be required.
If I import the WSDL file that is generated off the class itself, I have access to the methods, but I can't seem to find any way to log in (using their examples as reference).
I have 2 basic questions here.
- Do I really need to give full access to my instance to expose a single method?
- What is the bare minimum I need to provide?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
WSDL 本身只是 Web 服务的定义，并不控制对您组织的实际访问。要访问您的组织，对 Web 服务的每个请求中必须包含会话 ID。会话 ID 与您组织中的给定用户绑定，因此您还可以通过为他们提供自己的个人资料并仅锁定他们需要访问的内容来控制他们可以访问的内容。配置文件与对象/字段相关，而不是 Web 服务本身，请考虑它们需要访问哪些数据，因为它们始终可以使用同一会话来访问其他 Web 服务。配置文件上还有 Apex 类级访问控制，但这并不能阻止他们通过 SOAP API 执行相同的数据操作，因此请确保他们的配置文件仅公开他们需要访问的内容，并且将强制执行到处。
至于获取会话 ID，这在某种程度上取决于您与它们的交互方式以及它们的应用程序是什么样的。一般来说，推荐的方法是使用 OAuth（在 Salesforce 帮助中称为“远程访问”），这使得用户名和密码不必在应用程序中使用，而是在最后直接发送到 Salesforce用户。根据应用程序的不同，有几种不同的流程可供选择，并在帮助中进行了说明。 REST API 文档对使用 OAuth 获取会话 ID（OAuth 中的“令牌”）。说到 REST，您甚至可以考虑使用新的 Apex REST API，它允许您从 Apex 制作类似的自定义 Web 服务，但具有 REST 接口。
合作伙伴和企业 API 也有一个 login() 方法，该方法很方便，因为它也是基于 SOAP 的，但由于应用程序必须直接处理用户名和密码而失去青睐。如果您选择此选项，您将使用合作伙伴和企业 API 登录，获取会话 ID，然后切换到您的自定义 Web 服务。因此，是的，对于此选项，您必须使用您的 WSDL 以及合作伙伴或企业 WSDL，并且忽略其他方法，但同样，这些方法只是存在并不意味着它们可以访问它们（例如，如果您删除从给定对象类型的配置文件中删除，他们将无法使用 delete() 方法）。
The WSDL itself is just a definition of the web service and does not control actual access to your org. To get access to your org, a session id must be included in each request to the web service. Session ids are tied to a given user in your org, so you can also control what they can access by giving them their own profile and locking down access to only what they need to get to. The profiles are associated with objects/fields, not the web services themselves, think about what they will need to access in terms of data, because they could always use that same session to access other web services. There are also Apex class-level access controls on the profile, but this doesn't stop them from doing the same data operations through the SOAP APIs, so make sure you have their profile only expose what they need access to and that will be enforced everywhere.
As far as obtaining the session id, it somewhat depends on how you are interfacing with them and what their application is like. In general, the recommended way is to use OAuth (called "Remote Access" in Salesforce Help), which will make it so usernames and passwords don't have to be used in their application, but are rather sent directly to Salesforce by the end user. There are a few different flows to choose from depending on the app and are explained in Help. The REST API doc has a nice intro to using OAuht to get the session id (aka "token" in OAuth). Speaking of REST, you might even consider using the new Apex REST API, which allows you to make similar custom web services from Apex, but with REST interfaces.
The Partner and Enterprise APIs also have a login() method, which is convenient since it is also SOAP-based, but is losing favor because the app has to directly handle the username and password. If you do this option, you would login with either the Partner and Enterprise API, get the session id, and then switch over to your custom web service. So, yes, for this option you would have to consume both your WSDL and either the Partner or Enterprise WSDL, and just ignore the other methods, but again, the methods just being there does not mean they can access them (e.g. if you remove Delete from their profile for a given object type, they would not be able to use the delete() method for it).
您提供的内容和他们可以执行的操作是两件独立的事情，如果您为他们提供用户凭据，那么无论他们使用哪种 WSDL，他们都可以执行用户可以执行的任何操作。因此，您需要创建一个具有受限权限的用户，该用户拥有执行您想要执行的操作的最低权限。
一旦您掌握了这些，您向他们提供企业、合作伙伴还是自定义 WSDL 就不再重要了。
如果您为他们提供 apex 类 WSDL，那么他们将需要某种登录方式，可以从合作伙伴 WSDL、OAuth2 流之一或者 Webtab 或自定义链接登录。 （取决于具体场景）。
最后，您是否见过 web2lead 功能，该功能允许在您的 Salesforce 帐户中创建潜在客户，而无需 WSDL 或凭据。
What you provide, and what they can do are 2 separate things, if you give them a users credentials, then they can do anything the user can do regardless of which WSDL they use. So you'll want to create a user with restricted permissions that has the bare minimum rights to do what you want.
Once you've got that, it doesn't matter if you give them the enterprise, partner or a custom WSDL.
If you give them the apex class WSDL, then they'll need some way to login, which could be login from the partner WSDL, one of the OAuth2 flows, or a webtab or custom link. (depending on the exact scenario).
Finally, have you seen the web2lead feature, that allows for leads to be created in your salesforce account without needing a WSDL or credentials.