In the blog Introducing Microsoft ASP.NET WebHooks Preview, we gave an overview of how to work with Microsoft ASP.NET WebHooks. Out of the box we provide support for a variety of existing WebHooks providers such as Dropbox, GitHub, MailChimp, PayPal, Slack, Trello, and many more.
Salesforce does not support classic WebHooks, but they do have a concept called Outbound Soap Messages which shares many of the same characteristics. As a result, it is possible to receive these messages using ASP.NET WebHooks which we will describe here. To support receiving Outbound Soap Messages you need to install the Microsoft.AspNet.WebHooks.Receivers.Salesforce Nuget package into your Web Application but more about that later.
Configuring Outbound Soap Messages
In order to setup Outbound Soap Messages you need a Salesforce developer account. Then login to Salesforce.com and select Setup at the top of the page:
Then you select Build | Create | Workflow and Approvals | Outbound Messages.
Here you may see an Understanding Workflow page, which you can read if desired, and then continue to the Outbound Message page where you select New Outbound Message:
Here you pick an object such as Lead and then you fill in the required information. Just like described in the blog Introducing Microsoft ASP.NET WebHooks Preview the URI must be public and have the form https://<host>/api/webhooks/incoming/sfsoap. If you check Send Session ID, then the outbound message will contain a session ID which can be used for subsequent calls back to Salesforce. Lastly you pick the message fields you want in the notification.
Now we have defined a message – next we have to define a workflow rule which uses the message. Select Build | Create | Workflow and Approvals | Workflow Rules. Here you may again see the Understanding Workflow page, and after that you select New Rule:
Fill in the required fields, for example like below, and save:
Finally, it’s important to check that the rule is marked as Active:
Configuring Receiver
The next step is to configure the WebHook receiver. First make sure you install the Microsoft.AspNet.WebHooks.Receivers.Salesforce Nuget package into your ASP.NET application. Then the registration happens exactly like in the blog Introducing Microsoft ASP.NET WebHooks Preview by adding line 21 to the WebApiConfig.Register method:
1:using System.Web.Http;
2:
3:namespace WebHookReceivers
4: {
5:publicstaticclass WebApiConfig
6: {
7:publicstaticvoid Register(HttpConfiguration config)
8: {
9:// Web API configuration and services
10:
11:// Web API routes
12: config.MapHttpAttributeRoutes();
13:
14: config.Routes.MapHttpRoute(
15: name: "DefaultApi",
16: routeTemplate: "api/{controller}/{id}",
17: defaults: new { id = RouteParameter.Optional }
18: );
19:
20:// Load Salesforce receiver
21: config.InitializeReceiveSalesforceWebHooks();
22: }
23: }
24: }
Set the MS_WebHookReceiverSecret_SalesforceSoap application setting to the value of your Organizational ID which you can find on the Setup page under Administer | Company Profile | Company Information:
As stated in the blog Introducing Microsoft ASP.NET WebHooks Preview, the preferred way to do this is to set it in the Azure Portal:
Defining a Handler
Let’s define a handler that can process the incoming message from Salesforce – something like this will do:
1:publicclass SalesforceHandler : WebHookHandler
2: {
3:publicoverride Task ExecuteAsync(string receiver, WebHookHandlerContext context)
4: {
5: SalesforceNotifications nots = context.GetDataOrDefault<SalesforceNotifications>();
6:string sessionId = notifications.SessionId;
7:string company = notifications.Notifications.First()["Company"];
8:return Task.FromResult(true);
9: }
10: }
Trying it Out
After deploying your Web Application, we are now ready to try it out. Do this by creating a new Lead as follows: Go to the Leads menu and select New:
Then fill in the entry picking values that match the filter you set up for the Lead rule earlier and then hit Save.
When running with the debugger attached you should see something like this:
The session ID is available for subsequent calls and you can inspect the data from the notification (or multiple notifications) as well.
Finally, you can optionally inspect the delivery status of the messages by going to Build | Create | Workflow and Approvals | Outbound Messages and then select View Message Delivery Status. It should give you an overview of which messages were delivered:
That’s it – have fun!
Henrik