To populate our database, we have used the Fantasy Premier League API: https://fantasy.premierleague.com/api/bootstrap-static/. The use of real players, teams and game week stats, gives our magic quidditch application the essence of a real league, muggles like that. We adjust and transfer the data to Dataverse by using Dataflows inside Power Apps.

Additionally, and by using the same procedure, in good theaving bastard style, we use https://hp-api.onrender.com/api/spells to get some spells professor Snape had hidden in the restricted section of the library! By this we add business value to our existing data by enriching the FPL dataset with Publicly available sources that consist of spells in the Harry Potter universe.

By using the public chatGPT API inside a Power Automate Flow, we transform the FPL to make it Harry Pottery!

In order for the quidditch player to sign in, we use the hot technology of our dear sponsor LINK Mobility. We use their MyLINK SMS API to generate unique OTP codes. The uniqueness of the codes get validated by using a Power Automate flow while also managing the values in our Dataverse database.

As part of the implementation of the MyLINK SMS API, we helped not only other teams that struggled with the implementation of the API, but clarified some doubts from the one and only Thomas Sandsør.

We have further enhanced our solution by integrating Azure Cognitive Services’ Speech-to-Text API and the CloudConvert API, enabling seamless conversion of audio into text and back into sound… More about this functionality is coming soon in another post called: “The data is not yours, the data is MINE(er)”

When you think of Quidditch, you probably picture soaring broomsticks, intense chases for the Golden Snitch, and a whole lot of wizardly fun. What you don’t picture is the part where players pull out their smartphones to log into an app—because even magical athletes need tech that works!

The sponsor badges added another dimension to this year’s hackathon, and why not dive right in directly and incorporate one of them to our solution! The various services offered by Link Mobility gave us several ideas and we immediately decided to create a proof of concept for one of the elements in our solution.

Given our solution, users are engaging with the app by creating their own teams, choosing quidditch players as well as other personalized features. In order to extend the personalized experience and uniqueness, we also wanted to test the possibility of adding a login page. The concept was quite simple, we wanted to utilize the Link Mobility SMS gateway in order to generate unique OTP codes. The uniqueness of the codes would we validated by using a Power Automate flow while also managing the values in our Dataverse database.

There are several features that we potentially will add as well using the SMS service by Link Mobility. However, as a start we created the simple proof of concept which is illustrated in the short video below:

Sopranova crushing it before the sun rises!

The team spirit at an all time high after a long awaited dinner, and ready to continue deep diving into development!

We’re proudly representing Team Sopranova (part of house Ravenclaw), and we’re utilizing all hats available in our inventory!

In addition to great decorations, our team has kept our cool through bugs and caffeine overdoses, and would therefore like to claim the badge Remarkable Teamspirit.

Following the spirit of low code development, we wanted also wanted to align our CI/CD to reflect the same concept. As a result, we decided to utilize Microsoft Power Platform Pipelines including the relatively new Git integration feature. The over all business value using these technologies was that it provided us with a easily maintainable ALM solution, while also ensuring that our solution would be compliant, secure and protect privacy. The git integration with our managed solution also provided the transparency between the developers to validate any changes that were made, and do code review.

To begin, we created a dedicated production environment for hosting our pipeline app:

Next, we installed the installed the Power Platform Pipelines Model-Driven App and started configuring our pipeline:

NB. We eventually also configured the production environment and added this to our pipeline.

Once the pipeline was all configured we could verify by checking our solution. As illustrated below, we could see that our solution was connected to the pipeline and that we could initiate the first deployment to our TEST enviroment.

While inspecting the sitemap on the left, we could also see that the source control menu item also was available. At first glance we could see the change log:

Lastly, in Azure DevOps we created a new project with branches related to the respective environments:

To summarize, this approach enabled us to quite effectively setup a simple ALM solution and process to maintain control over our components and changes. It was also an appropriate approach in order to gain more knowledge about some of the new features that were quite recently made generally available.

In order to improve the business productivity of our solution we opted for creating a workflow using Dataflows. Instead of manual data entry and import, we created several dataflows to enrich our solution as a whole. The workflows were set to automatically refresh at a scheduled interval, making sure that our database always would stay up to date both in terms of new and existing data. The source used in our dataflows were utilizing a Web API, which would enable us to build a dynamic solution including near real-time data.

Below is a snippet of the public API that we utilized to populate our respective tables in our Dataverse database.

Dataflows offered an effective and low code approach of integrating external data into our system. The API consisted of multiple tables and columns which gave us the flexibility to cherry pick the statistics that were of most interest for our solution. We following a simple three step process for managing each data flow:

• Select table
• Filter and transform data
• Remove unnecessary columns

Once the data processing had been completed, we mapped the columns to the respective columns in our dataverse table.

Lastly, for the import method we opted for the merge option in order to be able to update our existing data automatically. This option was also essential in order to avoid duplicate data and manually configuring bulk deletion rules.