0
votes

I have console application for syncing products, orders data for different clients. I am using API's to pull and push data from 1 server to another server with task scheduler. But now I m facing a problem since number of clients are increasing. So while searching over Google I found topic about Azure functions. I went through some basic tutorials and understood how it works, but those are very simple applications.

In my current application I have 3 schedule job 1) Push partial product data updated recently (runs in every 15 mins) 2) Push orders data and acknowledge back (runs in every 15 mins) 3) Push all products data ( runs in every 6hrs)

from this link I got idea of Durable function and solution to my problem Stackoverflow Question but how can I store API details for different clients & how to start processing each of them ?

Thanks in advance

1
Why not use three timetrigger in the same function app? - Cindy Pau
You can have different triggers in a function app. - Cindy Pau
yes you are right about 3 different functions or may be 2, but if you want to use same code again for other clients then durable function is only option, sometime sync can run more than 10 mins. I m also more intersted to do this with Fan in/out architecture. Only problem for me is, how can I store all client api details & how can I read them ? - Jigar Sangoi

1 Answers

0
votes

Depending on the type of details required, you could either store them in Azure App Configuration (for config), Azure KeyVault (for secrets) or simply in Azure Blob Storage.

Also, you might want to use sub-orchestrators as required to reduce the load in the fan-in operation. Read more on that here.

The flow of your functions would be something like this

  1. [Timer Trigger Function] Initiate "Main Orchestrator"
  2. [Main Orchestrator] Call "FetchConfig" activity function
  3. [FetchConfig] Fetch and return details from where you stored them
  4. [MainOrchestrator] Split details per entity (user, customer, client, etc. based on your use case) and initiate "Child Sub-Orchestrators"
  5. [Child Sub-Orchestrator] Does what it has to do and returns data if required
  6. [Main Orchestrator] Process and accumulates the returned data if required

Another thing that you could consider is just having a simple HTTP Trigger to start your "Main Orchestrator" and offload scheduling to Logic Apps. This allows you to add many schedules without having to deploy your function app every time and there could be some payload sent as well to decide on what you orchestrator should do.