A Step-By-Step Guide
SaaS applications like Salesforce have proven to be highly disruptive for many .NET architectures. In this multi-part blog series, we’ll demonstrate step-by-step how .NET-centric organizations can use existing assets (e.g. legacy .NET applications, SAP) to maximize the value of their Salesforce investment without disrupting underlying code.
Scenario:
In Part 1 of this blog post series we will explore a scenario that has an Auto Insurance company building quotes that allow customers to evaluate their premiums. As part of this process there are some complicated quote calculations that must take place. These calculations take into consideration a customer’s age, driving record, level of education and location. These calculations are proprietary to the organization, provide a competitive advantage and have broad impacts if mistakes are made while building the calculations in the Quote system.
In Part 2 we will implement a Quote to Cash scenario that will allow us to integrate our Salesforce instance with SAP and automate a cross boundary business process that increases productivity.
Citing the need for more agility, the Quoting department has identified the existing Customer Information System (CIS) as a risk to the overall business. The custom CIS is a legacy application that is not flexible and is not accessible from outside the company’s firewall. This creates challenges for agents that are meeting face to face with customers to discuss requirements and is introducing lag to the sales cycle.
The Quoting department has decided to move the CIS functions to Salesforce where the agility and accessibility issues will be eliminated. However, moving the CIS functions to the cloud will create an integration challenge for the Quoting System. Currently the Quoting system leverages the CIS system for customer master data. The team that supports the existing Quoting system does not have any experience integrating with Salesforce nor any real integration expertise.
Replacing the Quoting system at this point in time is not realistic due to the customized business rules and lack of documentation and internal knowledge of the system. In order to address this challenge, a decision has been made to migrate the CIS web services from the custom application to the Mule ESB platform. This will allow the company to take advantage of the capabilities that Salesforce provides while preventing any disruptions to the Quoting system.
The Web Service contracts (or WSDLs) that are provided by the custom CIS system will be moved to Mule ESB where the endpoints will now be hosted. This ultimately means the custom .NET application will not have to be re-coded. Only the Web Service URL needs to be changed within the Quoting system’s configuration.
Instead of using the custom CIS for customer master data, Salesforce will be used. MuleSoft’s Anypoint Connector for Salesforce will allow the Quote system to leverage this master data. By using this connector, the organization can accelerate the development cycles involved in integrating with Salesforce and deliver value to the business faster than it could by developing point to point interfaces from the .NET application or by using BizTalk Server where significant customization would be required.
Build
The following steps will provide a high level walk through of this build process.
-
A WSDL (Web Service Description Language) acts as a contract between a consuming application and a server based web service. It describes the different message types and data structures that will be passed between these two systems. In order to import the existing WSDL into Mule ESB we can copy our existing WSDL from the CIS system to disk so that we can import it into Anypoint Studio or if our WSDL is available via a URL just make a note of it as we can import the WSDL using this method as well.
-
With our WSDL in place we can now create our Mule Project by clicking on File – New – Mule Project from within Anypoint Studio and we will call it InsuranceServiceModernization. For the purpose of this blog post we are going to use Mule ESB 3.5 early access but this also works with the Generally Available version of Mule ESB 3.4.
-
Click the Next button and Finish button in order to create Mule Project.
-
Next, we want to add a Mule Flow to manage our process. We can do so by right mouse clicking on our flows folder and then select New – Mule Flow.
-
We will call the Mule Flow called CreateAccountFlow.
-
We want to expose this Mule Flow through a SOAP endpoint. The first step in this process is to drag an HTTP Endpoint from the palette onto the the Anypoint Studio canvas.
-
In order for the HTTP endpoint to be accessed from a consuming application we need to configure the endpoint to include the Host, Port, and Path.
-
We now need to be able to process the incoming message. In order to do so we need to include the CXF SOAP Component which is available in our palette.
-
We can select this component from our palette and drag it onto our Mule Flow.
-
With our endpoint in place we now want to take advantage of our existing WSDL that obtained from the legacy .NET service. We have the opportunity to import this WSDL so that Mule ESB can support this same contract that our legacy .NET Service provided. In order to import this WSDL we need to click on our CXF SOAP Component and then click on the Generate from WSDL button.
-
We now need to point our Generate from WSDL wizard at the location of our WSDL. In this particular case our WSDL has been stored locally on disk, but we could also point it at a URL if necessary. We also need to provide a Package Name that will be used within all of the Java classes that this wizard will generate.
-
Once the wizard has completed we will discover that our Service Class field has been populated. We need to ensure that the class provided represents our Interface contract and not our implementation class.
-
We will also discover the Generate from WSDL Wizard has created all of our Java classes that represent our Request and Response Objects.
-
Since we are going to call Salesforce we do not need to implement a Web Method within our Java implementation class. Instead we are now going to connect to Salesforce to generate the contract required to interface with the Salesforce API. In order to do this we need to find the Salesforce connector from our palette.
-
We can now drag this connector onto our Mule Flow.
-
In order to populate the the Salesforce request message we need to connect to our Salesforce instance. We can create a connection by clicking on the + button as depicted in the following image.
-
We now need to make a choice in terms of what type of Salesforce connection we would like to make. In this case we will choose the Salesforce connection type. This will allow us to use standard Salesforce credentials. The OAuth Global Type addresses scenarios where users have access to a Salesforce resource for a limited period of time. For the purpose of this blog post using the standard configuration is sufficient. For more information regarding the OAuth Global type please refer to the following documentation.
-
Valid credentials must be provided in order to connect to our Salesforce instance.These credentials include a Username, Password, and Security Token. If you do not have Salesforce credentials you can sign up for a free developer or trial account here.
-
To ensure we have provided the right credentials, we can click the Test Connection button to validate them.
-
After we click the OK button, Mule ESB will connect to Salesforce and generate all of the related meta data from the Salesforce API.
-
We now want to select the type of Operation and the sObject Type. By doing so we are instructing the Salesforce connector to perform a Create operation on the Account sObject. Using this operation will allow us to create a new Account within our Salesforce instance.
-
Next we want to perform a transformation from the SOAP request message that we received from our Quote application and map it into our Salesforce request. To do so, we want to drag our Anypoint DataMapper onto our Mule Flow.
-
Dropping our DataMapper onto our Mule Flow is not enough, we now need to configure it and can do so by double clicking on the shape. We then need to specify the Type of input which in this case is Pojo. We also have to provide the name of our Class that represents our request message. In this case it happens to be com.mulesoft.blogs.Account. Our Output will automatically be configured since Anypoint Studio has determined that we are connecting to Salesforce based upon the configuration of our Salesforce connector. The final action in this step is to click on the Create mapping button.
-
DataMapper will now load and we have the ability to create our detailed mapping from our SOAP request message to our Salesforce request message. DataMapper will automatically derive some mappings and we must create any mappings that are not derived. It is also worth noting that any custom Salesforce attributes that have been configured within our Salesforce system will appear in this mapping as well. For example the DateOfBirth, IsCollegeGraduate and IsUpSell are all custom attributes.
-
With our SOAP request to Salesforce request mapping complete we will now focus on the response mapping. But before doing so we will also include a Logger Component onto our Mule Flow which will give us some additional visibility into the state of our interface. We will also drag another DataMapper onto our canvas. This DataMapper will be responsible for transforming our Salesforce response message into our SOAP response message.
- To configure our DataMapper double click on it. This time around our Input will be from the Salesforce Connector and we will select the create Operation and List<SaveResult> Object. Our Output will be of Type Pojo and our Class will be com.mulesoft.blogs.AccountResponse. Once we have configured this we can click on the Create mappingbutton to complete our configuration.
-
This time around DataMapper has anticipated my mapping and there is no additional mapping that is required. This concludes the configuration of our Mule Application.
Deploy
-
In order to test our new Mule interface we need to deploy it by clicking on Run – Run As – Mule Application.
Testing
-
After we have updated our configuration within our Legacy .NET application we can launch the application and create an Account.
-
If we navigate to Salesforce we will discover that our new Account has been created.
Conclusion
In this blog post we modernized a legacy .NET application without making any disruptive code changes to the application itself. In this particular instance we used an existing Web Service contract, or WSDL, and we imported it into Anypoint Studio. The Anypoint Platform is flexible enough to host this contract allowing the custom Quote application to function without any code changes. All we had to do was update the URL from being the URL of the legacy Customer Information Service and point it to our URL on the Mule platform.
Not only did we move the legacy Web Service from a .NET application to Mule ESB but we also integrated our custom Quoting application with a leading SaaS application; Salesforce. We now have a Quoting Department leveraging an industry leading platform. We demonstrated how easy it was to build this interface and did not need to write any code while building this interface.
We also discovered there are interoperability scenarios that Mule ESB supports with .NET applications. This was demonstrated by taking an existing .NET application and having it consume a Web Service hosted on Mule ESB. Even though Mule ESB is built upon Java, there were no interoperability issues or work-arounds required. Look for additional interoperability scenarios between .NET applications and Anypoint Platform in the near future as MuleSoft is making significant investments in this area.
Stay tuned for the second post in this series where we will implement a Quote to Cash scenario that will allow us to integrate our Salesforce instance with SAP and automate a cross boundary business process that increases productivity.
Delivering SOA, SaaS integration, and APIs on a single platform will facilitate future business opportunity and decrease resistance in integrating new services. This loosely coupled, frictionless architecture is made possible only with MuleSoft’s Anypoint Platform.
Download the free whitepaper to learn how to unlock the value of your .NET architecture with MuleSoft.
