Looking for tips on writing a service in VB

Good morning

About six weeks ago, I got asked to migrate an existing Access database and VB 6 module to vb.NET. The application that was in place effectively allows the users (in this case the team that manages our telephone dialer) to take a file that's emailed to them every morning and turn it into outgoing email. The Access database is effectively used as a means to augment the data that's being received in the CSV file and configure the contents of the email such as message text, sender address, message subject, etc.

The solution I've built contains two parts. The first part enables the user to upload the current day's file and process it. That processing also includes the functionality to allow emails to be sent out in batches, thus avoiding the possibility of a large number of people responding to emails at times when there might be a lower resource availability in the call-centre. The second part of the solution is an application which sits on one of our servers and is run via Windows Task Scheduler at 5-minute intervals. When it runs, it polls the back-end database to find any unsent emails that are now due, and sends them by harnessing the SmtpClient.

From conversations I've had this morning, it looks to me as if I'm going to need to make some changes to the application that the dialer managers use, in order to give them a little more control over when the emails are sent out. My issue with that is not the modification of the email processing application, but the fact that at any point the dialer managers could find themselves updating a record that is about to be picked up and read by the server-based email sender. Therefore, I'm thinking of rewriting the server-based application so that it runs as a service, which could then (theoretically) be stopped and restarted by the email processing application.

If anyone can point me in the direction of a good tutorial on service-writing that leans towards VB rather than C#, that would be very much appreciated.

Here's a pretty detailed walkthrough from Microsoft
And here's a slightly simpler Code Project example

Windows services are actually pretty easy. You just have to wrap your code up in the appropriate structure. Error handling's a bit more of a pain because you need to think about logging them rather than just chucking them up on a screen but you've probably already got a handle on that from your existing server based solution.

Have you thought about where you're going to house this service? I.e. it probably ought to be on a server and, if you want to be able to stop and start it you're going to need to think about how any clients will do so. Shouldn't be difficult but worth planning out from the start.

Yeah, the logging is already being handled the old-fashioned way - write a new line to a log file for the current day.

In terms of where the service will be housed, it would be my intention to house it on a server for a number of reasons, primary of which is that I'm effectively relaying emails through two different mail servers (depending on who the email is to appear from). Both of the servers are owned by us so there's no issue there but the ability to relay email is quite tightly restricted to specific IP addresses.

At the moment, the existing server-based solution is being run by Windows Task Scheduler, using a particular set of user credentials. I'm guessing that I would want the replacement service to run under those same credentials since those credentials are static. I'm also guessing that when I write the functionality that will enable clients to "remote control" that service, they'll need to impersonate those credentials in order to be able to control the service.

Quote:

---

Originally Posted by FunkyDexter

And here's a slightly simpler Code Project example

---

Sadly the example provided by Code Project is a C# solution. Whilst it probably wouldn't be the biggest hassle to refactor that for VB, I'd prefer to keep my learnings to one-at-a-time :)

To each their own, although since the first link covers both C# and VB versions you already have a custom "rosetta stone" that probably covers the majority of mapping C# to VB constructs of various aspects related to creating a service.
With that aid in hand, it is almost criminal not to attempt the conversion of a simple project.

But it is possible that, for you, there is no worthwhile knowledge to be gained to justify the time spent. Hopefully the first link is more than comprehensive enough by itself for you to get the job done.

Quote:

---

Sadly the example provided by Code Project is a C# solution

---

Sorry, my bad. I wasn't paying attention. The first one should suffice though and, as Passel said, you probably wouldn't struggle to translate the second if you really wanted to.

hmmmm.... personally I don't know that I'd feel comfortable letting clients stop/restart services on the server. I see too much going wrong with that.
I'd probably use a status field on the records... 0 means it is released and is ready to be sent. 1 means it was sent (so it doesn't get resent) and 2 would mean it's being held (someone has pulled it to be edited - once they are done it would be released and set to 0) ... then you only pull those with a released status and send them. And as I wrote that, I realized I assumed a database, which may not be the case... but I think the principle still applies, sequester those messages not ready and only send ones that are released. There's no stopping or restarting the service. In fact, you can then keep your scheduled task on the server... only the client app would need to change - to move the message to a hold folder while it is edited. Once that's done, it can be moved back again.


-tg

Quote:

---

I don't know that I'd feel comfortable letting clients stop/restart services on the server

---

This is a very good point and one I hadn't considered. Services are kinda meant to be stood up and left up. If your turning it off and on again sooner or later someone will forget to turn it on.

TG's solution of "withholding" individual records may be a little more complex but is likely to be much more robust.

Thanks to both TechGnome and FunkyDexter.

TG, you're 100% right in assuming that I'm using a database (MS-SQL 2012). I can also tell both of you that I understand your concerns regarding letting the user(s) switch a service off and on. I already realise that if I do give the users that ability, it's going to need to be done in code, with that code containing some sort of fail-safe to check the status of the service before the user is able to close the application.

The issue I have is this: the scheduling of the emails is run by the client-side application. When the user runs the process, s/he can determine how many records should be handled in a batch. I wanted to hard-code that but was over-ruled on the grounds that the quantity of emails to be sent in a batch should be variable depending on the total number of emails to be sent. Here in the UK, we have quite strict rules around cold-calling, and it seems that the emails that we're sending are classed as contact attempts, meaning that we are also limited to the hours during which we can send the emails.

When I built the server-side application, I built it to read the entire contents of a batch that had become due and populate a DataTable object. Once that DataTable has been populated, each row within it is processed sequentially to turn each record into a separate email and tries to send the email. In the event of a successful send (which takes around 5.5 seconds per message) the back-end record is updated. If there is any sort of failure at the transmission step, the record does not get updated but is deferred for transmission the next time the application runs.

My issue is this: if someone decides that they want to stop emails going to a particular address, the client-side application would certainly be capable of updating the appropriate record in the back-end database. However, the server-side application may already have read that record into the DataTable and would therefore ignore any changes that were made to the underlying database.

The only alternative I can see to going down the service route would be to change the server-side application so that it only grabs one record from the pending table at a time. I would still need to check the database to see if there's anything to be sent, but then select the records one at a time. Either way, it would be good to get the server-side application service-based.

Or. lock it from the other side... once it's picked up, it gets marked... right then and there... once it's been marked, then the client can't change it. As simple as that... you collect the messages, you mark them as pending send... if the client tries to pick it up, it's marked pending, so they can no longer change it.

Jsut a thought.

-tg


OR... you do a sanity check jsut before sending it... gather all the records, loop through each one, before you send it, re-check the database and either pick up any new changes, or skip the record if it's still being edited by a user and hasn't been released.

To be honest, the more I think about it, the more I'm thinking that I should count the number of records that are due to be handled - if the count is greater than zero then loop through each record, refreshing the count on each pass. As you say, the record currently being handled could be marked in some way to reflect that it's being worked with.

Either way though, I do want to continue my research on writing a service since it strikes me as a more efficient way of handling the server-side stuff.

Quote:

---

Here in the UK, we have quite strict rules around cold-calling, and it seems that the emails that we're sending are classed as contact attempts,

---

Be a little cautious with that assumption. I used to write marketing systems so I made sure I knew the rules and they're different from emails to phone calls. For a start, emails cannot be sent unsolicited (so all that spam we're all getting isn't just a pain in the fundament, much of it's actually illegal) even though unsolicited calls can be made. I don't believe emails are time bracketed though. For the record, I don't think telephone calls are time bracketed either, I think that's only door to door calls. I'm less sure on that, though, as we never called into the evening as policy so were never in danger of breaching any legislation anyway,


Here's a really good document from the Information Commissioner that breaks everything down really well. You probably have legal experts in your organisation who are responsible for knowing this stuff but it's a good idea to familiarise yourself as well because, as the programmer, you can actually be held responsible for a breach - particularly if your software is even sold on to another company.

Quote:

---

As you say, the record currently being handled could be marked in some way to reflect that it's being worked with.

---

That's basically what we did when feeding a call to a user in the call centre, we'd stamp it with their id and remove the stamp when they put an outcome on the call. It should work as a strategy for your scenario but you need to consider crashes which might result in the record never being released. We used to run an overnight job that just released everything but it was a pretty blunt approach and I always felt we should have come up with something better.

Quote:

---

Be a little cautious with that assumption. I used to write marketing systems so I made sure I knew the rules and they're different from emails to phone calls. For a start, emails cannot be sent unsolicited (so all that spam we're all getting isn't just a pain in the fundament, much of it's actually illegal) even though unsolicited calls can be made. I don't believe emails are time bracketed though. For the record, I don't think telephone calls are time bracketed either, I think that's only door to door calls. I'm less sure on that, though, as we never called into the evening as policy so were never in danger of breaching any legislation anyway,

---

The industry that we're in (Debt Management) is very strictly regulated by the Financial Conduct Authority and, because a lot of our business involves outbound calling we're also overseen by Ofcom. We're not cold-calling insofar as we're actively chasing debtors, as opposed to having got people's information from the 'phone book (not to give my age away :) ). As far as I understand it, Ofcom limits the number of contact attempts that can be made to someone in a day, and includes Email and SMS attempts as part of that.

The email isn't unsolicited, since the addresses were supplied to us by the companies for whom we're chasing the debt. Also, this application is solely for use in-house. Obviously if the company decided to turn it into a marketable product, we would have to revisit everything that the application does to make sure it is 100% legally compliant.

Quote:

---

The industry that we're in (Debt Management)

---

Ah, then you're bound by completely different rules. Ignore everything I said :)

Absolutely not. I'm always keen to hear other people's perspectives on the issues I'm dealing with.

The biggest headache for us is that a lot of the FCA/Ofcom guidelines, whilst being quite strict in some regards, are quite fuzzy in others.

Yeah we always found that too. Fortunately the company I worked for were "prestige" and all about building relationships rather than hammering out quick sales. That meant that the folks we were contacting had typically given very clear consent rather than being "cold" and that means pretty much all bets are off.

I don't know but I imagine most of the stricter Ofcom rules probably don't apply to you as they're mostly to do with cold marketing. The FCA rules, on the other hand, are notoriously strict and, half the time, directly contradict the DPA rules.

Believe it or not the DPA rules are actually easier to apply. When we send out a communication (email or SMS) it is only an invitation for someone to call us. When they make that call, they are taken through full ID&V (Identification & Verification) procedures to ensure that they are who they say they are. In my experience though, we're not likely to get too many phone calls from people offering to pay money towards someone else's debt!