I need to execute a Process where a file is downloaded using ftp and then parsed and the results used to update some tables in a database.
The system is built using a WPF client using WCF services to talk with the database.
I need to start the process from the WPF application. Now my question is:
Should I download the file on the client and then use the wpf to parse the data and to do the update using the services?
or should I download the file to the server where the services are hosted and proceed to update the database there? And if so how do I provide feedback to the client that the process is running/finished,etc?
I preffer the second alternative, but I am not sure on how to implement the feedback on the background process...
Thanks
There could be number of solutions to your problem but I can think of two at the moment.
You could maintain a flag in the database table. Which a background thread in a WPF apllication will poll at set intervals and read the flag to update the status.
You can make use of a FileSystemWatcher. If you are on the Intranet and you can write into the file that you are processing. A FileSystemWatcher can raise events in the WPF application.
Related
I'm wondering what the preferred architecture would be for the following situation:
I'm required to have a .NET application that will perform batch upload of multiple data files concurrently to a SQL Server. This will be invoked from a WPF application which will allow the user to select the files and the destination tables, as well as reporting on the individual progress for each upload (including error messages). I have absolutely no problem writing the code for any of this. However, there is a requirement that the user is able to close the WPF application altogether and for the upload process to continue. Further, if the user restarts the WPF application from the same machine, it should be able to get a handle on the existing uploads and report on the status as if the program were never closed.
My question is what are the ways of achieving this and which would seem the most standard/suitable?
I've considered simply not actually closing the WPF application but hiding all the windows, but this seems a cheat. Would it be best to create a WCF service on the server where the upload is taking place and simply upload the file? I don't think I can do that and report progress % etc though. What about a locally-running Windows Service, can I achieve a similar effect? Should I be thinking of MemoryMappedFiles?
Appreciate all your thoughts.
Because you are talking about long-running task, I would use local Windows Service communicating with your WPF application through MSMQ. For example, each file to upload can be represented by one MSMQ message. Your WPF application will be putting messages into queue and Windows Service, periodically and without any impact if WPF is running or not, should take it from queue and process. This will provide simple and reliable channel of providing tasks (uploads).
To provide internal status of the Windows Service to its clients (your WPF application), I would host inside it a WCF endpoint with simple service that is telling, for example, about progress.
I created a C# application to manage data synchronization between an ERP and a CRM. This application reads a table every 500ms, and sends data via WebService to CRM.
For the moment, I have two screens for my application : a first to configure connections (ERP's DB connection informations and CRM's URL and WS Token), a second with a start button to launch the loop thread.
I know want my application to be nothing more than a windows service installer. What I want to do is to launch my application, configure ERP and CRM connections, and then click on a 'Install' button. When this button is clicked, a service is created and makes the same work that my application makes now when i click the 'start' button.
I already read those links Converting my application in a Windows Service, Making an existing exe with gui into windows service and of course http://msdn.microsoft.com/en-us/library/d56de412%28v=vs.100%29.aspx.
Here is my question :
How to make a configurable windows service ? I think the simplest way is to store configuration into files that utility and service would share. Where to store those files ? The utility must be able to find these files afterwards : registry ?
Thanks,
It's a common practice in .NET to store application's or service's settings in this relative path Environment.SpecialFolder.ApplicationData
I have an ASP.NET MVC website which clients post files to as part of an order process. These files can be up to 200MB. I have a need to transfer these files to another server via FTP. I don't really want to burden IIS with this. So was thinking of writing c# app to handle the file transfer which ran every x minutes and use windows service to run it.
Would this be an ok solution or is there something that could handle this for me already?
If I wrote the application should I let windows service handle the scheduling i.e. start the app every x minutes or should I just get it start the app on say startup and let the app handle the sleep/wakeup.
I was envisaging something quite rudimentary. Using SQL to track what needs uploading and has been uploaded. Are there any other considerations particular to a window service?
The website runs on iis8 on a windows 2012 vps.
One architecture tip -- use a simple executable and a scheduled task rather than write a service. You don't need to worry about memory leakage over months then.
You could probably implement this without writing any code -- you can script ftp.exe pretty effectively. I'd just script it to push all the files, and then, presuming FTP.EXE exited with 0, to clean out the uploads folder and rinse and repeat.
We are developing a web application in ASP.Net and C#. The requirement here is to interact with a third party exe which is developed in Fortran77. This third party exe produces an output file after being provided with some inputs and shuts down.In windows desktop single user application this is easily possible by using System.Diagnostics.Process and the events provided therein. But in web there will be multi-user environment, and many calls will be made to this exe. What are the best possible ways to handle such an exe in web application?
Is it fine if we invoke exe on each user request as the exe shuts down after generating output file? Or
Is it possible to use windows service? Or
Any other approach?
Thanks in advance.
-Prasad
Typically, invoking a different process to do some job (for a request) does not scale well when your number of requests start growing. Said that, if the process invocation is not going to happen frequently then you should be OK. The number of concurrent requests and through-put etc will really depend on your server hardware and the best bet would be to load test the server. As such you should use Process class to launch the process to get the work done.
Yet another issue that is possible that your legacy executable does not support multiple instance. It's unlikely but there are quite a few desktop windows application that check for existing instance. So in such, you cannot launch process concurrently and only way would be to create a queuing logic - you can create a in-process queue (in your web application) or create a external application (such as windows service) that will do queuing.
There can be alternate approach for this solution that is useful when the time taken for process to complete is large (so that you cannot block your web requests till the job is complete) and/or you need to scale your app to support more load. Essentially idea is use producer-consumer pattern where your web server will add requests to a persisted (e.g. table in database) queue and then you have multiple machines/servers running a job/windows service that would read from this queue and run the process to generate file.
I am trying here to find a solution to control a process I launch via webforms.
I know it is quite easy to start-stop it using System.Diagnostics.Process class.
What I am trying to achieve is to send data to the process (a terraria server). Basically the server itself when it is launched correctly you can write inside it some commands like kick/ban/save/exit etc.
I'd like to write those commands but remote controlled via a webforms application.
The nearest solution I've thinked would have been to call the server via a daemon I would write that would work as gateway between the webforms commands and the server application. Is that the right way to do things ? Or is there any easier way to do it ?
Are you perhaps looking for the BackgroundWorker class that was introduced in .Net 3.5?
To execute a time-consuming operation in the background, you create a BackgroundWorker, and then listen for events that reportt the progress of your operation and signal when your operation is finished. It executes on a separate thread.
The MSDN site has some examples that might help you figure out if this is for you.
Or you could just use a web service or WCF, couldn't you? You can either host the web service on a web server or as a Windows service.
You can probably start the process on application start and keep a reference to it in a static variable. You'll also need to attach to the OutputDataReceived event so you can record any data the process sends to its StandardOutput stream.
The idea is that the process will be running on the server and the web application will be silently recording any information it sends. When a request comes the buffer will be sent to the user and cleared.
The user can also send commands which the web application will forward to the process through its StandardInput stream.
I haven't tried it but it could possibly work. You will also need to consider what will happen if the application pool recycles. For best results I think you should disable autorecycling.
Yes that is the best way, make windows service that will control and monitor the process and into that windows service build API for a ASP.NET (webforms) application.
ASP.NET application can automatically refresh page (via javascript or meta refresh tag) and get new status from windows service that is controling your process, and event better you can build javascript application and get new status data and send commands with ajax, so there will be no need for whole page refresh.