Mike
Tips, tricks and solutions for software developers.
 

WCF Web Services & iOS - Part 5 - Deployment

By Mike Gledhill

Pages:

So, we now have a collection of WCF Web Services for Creating, Reading, Updating and Deleting records in our Northwind database.

http://localhost:15021/Service1.svc/createCustomer
http://localhost:15021/Service1.svc/getAllCustomers
http://localhost:15021/Service1.svc/getOrdersForCustomer/ANATR
http://localhost:15021/Service1.svc/updateOrderAddress
http://localhost:15021/Service1.svc/deleteCustomer/ALFKI

I've been promising that I'd show you how to call these services from an iOS application, but before we can do that, we need to deploy our WCF Web Service and SQL Server database, somewhere externally ("in the cloud") so that our iOS app can access it.

If we tried to start writing iOS code now, it'd fail miserably as your iPhone or iPad would have no idea where to find the service called:

http://localhost:15021/Service1.svc

Deploying to IIS

If you're writing web services for use just within your company, deployment should be very straightforward. You might just be able to deploy your SQL Server database and WCF Services onto some "live" server in your company's data center, and make sure your iOS device has access to your company's network (so it can find your servers.)

For the rest of us, we need to choose a hosting service which supports Microsoft SQL Server and WCF Services, and deploy to it.

Deployment

For a long time, this tutorial suggested using GoDaddy or one of the other web-hosting services.
But, things have moved on, and now, there's one simple web-hosting recommendation I'd make: use Microsft Azure.
Why ?

  • It's fast.
  • It's much cheaper than using one of the other services (previously, I was paying GoDaddy an annual fee per website that I'd deployed. Now, I just pay Azure for the total disc space and resources that I use, and its much cheaper).
  • It's brilliantly integrated with Visual Studio.
    You can create your website in the Manage Azure website, download a "Publish Profile" file to your PC, then, in Visual Studio, import this in the Publish screen, and have all the settings needed to deploy your web services to Azure.

I get zero commission for recommending Azure, but the way Microsoft has implemented it, and the ease-of-use and flexibility makes it a no-brainer.
Go and sign up for a free Azure account, and see what you're missing.

Troubleshooting

Microsoft has made life a lot easier for us developers in the past few years, but deployment is an area where things can (and usually will) still go wrong.

So what should you do if you deploy your services, but you get an error when you try to use them ?
There are two things you need to check:

  1. Are the web services alive-and-kicking, once they've been deployed to Azure ?
  2. Are the web services able to talk to your SQL Server database ?


1. Are your web services alive ?

Let's start with the first one. Do you remember how, when you asked Visual Studio to create your JSONWebService project, it added a default "getData" service for you ?
If you hit problems with your WCF Web Services once they has been deployed, this is actually a really useful service to test with. It's an easy way to test that the "non-database" web services are alive and kicking, and once you've done this, you can test one of your other web services, which do access your SQL Server database.

For example, when I deployed my iNorthwind web services to Azure, I tested that my web services were working by opening this URL:

http://inorthwind.azurewebsites.net/Service1.svc/getData/13

Yup, this URL did correctly return some valid JSON, so I now knew that my web services were alive and kicking.


2. Can your web services talk to your database ?

Next, I would test one of the web services which returned data from my database, to check that my web services are able to talk to my SQL Server database:

http://inorthwind.azurewebsites.net/Service1.svc/getAllCustomers

If you click on the hyperlink above, you'll see that this web service does work fine.
But if, at this point, you found that your web services didn't work for you, here's how you would troubleshoot this.

Do you remember how I taught you how to use try..catch and get your web services to return a useful error message when something goes wrong ?
Well, this is when that advice becomes a lifesaver.

Open up Google Chrome, hit F12 to open the Developer panel, open the Console tab, then try to open the web services URL again, and see if an error message is being returned.

And straightaway, there's the cause: The server was not found or was not accessible.
In other words, your web services aren't able to find/contact the SQL Server whose name you've specified in your web.config file.

This is a very common problem, and here's the most likely causes:

  • Your web service's web.config has a connection string, pointing to a localhost SQL Server machine
  • Your connection string is either not specifying a SQL Server username & password, or one which isn't valid
  • Your connection string is pointing to some other SQL Server machine which can't be accessed from Azure

If it's not one of these three things, then read the exception message which is being returned to you, Google it, and I'm sure someone will point you in the right direction !

One other thing you can do is append your connection string to your error message, and check which database your services are attempting to connect to.

public List<wsCustomer> GetAllCustomers()
{
    NorthwindDataContext dc = null;
    try
    {
        dc = new NorthwindDataContext();
        List<wsCustomer> results = new List<wsCustomer>();
        foreach (Customer cust in dc.Customers)
        {
            results.Add(new wsCustomer()
            {
                CustomerID = cust.CustomerID,
                CompanyName = cust.CompanyName,
                City = cust.City
            });
        }
        return results;
    }
    catch (Exception ex)
    {
        OutgoingWebResponseContext response = WebOperationContext.Current.OutgoingResponse;
        response.StatusCode = System.Net.HttpStatusCode.InternalServerError;
        response.StatusDescription = ex.Message.Replace("\r\n", "") + "  " + dc.Connection.ConnectionString;
        return null;
    }
}

This has also saved me a few times, particularly when I've had a few connection strings in my web.config file, but the .dbml file has decided to use the wrong one !

You're welcome..!

I wish I had found a webpage like this, when I was learning web services.
In particular, the piece about troubleshooting, when your database web services go wrong, is a lifesaver.

I used to deploy my early services, I'd get some baffling, vague exception (spoiler alert: they're never helpful), and I'd waste half a day tracking down the cause.
This is why I walked you through those try..catch chunks of code, and deliberately left the getData service in its place.

Please. If you've found this useful, please consider donating $10 or more to one of the two charities which I'm supporting.

(I don't want your money.. but I do want your support !)

Safe water transforms lives.

(Clicking on these links will open a new browser window, redirected to the charity's own web site. I make absolutely no money out of this.)

P.S. Right now, it's 10pm on a Wednesday night in April 2016, and rather than watching Better Call Saul, I'm sat here, selflessly typing in this stuff, which you won't find anywhere else, to help complete strangers like yourself.
Please "pass it on" and help others, in return. Thanks.



< Previous Page
Next Page >


Comments