Hack 77. Track Message Delivery Time

Use a built-in feature of the BlackBerry to monitor message delivery times.

How can you determine whether your BlackBerry platform is working and delivery times are "normal"? This is not an easy question to answer. You could send yourself a test message and manually watch your device for it to arrive. However, a successful test may indicate that the BlackBerry Enterprise Server that your device is homed on is functioning properly, but there may be other BES servers in your architecture that aren't functioning optimally.

Also, if there is a delay in receiving your test message, is the delay a normal duration or is it a significant delay that requires further troubleshooting?

You can use the built-in message delivery confirmation feature [Hack #76] to build a simple delivery time monitoring tool to create a benchmark for message delivery times in your BlackBerry platform.

7.7.1. Requirements for This Hack

You'll need a functioning BlackBerry to which messages will be sent. This can be your own device, although it's best if you obtain another device just for this purpose. Ideally, the device could be stored in a secure place that has consistent wireless coverage otherwise, your delivery times will be skewed as the device goes in and out of wireless coverage.

You will also need an automated way to send an email through some point in your network. It's best to send the test messages through the outermost point possible from your device perhaps an external facing SMTP mail gateway that can deliver a message to your mail server. This allows your delivery times to reflect a worst-case scenario. On the other hand, you may want to confine your data as close as possible to your BlackBerry infrastructure in effect removing as many factors as possible from the equation. In this case, you should relay the messages through the closest point to your mail server.

7.7.2. Send a Test Message

Here is some Perl code to send the message through an SMTP server. It uses the Mail::Sendmail module that doesn't come in the default Perl installation (despite the word Sendmail in the module, this module is platform independent and does not require Sendmail). You can install it using CPAN by typing perl MCPAN e "Mail::Sendmail" from a command prompt. Of course, you will need to plug in the values specific to your environment.

 #! perl -w use Mail::Sendmail; use strict; my $smtp_server = "mail.server.com"; # change to your SMTP server my $mail_address = '[e-mail]'; # should be device's email my $from_address = '[e-mail]'; # change to monitor mailbox my $now = time(); my %msg_options = ( To => $mail_address, From => $from_address, Subject => "<\$confirm,removeondelivery> BB Delivery Time: $now", Body => "Message for delivery time monitoring", ); sendmail(%msg_options); 

7.7.3. Calculate the Delivery Time

Once the message is sent to the BlackBerry device, you'll receive the delivery confirmation email at the address specified in $from_address. The subject of the message is always "BlackBerry Delivery Confirmation," and the subject of your original sent message is in the message body. This allows you to check the confirmation message and compute the round-trip delivery time. Just take the received time of the confirmation, convert it to epoch time, and subtract the value of the epoch time that the original message was sent (I put it in the subject line as $now).

Here is the code I use to check the mailbox, perform the calculations on the delivery probe messages I sent using the first part of the script, and then delete the message. You'll need to change the values of $pop_server, $username, and $password to make them specific to your environment. Although it is possible to check the mailbox using a variety of protocols, I chose POP3 because of its broad support and ease of use.

 #! perl -w use strict; use Time::Local; use Mail::POP3Client; my $pop3_server = "mail.server.com"; my $username = "username"; my $password = "password"; my $pop = Mail::POP3Client->new( USER        => $username, PASSWORD    => $password, HOST        => $pop3_server, ); for (my $i = 1; $i <= $pop->Count(); $i++) {    my $header = $pop->Head($i);    if ($header =~ /Subject: BlackBerry Delivery Confirmation/) {   my $body = $pop->Body($i);   my $received_time = "";   ($received_time) = ($header =~ /Received: from .*?; (.+?)\n/s);   my $probe_sent = "";   ($probe_sent) = ($body =~ /BB Delivery Time: (\d+)/);   my $received_epoch = get_epoch($received_time);   my $duration = $received_epoch - $probe_sent;   print "Delivery took $duration seconds for" .     "probe sent at $probe_sent.\n";   $pop->Delete($i);    } } $pop->Close; sub get_time_stamp { my ($epoch) = @_; my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($epoch); my $yyyymmdd = sprintf("%04d%02d%02d",$year+1900,$mon+1,$mday); my $time_stamp = sprintf ("%04d-%02d-%02d %02d:%02d:%02d", $year+1900,$mon+1,$mday,$hour,$min,$sec); } sub get_epoch { my ($smtp_timestamp) = @_; my @parts = split / /, $smtp_timestamp; my $mday = $parts[1]; my $mon = $parts[2]; my $year = $parts[3]; my ($hour,$minute,$second) = split /:/, $parts[4]; my $tz = $parts[5]; my %month = (    Jan => 1,    Feb => 2,    Mar => 3,    Apr => 4,    May => 5,    Jun => 6,    Jul => 7,    Aug => 8,    Sep => 9,    Oct => 10,    Nov => 11,    Dec => 12, ); my $epoch_wo_tz = timegm($second,$minute,$hour,$mday,    $month{$mon}-1,$year); $tz = $tz / 100; my $epoch = $epoch_wo_tz - ($tz * 60 * 60); } 

Because the server where your mail resides stamps the received time on the message, you won't have to worry about when you run the delivery time calculation portion of the hack. All the data points you need to calculate the delivery time are in the message as it is received. You could even send out several test messages during the day, and then calculate them only once a day.

7.7.4. Hack the Hack

Once you've gathered enough data so that you are comfortable defining what a normal message delivery time is in your architecture, you could set a threshold that would warrant troubleshooting. Use that threshold and monitor the delivery times periodically, sending an alert if the threshold is exceeded. This type of proactive monitoring frees up your time for more important tasks. It's also nice to be automatically alerted of a potential problem so you can already have an idea of what the issue is by the time your users come calling.