Logic apps vs Azure function: a short review


 


One of the toughest questions to decide for any integration project is whom you are going to decide; that too if both of them could give you equal possibilities. It's like choosing your favorite Avenger hero, when you could see they are battling each other ⚔ 🏹 👺👲👨 


You could get a lot of suggestions across the net, here goes my list of observations, when to choose what:


📌  ALA and AFs are both trigger-based phenomena, however when you see you have a lot of connectors that you need to use in your ALA, which definitely are not free, (and give you an alluring offer of first 3 months' of subscription as free) -- I think you should choose Azure functions. Let me give you one example: I had a requirement, where I needed to read a PDF, as soon as it arrived a blob storage, then do some manipulations to the file and then move it to a shared folder drive, once done. Here, if we choose an ALA, then we need to use a lot of connectors that are readily available, so as to process the PDF and then move it to the shared folder. Unfortunately, these are all paid services and could eventually sum up to a huge bill amount, if not planned properly. 


In this case, the best choice is to go for an AF. Azure function can let you write your own code to process PDFs, move them across shared/SFTP folders (I remember, leveraging SAMBA client-based DLLs to orchestrate and call moving files between cloud to shared folder locs). In all these cases, functions are the best options to tailor-make your requirements, tossing it as a perfect cost-effective opinion.


📌 Cases where we need to retain expensive variables (eg. tokens) between different calls, A Durable function can offer you the best possible solution. A Durable function can be architectured with a myriad number of possibilities: of cascading one output to another's input, summing up outputs to be fed as a resultant input, delaying output, monitoring, chaining, async HTTP API calls -- which I suppose Logic apps might not be flexible enough to accommodate so much.


📌 Azure functions could safely be declared as a perfect way to tailor-fit your solution. A lot many triggers are just not available on Logic Apps side, which you can safely find amidst a rich set of bindings that are presently available in Azure functions' triggers. What? Didn't find, what you're looking for? Take a chill pill, I create my own connecters and call them from Azure functions (Please reach out to me, just in case you're interested about this cool hack).

📌 Anybody tired of fighting with Expression based formating on Logic Apps' controls? Try Azure function: the C-Sharp can do miracles: unleashing anything that you want to concatenate, format, add-up, substr, with quite ease. Not to mention, the ease with which you can play around with serialization, and deserializing your data, casting out variables of a class from an incoming JSON payload -- only to mention a few. Yes, these things could be done on Logic spps too, but Azure functions gives you a lotta freedom of speech.


📌 Yes, on the other hand, Azure functions are difficult to maintain. If your client asks you to tweak some logic to existing functions, you need to write a whole lot of staff, to make the thing work. For Logic apps, this is pretty straightforward and easy (owing to its low code-no code, and expression-based structures).


📌 Azure functions won't let you reprocess the errored runs, whereas Logic Apps can easily help you out on such matters.


📌 Not to mention, both the components have their own pricing model and a lot of other strategic differences, which could be found on: 


https://learn.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs#:~:text=Functions%20and%20Logic%20Apps%20are,Both%20can%20create%20complex%20orchestrations.

Comments

Post a Comment

Popular posts from this blog

X++ : mistakes which developers commit the most

Image
   The most important thing is to remember where and when to write the code. a. Developers have an inherent habit of writing erratic select statements: select * from custTable where custTable.AccountNum == <SomeValue> Where in essence we need to make use of optimized choice of fields in the select statement. b. Making use of 'continue' keywords: While select custTrans where <someConditions> { if (cusTTrans.CustGroup != mappingTable.CustGroup) { continue; } } 'Continue' statements are precisely a very unhygienic way of designing your code. The above statement could have been easily ornamented by using exists/not exists joins. Using Continue statements would eventually result in a high performance impact. Also select statements should be made punctuated with a 'firstonly' clause -- just not from best practise standpoint, but also from performance considerations. c. Writing nested loops: This is a common mistake that perha
Read more

Make your menu items visible on main menu, conditionally,, using this cool feature of D365FO

Image
  Wassup guys? I am sure you must have encountered this situation where you needed to display your menuItems, on main menu, based on some condition, haven't you? This was only possible by using config keys and flights. Things get a bit tricky,  when suppose you have a requirement like this: you need to make it dynamic, by introducing a toggle switch on a field on a paremeter form.  Suppose on Accounts Receivables Parameters >> You have a field called ' Show US customer '. You have a requirement that says when you turn on this toggle, then only the menuItem ' Input SSN details ', under AR module. This is now highly acheivable by leveraging subscription to 'SysMenuNavigationObjectFactory' class, simply by saying a. Create a new class USMenuItemsVisibilityManager b. Copy the following method, with proper documentation (don't change signature/anything else) [SubscribesTo(classstr(SysMenuNavigationObjectFactory), staticdelegatestr(SysMenuNavigationObjec
Read more

Speed up your execution performance by using SysGlobalCaches

Image
  Ever come across a situation where you needed to  a. Using a multi-threaded batch to import a journal header and lines, from a staging table. The table already contains the Journal Ids which you need to assign to the header and allocate the lines under that header. b. You need to continuously check after each line being imported, if the journal with the Id has been created. If not, it will create the header and create the lines under it;  If yes, it will directly create the lines for the header (Find or create). c. As you could rightly guess, this architecture has an inherent sluggishness associated with it -- each time you keep on checking if the header has been created or not, it does mean a lot of performance effects, as a consequence. Also as you can understand it's a multithreaded code, which means each thread has no direct relation with the other -- which does mean there is no way I can talk between the threads/pass on any information. SysGlobalCaches to the rescue: I perso
Read more