I need to access the Enterprise WSDL using the Salesforce API in my Java app. Can anybody help with this?
Salesforce WSDLs are only available in the Salesforce UI, not through the API. You can get them at:
Setup | Develop | API
If you find that need to get the Enterprise WSDL at runtime because your application needs to work with different sets of objects and fields, you should probably be using the Partner WSDL instead. It will allow you to get all the object and field descriptions at runtime and make dynamic API calls. There a little more work upfront, but results in a more flexible and resilient application. When the objects and fields change in the future, your application will continue to work without re-consuming the WSDL.
The WSDL is not available through the Salesforce API (to my knowledge). However, it is available through a REST call if you have the right information. First, you need a session token, generated through either an OAuth handshake or a username/password+security token handshake. You also need the name of the Apex class from which you generated the WSDL. With those two things, you can perform a GET. See the following pseudo-code for the requisite GET structure.
GET https://<SANDBOX_INSTANCE_URL>/services/wsdl/class/<APEX_WSDL_CLASS_NAME>?isdtp=p1
Headers:
'Cookie' : 'sid=<SESSION_TOKEN>'
EDIT:
I verified that this works with both Enterprise/Partner WSDLs and WSDLs generated from custom Apex classes.
You can use the following generic URLs for these WSDLs, as of v41.0:
Partner: https://<SANDBOX_INSTANCE_URL>/soap/wsdl.jsp
Apex: https://<SANDBOX_INSTANCE_URL>/services/wsdl/apex
Metadata: https://<SANDBOX_INSTANCE_URL>/services/wsdl/metadata
Tooling: https://<SANDBOX_INSTANCE_URL>/services/wsdl/tooling
Tooling (Enums): https://<SANDBOX_INSTANCE_URL>/services/wsdl/tooling?enumStyle=ALL_STRONG
Related
Can anybody tell me where can I see a documentation for the sharepoint rest api ? I would like to see documentation like swagger has e.g. endpoints + dto objects. I need to make an integration with sharepoint to have CRUD functional for files. On Microsoft I see an articls that describe how to use it, but can`t find concrete list with endpoints and data tansfer objects.
Here the official Microsoft documentation : SharePoint REST service,
Please read all the part in the left navigation :
Bonus : Also, if you are a beginner and you want to start with SP API, I recommend you to use SP Insider extention, it is a free SharePoint Discovery tool for Developers. It allows you to explore the endpoint in an intuitive way and build your Query easily.
Cordially.
In order to integrate the WSO2 BPMN with an external application, I want to make an API call to get all the Package Name or Claimable Task from the WSO2 BPMN. Currently there is no documented ways to make such calls.
When I used the fiddler, to capture the actions from the WSO2 web pages, I see the call made as
https://XX.XX.XX.XX:9443/bpmn-explorer/claimableTask?pagination=1
where the response is entire HTML page but not just the data.
Can some one please explain to me if it's possible to achieve this and where can I find further information regarding this.
If you are creating your own external web application or any other client application, you can use BPMN REST API provided with WSO2 BPS you can get information and do any updates for BPMN processes using it. Please follow [1] for more details.
[1] https://docs.wso2.com/display/BPS350/BPMN+REST+API
Thanks,
Mili
I am about to build a CRM application in CakePHP. The CRM will require an API for other applications to extract the data.
Applications that are not on the same server will obviously access this via some sort of API caller object that makes an HTTP request to the CRM.
As I understand it, the HTTP request time will increase to the overall load time. For applications on the same server is it possible/is it common practice to access the API by some other means. i.e. including the controller and using the actions ... (im not even sure if this would work as the framework wouldn't be bootstrapped right?). By doing this I am looking to: 1) Reduce load times. 2) Return data as PHP arrays instead of json/xml objects.
In order to return HTTP responses then you need some kind of HTTP server, API's are designed for exactly the reason that you are describing above - they allow multiple applications to access the data in a database by creating an interface to it in a way that can be controlled and standardised.
If you design your API well, have it return JSON objects then the average response shouldn't be a problem as you will only be returning a small amount of text.
Getting a PHP array from a JSON object is as simple as json_decode($json_object, true);
If you are using CakePHP to create an API you should look at using the awesome CRUD plugin by Friends of Cake
Hi
I am currently working on an application which is implementing salesforce.com REST api. I have done all the authentication part and received all the info needed. Now I want my application to push the leads into the customer's account. But the lead fields can be customized and different customer use their different custom fields, so any1 can suggest me how to add that custom field in my form which will be pushed to the customer's salesforce account.
Thanks
You can use the describe resource in the REST API to obtain the metadata about the Load object, including all the fields.
https://{someinstance}.salesforce.com/services/data/v20.0/sobjects/lead/describe
You can use the list of fields to drive your form, and to control what you subsequently POST to /services/data/v20.0/sobjects/lead to create the new lead.
Here's the link to the REST API pilot docs incase you haven't seen them
No idea if the REST API supports describe() calls, they're a way of querying for all metadata about table (columns, their types etc). In normal webservice API this info can be found at http://www.salesforce.com/us/developer/docs/api/index_Left.htm#StartTopic=Content/sforce_api_calls_describesobject.htm#topic-title
the Metadata REST API was put on hold by Salesforce, so there is no REST API for Metadata (there is some limited support in the Tooling REST API, but not enough to create an object).
https://salesforce.stackexchange.com/questions/20763/creating-a-custom-object-using-rest-api
What things should a developer designing and implementing an API for a community based website know before starting the heavy coding? There are a bunch of APIs out there like Twitter API, Facebook API, Flickr API, etc which are all good examples. But how would you build your own API?
What technologies would you use? I think it's a good idea to use REST-like interface so that the API is accessible from different platforms/clients/browsers/command line tools (like curl). Am I right? I know that all the principles of web development should be met like caching, availability, scalability, security, protection against potential DOS attacks, validation, etc. And when it comes to APIs some of the most important things are backward compatibility and documentation. Am I missing something?
On the other hand, thinking from user's point of view (I mean the developer who is going to use your API), what would you look for in an API? Good documentation? Lots of code samples?
This question was inspired by Joel Coehoorn's question "What should a developer know before building a public web site?".
This question is a community wiki, so I hope you will help me put in one place all the things that should be addressed when building an API for a community based website.
If you really want to define a REST api, then do the following:
forget all technology issues other than HTTP and media types.
Identify the major use cases where a client will interact with the API
Write client code that perform those "use cases" against a hypothetical HTTP server. The only information that client should start with is the response from a GET request to the root API url. The client should identify the media-type of the response from the HTTP content-type header and it should parse the response. That response should contain links to other resources that allow the client to perform all of the APIs required operations.
When creating a REST api it is easier to think of it as a "user interface" for a machine rather than exposing an object model or process model. Imagine the machine navigating the api programmatically by retrieving a response, following a link, processing the response and following the next link. The client should never construct a URL based on its knowledge of how the server organizes resources.
How those links are formatted and identified is critical. The most important decision you will make in defining a REST API is your choice of media types. You either need to find standard ways of representing that link information (think Atom, microformats, atom link-relations, Html5 link relations) or if you have specialized needs and you don't need really wide reach to many clients, then you could create your own media-types.
Document how those media types are structured and what links/link-relations they may contain. Specific information about media types is critical to the client. Having a server return Content-Type:application/xml is useless to a client if it wants to do anything more than parse the response. The client cannot know what is contained in a response of type application/xml. Some people do believe you can use XML schema to define this but there are several disadvantages to this and it violates the REST "self-descriptive message" constraint.
Remember that what the URL looks like has absolutely no bearing on how the client should operate. The only exception to this, is that a media type may specify the use of templated URIs and may define parameters of those templates. The structure of the URL will become significant when it comes to choosing a server side framework. The server controls the URL structure, the client should not care. However, do not let the server side framework dictate how the client interacts with the API and be very cautious about choosing a framework that requires you to change your API. HTTP should be the only constraint regarding the client/server interaction.