Wednesday, January 17, 2007 7:12 AM
Thomas E. Canter
Connecting SalesForce notifications WebServices to BizTalk Server 2006 – Blog Entry
At a recent client, the Salesforce developer (Doug Auerbach of Avanade) pointed out that the newest release (What's New in Apex Web Services API Winter '07) has the capability for Salesforce to call external WebServices with Notification messages. You can wire up a large range of events using various rules and use them to generate custom WSDL that, when exposed by your application, Salesforce will call with the data object specified. Tim Dutcher, the Technical Director at Acetta, agreed to pursue the possibility of using this new functionality.
In BizTalk Server 2006, we approached the solution from the viewpoint of exposing a BizTalk Orchestration as a WebService that consumed the WSDL generated by the Salesforce wizard. The WebService is a two-way send-receive port. The initiating event is a notificationsRequest ,and then we respond with a notificationsResponse message. The notificationsRequest is a sample api (not a real world sample) that contains two objects:
Id – the ID of the sent object
sObject – a repeating xml:Any node that contains a node of the types specified in the Salesforce wizard as a generic sObject and a RecordTypeId that specifies the type of the incoming object.
After the WSDL was in place, I created a simple Orchestration that received the Notification message and returned the response message consisting of a simple XML boolean flag (Ack) indicating success or failure.
We pointed the Salesforce engine at the exposed WebService and immediately got an error response in the Salesforce outbound message queue:
Server did not recognize the value of HTTP Header SOAPAction (URL).
Inspection of the WebService that was provided by Salesforce indicated that the SOAPAction property was set to "", an empty string.
After some searching for the error message Tim Dutcher found a web site (there are many) that told us to add the following attribute to the WebService Class:
[SoapDocumentServiceAttribute(RoutingStyle=SoapServiceRoutingStyle.RequestElement)]
After appending this attribute to the existing attribute list, we were able to complete a round trip communication between BizTalk and Salesforce.