This document takes you the steps of creating your first Web services call to SalesForce.com using the SOAP Agent.
Author: Rebecca Dias, Jennifer Jinhong
Last Update:  8/14/2013

1. If you don't already have one, create a SalesForce Account
Create yourself a SalesForce Development environment:
Go to: http://developer.force.com/ and click on Join Now
Note: Make sure you use a username that is different than your Automic login to our production environment.

2. Generate a WSDL specific to the SalesForce environment you are communicating to.
If you want to build a generic solution, you would need to use the partner wsdl.
Note: You only require the client side certificate for REST based call

Note: For application release scenarios, you will need to use the metadata WSDL

3. Turn on the Customer Portal, Activate the Portal and Add users to the Share Group: Note the activation takes a while so don't be surprised if it does not work right away.
From the left hand Nav click on Customize -> Customer Portal -> Settings

Once activated it should like:

The user permissions to the Portal need to include any account whose token you will use for Web service communication I just added all users to make my life easy. Likely in a production environment there will be a dedicated user for the external application.

4. Skip this step unless your are using the MetaData API
We don't actually need these IDs because we ignore the headers.  I only leave this here because the documentation is confusing and will send you on a wild goose chase.  It looks like this was required at some point in time and then removed the need for it but did not clean up the WSDL or the documentation.

4a. Finding the company profile info: Click on your profile name then Setup. Then on the left hand nav expand company profile and select company information 

4b.  Find the Customer Portal ID  (Note: This no longer appears to be needed)

4c. Convert the Company ID And Customer Portal ID
      The company ID and customer portal ID need to be converted before sending in the SOAP request
      https://cloudjedi-developer-edition.ap1.force.com/SalesforceIdConverter
      NOTE: IE Does not work well with this converter form, use Chrome

5. Setup your connection object

5a. Get your token. Generally it is emailed to you.  

5b. Use Basic Authentication to obfuscate your password.

Your password should be a your login password + your security token.

6. Build your Login Job
6a. Under Argument 1 (note this is actually a header)
Put your username in the username field e.g. {user}
	Put your password in the password field e.g. {password}

6b. In the request Object remove the Headers

From the following forum thread we don't need the header
http://boards.developerforce.com/t5/General-Development/INVALID-LOGIN/td-p/191765

We want to make sure the soap request is not sending the headers marked in red:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ ">
  <soapenv:Header>
    <ns1:LoginScopeHeader soapenv:mustUnderstand="0" xmlns:ns1="urn:enterprise.soap.sforce.com">
      <ns1:organizationId>00DG0000000gBNxMAM</ns1:organizationId>
      <ns1:portalId>060G0000000UN2oIAG</ns1:portalId>
    </ns1:LoginScopeHeader>
  </soapenv:Header>
  <soapenv:Body>
    <ns1:login xmlns:ns1="urn:enterprise.soap.sforce.com">
      <ns1:username> rebecca.dias@automic.com</ns1:username >
      <ns1:password>password</ns1:password>
    </ns1:login>
  </soapenv:Body>
</soapenv:Envelope>

to do this we pass &&null for the corresponding header value:

Reference the following thread: SOAP Headers magically appear... can we remove them?

6c. Pull the response value for the serverUrl and and Session ID for use in subsequent calls. Note, the duration of the session ID is something you can configure in your SalesForce environment. 

	
6. In any subsequent call e.g. query from the enterprise WSDL or any CRUD call from the metadata wsdl, you need to use the session ID from the login call in step 5.  To use the value from the previous call, make a workflow and have login be the first call of that workflow or setup a schedule and create global variables and reestablish that session based on the session timeout set.

6a. When you are part of a larger workflow, don’t forget to set ‘Generate at runtime’ so that the value is evaluated when the job starts, not when the workflow starts:

6b. When using the Enterprise WSDL, override the Service URI based on the response from the login object.
In the job definition for a subsequent call use &serverurl#

And the Session ID in the corresponding header: