Showing posts with label Esendex. Show all posts
Showing posts with label Esendex. Show all posts

Wednesday, January 16, 2008

Force a C# Web Service Proxy to use HTTP 1.0






(Code at the bottom)

Esendex customers can submit SMS using .Net Web Services. While the simple code samples we provide will get most people up and running, the samples aren't always enough when volumes start to increase.

The most common error report we receive from these high usage customers usually contains a complaint that our APIs are down, and aren't responding, but this is rarely the case. Our server array offers all our customers the responsiveness and the reliability that they will need, but the error report always seems to look like this is the case.

Normally the problem is at the customers side, and more often than not it's due to them consuming our Web Services using HTTP 1.1.

A limitation of HTTP 1.1 is that it only support 2 simultaneous connections to another server. This is usually OK, but if a customer has a multi-threaded application then this can quickly become a problem. The problem manifests itself with an error that looks like the server is down.

In reality what you'll have is a bunch of threads all waiting for a chance to connect, and when they don't you tend to get timeout errors that make it look like the server didn't respond.

To get around this you need to connect using HTTP 1.0, but by default Visual Studio creates a web reference using 1.1. So you need to do some tweaking.

Basically we need to override the GetWebRequest method on our generated web reference and alter the properties on the HttpWebRequest so that we can assign the right version.

When you add a Web Reference in Visual Studio you effectively add an auto generated class to your project, which (if you look down the directory tree in Windows Explorer) is saved in a Reference.cs file. This file changes every time you tell Visual Studio to update the web reference.

Because of this it isn't always possible to override that particular class. If you working with an API that can change and you want to be able to update it easily, then you'll have to use partial classes in order to override the method. Or you could sub class the proxy and override it in there.

Personally I like to move the Reference.cs file into the project as a normal file (renamed of course), and then edit the generated code. I can do this as I know that the API isn't going to change (if we do need to offer new functionality we release new Web Services rather than change existing ones).

This allows you to override the method in the normal way, and also allows you to change how the proxy gets the URL to connect to.

Whichever way you do it, here's the code you need to add in:
protected override WebRequest GetWebRequest(Uri uri)
{
HttpWebRequest request =
(HttpWebRequest)base.GetWebRequest(uri);
request.ProtocolVersion = System.Net.HttpVersion.Version10;

return request;
}
And, as you've now got access to the HttpWebRequest you can also disable Keep Alives if they're causing you problems as well.

Thursday, January 10, 2008

Needle in a haystack

Been a bit quiet on the blogging front recently. That's mainly because I'm currently running through some tests for the first iteration of an update that will drastically change the architecture of the Esendex Messaging System. I can't go into detail about the change, but my current tests run into a very intermittent failure.

At irregular intervals one of the services hangs: just totally stops responding, and because it's multithreaded the log files aren't much help. Actually, its worse than looking for a needle in a haystack, as at least in that case you know what you're looking for.

It first presented itself after sending only 100 messages, then after 2,000. An initial investigation didn't shine any light on anything so I sent some more messages. It hasn't failed again yet, and I've currently sent 15,000 through. No code change either, so the error is still in there waiting to be found.

Frustrating is not the word.

Thursday, January 03, 2008

Esendex Webservice SMS using C++

C++ is not my main language, but all Esendex developers are expected to help our customers integrate their systems with ours on top of our usual development work.

Admittedly we don't have many people asking for help with C++, but when they do we usually direct them to the C++ SMS SDK. This includes a COM component which developers must install, and this fact does pose some problems for some developers.

So, while waiting for a build I found How to Consume [a] WebService via unmanaged C++, which describes how you can get Visual Studio 2005 (and apparently 2003 as well, but I've not checked that), to generate a proxy for you.

In Visual Studio 2005:

1. Generate the proxy:

  1. Right click on the project in the Solution Explorer and click Add Web Reference.
  2. In the dialog, enter http://www.esendex.com/secure/messenger/soap/SendServiceNoHeader.asmx as the URL, and give it a name
  3. Click Add Web Reference
  4. This will generate a file in your project (with the name you gave it)
2. Write code to call the proxy:

SendServiceNoHeader::CSendServiceNoHeader proxy;
BSTR result = NULL;
HRESULT hr = proxy.SendMessageFull( CComBSTR("username"),
CComBSTR("password"),
CComBSTR("account reference"),
CComBSTR("originator"),
CComBSTR("destination"),
CComBSTR("C++ Hello!"),
CComBSTR("Text"), 0, &result);
3. Notes:
  1. result will contain the ID of the message you've just sent
  2. hr can be used to check if the operation was successful
  3. You may need to include the line CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); before this code if your application doesn't already have it.

Wednesday, November 14, 2007

How fast is your turnaround time?

There's currently a question been posted on AskSlashdot which asks How fast is your turnaround time?:

...Overall, we manage to get a 'bullet-proof' patch in about 4-5 weeks (from coding->QA->Build/Packaging->shipment), which I consider not so bad. But the other day, we got an urgent request from our support team to come up with a decent fix in 48 hours. I think they're a tiny bit unrealistic. So I wanted to get feedback from my peers: are we doing that bad?...


Esendex's core product is an online service, which means our customers don't need to install anything. So realistically I'm not in a position to comment on this particular matter. We don't need to go through a packaging stage, and we can be pretty confident that we won't have installation issues as we own all the server hardware the system runs on.

But looking at the timescales involved here puts a few things into perspective. If one of our releases introduces a critical error (by which I mean that people can't use our service anymore), then the entire business rests on getting that error fixed. In these cases (thankfully they are few and far between) 48 hours is just too long. In fact much too long.

If we're in a position where we have customers not able to send messages then our SLAs make us contractually obliged to fix the problem within 4 hours. I remember being alerted to one such error a few years ago at 2am on a Sunday morning. By 5am that day the system was patched and fully operational again.

A quick turnaround stems from the design methodology you are using. With XP we learn to expect change, so we make sure that we don't code ourselves into a corner. This makes new requirements easy to add, but it has the side effect of making most bugs easier to fix as well.

Of course, there's always going to be the possibility that your design is so flawed that it's impossible to fix a certain bug. In these cases backing out of an update is sometimes the only feasible option.

All non-trivial software contains errors. If there's one truism about software development, that's it. The important differentiating factor is the severity of those errors. A truly business critical severe error needs to be fixed as fast as possible, and if it means late nights then so be it.

As professional developers we're paid to release working software, and if that software doesn't do its job then we haven't done our job.

Thursday, October 25, 2007

Monitoring Custom Windows Services

A lot of my work at Esendex involves creating and maintaining Windows Services that form the guts of a much larger product that we collectively call the Esendex Messaging System. The work that these services do can differ wildly: everything from the relatively mundane to complex critical services that the business depends on.

Because of this, each service needs to be monitored in different ways. Sometimes its OK to trawl through log files to discover what the service is doing, but with other more widely used services this quickly becomes tedious.

We're currently in the process of rolling out an update to one of our critical Windows Services, and this update involves an architecture change that makes examining logs beyond tedious, it's actually unworkable for anything other than tracking historical events.

This is where we use custom performance counters. If you're a developer and don't know what these are, then read up on it, and quickly. Performance counters can be used to give you visibility on the near-realtime progress of your systems.

Here are some examples of what we monitor with performance counters:

  • Execution time of certain key interface methods,
  • Total counts of current throughput at various stages of a message's journey through the system,
  • Rates of current throughput (how many messages per second, etc),
  • Statuses of key services.
From these we can use the standard Windows Performance Monitor to watch what a service is doing. For a more bespoke monitoring solution you can also write your own applications that read your performance counters and display the results in a more friendly way.

If I get time I'll knock up some sample code demonstrating how to do this.

Wednesday, October 10, 2007

Sending SMS to a specific port using the Esendex API

I've written an Esendex Developers Blog entry describing how to send SMS to a specific port. It's quite technical, but we've had a few support cases raised about it in the last couple of weeks, so thought I'd write about it.

It's quite long as well, but I don't think I could make it be any shorter and still be meaningful.

Friday, October 05, 2007

Batching Bulk SMS Submissions using the Esendex API

I've written a summary of how to submit batched messages using the Esendex APIs, which will help anyone having problems submitting large amounts of messages at once.

It's not code specific, but should point you in the right direction if you find that making many single submissions is giving you network errors.

Read this Esendex Developers Blog entry: Batching Bulk Submissions using the API for more information.

Thursday, October 04, 2007

Esendex Website Updated

The new style web site went live yesterday afternoon, with surprisingly (but reassuringly) few problems. It's early days yet, and I'm sure we'll get a few calls from people who can't find things in the new format, but it looks like the deployment has been successful.

I was in two minds about posting about this actually, because I've not done that much work on it. I've paired with Neil and Kevin on the odd task, but I think of the developers here I've probably done the least on it.

The new website contains various blogs (like for support, development, and the company as a whole), so please check those out. I've already posted to the development blog, summarising the inbound multipart message update I blogged about here recently.

Right, onto the next story.

Monday, September 17, 2007

A Day For Winning

I got back from a week's holiday this morning to find that I had not only won Esendex's new strapline competition, but I've also taken the spot prize in the Esendex fantasy football mini league.

Maybe I should go and buy a lottery ticket ;)

Wednesday, August 29, 2007

Potential Breaking Change For API Customers

We are currently working on reassembling multipart inbound messages before they are placed into inboxes, which has the effect of increasing the maximum length of an inbound message from 160 to a purely theoretical 38,862 characters.

Esendex customers who use the API to receive inbound messages and have restricted their systems to the current 160 maximum will need to increase their current restrictions.

Read more here.

Esendex Inbound Multipart Messaging Update

Most people who use SMS will know that a standard SMS message is limited to 160 characters (using a standard 7-bit character set). But most people will also know that mobile phones are capable of sending a message of more than this.

The phone does it by splitting the message into parts, and placing a header on each part that describes:


  • how many total parts there are in the message

  • which part this current segment is

  • a reference so parts from different messages don't get mixed up


Esendex's outbound service has supported sending these long messages for more than a year, but at the moment we treat inbound message parts as separate messages.

We're currently working on an update that will cause these message parts to be reassembled into one message, so all parts (or however many parts we actually receive) will be displayed as 1 message in the Inbox.

So what is this going to affect? Well, if you use the website to view your inbox, or have your messages emailed to you, then this won't affect you at all--all you will see is a longer than usual message if a multipart message is sent to your account.

However, if you have written an application that retrieves your messages from your Inbox, or which receives direct messages through the Application Notification service, then this could potentially be a breaking change.

If you are expecting a message to be a maximum of 160 characters, you will need to modify your code and/or database tables to accept messages longer than this. If you need to apply a maximum length, then the limit of 1 Esendex inbound message will now be based on the total characters in the maximum number of parts allowed by the specification.

The maximum number of parts is stored in an unsigned byte starting at 1, which gives a potential for 254 parts(!). Each part can have 153 characters, which gives a technical maximum of 38,862 characters in an inbound message.

However, I seriously doubt any provider or phone manufacturer will allow anyone to send a 254 part message. I certainly know that phones have their own limits on the number of parts a handset can send.

As an example Esendex's outbound service limits you to sending 4 message parts, or a total of 612 characters.

A maximum of something like 1000 characters should probably handle most cases, but the potential is there for 10s of thousands of characters under the right circumstances.

This update is currently in development and will hopefully be going live in September sometime. I've been told an email will be sent around to API customers giving an official announcement, but you can get a head start on any changes you need to make right now.