Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to send Email and SMS in bulk in c# MVC. So, method would be better, cron in a web application or separate scheduler service for it?
I have a web application running already. So, should I integrate the cron in the web app itself or create a new scheduler service for it.
I want to use the best method in terms of reliability, speed and load of data.
its better to make separate service for that for the below reasons :
1- Maintainability : If there is a problem in sending mails or SMS you know where you need to check without going to your main solutions.
2- Availability & Scalability : You can scale this Module only or if any thing happens to your main app, your mailing and sms will still be working.
3- Separation of Concerns : SMS and Emailing is considered to be a cross cutting functionality that it will be used in alot of places in system, so it is better to have it in one separate place.
4- I/O latency : like this you will avoid any latency or any performance effects on your main business domain.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am planning to write a web server in c# that will run on my computer. I've heard that windows services are good for such tasks because they can start on startup and because they run in the background and don't interfere with your work. The only problem with this is that I would like to see the activity on my web server through a terminal. I don't think services can do this, but it's not a big problem because I'm sure there is a way to make the service run the server and create a separate console application to interface with the server service.
My question is, why bother? Can't I just have a console application run everything and also handle the terminal interface? The only reason I would consider using a service is if it offers some kind of performance boost. Does it?
Windows service - is not about performance boost. Your choice depends on what is the main goal of your service. If it's just an utility app and you plan to start and stop it manually perhaps console app will be good for you, else IMHO you should consider windows service that store logs and/or push events + console/wpf/winforms or any other appropriate kind of application for monitoring purposes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am working on code to send an sms to customer one week before their subscription reach expiration date. I absolutely don't know how to proceed. I am coding in asp.net c# and sql server.
Create one console Application which will take user whos expiration comes in week, Then write code to fetch the user with there numbers. Then use any third party Api to send sms. you have to send parameters to this Api with your appropriate message.
Then create one job inside sql server which will run everyday which will execute your Console Application code to send SMS.
I would say, separate out publishing and subscription tasks. So in future you can do more with such customers.
Prepare a Publisher which looks for such customers and adds a task to Queue.
Write a Subscriber who watch outs for new queue items and take action.
So in future if you want to make multiple way of communicating to customer like, email then you just need to add more subscriber.
Host your logic as a .NET windows or IIS service.
Benefit: Publisher can independently perform addition.
Subscriber performs task as soon it sees something in queue.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I would like to know what is the best practice on making one Microservice to interact with another Microservice?
I am developing in C#. What I currently have done is, created a service bus which passes new events created from one Microservice. I then use task runner (WebJob) which consumes the messages off the bus and then I am using Http to Post to another Microservice endpoint. Each microservice is a web api.
I would like to ask if I am doing it correctly, if not I am happy to hear the suggestions.
One of the key benefits and characteristics of microservices is Decentralized Data Management, and that means each service(i.e. each service fabric app) manages its own database and any other external bounded contexts must go through the service's API to get at it. I think one of the biggest challenges in the microservice architecture is identifying the bounded contexts and how it can mirror the business and team structure/technology/geolocation.
Your doing is the first step to fabricate a Microservice; making each service as compact/independent/isolate/unique as possible, expose them to well-known(REST) endpoint, and communicate them with messages.
It is not suitable to describe the definition of Microservice in detail at this post but you could read lots of article about Actor model, Microservice, or their related patterns and applications.
practically, there are frameworks to achieve Microservice architecture. Akka.net and Azure Service Fabric are recommended for C# developers.
In addition, you said WebJob and if it is Azure WebJobs, why don't you read this great article; https://msdn.microsoft.com/en-us/magazine/mt595752.aspx
Hope this helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is it possible to somehow notify a running process from the "outside"?
I have a C# program that theoretical runs forever. And I would like to notify it to trigger some action manually. It would be best, if this solution is possible on Windows and Linux (mono).
EDIT:
The solution should work without a user interface
My program is, as for now, a part of web service. On initializing, a new Theread is created, which uses the Task class to stay alive
Take your forever-running-process and let it provide a webservice other processes can call.
You might use any cross-plattform webservice framework like WebApi or ServiceStack to achieve this via HTTP calls. This will even work over the internet (if the machines can reach each other).
There are dozens of approaches. You could also use named pipes for example, or put commands into a database (the other process has to query regularly) or - if you're fearless enough - write/read files to communicate. Be creative ...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on a newsletter. Newsletter content is saved in the table along with frequency such monthly, weekly, daily. Newsletter also have start date. What I have to do is based on the data and frequency. Newsletters are emailed to all the subscribers. My confusion is that whether I need to write a sql server job for this or simply asp.net can do this. If yes then how would I be able to do this.
As your web application will be terminated in times of inactivity, you usually have a service or task scheduler run such periodical tasks. Also your web application is responsible to return requests quickly and should run with a very limited set of permissions that might not be enough for your jobs (it is preferable not to allow the app pool account to send e-mails to lots of accounts).
There are various alternatives that differ in terms of convenience and deployment of your application.
An important requirement besides the capability to run jobs periodically is how you can trace errors in the job, so you should think about your logging strategy before the first problems arise.
Besides writing a SQL Server job, you could also:
Create a console application and use Windows task scheduler to run it periodically (interval is the minimum of your scheduling options, in your question daily). This is easy to implement, but requires some steps to deploy it to a computer.
Create a dedicated windows service that is installed to the computer. While this requires more effort to create and test the service, you can also create an installer to simplify the deployment.
I eventually went for the application events. I set the timer in application event and it works similar like jobs and windows services.