I'm migrating extensive SharePoint application to Azure and I'm looking for a recommendation in terms of replacing Timer Jobs with some Azure service. Which one would be most suitable? Azure Functions, Azure Logic Apps? The timer job needs to connect to a web service and make some GET / POST calls. Maybe sending e-mails.
What would you recommend? Any pros / cons?
Thanks,
George
With that additional context, but without a full understanding of the logic you need to implement around the calls, I'd suggest you look into a combination of a Logic App and a Function. The Logic App will make the time trigger and any email jobs more configurable, but the Function will give you more control of your web requests and logic, especially if those are more complex than simply making a request and ensuring it succeeded.
Set up the Logic App on a time trigger, and use it to orchestrate the Function and any email jobs. You can use the Logic App HTTP connector to trigger an HTTP-based Function, or you can look at the Function App connector.
For the Function, write it in C# and reuse your code there. Add any other calls and handling logic you require, then return a response for the Logic App to consume.
Add Control and Email (there are several of these for different email providers) connectors to the Logic App to send out relevant emails per the Function app result.
Related
I've recently started experimenting with Azure functions and I'd like to get some info on whether the following makes sense and is possible..
How feasible is it to build a normal .NET Core Web API following DDD patterns but replacing the API endpoints with durable azure functions? Is this a possible use case for Azure Functions, to make the web API "serverless"?
And how would the whole thing be structured? Does each Azure function need its own project or can they all be placed in one project?
Thanks
As I wrote in comments why not?
You can define bounded context and deploy to one azure function as microservice for instance service which will be responsible for orders, other azure function of delivery and so on.
Use durable function when you need to orchestrate actions, for instance you have buy flow when in first action you lock products, take payments and unlock so you have kind of dependency on each other.
You can use azure functions with service bus or azure queue storage for event processing.
One thing keep in mind that when you design function you have time limitations is up to 5 minutes on provisioning plan. So when you design newsletter for instance keep in mind that you would need to send email in batches.
I have a scenario wherein I want to invoke the logic app as API (probably HTTP trigger) and at the same time, I would like to invoke the logic in recurrent fashion as well (probably using recurrence trigger). Since there can only be one starting trigger in the logic app, how can I solve this problem?
Logic apps can only have one trigger.
Consider a second logic app which is recurrence based and calls the http triggered logic app. There is a built in connector for logic apps to call other logic apps.
Your Logic App can have up to 10 triggers. Per the documentation on the Logic Apps schema definition:
The definitions for one or more triggers that instantiate your workflow. You can define more than one trigger, but only with the Workflow Definition Language, not visually through the Logic Apps Designer.
See: Schema reference for Workflow Definition Language in Azure Logic Apps
For this, the general pattern would be to use 3 Logic Apps.
One containing all the processing logic and flow.
Then as many Trigger Logic Apps as your situation requires, 2 as described. The Trigger Logic Apps simply call the processing Logic App.
How do I change the Azure Logic App Frequency and Request type (Not programmatic ally)
Frequncy and Request type
Thank you for providing a screenshot! So the REQUEST and FREQUENCY info that you're seeing on the Overview section relate to the specific Trigger that you're using in your Logic App. Different triggers will show different info here depending on how they're designed to operate & work.
In your case, it looks like you're using one of Logic Apps' built-in connector called Request which will trigger workflow in your Logic Apps whenever a request is received to its endpoint hence manual and on-demand.
To change this trigger, navigate to Logic Apps Designer view under DEVELOPMENT TOOLS in the Azure Portal as shown below:
Moreover, I recommend reading Logic Apps' documentation here and finding more about triggers and actions; overall concepts behand Logic Apps. Hope this helps and goodluck with your journey on Logic Apps!
Can I achieve Azure function chaining with Durable Functions located in different resource groups & consumption plans?
OR do the functions have to exist in the same resource group/service plan?
If this is not possible, then apart from using service bus, how can functions communicate with each other across different services?
We only support chaining durable functions from within a single function app. This is a technical limitation imposed by the current design of the underlying Azure Storage provider.
However, you could work around this in various ways depending on your needs. For example an orchestration in function app A could send a queue message that triggers a queue-trigger function in function app B which internally starts another orchestration or raises an event to an existing orchestration using the Instance Management APIs.
Durable Function orchestrations also support the async HTTP model, which means that an orchestration in function app A could use HTTP to start an orchestration in function app B, then poll the status endpoint it gets back to get the response when it's available (more info in the HTTP API topic).
But can you comment on why you want to have communication across different function apps? We've received this request before and having more data might help us implement a solution sooner. :)
I have looked through documentation for WebJobs, Functions and Logic Apps in Azure but I cannot find a way to schedule a one-time execution of a process through code. My users need to be able to schedule notifications to go out at a specific time in the future (usually within a few hours or a day from being scheduled). Everything I am reading on those processes is using CRON expressions which is not designed for one-time executions. I realize that I could schedule the job to run on intervals and check the database to see if the rest of the job needs to run, but I would like to avoid running the jobs unnecessarily if possible. Any help is appreciated.
If it is relevant, I am using C#, ASP.NET MVC Core, App Services and a SQL database all hosted in Azure. My plan was to use Logic apps to check the database for a scheduled event and send notifications through Twilio, SendGrid, and iOS/Android push notifications.
One option is to create Azure Service Bus Messages in your App using the ScheduledEnqueueTimeUtc property. This will create the message in the queue, but will only be consumable at that time.
Then a Logic App could be listening to that Service Bus Queue and doing the further processing, e.g. SendGrid, Twilio, etc...
HTH
You could use Azure Queue trigger with deferred visibility. This will keep the message invisible for a specified timeout. This conveniently acts as a timer.
CloudQueue queueOutput; // same queue as trigger listens on
var strjson = JsonConvert.SerializeObject(message); // message is your payload
var cloudMsg = new CloudQueueMessage(strjson);
var delay = TimeSpan.FromHours(1);
queueOutput.AddMessage(cloudMsg, initialVisibilityDelay: delay);
See https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.storage.queue.cloudqueue.addmessage?view=azure-dotnet for more details on this overload of AddMessage.
You can use Azure Automation to schedule tasks programmatically using REST API. Learn about it here.
You can use Azure Event Grid also. Based on this article you can “Extend existing workflows by triggering a Logic App once there is a new record in your database".
Hope this helps.
The other answers are all valid options, but there are some others as well.
For Logic Apps you can build this behavior into the app as described in the Scheduler migration guide. The solution described there is to create a logic app with a http trigger, and pass the desired execution time to that trigger (in post data or query parameters). The 'Delay Until' block can then be used to postpone the execution of the following steps to the time passed to the trigger.
You'd have to change the logic app to support this, but depending on the use case that may not be an issue.
For Azure functions a similar pattern could be achieved using Durable Functions which has support for Timers.