Migration to SharePoint 2010: Part 3 - Integrating the ASP.NET Web Service into a SharePoint page

In my final posting for this 3-part blog, I will detail the simple steps needed to integrate the ASP.NET Web Service we have worked on into your SharePoint site.

1. Open Microsoft SharePoint Designer 2010.
2. Click on Open Site.
3. Under Site name enter the location to the SharePoint site you wish to connect too.  Click Open.
4. Under the quick launch area (located to the left of the screen) expand the Site Objects tab.
5. Click on Data Sources.  The summary area should now show you a list of data sources that are inside SharePoint.  Such as lists, document libraries, etc.
6. Click on SOAP Service Connection in the ribbon, located at the top of the screen.  You will see the following:
   
   
   
   
7. The Service description location is where you will want to put the path to your ASP.NET WSDL.  Should be something like https://localhost/ws-server/MyWebService.asmx?WSDL or whatever you setup.
8. Click on Connect Now or Reconnect.  You should see your other fields light up.

The rest is pretty self-explanatory.  You can edit your parameters by clicking Modify at the bottom of the screen.  Or you can flag them to be set during runtime.  Under the General tab you can place a name and description to your SOAP service.  I didn't experiment with the Login tab, but it sounds simple enough.

To add this Web Service directly to a page in SharePoint do the following:

1. Still remaining in SharePoint Designer, click on the Site Pages option under Site Objects.
2. Add a new ASPX page.  You can add this page by:
1. Click on the drop-down menu for Page from your ribbon at the top of the screen.
2. Select ASPX and rename the file.
3. Right-click on the newly created file from your summary screen.
4. Select Edit File in Advanced Mode from the context menu.
5. You will see some code but, what you are interested in is the code between the <form> tags.  Click and place your cursor between those tags.  Or whatever you have setup on the page to meet your needs.
6. From your ribbon you will want to select the Insert tab.
7. Under the Data Views & Forms category you will want to select Data View.  This will present you with a list of options.
8. Scroll down until you find the SOAP service you created under Data Sources earlier.  If everything is successful, you should see a new DataFormWebPart that contains data fed back from the Web Service you just called.  If you get an error you may need to check your logs to determine why.

And that is it.  You have setup your ASP.NET Web Services server, created a Web Service on that server, added that Web Service to SharePoint, and inserted the Web Service directly into a page on the SharePoint site.

Self-Signed Certificate (SSL), SharePoint Designer 2010, and a SOAP Service Connection... Making it work

If you are here you have probably at some point seen the dreaded message...

"The server returned a non-specific error when trying to get data from the data source.  Check the format and content of your query and try again.  If the problem persists, contact the server administrator."

Maybe even specifically whilst attempting to implement a SOAP Service Connection's data view into your ASPX page.  The SOAP service living on a server with SSL enabled and using a self-signed certificate.

Have no fear.  I am going to explain what leads you to this problem and how to correct it.

While setting up my ASP.NET Web Service I had a need to configure localhost to use SSL.  Once this was done I needed to add the service to SharePoint.  In my case, through the SOAP Service Connection GUI located in SharePoint Designer 2010.

The funny thing with Designer is that it attempts to hit the web service through your local machine, but it validates your SSL on the actual SharePoint site (even if you are pointed to a non-local instance of SharePoint).  It does this because of the DataFormWebPart that is being placed in the page.  This paradox hoses up your ability to test the Web Service if you haven't told SharePoint to trust your certificate.

It is really simple to correct this problem.

1. Export your certificate using the Microsoft Management Console.
1. Make sure you choose DER Encoded Library X.509 (.CER).
2. Open your Central Administration site in SharePoint.
3. Click on the Security heading.
4. Under General Security you will want to select Manage trust.
5. Enter the name of your trust relationship and point to the .CER location.
6. Click OK.
7. You may or may not need to perform an iisreset.

That is it.  Your Web Service should now work, using SSL, and on your local machine.  You may have to fiddle around with your WSDL url in the Data Sources area of SharePoint Designer.  Try https://localhost and https://127.0.0.1 and even try https://yourpcname.  You may also need to include the port (443) on your url.

I hope this helps.

Migration to SharePoint 2010: Part 2 - ASP.NET Web Service

In continuation of Part 1, the decision was made to create a bridge between our third-party web services and SharePoint due to the native SOAP service connector not being compatible with the WSDL format.

To do this I created an ASP.NET Web Service solution in Visual Studio 2010.

1. Open Microsoft Visual Studio 2010 (in this case I used VS Professional).
2. Click on File in the toolbar.
3. Select New Web Site.
4. Pick your poison (Visual Basic or C#).  For purposes of what I was working on, I choose C#.
1. This is where things got interesting.  .NET Framework 4 did not appear to have a ASP.NET Web Service template.  Likely because they expect you to use WCF Service.  I don't know.
5. Switch to .NET Framework  3.5, if necessary, at the top of the window.
6. Click on ASP.NET Web Service from the list of templates.
7. Click on Browse next to your Web location field at the bottom.
8. Select Local IIS located on the left side of the screen.
1. A warning here.  When I did this I received the following message:
   
   
   
   I resolved this error message by enabling the Windows feature.  This is how you can enable in Windows 7:
   
1. Click on your Start icon.
2. Select the Control Panel.
3. Click on the Programs category heading.
4. Click on Turn Windows Features on or off under the Programs and Features category.
5. Branch down in the following order: Internet Information Systems => Web Management Tools => IIS 6 Management Compatibility.
6. Put a check in the box next to IIS Metabase and IIS 6 configuration compatibility.
7. Click OK.  You may or may not have to restart your machine.
9. Click on Default Web Site under your list of local web servers.
10. In my case I needed SSL enabled.  So I selected the option for  Use Secure Sockets Layer. Before you do this though, make sure you have SSL enabled in IIS for localhost.
11. Click on Create New Web Application.  This is a small icon in the top right of the window.
12. Enter the name of your web service.  For example, ConversionWebService.  Then click Open.
13. Click OK.
1. Another warning.  At this point I got the following message: "ASP.NET 2.0 has not been registered on the Web server. You need to manually configure your Web server for ASP.NET 2.0 in order for your site to run correctly, Press F1 for more details."  To correct this problem I had to revisit the control panel to access Windows features.
1. Click on your Start icon.
2. Select the Control Panel.
3. Click on the Programs category heading.
4. Click on Turn Windows Features on or off under the Programs and Features category.
5. Branch down in the following order: Internet Information Systems => World Wide Web Services => Application Development Features.
6. Put a check in the box next to ASP.NET.  This will also automatically place a check next to other options.  Which is fine.
7. Click OK.  You may or may not have to restart your machine.
14. At this point Visual Studio opened up a generic class file called "Service".  Which contains the C# code for managing the Web Service.

Up to this point I have essentially covered creating the Web Service under IIS.  You can modify this default file or create a new web service.  In my case, I started fresh and removed the generic Service.cs and Service.asmx files.  Keep in mind that my situation may be different then your own.  I am attempting to build a web service proxy.

So here are the steps I followed to create the new web service:

1.  In the Solution Explorer pane to the right, right-click your solution name (should look like a URL) and select Add New Item.
2. Select the Web Service template under your Installed Templates language of choice (again, in my case this is C#).
3. In the name field, go ahead and name your Web Service.  If you are building the temperature conversion call (from W3C Schools) you could call the Web Service 'Convert.asmx' minus the single quotes.
4. Place a check in the Place code in separate file box.
5. Click on Add.
6. At this point I deleted the original Service.asmx and Service.cs files since I had no plans on using them.
7. This is where your C# or Visual Basic skills come into play.  The default code includes a Web Service method called HelloWorld().  Include the following code after the HelloWorld() method.  Again, I am doing C#.
   
   

   [System.Web.Services.WebMethod()]
   public double FahrenheitToCelsius(double Fahrenheit)
   {
       return ((Fahrenheit - 32) * 5) / 9;
   }
   
   [System.Web.Services.WebMethod()]
   public double CelsiusToFahrenheit(double Celsius)
   {
       return ((Celsius * 9) / 5) + 32;
   }
   

   
   
8. Save the file.

Now we can and should test the web service to make sure it actually works.

1. In the Solution Explorer pane located to the right, click on your service ASMX file and hit CTRL + F5.  You should see the three operations (CelsiusToFahrenheit, FahrenheitToCelsius, and HelloWorld) at the top of the page that just loaded.
2. Click on CelsiusToFahrenheit.
3. In the Celsius field, enter a value (in this case I entered 37).  Then click on Invoke.
4. If all has gone according to plan, you should see your Fahrenheit value (in my case it was 98.6).

Sweet.  We now have a Web Service.  Since I am building a type of proxy, where one web service calls another, my code looks much different than what is listed above.  But, you can code the web services to match your situation.

In my next post, I will go on to describe how I took my Web Service and integrated it into a page on SharePoint 2010.

Migration to SharePoint 2010: Part 1 - SOAP Service Connection

At work we began the path of changing from a PHP and Java shop into a .NET shop.  Specifically migrating over to use SharePoint 2010 for both internal and external facing websites.  A large undertaking for a company that has traditionally avoided .NET.  In other words, an IT staff that doesn't know the framework at all (including myself!).

Before going any further I should warn you, the reader of this blog post, that at the time of writing this I was the only developer that my company had.  Therefore,  I really had no other team member that I could bounce questions off of in my pursuit to conquer .NET and SharePoint.

I took the initiative to learn as much as I could as quickly as I could.  Training and books on topics such as ASP.NET, C#, SharePoint 2010, Visual Studio 2010, and so on.  All of that training preparing me for the moment where I would be handed that first official .NET related development project.  That time had come...

I was assigned a task to connect SharePoint 2010 to a set of WSDL files using SOAP on another server where our billing software resides.  Essentially with two goals from management with a primary objective of confirming this would even work:

1. Allow a customer to authenticate their account via form submission on a page within SharePoint's publishing portal (public website).  The Web Service should take the username and password, returning a valid or invalid authentication attempt.
2. Expose data through Web Services into SharePoint lists on our internal (intranet) facing SharePoint site.

Whether right or wrong I performed the steps listed below.

The first step I took was to try connecting to these services by using SharePoint's native "SOAP Service Connection" tool under SharePoint Designer's "Data Sources" object.

1. Open Microsoft SharePoint Designer 2010.
2. Click on Open Site.
3. Under Site name enter the location to the SharePoint site you wish to connect too.  Click Open.
4. Under the quick launch area (located to the left of the screen) expand the Site Objects tab.
5. Click on Data Sources.  The summary area should now show you a list of data sources that are inside SharePoint.  Such as lists, document libraries, etc.
6. Click on SOAP Service Connection in the ribbon, located at the top of the screen.  You will see the following:
   
   
   
   
7. The Service description location is where you will want to put the path to your WSDL.
1. A good sample Web Service is http://www.w3schools.com/webservices/tempconvert.asmx?WSDL.
8. Click on Connect Now or Reconnect.  You should see your other fields light up.

The rest is pretty self-explanatory.  You can edit your parameters by clicking Modify at the bottom of the screen.  Or you can flag them to be set during runtime.  Under the General tab you can place a name and description to your SOAP service.  I didn't experiment with the Login tab, but it sounds simple enough.

To test the Web Service and make sure all is well I had to get creative.  Keeping in mind I am new to SharePoint Designer and the such.

1. Still remaining in SharePoint Designer, click on the Site Pages option under Site Objects.
2. Add a new ASPX page.  Call it something like WSTest.aspx or whatever is easy to distinguish it from the rest of your SharePoint site.  You can add this page by:
1. Click on the drop-down menu for Page from your ribbon at the top of the screen.
2. Select ASPX and rename the file.
3. Right-click on the newly created file from your summary screen.
4. Select Edit File in Advanced Mode from the context menu.
5. You will see some code but, what you are interested in is the code between the <form> tags.  Click and place your cursor between those tags.
6. From your ribbon you will want to select the Insert tab.
7. Under the Data Views & Forms category you will want to select Data View.  This will present you with a list of options.
8. Scroll down until you find the SOAP service you created under Data Sources earlier.  If everything is successful, you should see a new DataFormWebPart that contains data fed back from the Web Service you just called.  If you get an error you may need to check your logs to determine why.

This attempt to connect to the third-party WSDL files was a huge flop though despite my best efforts.

The first issue lie in the WSDL files themselves.  The vendor for our billing software was using a RPC style rather than a Document style on their generated WSDL files.  Which isn't supported by the type of service connection we were trying to create.

We worked with the vendor and they upgraded their format to a document format which could be consumed by SharePoint.  Now we are getting somewhere!

Alas, the victory was short lived.  It appeared that the operation names within the WSDL did not match the input names.

<wsdl:message name="sampleMessageName">
    <wsdl:part element="impl:sampleMessageName" name="parameters">
    </wsdl:part>
</wsdl:message>

...

<wsdl:operation name="sampleOperationName">

When SharePoint was looking for "sampleMessageName" to be "sampleOperationName".  The above is a very crude example.  This caused the request packets to be incompatible with what the vendor was looking for.

The vendor gave up trying to resolve this and informed us that their Web Services just won't work with SharePoint the way we were attempting too.  If we wanted it to work we would have to customize each WSDL their tool was generating.  And we would have to do it ourselves after they delivered the WSDL files to us.  They wouldn't do it for us.  In short, we were on our own.

Okay, so back to the drawing board it is.  We wouldn't be able to add a simple "SOAP Service Connection" inside SharePoint Designer.

I decided that I would now attempt to create a "ASP.NET Web Service" project inside Visual Studio 2010 and use that as a bridge between SharePoint 2010 and the incompatible WSDL files.  I would hit my own web services that would in turn send the correctly formatted packet to our vendor's web services.

The details of that project will be included in Part 2 of this Migration to SharePoint 2010 series.  More to come, wish me luck...