Automated/No Return Command Objects?

Automated/No Return Command Objects?

Old forum URL: forums.lhotka.net/forums/t/3675.aspx


jkellywilkerson posted on Monday, October 08, 2007

Greetings:

Not sure if this has been asked or addressed before - I can't find a reference to it in any previous post.  I have a need to iterate through a collection of BO's to call the BB.Reconcile or BB.CreateInvoice Command Object, but I do not want the UI (Web App) to block on the call and wait for the cmd.ExecuteNonQuery to return with a result.  These are potentially very long running calls that will be made from a Web App.

I would like for the user to click "Create Invoice", or something similar, and have the server do all the work and a Pass/Fail entry in a log table of some sort.

I understand the Command Object and how the Exists call works; I am just not real sure of how the start the Command Object running and have the UI continue what it is doing without regard to the call that was just made.

Thanks for any and all input in advance.

Kelly.

RockfordLhotka replied on Monday, October 08, 2007

This is a pretty complex issue.

On the surface it might seem that all you need is to do some sort of async data portal call (if the data portal had such a thing). But that wouldn't work in reality.

If the data portal were configured to run local, the task would run on a background thread, but would be aborted mid-run if the user closed your app or shut down the workstation This is a totally unreliable solution.

If the data portal were configured to run remotely, the task would run in COM+ or (more likely) IIS/ASP.NET. Neither of those hosts will continue to run a thread if the client disconnects, and both hosts could shut down in the middle of your long-running task (under certain circumstances). So this is also an unreliable (and effectively unworkable) solution.

So the easy answers are out.

What you need is to write a queued request somewhere (like a SQL table or into MSMQ), and then have a host process (probably a Windows service) that is designed to pick up items from that queue and execute them. This service would need to have the ability to restart (or resume?) your long-running task if it was aborted mid-run (like the server shutting down).

The commercial answer from Microsoft is Biztalk Server.

Alternately, you could roll your own using Workflow Foundation in .NET 3.0.

Perhaps you could use the message queuing capabilities in SQL Server 2005 - but you'd still need some way to orchestrate and deal with the long-running task, and so you are probably back to WF.

JoeFallon1 replied on Tuesday, October 09, 2007

I use a message queue approach to this. But I keep it simple by having a table in my database store the required data (Invoice number, etc) and then I run a Windows service to process all the data in the table on a scheduled basis. e.g. every 10 minutes or once a day, or...

The service logs each row of the table that it processes and provides a summary of its activities. Plus it logs errors and does not remove rows from the table if an expection occurs. All of this information is just put in another table in the DB.

Joe

 

jkellywilkerson replied on Tuesday, October 09, 2007

Thanks for your input.  That appears to be the easiest road, for me anyway.  I just really don't have the time or the "Drive" to put a BizTalk Server in place and get it configured properly.

I also like the scheduling idea - some of these long running tasks I would like to run overnite and have everything ready for the users the next morning.

Thanks again,

Kelly.

jkellywilkerson replied on Tuesday, October 09, 2007

Thanks, Rocky, for the reply.  I just finished looking over the BizTalk Server docs and website; also a webcast.  Seems a bit overkill and a little complex for what I have time for - I may venture down that road a little later.

However, I do like the Windows Service idea and will look into getting something together along these lines.

Thanks again,

Kelly.

Copyright (c) Marimer LLC