For some time I've been meaning to do some multi threading in the Dynamics SOP Fulfilment software I wrote. I have always thought that I could make things run a little more slickly. At fulfilment the following processes occur;
Credit/debit card debited if one is attached to the order
Order lines are fulfilled by quantities on the pick list being fulfilled
receipt printed (optional depending on carriage option- customer collect etc)
despatch note printed (optional)
invoice printed (optional)
thermal parcel label(s) printed one for each parcel entered
consignment details are exported via XML to UPS / Business Post / TNT depending on carriage routing algorithm
UI is constantly updated with progress bar and messages about progress
Spinning the fulfilment thread off on to its own thread using a background worker control was straight forward and is something I did when VS2005 was released. However some of the above processes take quite a few seconds to run, the fulfilment computers are quite recent hardware and thus should be able to perform better.
Thanks to good object orientated design, it turned out to be fairly trivial to get each of these processes to run on their own thread and synchronise them using wait handles. I had to use wait handles as some tasks depend on the successful completion of others. More...
Many, years ago (2001) I wrote a small application in Delphi that would allow a user to print thermal labels to a Zebra or Eltron EPL or ZPL language printer. It also supported printing to dotmatrix labels. That shows how long ago it must have been.
the labels were based on information drawn out of Dynamics GP. Thus warehouse bin location, item description etc was pulled through from GP allowing the goods in department to quickly print off labels for goods they were bagging or stocking.
As we have recently added another company to our premesis it is now desireable for the application to automatically detect which company the part number entered belongs to and print a label with the correct layout for that company out. The applicaiton originally written in Delphi is overdue for a rewrite into .NET.
There was no hours available in work time to write this applicaiton so I took it home to write in the evenings. The following posts show you how I got on. I had, as usual forgotten about some of the nice features I had encorporated into the original application.
Part II to follow....
Throwing people at the problem is not always the solution. Something large development teams I expect are fully aware of.
Paul Murphy has some wise words on the subject, pointing out the obvious, a fully descriptive design would actually be the code to do the job...
Development work and team size by ZDNet's Paul Murphy -- the programming language appropriate for a particular application is the highest level language in which the requirements can be fully and completely expressed.