Author Archives: devkeydet

About devkeydet

Global Sales Director - PowerApps & Flow

Why CDS?

“It’s just a database as a service, right?  Why wouldn’t I just put my data in SharePoint or MySQL or SQL Server or…”

This is a conversation I’ve had so many times in the XRM days.  Some day, I will be able to stop explaining that model-driven PowerApps run on the Common Data Service for Apps (CDS) and it’s the evolution of what we used to call XRM.  Name changes are hard.  Coincidentally, I just had a great conversation with @rappen and @ddlabar about this very topic on the XrmToolCast:

https://crm.audio/xrmtoolcast-naming-stuff-its-hard-with-marc-schweigert/

Just in case you are interested in the conversation (shameless plug, I know).  But I digress. 

The video below is how I typically talk to people about CDS to try to help them better understand what CDS is and why they might want to consider using it to build business applications.  The video assumes you already know Power Platform fundamentals.   It assumes you know the differences between canvas apps, model-driven apps, Flow, and CDS, but haven’t quite had that “lightbulb moment” when it comes to answering the question “Why CDS?”.  Hopefully this helps.  YMMV.

@devkeydet

Integrating with SAP from PowerApps & Flow using Azure Logic Apps

Scenario:

“PowerApps & Flow are awesome, but there is no SAP connector.  How do I use PowerApps & Flow with SAP?”

 

Azure Logic Apps to the rescue!  I show you how to do so in this video:

I also make reference to a few other resources to help you take the fundamentals I show in the video and evolve them to more advanced scenarios:

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-using-sap-connector

https://blogs.msdn.microsoft.com/david_burgs_blog/2018/12/01/azure-logic-apps-connected-to-sap-and-now-what/

https://docs.microsoft.com/en-us/azure/connectors/connectors-native-reqres

https://blogs.msdn.microsoft.com/devkeydet/2018/04/30/calling-an-azure-ad-secured-rest-api-from-powerapps-using-flow/

HTH

@devkeydet

Calling an Azure AD secured REST API from PowerApps using Flow

Scenario:
”I am building a canvas PowerApp.  The connector I am using doesn’t do exactly what I want it to do.  However, I know the connector uses a REST API secured by Azure AD.  Can I call the REST API directly?”

The answer, as of this post, is that you cannot call the REST API directly from a canvas PowerApp (as far as I know).  However, two new features were recently introduced that enables some really powerful integration between PowerApps and Flow:

https://flow.microsoft.com/en-us/blog/return-data-to-powerapps/ (the return data part)
https://flow.microsoft.com/en-us/blog/howto-upload-return-file/ (the return data tables part)

When you combine these two features, it opens a whole new world of repeatable logic execution from PowerApps.  If you drop an HTTP with Azure AD connector in between, you now have full control over your REST API call.  Here’s a quick walkthrough of all this in action:

@devkeydet

Productive web resource development for model-driven PowerApps

One of the most common questions I have been asked over the years (and still am today) about extending model-driven PowerApps / Dynamics 365 CE with html and JavaScript is:

“What’s the most productive way to develop and debug Dynamics 365 (and now model-driven PowerApps) web resources?”

The answer to that question will certainly be different depending on who you ask.  Any answer to this question is subjective.  There are lots of code editors out there that allow you to edit the various file types supported by web resources (html and JavaScript being the most common).  There are lots of helpful tools available that could be leveraged in different ways to answer this question (some from Microsoft, many created by members of the community).  I’ve tried lots of approaches over the years.  If you’ve come across any of my older blog posts or videos on the topic, then you’ve probably seen some of them.  When I show people my current preferred approach, most generally agree that it is more productive than what they are currently doing.  The video below is a comprehensive walkthrough of my my current approach.  As you will see in the video, at the time of this post, my toolchain is Visual Studio 2017, a must have (in my opinion) Visual Studio extension from Jason Lattimer called D365 Developer Extensions, and Fiddler.

HTH

@devkeydet

Build and deployment automation of PowerApps & Flow using Azure DevOps

11APR2019: Version 9.0.3.1 of the CoreTools now has basic support for Canvas apps & Flow.  However, this feature is still in preview as this update.

11MAR2019: Canvas PowerApps & Flow are have limited solution packaging capability in preview today.  They don’t work with the solution packager tool as of this post update.  These capabilities are targeted to be Generally Available in June of 2019.  See this page for details on the features and this page for timing (subject to change…check back often).

26SEP2018: I have updated the title of this post to reflect the announcements here and here sharing that canvas PowerApps & Flow are now included in the same solution packaging I describe in this post.  I’ve also changed the title to use “Azure DevOps” instead of VSTS per the name change announced here.  This post and video still only go through the process with the Common Data Service, model-driven PowerApps, and Dynamics 365 CE extensions using the old VSTS.  While I haven’t gotten around to updating the videos, and some of the experiences have changed, hopefully this post can still serve as a guide to help you understand the fundamentals of how to do this with canvas PowerApps & Flow using Azure DevOps.  You might have to connect the dots a little, but until I can to more meaningful updates for this blog post and video, I wanted to make sure the “Oh, I can do this now with canvas PowerApps and Flow now too!” lightbulb goes off.  HTH

This is the second part of a two part video.  The first part is here:
https://blogs.msdn.microsoft.com/devkeydet/2018/04/10/zero-to-full-source-control-of-a-model-driven-powerapp-using-spkl/

The second video won’t make as much sense if you don’t watch the first video.  In this video, I build on the work I did to get a model-driven PowerApp (the artist formerly known as XRM…as I like to say) into source control by showing how to enable deployment automation using Package Deployer, including setting up initial data using the Configuration Migration tool.  Then, I show you how to use Visual Studio Team Services (VSTS) to build all the assets in source control into their deployable form.  Finally, I show you how to then use VSTS to automate the deployment of those assets to one or many environments.  One of the things I highlight in the video is the Dynamics 365 Build Tools on the Visual Studio Team Services Marketplace.  These tasks greatly improve the productivity of using VSTS with Dynamics 365 & the Common Data Service.

All of the things I do from scratch in these two videos are the foundation of some of the more advanced things I highlight in the Dynamics 365 model-driven PowerApp DevOps work I mention here:
https://blogs.msdn.microsoft.com/devkeydet/2017/10/27/announcing-dynamics-365-devops-on-github/

@devkeydet

Zero to full source control with PowerApps & Flow using spkl

11APR2019: Version 9.0.3.1 of the CoreTools now has basic support for Canvas apps & Flow.  However, this feature is still in preview as this update.

11MAR2019: Canvas PowerApps & Flow are have limited solution packaging capability in preview today.  They don’t work with the solution packager tool as of this post update.  These capabilities are targeted to be Generally Available in June of 2019.  See this page for details on the features and this page for timing (subject to change…check back often).

26SEP2018: I have updated the title of this post to reflect the announcements here and here sharing that canvas PowerApps & Flow are now included in the same solution packaging I describe in this post.  This post and video still only go through the process with the Common Data Service, model-driven PowerApps, and Dynamics 365 CE extensions.  While I haven’t gotten around to updating the videos, and some of the maker experiences have changed, hopefully this post can still serve as a guide to help you understand the fundamentals of how to do this with canvas PowerApps & Flow.  You might have to connect the dots a little, but until I can to more meaningful updates for this blog post and video, I wanted to make sure the “Oh, I can do this now with canvas PowerApps and Flow now too!” lightbulb goes off.  HTH

Most people who build applications have used some sort of source control system.  Source control has become the de-facto way to keep track of changes as an application evolves.  I often find that people think they have to give up the well understood benefits of source control when adopting a no-code/low-code rapid application development platform.  Well, if you are creating a model-driven app using PowerApps and the Common Data Service, you don’t.  You can achieve the same granular level of visibility into changes in your application, over time, you get with traditional source code.  In fact, I wrote a blog post and video walkthrough about this very topic well over 6 years ago:
https://blogs.msdn.microsoft.com/devkeydet/2012/09/19/crm-2011-visual-studio-and-source-control-of-non-code-customizations/

Back then we were still calling it XRM.  Heck, just a few weeks ago it was still called XRM by those who associate with the term.  It will likely be called XRM, out of habit, for some time still.  Nonetheless, moving forward, it’s PowerApps and specifically the model-driven type which require the Common Data Service today.  If that hasn’t quite sunk in yet, head over to the announcement:
https://powerapps.microsoft.com/en-us/blog/powerapps-spring-announce/

While just about everything in my video from 6+ years ago can be done today, there are community tools out there which make the process much more efficient, therefore making the individual executing the process more productive.  Which, of course, makes the whole idea more approachable.  The two community tools that I am most fond of for this are spkl and D365 Developer Extensions.  However, I am finding that spkl and the D365 Developer Extensions aren’t as commonly known in the community as perhaps they should be.  Based on some feedback I’ve recently received on the general topic, I decided to create a new video demonstrating how go from zero to full source control of a Common Data Service based app using spkl and the Visual Studio IDE.  If there is enough interest, I can record a similar video for the D365 Developer Extensions.  The general flow of the video would be the same, but the mechanics of using each extension within Visual Studio will be a bit different.

HTH

@devkeydet

Calling an Azure Active Directory secured Azure Function from PowerApps

Scenario:
”I want to secure an Azure Function using Azure Active Directory (AAD) and call it from a PowerApp using a custom connector.  There are a few different docs out there that can help me figure it out.  However, I haven’t found anything that shows how to do it beginning to end.”

While the info in this documentation is the bulk of the work:

https://docs.microsoft.com/en-us/connectors/custom-connectors/azure-active-directory-authentication#2-create-your-second-azure-ad-app-for-your-custom-connector

It is written to be more generic and broadly applicable.  It doesn’t cover Azure Functions specifically.  Nor does it show you how to establish the PowerApps custom connector.  So I pieced together what I know about Azure Functions and how you can enable AAD authentication using:

https://docs.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication

…since Azure Functions are built on top of Azure App Service, with this blog post:

https://powerapps.microsoft.com/en-us/blog/cognitive-services-with-powerapps-using-custom-connectors/

…and extracted the relevant pieces to provide an end to end walkthrough:

HTH

@devkeydet