Introduction-An example for nearshoring benefits

Imagine that you’re a software development company that started to work with British and North American companies a long time ago, preferring AWS as their cloud provider. So, you have already picked up a significant amount of knowledge and experience about AWS. Then, some of your clients’ recent developments required some Azure and Microsoft API-related knowledge as well to achieve their goals. Let’s review our two recent case studies where having a partner experienced in Azure turned out to be beneficial and efficient for our client.

Utilize the full potential of Power BI reports

Imagine you have a B2B platform where you can create assessments for your partner companies that allow them to measure their skills in certain areas through assessments designed for them. Obviously, at some point, the top-level management of the company will want to see some overall reports with some important KPIs besides how individual people performed one-by-one. To address this we decided to create some Power BI reports. These reports must be available to the managers any time they would like to look at them.

Power BI’s licensing model allows you to share the report links that are publicly available. If you need to add some protection to restrict who can see the report, you will need to choose between the following options:

·       Pay for a Power BI Pro account for every person that should have access to the report

·       Embed the report using Power BI Embedded anywhere you want

We decided to go for the second option, as we already knew that this is just the first round of showing the reports and later, we would need to make them available for a broader audience. The licensing fee of the Power BI Pro accounts are based on the number of users. And embedding the report into a custom website allows you to have a more flexible way of defining access rights to the reports.

This turned out to be a powerful solution as later we needed to share the reports with some managers that should have access rights only to a subset of the users. So, we started to embed the reports using embed tokens and we started to use row-level security by first defining some fixed roles. Then, we created the embed tokens using a service principal that had read access to the reports and by putting g this static role of the user into the token stored in our database.

Later, at the third round, by introducing another round of managers, we needed a more automated way to define their roles. We also wanted to change the roles so that the report can identify which records to show by knowing their identity. This is where using the USERPRINCIPALNAME function became really handy because we just put the email address of the user into the token with a generic role, and the row-level security was able to pick up the user’s email address and filter the records based on that. This turned out to be a powerful and generic solution because this way we could define and test the access rights within Power BI desktop application before publishing.

MS Teams API integration

There was another website that we developed and have been maintaining since day 1. It has a feature that certifies the members of the community by having a 15-minuteconversation with some representative of the institute. These conversations are hosted on the Zoom platform. With Zoom losing the trust of many users and companies due to the recent issues found (most of them turning up when a lot of people started to work from their home office during the first wave of COVID-19), some companies have already banned Zoom from their company machines. This also meant that some of the B2B users of this website were not able to get their certification and the admins needed to find some workarounds to help these users.

One of these workarounds were that they held the conversations outside of Zoom and were sending them Microsoft Teams invitation links. This created the opportunity to bring both Teams and Zoom conversations to life. This was an interesting development because we needed some knowledge how to connect to MS Graph API by using app registration and service principals, plus create and manage meetings programmatically. It was helpful that we became familiar with that a couple of months ago so that we could make the Power BI reports work as described in the previous section.

The already existing Zoom integration evolved with some features during its lifetime so that it could maximize convenience since it was first introduced. One of these features was to be able to display phone access to the meeting to both the certifier and member. The other was to record the conversations automatically and save the recordings to an AWS S3 bucket.

As experienced Teams users, we knew that recording the meeting is an available feature on the platform. But, unfortunately, it is not supported by the API yet. Since the implementation, downloading the recording became available in the beta version of the Graph API. But this is not something that we want to use in a production environment yet. We have discussed this issue with the client and let them know that we can later introduce this feature when it becomes supported. Until then, we can turn on the auto-recording and they will be able to get the recordings from Microsoft Stream. And they agreed to that.

As for connecting via phone, MS Teams required a different license that the client already had, and they decided that this feature was not so important to upgrade the license to support this. They most likely decided to drop that feature because it was not heavily used by Zoom platform users for their conversations.

This was an interesting development for us developers (both the planning and implementation phase), and a useful feature for the users and the client. So everybody was happy after releasing it to production.

Conclusion

The bottom line is, if there is a strict deadline and you are not familiar with the technology you need to use, or it is extremely complex where you really need somebody experienced to do it properly then asking for help from other companies is nota shame, but most likely the way to go. On the way, you can pick up the required knowledge and your developers can continue to work with the solution and adapt to their other projects as well. To see why we also like to work with other teams too, read our other post about nearshoring software development here!