Salesforce Services (8 Part Series)
Welcome to Part 3 of my Salesforce Outbound Messages Series! In this tutorial I am going to teach you how to add more fields to your Outbound Message and Web Service for cases where you've built out your connection and realize you actually needed more fields than your original WSDL contained. This is important because we used svcutil to replace the contents of our Interface class with that of our Salesforce WSDL instead of importing it within Visual Studio. This means we have no Web or Service Reference and must update our Interface class manually and thankfully this isn't too difficult.
At this point I'm going to assume that you have an Outbound Message set up in Salesforce, a .NET WCF Web Service that compiles, and a "True" Ack notificationsResponse when you connect with them using a PutsReq bucket.
The first step is updating Salesforce with your new fields. Navigate to your Salesforce Outbound Message, click Edit, and add the fields you need from the Available Fields. Click Save when you've finished.
Use the link to generate a new WSDL (you don't need to save it). You should now see your new fields with the original AccountId element, you will want to note whether they are nillable and what their type is because we will be using these values in our service.
Open your Web Service project and add the new fields to your Interface class where partial class Quote inherits from sObject. It will look something like the code below:
Create or use an existing PutsReq bucket for your Outbound Message endpoint URL, then create a new Quote in Salesforce. Remember to update the Order XML field if your Workflow Rule checks for changes in this field! The Outbound Message will still fail, as we do not have a real connection, but PutsReq will give us the POST Soap Envelope which we can use in one of two ways:
- Paste the entire Soap Envelope into a SOAP UI Request and click Submit
- Paste each field from the Soap Envelope into your Web Service WCF Test Client
Whichever method you choose, you should receive a True Ack notificationsResponse for Salesforce to be happy.
The final step in this process is the most individualized - you will need to get your Web Service online and make it accessible from outside of your organization's security and firewall. You must also build the functionality into your Web Service to use and manipulate the fields you've passed in depending on what you use them for. There will not be a Part 4 covering this portion; I leave this endeavor up to your own curiosity. Happy coding!