In today's fast-paced business landscape, staying ahead of the competition requires efficient and effective solutions. According to Microsoft’s Work Trend Index, nearly 70% of employee report that they don’t have sufficient time in the day to focus on “work”, with more time being spent Communicating than Creating.
Microsoft 365 Copilot is designed, with Microsoft’s cloud trust platform at its core, to allow for employees to both be more productive, reduce the time spent searching for information, performing mundane tasks, and other low-value activities.
One of my goals for this year was to become more adept at coding. While most of the Azure Suite does not require heavy coding knowledge to be successful at producing working solutions, having a basic understanding of the fundamental concepts of code can be beneficial. One of the fundamental concepts I particularly enjoyed learning is recursion.
Recursion is one of the more difficult concepts that I have learned so far. Recursion allows a function to call itself repeatedly until it reaches a specific base case. In simpler terms, recursion is a process of solving a problem by breaking it down into smaller and smaller subproblems until it is simple enough to be solved directly.
In programming, recursion works by breaking down a larger problem into smaller, similar subproblems. A recursive function calls itself, passing the smaller subproblem as an argument, until the subproblem is solved. Once the subproblem is solved, the function returns the result to the caller.
The process continues until the original problem is solved. Recursion requires a base case to be defined, which is the condition where the function stops calling itself and returns a result.
In addition to computer science, recursion is widely used in mathematics and other fields to solve complex problems that are difficult or impossible to solve using traditional iterative methods. Traditionally, recursion is used to break a big problem into smaller parts, but in this experiment, I am going to do the reverse. I will make a big problem by looping together small parts. To explain how this works, I am going to use this comic as a visual aid.
I like this four-panel comic because it’s a decent visual representation of recursion. Tigger the tiger is reacting to Pooh the bear for eating what he’s not supposed to, recursion, in the first three panels. Instead of the predicament resolving itself in the fourth panel, we find a loop of the first three panels, like when you look into two adjacent mirrors.
The problem with this piece is that it is not a real instance of recursive action. It’s merely an artist’s depiction of what it might look like. As you look closer into the bottom right corner of the shot, you’ll find that in the inner most embedded panels there are only smudges of color to represent recursive action. For us to truly get recursion, we must recreate this piece with a self-referencing process.
To do this, we are going to use Microsoft Cloud architecture. To synergize all their product offerings, Microsoft conveniently created enough embeddable programs to circulate a reference. Per the current configuration, Power BI reports can be embedded into a Power Point Slide, a Power Point Slide can be stored in SharePoint, and then referenced in a PDF viewer in a Power App. Finally, that Power App can be embedded in a Power BI report, finishing the cycle.
However, as the process ran, there was a problem I ran into. What I found is that SharePoint is designed to have a limited number of calls so that one site does not suck up all available bandwidth and lock out other users from using it. Without this stop, anyone could cripple an entire business by overloading a single site with call requests.
In the context of this exercise, while editing both the PowerPoint and the Power App in the process, I ran out of call requests before completing the loop. Even after waiting 24 hours for the steps to be complete, the loop would never get to the Power BI step to reach completion. The reason why this happens is related to how PowerPoint is displayed within the PDF viewer in PowerApps. With the viewer you can reference the SharePoint site as a data source, then display the PowerPoint as part of a list in a gallery. To display the slide in the PDF viewer, you feed the command editor with a script that converts the PowerPoint slide thumbnail viewer to PDF. This is important to understand because the thumbnail of a slide is not the slide itself, but a preview jpeg that is sent out to SharePoint as a separate entity to represent the slide. This thumbnail is also found in the preview ribbon of the PowerPoint application (see below).
This is the problem in why SharePoint was timing out and not allowing the process to work. The thumbnail itself is not updated immediately. Since PowerPoint’s are constantly updated in development, it does not make sense for SharePoint to actively update the preview thumbnail at every change. Rather, there is a set time in which it updates to prevent exceeding the call request limit. Unfortunately, I do not know the exact time in which that happens outside of that it takes longer than I need it to happen to make my recursion experiment to work.
Since the loop is too short for PowerPoint to load in a new thumbnail in the viewer, logically the solution is to expand the loop so that there is time to load. If the recursive action we designed puts too much of a load on one SharePoint site, the fix should be to distribute the load across two SharePoint sites. This will give just enough time between calls for the PowerPoint thumbnail to update to not exceed the API call limit. Therefore, the new loop looks like this:
By utilizing two separate SharePoint sites, the load of the recursive load is distributed enough for everything to load correctly. One point to note is that only PowerPoints need to live on separate SharePoint sites. The Power BI reports and Power Apps can live in the same respective workspaces due to the way they load. Since both Power BI and Power Apps load in real time, there is no need for a build in time buffer. Now that the loop works properly, we can visualize the steps below.
Step one: Load into Power PowerPoint and save to SharePoint. This is the only step with the three panels. All other steps will have the full iteration because I forgot to take screenshots as I built it.
Step two: Reference PowerPoint slide thumbnail in the Power App. The PowerPoint file information at the top is how it loads into the Power App. The thumbnail itself can be expanded over the graphic to maintain a clean transition.
Step three: Load the Power App into the Power BI desktop, then publish to a workspace in the Power BI service. When you use the Power App visual in Power BI, you use the URL of the app itself. It was important that I referenced the right one since we have two apps in this process.
Step four: Reference the Power BI report into a new Power Point. It’s important that this new PowerPoint is saved in a different SharePoint site so the thumbnail load is distributed correctly.
Steps five and six are the same as two and three. You create a separate Power App and Power BI report and load those into their respective places. The final step is to embed the final Power BI report into the original Power Point in step one, completing the loop. After that, you need to reload everything, and recursion has been made.
Now this might seem like a trivial exercise since there is no practical application to creating a loop like this. However, this exercise sheds light on how well integrated these programs are. While I did find the limit of SharePoint site calls, none of the other services showed any hesitation to any of this madness. Sure, there is a bottle neck in SharePoint, but Microsoft was smart in doing so. It is fun for developers to test the limitations of Cloud Architecture, but these programs are designed to supplement our work and improve our productivity. This recursion experiment shows that no matter what crazy requirements we have, Microsoft Cloud Architecture will often have an easy, pain-free solution to meet them.
As a Microsoft Gold Partner with 30 years experience helping organizations achieve their IT business goals, we offer unrivaled expertise and innovation in Microsoft technologies.
