(2021-May-31) Recently, I created a prototype solution for one of the projects, that would copy data files from Azure to SharePoint location. The task is trivial, doesn't require a lot of effort to build such a workflow with the help of the Azure Logic App. However, SharePoint itself is like another ecosystem and it may throw a curveball to me and slow down my solution development timeline dramatically. This post is a reminder to myself on how I had spent 5% of my time to develop this solution and then the other 95% to understand why it wasn't working initially to later resolve it.
Solution approach:
- Retrieve folder name and Azure file location from an HTTP request and save them in variables
- Retrieve a content of the Azure located file
- Create a new folder in SharePoint if it doesn't exist
- The final step is to save the extracted Azure file content into my SharePoint folder
Recent SharePoint problems and ways to resolve them:
(a) Resource is not found, HTTP 404 error
Often, some of the simple SharePoint tasks in Logic Apps would require a reference to a resource, whether it's a folder, list or actual document, or a file. You type a full path for a file or folder that looks exactly how it's being shown in the URI, then you test your Logic App workflow and it comes back with the 404 error code, saying that it can't find a specified resource. You check the code of the SharePoint task, see that it already has the encodeURIComponent function to convert your free text into the normal URI path, and you still wonder why it's not working. Then, after placing another instance of the encodeURIComponent function, everything becomes green and flawless.
Your original file path reference @{encodeURIComponent('Your SharePoint File Path')}
turns to @{encodeURIComponent(encodeURIComponent('Your SharePoint File Path'))}
I don't know why, but sometimes this double patching with the encodeURIComponent function helps to resolve the 404 HTTP problem.
(b) Correct reference of the "List or Library" property of SharePoint tasks
Standart SharePoint tasks in Logic App require a SharePoint site address along with a full path reference to a particular SharePoint resource (file or folder). In some other cases this full file/folder path could be requested in two parts: {List or Library} + {Remaining portion of the file/folder path}. And with lists in SharePoint, the 404 HTTP resource not found (or list not found) problem may come back.
The previously discussed patch with the encodeURIComponent function doesn't help. You try to place different combinations of your correct SharePoint list/library name as a free text since, by default, none of the SharePoint tasks dropdown lists in Azure Logic App would allow you to select sites/lists/libraries/folder/files, just nothing! That's where a Power Automate Flow comes in very handy, it's like a big brother, who used to be small, and now it extends its helpful hand.
In Power Automate Flows contrary to Azure Logic Apps, all similar SharePoints tasks provide visibility and selection of sites/lists/libraries/folder/files based on the granted permissions. There you can create simple flow with a SharePoint task, find a proper text alias name for the list/library (not the one from the URI) from a dropdown list, and then copy it to the same task in Logic App, and voilà, another 404 HTTP error in Azure Logic App is gone!
(c) Visually similar tasks in Logic App and Power Automate Flow vary in code
Feeling empowered that now I can solve most of my tasks in Azure Logic App and during troubling times Power Automate Flow may come to rescue me, then a pure curiosity to compare SharePoint (Create file) task led me to a discovery that their code structures are different between these two brothers. Let me illustrate this.
Here is how a Logic App SharePoint (Create file) task looks like:
A similar visual layout is portrayed for the same task in Power Automate Flow:
However codewise, there are different.
Share Point (Create file) task code in Azure Logic App
Share Point (Create file) task code in Power Automate Flow
I understand that hosting platforms for Azure Logic Apps and Power Automate Flows are different, but the core code structure could still be similar. This also reminded me of the line from the "Solo" Star Wars movie, where the Backett character shared his advice, "Assume everyone will betray you. And you will never be disappointed".
I didn't want to spend more time trying to understand why the codebase was different, nor did I seek a friendly relationship with Azure Logic Apps or Power Automate Flows. I just needed to get this job done. I'm still positive, but less emotional, and perhaps this will explain the title of the blog post.
