However, \u201cPowerApps Enterprise\u201d is a lot more than the client apps you can create. There’s a lot of stuff in Azure as well, and the Azure area from PowerApps is precisely the right space to work on for developers. The following is a high level diagram that I made trying to show the PowerApps landscape, including assets from Microsoft Azure and Azure App Service which are the foundation pillars for PowerApps Enterprise.<\/p>\n
Personally, I like the following definition available at azure.com:<\/p>\n PowerApps Enterprise definition<\/a>: \u201cPowerApps includes all of the existing capabilities available in Azure App Service, and introduces new enhanced capabilities optimized for building business apps. Additionally, PowerApps includes new and innovative visual tools that enable anyone in the organization to create their own apps using APIs and services built by developers<\/em>.\u201d<\/p>\n That tells you that \u2018PowerApps Enterprise<\/a>\u2019 is not just the \u201ccreate mobile apps in 10 minutes with no code required<\/em>\u201d feature you get with the PowerApps Authoring Tool<\/a>, but it is a lot more extending Azure App Service<\/em> environment in the cloud, especially in regards \u201centerprise security for your services with Azure AD\u201d.<\/p>\n Usually, if you are creating new cloud API\/services to be consumed by PowerApps client apps, you\u2019d create those services as Azure API App<\/a> that already provides like a wrapper of metadata (based on Swagger<\/a>, a very popular RESTful API description metadata) around your service that can be used from the PowerApp client app to discover and consume the service.<\/p>\n You have the following articles in azure.microsoft.com that tells you precisely about that green-field scenario with PowerApps<\/strong> services and Azure API Apps<\/strong>.<\/p>\n Ok, but what if rather than focusing on a green-field scenario with \u201cMicrosoft PowerApps services in Azure and the simple power-user data-driven apps\u201d I had a developer scenario with current mobile apps (Cordova, Xamarin, UWP\/C#, etc.) and current services\/API in Azure (maybe Azure Mobile App<\/strong> services) and I\u2019d like to extend my existing investments so it supports PowerApps as well?<\/p>\n That scenario is comparable to what Scott Hanselman<\/strong> talks about in this Channel 9 video<\/a>, but in this blog post I\u2019m drilling down further and explaining how to actually do it, step by step, as it requires quite a few steps and things to take into account.<\/p>\n The walkthrough assumes that you are familiar with ASP.NET Web API and Azure Mobile App services; if you need more info about Web API and Azure API Apps, check the following articles –<\/p>\n <\/p>\n The instructions and screen shots assume you’re using Visual Studio 2015 with Update 1.<\/p>\n The instructions and screen shots assume you have installed the Azure SDK for .NET (VS 2015) 2.8.1 or newer version.<\/p>\n You need an Azure account to complete the tutorial. You can:<\/p>\n As of December of 2015 you need to:<\/p>\n In order to work with PowerApps, you need to have PowerApps Enterprise<\/strong> support in your Azure subscription. As of today (December 2015) you need to join the PowerApps Preview program for that. You can get more info about it in the links above.<\/p>\n Take into account that the following steps that I describe in the blog post are what you need to do today, December 2015, when PowerApps is still in PREVIEW state. It might change and get simpler in the future.<\/p>\n A useful case would be to start with the sample apps and services from the new HealthCLinic.biz<\/a><\/strong> scenario that we created for Connect() 2015<\/a>.<\/p>\n In my initial scenario, I have the HealthClinic<\/a> services and apps that we published in GitHub-HealthClinic-Repo<\/a>, shown in the simplified architecture with the diagram below.<\/p>\n Specifically, I want to focus on the Azure Mobile App<\/strong> services that are consumed by the Cordova app<\/strong> (the two yellow highlighted assets in the diagram), but I\u2019d like to publish\/register the same services as \u2018PowerApps services\u2019 so I could re-use them from PowerApps<\/strong> client apps. That way, anyone in the enterprise could create simple data-driven apps related to the Doctors data, in this case.<\/p>\n You can see below another simplified diagram focusing just on the new scenario I\u2019m chasing.<\/p>\n Note that I\u2019m highlighting the Cordova app because I\u2019m migrating the Azure Mobile App service and the Cordova app is the one using it. In HealthClinic.biz, the Xamarin apps (native apps) are consuming the other ASP.NET 5 WebAPI services deployed as Azure Web App, just because we wanted to have that additional scenario. So, for this case, it doesn\u2019t matter if you want to use Cordova or Xamarin as client apps as I\u2019m focusing just on the cloud side, publishing an Azure Mobile App service as PowerApps Managed API in Azure.<\/p>\n Basically I need to do two main things in order to publish my Azure Mobile App to a PowerApps \u201cIT Managed API\u201d:<\/p>\n 1. Publish\/register my original Azure Mobile App service as a new PowerApps \u2018IT Managed API\u2019 with the required connections.<\/strong><\/p>\n 2. Test my new published PowerApps \u2018IT Managed API\u2019 from the PowerApps \u2018Authoring Tool\u2019 and create any simple PowerApp.<\/strong><\/p>\n But in order to be able to register an original Azure Mobile App service as a PowerApps Managed API you need to actually do a few things in your service\u2019s code:<\/p>\n 1.1. Swaggerize the service.<\/strong> We need to have Swagger metadata wrapping our service so PowerApps can \u201ctalk to it\u201d, \u201cunderstands\u201d what it is about and can be discoverable from PowerApps. That will require some easy code changes in our Web API Azure Mobile App project.<\/p>\n 1.2. Deploy the service into the PowerApp Environment in Azure<\/strong>. This step is easy and will be done through the Azure portal, as I\u2019ll show you.<\/p>\n 1.3. Create an \u2018IT Managed API\u2019 in the PowerApps Environment in Azure that wraps-out my backend service. <\/strong>Simply by registering my Azure Mobile Service as IT Managed API in the PowerApps environment. Then granting access to the specific Active Directory users.<\/p>\n So, let\u2019s see in detail the steps I needed to perform.<\/p>\n As mentioned, this action will require a few steps. It is very easy when you know it, but it can take some time if you don\u2019t know about Swagger<\/strong> and PowerApps<\/strong>.<\/p>\n First things first. What is Swagger?<\/strong> As mentioned, Swagger<\/a> is a very popular RESTful API description metadata so services can be discoverable from the outside and it is basically what Azure API Apps<\/strong>, Azure Logic Apps<\/strong> and now PowerApps<\/strong> use to understand how to use services\/APIs and connect to it.<\/p>\n You could manually create a Swagger file that would map all your service\u2019s operations and then just upload that Swagger file to the PowerApps definitions in Azure, like described in this article Register an API from Swagger 2.0 API Definition<\/a>. The thing is that registering an API with an existing Swagger file is very easy, but what is not so easy\/simple is to generate a Swagger file manually. That would be a lot of JSON code written manually and testing to make sure it is mapped right\u2026<\/p>\n So, how can that be done much easier? With Swashbuckle<\/strong>!<\/p>\n Swashbuckle<\/a> is seamlessly and automatically adds Swagger metadata to ASP.NET WebApi projects. It could be a plain WebAPI project or Azure API App or even an Azure Mobile App project which is my case! It combines ApiExplorer and Swagger\/swagger-ui to provide a rich discovery and documentation to your API consumers.<\/p>\n In addition to its Swagger generator (internally it works by using .NET Reflection to generate the Swagger schema describing your API types), Swashbuckle also contains an embedded version of swagger-ui which it will automatically serve up once Swashbuckle is installed.<\/p>\n You can see further info in GitHub at the Swashbuckle<\/a> page.<\/p>\n Swashbuckle <\/strong>is just basically made by two Nuget packages – the Core library (Swashbuckle.Core<\/strong>) and a convenience package (Swashbuckle<\/strong>) – that provides automatic bootstrapping. The latter is only applicable to regular IIS hosted Web APIs. For all other hosting environments (which is my case as an Azure Mobile App service does not use IIS), you should only install the Core library.<\/p>\n So, you can open the Azure Mobile App<\/strong> service from HealthClinic.biz<\/strong> with the solution called 06_Demos_MobileApp.sln<\/strong> which opens the project called MyHealth.MobileApp<\/strong>:<\/p>\n This project is a typical Azure Mobile App<\/strong> service that you can deploy to Azure App Service<\/strong> in the cloud. You can also test it locally by just hitting F5 and you\u2019ll see the following page in the browser:<\/p>\n —————————————————————————————————————————————————————————-<\/p>\n OPTIONAL: Test the local Mobile App service with the Cordova mobile app from HealthClinic <\/strong><\/p>\n NOTE<\/strong>: In order to have the HealthClinic services up and running you also need to have the SQL Database populated with test-data and running. For that you first need to run, at least once, the ASP.NET 5 project (web app with solution called 01_Demos_ASPNET5.sln<\/strong> and project that you need to run called MyHealth.Web<\/strong>) which generates de SQL DB either locally (SQL localdb) or in Azure as an Azure SQL Database. Once you have the SQL Connstring to your final database in Azure you have to update that in the conn-string within the Web.config of the Azure Mobile App that we\u2019re using in this walkthrough.<\/p>\n Of course, that page above from the Mobile App service doesn\u2019t tell you anything, but you can test this specific Azure Mobile App from the Apache Cordova app that we built as part of the HealthClinic suite. So, if I open the solution called \u201c\u201d and I double click the file configService.ts<\/strong> I can change the URL that the Cordova app is going to consume, in this case, the following code updating the URL to the same URL where my Mobile App service is running locally that you see in the browser above:<\/p>\n If you have all the different parts (SQL db, conn-strings and API_URL) running and properly configured, you Cordova app could run like the following app in the Android browser, with sample data:<\/p>\n Cool, so I tested that my service is working properly before advancing and doing anything with Swashbuckle.<\/p>\n —————————————————————————————————————————————————————————-<\/p>\n The point is that I\u2019d like to check that the Mobile App service is running properly without having to check it from the client Cordova app. That is another reason why Swashbuckle is pretty convenient!<\/p>\n Swashbuckle\u2019s setup in your Azure Mobile App service project<\/strong><\/p>\n Since Azure Mobile App service projects use OWIN (therefore the MyHealth.MobileApp <\/strong>project), we just need to install the Swashbuckle\u2019s Core library through \u2018Manage NuGet packages<\/strong>\u2018 in References<\/strong> or by typing the following within the \u2018Package Manager Console\u2019 in VS :<\/p>\n Install-Package Swashbuckle.Core<\/strong><\/p>\n Then we need to add some code to enable the Swagger under OWIN\u2019s infrastructure.<\/p>\n This is the code I added to the Startup.css<\/strong> file:<\/p>\n Add \u201cusings\u201d for Swashbuckle and Json serialization:<\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/7558.image_thumb_711B9934.png\" "\\"image\\"")
<\/a><\/p>\n\n
<\/h4>\n
Why adding an Azure Mobile App service to PowerApps Enterprise environment \u2013<\/h2>\n
The Developer Story<\/h2>\n
Prerequisites for this walkthrough<\/h2>\n
<\/h4>\n
Azure Mobile App service and ASP.NET Web API<\/h4>\n
\n
Visual Studio 2015 with Update 1 (at least the \u2018Community\u2019 or \u2018Professional\u2019 edition)<\/h4>\n
<\/h4>\n
Azure SDK for .NET (VS 2015) 2.8.1<\/h4>\n
Azure account\/subscription<\/h4>\n
\n
<\/h4>\n
Prerequisites to get started with PowerApps Enterprise (IMPORTANT)<\/h4>\n
\n
Disclaimer<\/h2>\n
Initial scenario to evolve \u2013 The HealthClinic.biz services and apps<\/h2>\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/8306.image_thumb_296A37D3.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/1715.image_thumb_54B15F8B.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/1033.image_thumb_63E7C858.png\" "\\"image\\"")
<\/a><\/p>\n1. Publish\/register my original Azure Mobile App service as a new PowerApps \u2018IT Managed API\u2019 with the required connections.<\/h2>\n
1.1. Swaggerize the Azure Mobile App service from HealthClinic.biz<\/h2>\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/3386.image_thumb_28441A89.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/1651.image_thumb_7A3D6D9D.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/0511.image_thumb_755AB9E1.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/5140.image_thumb_577C35E0.png\" "\\"image\\"")
<\/a>\u00a0 ![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/1565.image_thumb_59B8BE9C.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/6232.image_thumb_7BA42120.png\" "\\"image\\"")
<\/a><\/p>\n
![\"clip_image002\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/3678.clip_image002_thumb_0FBD3DAA.jpg\" "\\"clip_image002\\"")
<\/a><\/p>\n![\"clip_image001\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/6786.clip_image001_thumb_2D321F67.jpg\" "\\"clip_image001\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/5102.image_thumb_6F388EA8.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/3157.image_thumb_0A70E7AA.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/8360.image_thumb_2C5C4A2E.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/6082.image_thumb_4794A32F.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/32\/2019\/03\/2816.image_thumb_77BE7EA3.png\" "\\"image\\"")
<\/a><\/p>\n