Hi, I am working on a commercial project which is a web application (and now more) for a power company. This was a start-up power company so they needed all new software to run everything. Anyway, at first we built them just a simple web app where they could log in, add customers to a database, create invoices, payments, edit / lookup customers, etc... it is mostly for their phone operaters to use when a customer calls in and wants to sign up.. However we are also eventually going to develop their entire system and automate everything that is possible (buying wholesale power, managing bills from the wholesale company, turning on/off power,etc..). We have already started doing some of this... Recently we have started to do more system based stuff for them. For example they wanted it so that their customers could go to Ace or Moneygram (or Western Union, etc..) to pay for their power, and wanted us to write some software which automatically processed these payments at midnight each night... however they also wanted to be able to push a button on the website which triggered the processing. Well, my first instinct when i hear "process every night at midnight" tells me that this should not be logic done on the web application... since a web app has no "real" state and is not just always running like a "normal" application, I didn't see how it was even possible for the web app to "wake up" at midnight and do the processing... so, I wrote all the code in C++ with some Python scripts for the high level things like FTP operations... Anyway, this seems to be working fine, albeit the button on the site to trigger the processing is an UGLY hack (it just sets a flag in the database to "true", and the C++ app that is always running is just constantly checking that field, if it is true, then it processes the payments). Now, here is the problem: recently they wanted to add another feature to the site, basically a page called "Disconnect Customer", where the user could go to this page, fill in some info, push a button, and it turned off that persons power, for non paying customers. Anyway, the way this works is we write a flat file with the data in it (like the persons name and address) and then FTP it to the power provider... this is all very simple, but... this situation just screams "put the logic directly in the web app"... I could just put in some text boxes and when they push the button, format / dump the values into the text file and FTP it on over to the company... However, isn't this inconsitant and contradictory? It just doesn't feel right, that some of the system logic is done in a C++ daemon and other business logic is done directly in the web site. To make things worse, they now want to be able to automate paying their power providers, which is almost a situation in between the moneygram and disconnect thing (we get a feed from the power provider, process it, then spit a feed back to them). I'm not sure what to do with this, as it might require a "process every night at midnight" type thing in the future... So, my questions are, should I not have used C++ for the moneygram/ace processing? Should I just put the logic for the "Disconnect Customer" page in the web app (easier and cleaner, but inconsistant) ? What about the automated payments to the power company, which is basically just 2 transactions (they send us a file, we process it and then send them a file)... should this be in the web app or the C++ program? It would probably be easier and cleaner to put it in the C++ app, however then that would be inconsistant even more if I put the Disconnect Customer page directly on the site... Also, in general... where should system logic go? And any other tips or advice is appreciated... Anway, sorry for the long post, and please forgive any ignorance. This is not only my first web application but also my first system designing experience... I only work with one other person, my boss, who I should mention is a complete moron who can't write code and is a piss poor systems designer as well..... Thanks for any help.

Yeah, I know what its like constantly battling the line between what goes where in one of these expanding projects. Have you considered actually seperating pieces of functionality from each other? I was thinking you might like to create a web service that is in charge of creating the file, ftping, etc. You just provide it the data and let it do its thing.

This way that functionality is nearly completely split from the rest of the app, and you can easily swap out however you are actually solving the problem by putting another solution behind the web service.

Thanks for your (fast) reply. I don't have much experience with web services, but I'll do more reaserch into them. I hope there is a good solution to the problem, I really do need a "central" place for all these different transactions to take place... This system is going to be relatively large (at least a years worth of full time work, probably more).. we are going to automate everything this company does, which is a lot of "small" things which have seperate protocols and transactions (like turning off someones power, buying more power, paying bills, processing outside payments from customers who used things like Moneygram, etc... each one of these tasks requires its own little set of logic, so it definetly can be seperate, although I don't want to lock myself into keeping everything seperate because it might screw me down the line). I just don't want to end up with 10 different C++/Python apps and 7 different web pages which each do their own logic... it would just be plain ugly and a maintence nightmare.

I'm not sure exactly how your processes running at midnight have to work, but it sounds to me like something a cron job might be good for if you're on a Unix or Unix-like server. I've never used a cron job and know hardly anything about them; it was just a buzzword that stuck with me, so I can't help you much on how you would go about doing that. A wiki for it can be found here. Hope this helps!

Edit: Linkified

The server runs on Win2k server and its an asp.net app so no Unix.... thanks though.

About web services, I did some research and they seem like what I need so I can put all the code in one spot... The only problem is that the current daemon uses C++ with some python scripts so it would probably not be worth it to use web services in C++ since this isnt performance intensive or anything (I should have used C# or VB.NET in the first place)... I think i'll use C# or VB.NET now for applications...

But still it makes me think, should I even bother making daemons which are constantly on to process system logic? Is it bad to put everything into the web app? And is it logical to have system logic in a web app and have it also run at midnight each night? (wondering if thats even possible to do in asp.net).

Quote:Original post by graveyard filla
The server runs on Win2k server and its an asp.net app so no Unix.... thanks though.

About web services, I did some research and they seem like what I need so I can put all the code in one spot... The only problem is that the current daemon uses C++ with some python scripts so it would probably not be worth it to use web services in C++ since this isnt performance intensive or anything (I should have used C# or VB.NET in the first place)... I think i'll use C# or VB.NET now for applications...

But still it makes me think, should I even bother making daemons which are constantly on to process system logic? Is it bad to put everything into the web app? And is it logical to have system logic in a web app and have it also run at midnight each night? (wondering if thats even possible to do in asp.net).

Anything you put inaa web service can be called from anything else in .Ne, whatever the language. So you can write the web service in C# and still have it interoperate with whatever code you have running with .Net now.

As far as the "run at midnight" job, Windows has a scheduler. At least on XP you want to look for "Scheduled Tasks" in the control panel, it is probably something similar on your OS. It should be able to launch any type of exe, so either use your C++ app or use a .Net console app (and try to reuse code). The .Net console app can use any web services you have made, so anything in the web services become easily used across platforms.

Just don't make a monolithic service, I would keep them split up into groups based on functionality.

thanks, i've already started to write some code using C# for the first time, and MAN i wish i would have used this in the first place... i wrote some parsing code that was much more flexible and elegant then any of the C++ parsing code i've ever written, and i wrote (much) less code, too....

Quote:Original post by markr
Personally I hate things like "DTS jobs", "Stored procedures", "Triggers" and all manner of ways of putting bits of your business logic in the database. They make your application more difficult to deploy.

It's very important to have a simple robust deployment procedure - what use is proper testing if you can't deploy your application correctly?

Mark

Right now I am making extensive use of Stored Procedures, and it is letting me make changes to the database structure without making any changes at all to the front end. And for deployability, you just need to keep a listing of all your scripts. I have about 8 script files which have all of my database and procedure changes for a recent project that I run in sequence to deploy. For Pre-Prod you just follow the exact same steps you will in Prod, we copied over the latest Prod backup and I ran all of my updates on it for testing.

How else would you make changes to the database backend? Doing it by hand is more error prone then the scripts, because you end up having to write a 'script' for yourself to follow just to make sure you do it right the next time. Since I make all my changes on Dev with the scripts in the first place, I can just save them and know they will do exactl what I want the next time around too.