In this post I would like to continue, where I left of in Part I where a did a run down in setting up an account at SalesForce, building a service and how to consume its WSDL. Also explained some security details necessary for communication with your SalesForce service. In an orchestration you can consume a web service build in SalesForce, through running BizTalk WCF Service Consuming Wizard. If you run the wizard and pick WDSL generated for your service BizTalk will generate schema and binding file for you. Schema en binding file shown below.
Binding file will be helpful in creating WCF-Custom send port. I have built an orchestration that consumes my created SalesForce web service. The orchestration is initiated (activated) by picking up a file form a folder location. Xml file contains account name I want to retrieve details from SalesForce. Information in the file will be used to call the service and response message is sent to MSMQ.
In MessageAssign shape code from ForceToken is called to obtain sessionId:
I have created a Windows Application to read message from the queue. Request message looks like this:
Response from web service using the request above will result in message containing it to queue.
I have created a windows application (test application) to read the message from the queue.
I can directly call my SalesForce service through .net (GetDetails), read from queue and write to queue. In .Net you are able to create proxy code from WSDL, through same steps as explained in part I (through adding a web reference).
Above you will find code used to test service.
One side note I would like to mention now is that if logins to SalesForce fail a couple of times you will be temporarily locked out of salesforce.com due to failed login attempts. So if forgot your password, that you have to ask for new one (I do not know how long your are locked out). Then take into account that your security token is tied to your password and subject to any password policies your administrators have configured. Whenever your password is reset, your security token is also reset. In first part you will see how. During writing of this post I was locked out.
If I try to get details from an account I click GetDetails, which in this case only returns website from the account.
If I click ReadFromQueue I will get complete response from the web service.
Code for ReadFromQueue:
I have created another web service on SalesForce in which I can update annual revenue for account.
I followed basically same procedure as for first web service created in SalesForce. I generated the WSDL, saved it to file and through BizTalk WCF Service Consuming Wizard I got schema and binding file. I created a new orchestration that reads files from MSMQ with new annual revenue information to be updated.
In my test application I can change to annual revenue from 1000 to 2000 and then click SendToQueue.
I change value inside my test app textbox including messagetype that has to be returned.
If I look at my account details now I see they changed.
With binding files generated by BizTalk you can import these inside your application through BizTalk Administrator console so that WCF-Custom send ports are generated for you.
If you right click on one of these generated port and click properties and then configure you will see details.
Action is filled in and URI and if you go to the net tab the binding then you also noticed that is filled in.
As you can see integration with SalesForce through web services is pretty straight forward. In coming posts I would like to share different implementations using same sample and dive into logging and support.
Labels: BizTalk, BizTalk Server 2009, SalesForce