Customer Service and Star Wars: The Old Republic

This morning I wanted to share a Customer Service experience that I recently had with the game development company, BioWare. First a little background information, then the problem, and then I will finish by discussing my Customer Service experience.

I recently pre-ordered and purchased their new MMO (massive multi-player online) game called "Star Wars: The Old Republic". I currently have a subscription that is good until January 19th, 2012. At which point the expectation is to start paying for a monthly fee. I personally subscribed for the six month at a time block. Which is to say, I pay one time and am good for six months of play. As opposed to per month.

Getting back on track... The game released and wasn't exactly clear of software bugs. One, of a particular note, is known as the "Horrid FPS" bug. The games frame rate drops to dramatically low numbers but, only does this in particular areas of the game. Or, when there is a heavy presence of other characters nearby.

Some other people would have you believe that the issue is strictly on the user's computer. "You have a poor machine and it can't handle the game." they might say.  They would also be inclined to throw numbers at you and say "One million people are playing just fine, who cares about the five percent having this problem?".

First, in response to that I would have to say that the problem is not so easily explained away with a simple computer upgrade. Nor can these people give us reports on who has the problem and who does not. For they themselves do not work at BioWare nor have access to BioWare's reports.

I decided that the best course of action was to troubleshoot my own computers (a laptop and a desktop). Both are equally suited for playing the game. Easily surpassing the games relatively low minimum specifications.

Some steps I took are:

1. Updated my drivers on both computers to the most current drivers available (this currently happens to be AMD Catalyst 12.1a Preview drivers).
2. Ensured that the computers were up-to-date on all relative pieces of software (operating system, DirectX, etc).
3. Tweaked the game's client configuration files. In an attempt to lower settings.
4. Modified in-game settings up and down. Just to see if I could get FPS gain from the changes.
5. Utilized the Catalyst software to force certain graphic settings (Anti-aliasing, etc). Again for FPS gain.
6. Attempted to run the swtor.exe application using different compatibility settings. Such as running the game in Windows XP SP3 mode.
7. Ensured game is set as being ran as an administrator.
8. Using Windows services, practically turned down all other applications and settings. To maximize my machine's performance.
9. Through hardware upgrades, increased my machine's RAM (planned on doing this anyway).
10. Overclocked my video card on the desktop machine (do this at your own risk).
11. Installed gaming boost software, such as Rivatuner.
12. Ensured game was forced to run in 3D mode and never drop into 2D mode. To help prevent FPS stutter.

I am sure I am missing some steps I have taken but, needless to say I extensively applied my technical skills to fixing this frame rate issue. But, alas, I was unable to correct the low frame rates. Which was surprising when games such as Neverwinter Nights 2, Guild Wars, World of Warcraft, Call of Duty, etc could all be played with zero frame rate issues. On the highest graphical settings. The graphics in Star Wars: The Old Republic were less then exemplary in comparison to these others.

I then began to monitor my resource usage. And this is when I stumbled upon the problem at its core. I noticed that during frame rate highs (70-100 FPS) the game was utilizing about 75% of my processor, about 50-75% of my RAM, and about 80% of my video card's resources. But, when dropping to frame rate lows (0-5 FPS) the game stayed exactly the same with the exception of my video card resources. The game was only utilizing 20% of my video card.

So this immediately told me what I needed to know. BioWare was not communicating (via my drivers) the correct amount of resources in needed to load upon my video card. And I decided it was time to start looking into reaching out to BioWare's support team.

A spokesperson for BioWare stated the following on January 5th, 2012 at this thread.

Because this FPS issue is so varied, and any number of factors could affect it, it's taking a bit more time to investigate. At the moment, our developers are going over logs and are working on a more detailed blog post that we should be posting soon. Thanks again for your patience!

Which has yet to be blogged at the time of my writing this. I was able to jostle a BioWare spokesperson myself, with the following response on the forums (yes, I hijacked the thread a little bit):

FPS / framerate performance issues are also being looked at. Like the 'Ability Delay' issue, framerate issues are not something that can be solved in a quick and easy way with a single fix. Investigation into the various causes of framerate issues takes time, and solutions may not immediately work for all. Work continues to optimize and improve the game.

Which I immediately replied with:

Look at it from my perspective though. I truly want to subscribe to the 6 month subscription. Which I have (so far). But, if I am being told my FPS issue could take an extended amount of time research to address, why keep my subscription which takes affect January 19th, 2012?

And was told:

Feel free to share your dxdiag and machine specs in this thread - that's where we're collating feedback and having the development team actively monitor to help improve things for players. I assure you it's being looked at. 

My frustration was really high at this point. I did not want a stock / canned response. This took me to the next level. I needed to call someone. So I contacted BioWare on January 6th, 2012 at 1 (855) 467-9867. After navigating the various prompts I reached a person, relatively quickly, calling themselves Mel. This appeared to be an overseas (India?) call center based on the background noise and representatives accent.

Mel asked me for some basic account information before he began discussing my issues with me. He asked if my computer met the minimum game requirements (easily) and if I had tried adjusting the in-game settings (first thing I did). I then detailed other various troubleshooting I had performed on my own. And told him that I pinpointed the issue was the game engine communicating with my drivers.

Mel placed me on hold to go see if there was anything else he could walk me through over the phone. After about five minutes, he returned. Mel told me that he would have to have me email the details of the phone call to him (shouldn't you be writing this down in your call log Mel?) and that he would escalate to the next tier of their support team.

I informed Mel that I did not wish to send in an email and would prefer speaking with a member of this support team myself. I explained to him that I am a software engineer and could easily relate to them the details behind the problem. It was at this point he informed me that he could not transfer me because it was not allowed.

I said "Mel, I know very well that you or your supervisor can transfer my call to the other department. Please put your supervisor on the phone.". With which he told me "Well, let me see if I am allowed to transfer you." and placed me on hold yet again.

It was at this point that I was "allowed" to be transferred to the "Technical Support department". Which I can only guess what department it was that I was currently speaking too.  Now, buckle your seat belts because this is where things get interesting.

The mysterious representative: "Is there something I can help you with?"
Me: "Yes, I am sorry... I didn't catch your name."
The mysterious representative: "(mumble mumble) Can I help you?"
Me: "I'm sorry, I still didn't catch that. Can I have your name please?"
The mysterious representative: "Sir, we don't have names here. Is there something I can help you with."
Me: "Excuse me, you don't have names?"
The mysterious representative: "That's right."
Me: "Okay, I would like your operator number or to speak with your Supervisor please."
*click*

Wow is all I could say (actually I said some other choice phrases out loud). I immediately called back and this time got a Lawrence and what sounded like a completely different call center.

I relayed the entire story to him and he sounded genuinely astonished at the experience thus far. It was Lawrence who provided me with the details that "Yes, there is something incorrect on our side we are trying to address" and "We are having trouble pinpointing the exact problem so it is taking longer then we had hoped to correct".  Lawrence was very apologetic and I told him I would be more then happy to detail the problems via email. As long as he assured me it reached the development team. Lawrence assured me it would.

I then sent a very detailed email to their team via reply to a generated email to myself (thanks Lawrence).

And to this day, I have not heard back.

All in all, this is one of the rougher game start ups I have seen. And the Customer Service is a bit lacking, to say the least. My recommendation to anyone considering buying this game is to wait. And to read the game's forums (you can do this publicly) until some of the dust clears.

While an excellent game, some of these finer points are actually hurting the game. I will post a follow up when I have something to follow up with.

Making your Apache Web Server more secure

I just wanted to post a few tips that you can use on your Apache 2.2 web server to help make your server a little more secure.  This isn't a list of every security measure you can take but, just a few tips.

One of the first things you should do to secure your Apache installation is to configure Apache file permissions.  This will help mitigate access to primary systems if someone is able to hack into your server through Apache. You can do this by performing the following steps (there are a few, fair warning):

1. After Apache Web server has been installed open the "Computer Management" console by doing the following:
1. Click on "Start"
2. Go to "Administrative Tools"
3. Click on "Computer Management"
2. In the "Computer Management" window, expand the "Local Users and Groups" section.  Click on "Users" to see a list of the current users for your system.
3. Right-click on "Users" and select the "New User" option.
4. Enter the following information for the new user:
1. User name
1. apacheservice
2. Password
1. adminpw123 <put something secure here>
3. Confirm Password
1. adminpw123 <reminder, change this to something secure>
4. Clear the "User must change password" check box
5. Select the "User cannot change password" check box
6. Select the "Password never expires" check box
5. Click the "Create" button and then click "Close" to close the "New User" dialog.
6. Right-click the "apacheservice" user you just created and select "Properties". Click the "Member Of" tab.
7. Make sure the "apacheservice" user is a "Member Of" the "Users" group.  Click "Cancel" to close the properties window.
8. Exit out of the "Computer Management" console.
9. Open the "Services" console by doing the following:
1. Click on "Start"
2. Go to "Administrative Tools"
3. Click on "Services"
10. Right-click the "Apache2" service and select "Stop".
11. Open Windows Explorer (not Internet Explorer) and navigate to the following:
1. C:\Program Files\Apache Software Foundation\Apache2.2
12. Right-click the "Apache2.2" folder, select "Properties" and then select the "Security" tab.
13. Make sure that only READ and EXECUTE permissions are granted to the Users group.
14. No changes should be necessary so just click "Cancel".
15. Using Windows Explorer, review the permissions for the following:
1. C:\Program Files\Apache Software Foundation\Apache2.2\logs
16. Now, we do want to change permissions on the "logs" directory.  To do that do the following:
1. In the logs Properties dialog's Security tab, click the "Advanced" button.
2. Clear the "Allow inheritable permissions from the parent" check box.
3. Click "Remove" in the security window.
4. Select the "Replace permissions on all child objects" check box and click the "Add" button.
5. In the "Enter the object name to select" field, type the username "administrator" and click OK.
6. Under "Allow", select the check box for "Full Control" and click OK.
7. Click the "Add" button again and in the "Enter the object name to select" field, type the username "apacheservice" and click OK.
8. Select the following check boxes under Allow:
1. List Folder/Read Data
2. Read Attributes
3. Read Extended Attributes
4. Create Files/Write Data
5. Create Folder/Append Data
6. Write Attributes
7. Write Extended Attributes
8. Read Permissions
9. Click OK when done.
17. Click OK to close the "Advanced Security Settings" window and again, click OK when asked to continue.
18. If you check permissions for the "apacheservice" user in the logs Properties dialog's Security tab, you will find we should now have read / write access only.
19. Click OK to exit out of the logs Properties window.
20. Now view the security permissions of your web root.  By default, this is the "htdocs" folder found under your Apache2.2 installation.
21. Click the "Advanced" button under the "Security" tab.
22. In the "Advanced Security Settings" dialog, clear the "Allow inheritable permissions from the parent" check box.
23. Click "Copy" in the security window.
24. Click the OK button to dismiss the Advanced Security Settings.
25. Select the "Users" group and click Remove.
26. Select the "SYSTEM" group and click Remove.
27. Click the Add button and in the "Enter the object name to select" field type the username "apacheservice" and click OK.
28. In the "Permissions for apacheservice" section, change the permission to Allow Read and Deny Write. Clear any other check box that may be selected.
29. Click OK to close "WebRootFolder Properties" and click Yes when asked to continue.
1. Those last steps will ensure that the "apacheservice" user will only ever be able to read, never write, to the root Web document folder.
30. Switch back to the Services console, or open it again by select Start -> Administrative Tools -> Services.
31. Right-click the "Apache2" service and select "Properties".
32. In the properties window, select the "Log On" tab and perform the following steps:
1. Select the "This account" radio button and type the user name "apacheservice".
2. Enter the password and confirm the password for the account.
3. Click the "Apply" button.
1. You should see a message indicating the account has been granted the "Log On As A Service" right.  This is fine, click OK to dismiss.
4. Click OK to close the Apache2 properties window.
5. Right-click the "Apache2" service in the Services console and select "Start".
1. If you see an error when restarting Apache, then there is a problem with the permissions of the apacheservice user.  Verify your steps by checking permissions (see the instructions leading up to this step).
33. The last step is simple... When the server comes back up just surf to the URL and ensure it is working.

Now, lets add a few tweaks to our server config file. In the "httpd.conf" file that is located in the "conf" directory of your server you can add the following:

#
# Controls who can get stuff from this server.
#
<Limit GET HEAD POST>
    order deny,allow
    allow from {%}
    deny from all
</Limit>

This configuration is added under your <Directory> for your document root. Replace the {%} token above with any IP address or IP block.  For example you can use the site County IP Blocks to generate a block of IP addresses only from a particular country (such as the USA).  Anyone coming from an IP address not in your block would be denied access.  Or you can do the following...

allow from 127.0.0.1

...to ensure only local access to the Web server.

#
# Limit to POST and GET commands only.
#
<LimitExcept POST GET>
    Require valid-user
</LimitExcept>

This should also be added under your <Directory> root. This configuration will prevent other un-secure commands from being accessed by a user.  POST and GET are really all you should be allowing on your Web server anyway.

#
# Hide server details from the HTTP response header
#
ServerSignature off
ServerTokens prod

This configuration (added at the end of your conf file) hides detailed server information from your HTTP response headers (such as Apache version) from potential attackers.  Attackers use information like that to coordinate attacks on your server.

And, of course you should always follow the security tips provided by Apache.  Those can be located here:

http://httpd.apache.org/docs/2.2/misc/security_tips.html

I hope some of these tips can help you to make sure your Web Server is more secure.  I will likely post more in the future and will also try to include application servers (Tomcat) and even IIS.

Add custom controls to SharePoint Designer 2010

Haven't posted in a week or so.  So decided it was time to add something.  Lots of idea bouncing while I have been attending a training course on SharePoint Designer.

A question came up during class which was, "How do I add custom controls into SharePoint Designer that I can drag-and-drop like the controls already there?  For example, the ASP.NET controls.".

Here is the answer...

You will need to first copy your DLL and namespace to the SafeControls section of the 'web.config' file.  This will make your control available to SharePoint Designer.  However, an extra step is needed to make the control visible inside the GUI.

You will need to add an attribute to your class file.  Just above your class definition.  The attribute is:

[ToolboxData("<{0}:SomeNewControl runat=\"server\" />"), ToolboxItemFilter("Foo")]

Again, this goes above your class definition.  That is it.  You should now see your custom control inside SharePoint Designer under 'Server Controls'.  And it should work just like the others (drag-and-drop).

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.

How to enable SSL on IIS 7.0 for localhost

As a developer I have a need to do  this thing called development.  And for me to develop solutions that will one day live on a SSL enabled website, it just makes sense to enable SSL for localhost.

This walk through will hopefully get someone using IIS 7.0 up and running with SSL.  And IIS 7.0 makes this very easy to do.

1. Make sure you have IIS 7.0 installed.
2. Click on Start from your desktop.
3. Hover over Administrative Tools.  This will present you with some additional options.
4. Click on Internet Information Services (IIS) Manager.
5. Under the IIS category, double-click on Server Certificates.
6. Under the Actions pane on the right-hand side of the screen, click on Create Self-Signed Certificate.
7. Enter a "friendly name" for the certificate request.  In this case I used 'Localhost' minus the single quotes.  Since I was aiming for https://localhost as my URL.
8. In the Connections window to the left expand (if not already) in the follow order: Local Computer Name => Sites.
9. Under Sites heading (in the left pane still) click on Default Web Site.
10. On the right-side window pane select Bindings.
11. In the Site Bindings window click Add.
12. Set the following fields accordingly:
1. Type => https
2. IP Address => All Unassigned
3. Port => 443
4. Host name => 
5. SSL certificate => Localhost (or whatever you named it)
13. Click OK and Close to return to the management screen.
14. You should now see Browse *:443 (https) in the far right window pane.  Click on it to verify that the binding worked.
1. You may be warned that it is an "untrusted connection" or a "phishing attempt".  This is just your browser not liking a self-signed certificate.  You can ignore it.  Add https://localhost into your trusted sites to avoid it in the future.

That is it.  You have now enabled SSL on localhost for IIS 7.0!

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...