Integrating CRM with ERP/Financial systems can be a challenge. Particularly if the systems are from 2 different vendors, which is often the case when using Salesforce.com CRM.

At Facebook, we've gone through several iterations of integrating Salesforce with Oracle Financials and the team has arrived at a fairly stable and reliable integration process (kudos to Kumar, Suresh, Gopal, Trevor, and Sunil for making this all work).

Here is the basic flow (see diagram below):

1) The point at which Salesforce CRM needs to pass information to Oracle is typically once an Opportunity has been closed/won and an order or contract has been signed.

2) Salesforce is configured to send an outbound message containing the Opportunity ID to an enterprise service bus (ESB) that is configured to listen for specific SOAP messages from Salesforce.

3) The ESB accepts the outbound message (now technically an inbound message on the receiver side) and asserts any needed security policies, such as whitelist trusting the source of the message.

4) This is the interesting part. Because the Salesforce outbound message wizard only allows for the exporting of fields on a single object, the ESB must call back to retrieve additional information about the order; such as the Opportunity line items, Account, and Contacts associated with the Order.

In Enterprise Application Integration (EAI) speak, this is referred to as a Content Enrichment pattern.

5) An apex web service on Salesforce receives the enrichment request, queries all the additional order details, and returns a canonical XML message back to the ESB.

6) The ESB receives the enriched message and begins processing validation and de-duplication rules, then transforms the message into an object that can be consumed by Oracle.

7) The ESB then inserts the Order into Oracle.

8) The Oracle apps API inserts/updates the various physical tables for the order and throws any exceptions.

• Apple XCode Developer Tools
• JAWS Framework (GitHub download)
• Force.com IDE
• jQuery Mobile (optional)
  

• Initial deployments of new custom applications are much easier using Change Sets
• Incremental deployments are more easily managed using Ant

• Some metadata simply is not packageable via Ant, therefore Change Sets must be used
• The dependency checker in the Change Set packager, while not 100% perfect, is much more reliable than manually adding 100+ individual components
• In the absence of an IT-Engineer who can create Ant packages, business process owners and non-technical users always have the fallback option of using change sets
• Prior to Spring '11, invalid inbound change sets could not be deleted, resulting in an accumulation of cruft
• The ability to delete deployed change sets in Spring '11 removes the ability to audit change history (a compliance violation)
• The ephemeral nature of some sandboxes means constantly re-establishing deployment connections.

1. Continuous Integration - Support daily deployments
2. Minimalism - Incrementally deploy only what is needed, and nothing more
3. Reliability - Changes should be 100% backwards compatible and not break existing functionality

• Start the refresh of a sandbox named "staging"
• Package a release using Eclipse
• Create an ant package and validate the deployment against the staging sandbox
• Deploy the changes to production

~/Documents/workspace/changes/ant-salesforce.jar
~/Documents/workspace/changes/sforce.properties

# sforce.properties
#

# =================== Sandbox Org Credentials ===============
sandbox.username	= user@domain.com.staging
sandbox.password	= password
sandbox.url			= https://test.salesforce.com

# =================== Package Deployment Credentials ================
deploy.username		= user@domain.com
deploy.password		= password
deploy.url			= https://login.salesforce.com

# Use 'https://login.salesforce.com' for production or developer edition (the default if not specified).
# Use 'https://test.salesforce.com for sandbox.

mkdir ~/Documents/workspace/changes/CHG12345
cp -r ~/Documents/workspace/CHG12345/src ~/Documents/workspace/changes/CHG12345

<project name="Salesforce Package Deployment Script" default="usage" basedir="." xmlns:sf="antlib:com.salesforce">
	<property file="../sforce.properties"/>

	<target name="usage">
		<echo>Usage: ant [task]
Task options:
ant validate: Simulates a deployment of the package and returns pass/fail debugging information
ant deploy: Deploys the package items defined in package/package.xml
ant undeploy: Rolls back deployed items (must follow ant deploy)
	</target>
	
	<target name="validate">
		<sf:deploy 
			username="${sandbox.username}" 
			password="${sandbox.password}" 
			serverurl="${sandbox.url}" 
			deployRoot="src" 
			logType="Detail" 
			checkOnly="true"
			runAllTests="true"
			pollWaitMillis="10000"
			maxPoll="200" />
	</target>
	
	<target name="deploy">
		<sf:deploy 
			username="${deploy.username}" 
			password="${deploy.password}" 
			serverurl="${deploy.url}" 
			deployRoot="src"
			pollWaitMillis="10000" 
			maxPoll="200">
		</sf:deploy>
	</target>
	
	<target name="undeploy">
		<sf:deploy username="${deploy.username}" password="${deploy.password}" serverurl="${deploy.url}" deployRoot="src"/>
	</target>
</project>

• Notice that the environment variables are pulled in from sforce.properties in the parent directory.
• The "validate" target uses a sandbox for testing the deployment
• Winter '11 introduced the ability to refresh dev and config sandboxes daily. Validating a deployment against a recently refreshed sandbox will identify any potential production deployments upfront
• The "deploy" target uses the production credentials
• "undeploy" must be run immediately after a "deploy" to work. Undeploy has some quarky requirements and is not always known to work as expected

cd ~/Documents/workspace/changes/CHG12345
ant validate
ant deploy