Can we run part of an ASP.NET Core MVC web application as console application which is scheduled using Windows Task scheduler

Question

. 。 Answers to this question are eligible for a +250 reputation bounty. Bounty grace period ends in 12 hours . john Gu wants to to this question. 对这个问题的。

I am working on a new project which contain 2 main parts:-

1. Scheduled service which reads files from SharePoint online and send them to external API.

2. The external API will process the received documents using Artificial Intelligent models >> extract data from the documents >> then Push the extracted data back to our system >> where our system will update SharePoint with the extracted data.

So currently I am defining the architecture and technologies that I am going to use, where I define the following at this stage: -

1. For point one, I am going to build a .net core console application >> hosted it inside windows server >> schedule it using windows tasks scheduler. This service will read the files from SharePoint using SharePoint API >> send them to the external API.

2. But I am not sure about point 2? How I am going to received the pushed data from the external API inside our system? Can I define an API end point inside my console application? Or for this I need to build something like ASP.NET Core MVC hosted in IIS which exposed some API endpoints to get the pushed data? Keeping in mind that the external API and our system will be installed inside the same windows server. OR I can build an ASP.NET Core MVC web application which will expose a controller class as an API end point + use its console application program.cs to be scheduled using windows tasks scheduler?

Thanks

Answer 1

After the external API handles the data, when it returns data to your system, there should have an endpoint for the external API to call and send data. So, you could create an Asp.net core MVC application and expose the related endpoint method.

For the console application, it is used to create the Scheduled service, right? If that is the case, you can create background tasks with hosted services , and add it in your MVC application, then there is no need to create the console application.

You can also refer this thread: How can I execute a method every year using BackgroundService in ASP.NET core Application?

Edit :

The Asp.net core application can be hosted on Windows as a Windows Service, you can create the API application and host it as a windows service to receive the data from external API refer the Host ASP.NET Core in a Windows Service .

Besides, you can also search "Create a Worker Service with an API door in .NET Core 3.1" using Google or Bing, there has multiple tutorial or sample to create a worker service with API.

Answer 2

My thoughts on this, having built similar solutions:

1. The scheduler feels fine unless you want to cluster it, in which case you could use a component such as Quartz.Net to ensure that each job only runs on one server at a time.

2. This will depend on how the External API can return results. The most common option would be to for you to provide an internet API endpoint, and for the external API to act as its client. You would not use an MVC app since you are not providing a Web UI for the external API - here is an example .Net Core API .

You will need to ensure that the API endpoint is secured, as in the above example. The simplest option might be an API key, but again it will depend on the External API, its options for returning results, and perhaps its developers.

CONNECTIVITY, HOSTING AND DATA

This feels like a key consideration. You can host HTTPS endpoints in IIS or any other process type, eg Windows service or console app. But then you need to expose that process to the internet so that the Extermal API can call it right?

It is worth seeing if you can use a cloud provider such as Azure to reduce costs for some of this:

• Azure Scheduler
• Azure Servlerless APIs

That will of course depend on where the data itself is hosted and whether you can move some or all of it. That is the design area I would focus on first.

Whichever option you choose, it feels like you are likely to need to enable inbound connectivity back to your main system.

Answer 3

You can post in many ways, it is a bit simplistic using a console app and letting windows task scheduler handle the invoking, but then simplicity is King they say, allegedly :) i'd base off a .net background worker service like suggested in the thread or if available an Azure function.

So "can I post/ recieve pushed data", yea surely you can, depending on your experience you may want to favour WCF, SOAP, REST to name a few receiving/ client options that you can find a virtual shovel load of examples of doing on the web, depending on what your business partner knows, and if you get to choose, choose REST. But it's really not significant, which brings more smile to business partner, you could give them access to a simple FTP service and handle files as a batch thing or use the FileSystemWatcher to trigger when they upload.

so how does the other party push data? well that depends on what they support, are you sure they don't have an endpoint that you get to query? depends on who gets to have the initiative and mostly we'd build systems where somebody has do do something and we have to do nothing except what they ask of our API.

So we end up you'll have to beyond building your planned stuff, read though and replicate this one then modify a POST address to accept what payload they off, if they can play HTTP REST: https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio