I did a search for salesforce.com and came back with nothing. What am I missing? People must use webMethods to integrate with salesforce.com, right?
Hello,
Yemi Bedu
Chris,
Assuming that the Salesforce API used web services, you could take the first steps, but generating Web Services Connectors from the WSDL files provided by the vendor.
After getting something up and working using Web Services Connectors, I prefer to modify them to read things like endpoint addresses and login credentials from properties files or database tables and to attempt the pub.client:soapHTTP invoke inside of a retry loop for better fault tolerance.
Depending on the service levels of the SF server, you might first publish the soap message to the broker and create a separate service to attempt to send it to the SF server. That way, you have two levels of retry, one inside the Flow and another controlled by the trigger.
The good news is that no application adapters are needed to connect to SalesForce.com.
Mark
Thanks for the good info. I have the enterprise WSDL from salesforce.com. From this, I can create the web service connectors. These allow me to log in, get a session id, and do all of the activities I need in order to integrate.
The problem I am facing is that the CRUD methods take a very loosely-type object as their input. The foundation for these types is a salesforce SObject. The business objects extend the SObject. For example, the basic building block for sf.com is an Account.
The WSDL describes what an Account is. When I pull the WSDL into Developer to create the web service connectors, the document that represents Account is nowhere to be found.
I can create an ad-hoc Account in Developer, but that doesn’t seem right to me.
What am I missing here?
Not sure why the web services connector is not generating doc types from the WSDL.
If you open the WSDL, you will see one or more embedded schemas describing inputs and outputs. The definition for the Account element should be there. You can manually extract the schema to your file system and create document types from that.
One other thought, some WSDL files import schema definitions. If the one for SF.com does that, make sure you have it in the same location as your WSDL (or in the schemaLocation it is looking for).
HTH,
Mark
There is an import statement in the WSDL with no schemaLocation attribute. Because of this, XML Spy complains when the WSDL is validated.
Thanks for the info, Mark.
Ahhhh. Is it working OK now?
Not yet, but I am learning a lot about XML. I am trying to figure out the best way to resolve this.
I can open the WSDL w/ XML Spy, and from it, I can edit the schemas. Spy warns that namespaces are defined by imports that do not have corresponding prefixes, and offers to create them. After answering yes to have them created, XML Spy says that the schemaLocation is missing and will be ignored.
If I had this schema, and I put it in the same folder as my WSDL, this wouldn’t be a problem.
You’ll have to obtain the schema before you can either use the web services connector to generate Flow to invoke the web service (WSDL2Flow) or to create the document types correctly so that you can write your own Flow to do so.
In essence, the WSDL is not complete unless the publisher provides all of the referenced types.
Mark
I am having the same issues as Chris. Has anybody successfully used the update API to update an Account? If so, how?
Try SiebelOnDemand. I got their web services up and running in a matter of minutes.
But seriously, you have to address the fact that there isn’t enough information in their WSDL to create the business objects (like Account, AccountContactRole, AccountShare, Asset, …) in webMethods Developer.
Well, if the SF.com WSDL imports an XML schema that defines these objects, then I would argue that as long as they provide the schema, then they have provided “enough information in their WSDL”.
If you don’t have all of the imported schemas then you don’t have the complete WSDL and you can not proceed.
Mark
I agree with your argument, Mark.
Looks like Salesforce.com requires you to generate the WSDL file using an administrative function which can be found by logging into your Salesforce.com account (or free developer account) and navigating to Setup->CustomForce->Integrate-WSDL Generator. This function allows you to generate a WSDL file specific to your organization and includes custom fields your company may have added (or deleted).
The AppExchangeAPI Quick Start docs cover the steps required to do this. Once you have your WSDL you would generate IS web services connectors (FLOWs) from that WSDL.
Chris, was this how you obtained your WSDL? Did it generate the schemas that were referenced in the WSDL as imports?
Mark
Yes, this is how I obtained my WSDL. Salesforce.com did not provide the schemas referenced in the WSDL.
The “enterprise.wsdl” generated by the development server defines three different schemas in the “types” section.
Each of these schemas has a namespace and two of them import the definitions of one of the other schemas. The third schema which defines the enumerations of error types for the fault messages does not appear to depend on the other two.
These three schemas can be extracted, as I’m guessing you have done, into individual XSD files. The first two must use import statements to reference each other.
These XSD files can be imported as Integration Server schemas and used to create document types for the Salesforce.com operations that you need to support.
IS will generate document types when creating web service connectors, but will not generate the doc types (or mapping statements) to create header elements and add them to the soap request.
I was able to generate a web services connector from the enterprise.wsdl file. I could run the login service with no changes, but had to create a document type to be used to build the SessionHeader document to hold the sessionId returned by the login service. This SessionHeader doc must be added as a soap header in subsequent service calls.
You must also use the URL retuned by the login message as the endpoint address in subsequent calls. Once I figured that out, I had the getServerTimestamp service up and running in no time.
The Salesforce.com development server could process the login request and subsequent getServerTimestamp request in 2-4 seconds on average. I’m sure this would be a bit longer for servers with production-level data volumns and transaction loads.
BTW, the attached XML file contains a valid getServerTimestamp request showing the SessionHeader soap header containing the sessionId. The sessionId and endpoint address are two of the parameters returned by the login request.
Mark
(Message edited by admin on December 20, 2005)
Simon Fell, of PocketSoap fame, blogged recently about the impact of enabling various performance tuning recommendations when using the Salesforce.Com web services API.
The biggest impact was relating to enabling GZip compression on the https request/response.
Simon used PocketSoap to creat a simple utility for assessing the impact of these tuning suggestions called sforceExporter. sforceExporter connects to a sforce server (including the server that is accessible with a free developer account) and exports the contents of one of the sforce object types. It has command line switches to disable the keepalive, readahead and gzip compression options as well as to configure the batch size.
Read Simon’s blog post on this topic here
Mark
Hi Roger,
I am facing the same problem… not able to update Account. Could you please share the solution? I get the message " Destination URL not reset. The URL returned from login must be set in the SforceService".
Any idea what to do with the serverUrl/endpoint addresses ?
Regards,
Sandesh Tak
Hi Mark
I am also trying to integrate with salesforce.com. Can you please guide me in the process. I found the following posting from you.
How exactly you added the session ID and serverurl to the soap header. Can you attach a sample
Thanks
[FONT=Arial]The “enterprise.wsdl” generated by the development server defines three different schemas in the “types” section. [/font]
Each of these schemas has a namespace and two of them import the definitions of one of the other schemas. The third schema which defines the enumerations of error types for the fault messages does not appear to depend on the other two.
These three schemas can be extracted, as I’m guessing you have done, into individual XSD files. The first two must use import statements to reference each other.
These XSD files can be imported as Integration Server schemas and used to create document types for the Salesforce.com operations that you need to support.
IS will generate document types when creating web service connectors, but will not generate the doc types (or mapping statements) to create header elements and add them to the soap request.
I was able to generate a web services connector from the enterprise.wsdl file. I could run the login service with no changes, but had to create a document type to be used to build the SessionHeader document to hold the sessionId returned by the login service. This SessionHeader doc must be added as a soap header in subsequent service calls.
You must also use the URL retuned by the login message as the endpoint address in subsequent calls. Once I figured that out, I had the getServerTimestamp service up and running in no time.
The Salesforce.com development server could process the login request and subsequent getServerTimestamp request in 2-4 seconds on average. I’m sure this would be a bit longer for servers with production-level data volumns and transaction loads.
[I]BTW, the attached XML file contains a valid getServerTimestamp request showing the SessionHeader soap header containing the sessionId. The sessionId and endpoint address are two of the parameters returned by the login request.
[/i]
You need to create a document type matching the structure of the SessionHeader element. You can do this manually by creating a new doc type from scratch or by creating the doc type from a XSD extracted from the SF.Com WSDL.
Once you have a document type, populate it in a MAP step with the sessionID and URL returned from the login operation. Then convert it to a node and add it to the soap request using pub.soap.utils:addHeaderEntry.
I don’t have any examples and will not be creating any. This should get you started.
HTH,
Mark