Publishing an existing Azure Mobile App service as PowerApps ‘IT Managed API’ (Using the HealthClinic.biz sample apps)
Intro to “PowerApps Enterprise”
You may have heard of Microsoft PowerApps and ‘PowerApps Enterprise’. Its code-name was “Project Kratos” and part of it is deriving from the original “Project Siena”. But in PowerApps, the client PowerApps are cross-platform (iOS, Android and Windows) as they are internally based on Apache Cordova.
However, “PowerApps Enterprise” 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.
Personally, I like the following definition available at azure.com:
PowerApps Enterprise definition: “PowerApps 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.”
That tells you that ‘PowerApps Enterprise’ is not just the “create mobile apps in 10 minutes with no code required” feature you get with the PowerApps Authoring Tool, but it is a lot more extending Azure App Service environment in the cloud, especially in regards “enterprise security for your services with Azure AD”.
Usually, if you are creating new cloud API/services to be consumed by PowerApps client apps, you’d create those services as Azure API App that already provides like a wrapper of metadata (based on Swagger, 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.
You have the following articles in azure.microsoft.com that tells you precisely about that green-field scenario with PowerApps services and Azure API Apps.
Why adding an Azure Mobile App service to PowerApps Enterprise environment –
The Developer Story
Ok, but what if rather than focusing on a green-field scenario with “Microsoft PowerApps services in Azure and the simple power-user data-driven apps” I had a developer scenario with current mobile apps (Cordova, Xamarin, UWP/C#, etc.) and current services/API in Azure (maybe Azure Mobile App services) and I’d like to extend my existing investments so it supports PowerApps as well?
That scenario is comparable to what Scott Hanselman talks about in this Channel 9 video, but in this blog post I’m 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.
Prerequisites for this walkthrough
Azure Mobile App service and ASP.NET Web API
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 –
Visual Studio 2015 with Update 1 (at least the ‘Community’ or ‘Professional’ edition)
The instructions and screen shots assume you’re using Visual Studio 2015 with Update 1.
Azure SDK for .NET (VS 2015) 2.8.1
The instructions and screen shots assume you have installed the Azure SDK for .NET (VS 2015) 2.8.1 or newer version.
Azure account/subscription
You need an Azure account to complete the tutorial. You can:
- Open an Azure account for free. You get credits that can be used to try out paid Azure services. Even after the credits are used up, you can keep the account and use free Azure services and features, such as the Web Apps feature in Azure App Service.
- Activate Visual Studio subscriber benefits. Your MSDN subscription gives you credits every month that you can use for paid Azure services.
Prerequisites to get started with PowerApps Enterprise (IMPORTANT)
As of December of 2015 you need to:
- Sign up for PowerApps Enterprise
- Create an app service environment
In order to work with PowerApps, you need to have PowerApps Enterprise 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.
Disclaimer
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.
Initial scenario to evolve – The HealthClinic.biz services and apps
A useful case would be to start with the sample apps and services from the new HealthCLinic.biz scenario that we created for Connect() 2015.
In my initial scenario, I have the HealthClinic services and apps that we published in GitHub-HealthClinic-Repo, shown in the simplified architecture with the diagram below.
Specifically, I want to focus on the Azure Mobile App services that are consumed by the Cordova app (the two yellow highlighted assets in the diagram), but I’d like to publish/register the same services as ‘PowerApps services’ so I could re-use them from PowerApps client apps. That way, anyone in the enterprise could create simple data-driven apps related to the Doctors data, in this case.
You can see below another simplified diagram focusing just on the new scenario I’m chasing.
Note that I’m highlighting the Cordova app because I’m 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’t matter if you want to use Cordova or Xamarin as client apps as I’m focusing just on the cloud side, publishing an Azure Mobile App service as PowerApps Managed API in Azure.
Basically I need to do two main things in order to publish my Azure Mobile App to a PowerApps “IT Managed API”:
1. Publish/register my original Azure Mobile App service as a new PowerApps ‘IT Managed API’ with the required connections.
2. Test my new published PowerApps ‘IT Managed API’ from the PowerApps ‘Authoring Tool’ and create any simple PowerApp.
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’s code:
1.1. Swaggerize the service. We need to have Swagger metadata wrapping our service so PowerApps can “talk to it”, “understands” 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.
1.2. Deploy the service into the PowerApp Environment in Azure. This step is easy and will be done through the Azure portal, as I’ll show you.
1.3. Create an ‘IT Managed API’ in the PowerApps Environment in Azure that wraps-out my backend service. Simply by registering my Azure Mobile Service as IT Managed API in the PowerApps environment. Then granting access to the specific Active Directory users.
So, let’s see in detail the steps I needed to perform.
1. Publish/register my original Azure Mobile App service as a new PowerApps ‘IT Managed API’ with the required connections.
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’t know about Swagger and PowerApps.
1.1. Swaggerize the Azure Mobile App service from HealthClinic.biz
First things first. What is Swagger? As mentioned, Swagger is a very popular RESTful API description metadata so services can be discoverable from the outside and it is basically what Azure API Apps, Azure Logic Apps and now PowerApps use to understand how to use services/APIs and connect to it.
You could manually create a Swagger file that would map all your service’s 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. 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…
So, how can that be done much easier? With Swashbuckle!
Swashbuckle 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.
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.
You can see further info in GitHub at the Swashbuckle page.
Swashbuckle is just basically made by two Nuget packages – the Core library (Swashbuckle.Core) and a convenience package (Swashbuckle) – 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.
So, you can open the Azure Mobile App service from HealthClinic.biz with the solution called 06_Demos_MobileApp.sln which opens the project called MyHealth.MobileApp:
This project is a typical Azure Mobile App service that you can deploy to Azure App Service in the cloud. You can also test it locally by just hitting F5 and you’ll see the following page in the browser:
—————————————————————————————————————————————————————————-
OPTIONAL: Test the local Mobile App service with the Cordova mobile app from HealthClinic
NOTE: 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 and project that you need to run called MyHealth.Web) 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’re using in this walkthrough.
Of course, that page above from the Mobile App service doesn’t 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 “” and I double click the file configService.ts 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:
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:
Cool, so I tested that my service is working properly before advancing and doing anything with Swashbuckle.
—————————————————————————————————————————————————————————-
The point is that I’d 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!
Swashbuckle’s setup in your Azure Mobile App service project
Since Azure Mobile App service projects use OWIN (therefore the MyHealth.MobileApp project), we just need to install the Swashbuckle’s Core library through ‘Manage NuGet packages‘ in References or by typing the following within the ‘Package Manager Console’ in VS :
Install-Package Swashbuckle.Core
Then we need to add some code to enable the Swagger under OWIN’s infrastructure.
This is the code I added to the Startup.css file:
Add “usings” for Swashbuckle and Json serialization:
| using Swashbuckle.Application; using Swashbuckle.Swagger; using Newtonsoft.Json.Serialization; |
Add additional “usings” you’ll need for the filter-classes:
| using System.Web.Http.Description; using System.Globalization; using System.Linq; |
Then add support for docs and swagger-ui by invoking the extension methods (in namespace Swashbuckle.Application) on an instance of HttpConfiguration in Startup.cs. Check the code in bold below:
| public class Startup
{
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
// Set the Json serializer to CamelCase explicetely so Swashbuckle takes into account and swagger schema is consistent with Json. config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver(); config .EnableSwagger(c => { c.SingleApiVersion(“v1”, “MyHealth.MobileApp”); // Set filter to eliminate duplicate operation ids from being generated // when there are multiple operations with the same verb in the API. c.OperationFilter<IncludeParameterNamesInOperationIdFilter>(); // Set another filter to eliminate duplication operation ids from being generated // when there are multiple Web API routes, like /tables and /api c.OperationFilter<IncludeRouteNameInOperationIdFilter>(); } ) .EnableSwaggerUi(); //Other code related to Owin and Web API //…… new MobileAppConfiguration() .UseDefaultConfiguration() .ApplyTo(config); app.UseWebApi(config); } } |
As you can see in that code, I had to apply two custom filters when generating the Swagger metadata.
– One filter to eliminate duplicate operation ids from being generated when there are multiple operations with the same verb in the API. This filter is the same filter that is also applied in regular Azure API apps created with the Visual Studio and Azure SDK templates. This filter is defined in the following class placed after the Startup class code:
| internal class IncludeParameterNamesInOperationIdFilter : IOperationFilter
{
public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription)
{
if (operation.parameters != null)
{
// Select the capitalized parameter names
var parameters = operation.parameters.Select(
p => CultureInfo.InvariantCulture.TextInfo.ToTitleCase(p.name));
// Set the operation id to match the format “OperationByParam1AndParam2” operation.operationId = string.Format( “{0}By{1}”, operation.operationId, string.Join(“And”, parameters)); } } } |
– A second filter that I created to eliminate duplication operation ids from being generated when there are multiple Web API routes, like /tables and /api. This issue only happens in Azure Mobile App services and Azure Mobile Services as they have the additional route called “/tables”. A plain WebAPI project would usually have just the /api route.
This happens because at this time, Swashbuckle is generating duplicated operationIds when it finds several WebAPI routes in your code when using reflection.
In fact, it will be generating 2 operationIds per method in the controller, one per base Web API route, because Azure MobileApps has internally two routes, /tables and /api like:
a. /tables/Doctor/{id}
b. /api/Doctor/{id}
Therefore, Swashbuckle will be generating the same operation id name for both base Web API routes.
So, my workaround is to change the name of each operation in Swagger by extending it with its current Web API route.
| internal class IncludeRouteNameInOperationIdFilter : IOperationFilter
{
public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription)
{
//Find current Route name string routeTemplate = apiDescription.Route.RouteTemplate; string BaseRouteName = routeTemplate.Substring(0, routeTemplate.IndexOf(‘/’)); string postfix = “_” + BaseRouteName + “_Route”; // Set the operation id to match the format “OperationThroughRouteName” operation.operationId = string.Format( “{0}_Through{1}”, operation.operationId, postfix); } } |
If you don’t add that second filter, further in the process (almost at the end of this blog post) you’d get errors when trying to publish/register your service in Azure as an IT Managed API. You would get the following error:
“Creating API HealthClinicMobileAppManagedAPI failed: One or more fields contain incorrect values:” Like the error below.
If you have that issue, you can confirm it when trying to validate your Swagger schema with http://editor.swagger.io/ and providing the URL to your generated Swagger, like http://myserver:port/swagger/docs/v1 (see below more info about the Swagger URL), as it will show errors related to duplicated operationIds.
You can see that in that case, Swashbuckle was generating 2 operations per each controller, one based on /tables and the second based on /api, but they are essentially the same methods in each controller
So, to avoid that, set that filter second that I created or you could create another workaround to avoid duplicated operation names in the generated Swagger.
– IMPORTANT: Explicitly set the json data contract serializer to CamelCase in your code in order to have consistent Swagger schema and Json data coming from your service. If you don’t set this right, the PowerApps Authoring tool won’t work properly when consuming your service.
The issue is that the default JSON data contract serialization used by an Azure Mobile App or Web API project with Newtonsoft.Json is CamelCase, so it will be lowering the first letter of each field/property in your Json when returning data through the network. That is a right approach because usually when using JSON (especially when consuming it from JavaScript) it’s common to use CamelCase. Something like “firstName” as a property/field.
On the other hand, if you don’t specify it explicitly, the default schema generation made by SwashBuckle is not consistent with the default serialization made by Web API because SwashBuckle will generate the field/property names in the Swagger metadata as you have it in the .NET C# model, which is usually PascalCase. Something like “FirstName” as property/field.
In order to make both serializations consistent (Swagger schema and actual data in JSON coming from your service), you need to explicitly add a line of code to your Web API or Azure MobileApp project and set explicitly the JSON serializer ContratResolver to CamelCase, even when it coincides with the default in Web API which is also CamelCase. But if you set that line explicitly, SwashBuckle will take it into account when generating the Swagger schema, too. 🙂
So, in your startup.cs class from my Azure MobileApp project, make sure you add the following line of code right after grabbing the HttpConfiguration object:
config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
Now we’ll have something like “FirstName” or “address” as fields/properties in both places (Swagger schema and data in Json).
With that, I have successfully enabled Swashbuckle in my Azure Mobile App and now I’ll have Swagger metadata and Swagger UI created automatically around my service.
We can check it out by running the service again from VS by hitting F5. We’ll get the same “welcome page” that we get in every Mobile App service, but if I now add “/swagger” to the same URL, like:
http://localhost:35715/swagger/
You can see how nicely I can see now what’s my service about! 🙂
I can open the HomeAppointment operation and check its schema automatically generated by Swashbuckle:
Or you can even check the data coming when I run it from this UI tester by pressing the “Try it out” button!
Another thing you need to check is the real Swagger metadata that is being generated. That JSON code is, like I mentioned, being generated automatically by Swashbuckle, and you can grab it by running the URL you see on the top, like:
http://myserver:port/swagger/docs/v1
In my case, I’m getting this Swagger code:
That is precisely the Swagger metadata that PowerApps needs in order to register your service as a PowerApps IT Managed API!
We are all set!, I have already “Swaggerized” my Azure Mobile App service.
For additional info about Swagger and Swashbuckle, check the following articles and sites:
Awesome! Now let’s see how I can deploy my service to Azure’s PowerApp Environment and how to create a new IT Managed PowerApp service…
1.2. Deploy the Azure Mobile App service into the ‘PowerApps Environment’ in Azure
Before getting into the deployment to PowerApps environment in Azure, let me clarify that you could also re-deploy your already swaggerized Mobile App service into your current environment in Azure App Service. Or it could even be deployed in a different cloud or on-premises. This scenario is described in this article “Register an API from Swagger 2.0 API Definition”. But if you are able to deploy your backend API/Service into the same PowerApps Environment it’ll be more cohesive and will have many advantages like having very low latency between your original backend service (i.e. my Azure Mobile App service) and the additional tier of secured Managed APIs provided by PowerApps enterprise. Therefore, my recommended scenario for most cases is to deploy your backend within the same PowerApps environment, although, as mentioned, alternatively it could also be placed in a remote place/cloud/datacenter. In other cases it could make sense, too. It depends.. 😉
Ok, so coming back to my scenario, once the backend service is tested locally and you also have your database up and running as an Azure SQL Database, you can deploy the backend service into the ‘PowerApp Environment’ in Azure.
For that, just go to Azure’s portal. You’d need to have created a PowerApps Environment. You can see how to do that in the ”Step 4: Create an app service environment” within the article What is Microsoft PowerApps enterprise?.
In my case, I’m using a subscription where the PowerApps environment is already created for my tenant, so I just go ahead and brows for PowerApps in the Azure portal.
1. Select Browse in the task bar, then type powerapps and click on it:
2. I see quite a few services and PowerApps that we have deployed in our current PoewrApps Environment (based on an Azure App Service environment):
Ok, so as the first step, I want to deploy my Azure Mobile Service into this environment, within the “Mobile apps” section you see above.
Then, once I confirm that the Azure Mobile App service is up and running, I’ll “wrap it around” with a PowerApps “IT manages service” as I show in the diagram.
For now, let’s do the step highlighted with the #1 circle in the diagram, which means “Just publish the Azure Mobile App in Azure”.
NOTE: Of course, make sure first that you deployed the HealthClinic DB as an Azure SQL Database and that your ConnectionString within the Web.config in the service is pointing to it. Other than that the service won’t work properly and won’t return any data. Like:
3. First, I need to create the “slot” where I’ll deploy my service. With that I mean that I need to create an empty Azure Mobile App service in Azure but created from the PowerApps environment. For doing that, select the “+ New” from the root dashboard in the Azure portal, then click on “Web+Mobile”, then on “Mobile App”, and finally set the name of your Mobile App to a meaningful name like “HealthClinicMobileAppServiceBackend”.
4. After creating your Mobile App, kind of “empty slot” as we still didn’t deploy anything, you should be able to see it from the PowerApps environment:
Now that we have the Mobile App, let’s deploy our code/project!
5. The easiest way to deploy an Azure Mobile App service to Azure is from Visual Studio, so having the project “MyHealth.MobileApp” opened in VS, just right-click on the project and select the “Publish” menu option.
6. You’ll get the new assistant for Azure App Service that comes in the latest Azure SDK (I’m using Azure SDK for .NET (VS 2015) 2.8.1 released on late November 2015) where the deployment for Azure Web apps, Mobile Apps or API Apps are finally unified under “Microsoft Azure App Service”.
Click on “Microsoft Azure App Service” under “Select a publish target”:
7. You’ll see a new dialog from the SDK where you can select the right Azure Subscription and filter by asset’s type. So I filter by type (Mobile App) and then I select the just created Mobile App, like you see below:
8. After that, just press the “OK” button and it should go to the next step where you already will have a new Profile created for you and with all the credentials needed for that obtained from Azure because you should have been authenticated against Azure from Visual Studio previously so you are all set, underneath.
9. At this point you can click on “publish” or click several times on “Next” if you want to see further info. I’ll show all the steps.
I’m selecting the “Debug” configuration just in case I need to debug remotely:
10. At the end of the wizard you can either start a Preview or just go ahead and Publish. Hit the “Publish” button:
11. Then open the “Azure App Service Activity” and check how it is advancing with the deployment:
12. When it is done, it’ll open a browser with the default page for the Mobile App service :
13. But because we already “swaggerized” our service, we can test it out in the cloud right away! – Just write “/swagger” at the end of the URL, like the following and you’ll see our schema and could do the same testing steps we did before, but this time everything is running in Azure’s cloud!
14. IMPORTANT step – Set the Swagger URL into the Mobile App “API Definition” property: If you miss this step, the PowerApps IT Managed Environment won’t list your service when trying to register it, later on in the process.
Before registering the service as PowerApps ‘IT Managed API’, we need to precisely inform/update in Azure where it can get our Swagger schema from. So, copy the URL pointing to your Swagger schema from the Swagger edit box:
And paste it into the “API Definition” property within the Azure Mobile App “Settings“, nd hit the “Save” button.
15. (OPTIONAL) I can also test the Mobile App service from the client Cordova app by just changing the service URL in the TypeScript file named file configService.ts that I showed previously. It should work the same way it did locally.
1.3. Create an ‘IT Managed API’ in the PowerApps Environment in Azure that wraps-out my Mobile App backend service
OK, but so far I just published an Azure Mobile App in Azure. There was nothing related to PowerApps Enterprise just yet.
Now, I want to create a PowerApps “IT Managed API” by registering my Mobile App Service within that “wrapper” (in reality, this wrapper is an additional tier of services that will have a new HTTP URL), so out-of-the-box I’ll get the benefits of PowerApps services which is especially centered on security and Azure AD authentication and authorization.
Securing the services: My current HealthClinic service (Azure Mobile App service) doesn’t have any authentication and authorization implemented. But if I had it, I could connect to it from the PowerApps IT Managed API tier by propagating the security context through security tokens. However, what I’m going to have, though, is a secured PowerApps “IT Managed API” tier as Azure AD authentication comes out-of-the-box when using PowerApps enterprise. As you’ll see later on, the PowerApps connections are used by Active Directory users.
So, let’s create the PowerApps “IT Managed API” by registering my backend service in Azure as I try to illustrate in the image below with the step/circle #2.
It will be pretty simple, it doesn’t require new code or any new implementation.
There’s also an article explaining the process from a generic point of view: Register an API hosted in your app service environment
1. In the Azure portal, select “Browse –> PowerApps”, and then click on the “Manage APIs” section and finally hit on the “+ Add” menu option:
2. In “Create API”, enter the API properties:
In Name, enter a name for your managed API, something like “HealthClinicMobileAppITManagedAPI”. Notice that the name you enter is included in the runtime URL of the API. Make the name meaningful and unique within your organization. In Source, select “From APIs hosted in App Service Environment”:
3. When selecting that option, the portal will query and show you the available services/APIs in the same environment that provide Swagger.
If you don’t se your service listed here it is probably because you missed the step above called “IMPORTANT step – Set the Swagger URL into the Mobile App ‘API Definition’ property”… 😉
Hit OK, and that will trigger the IT Managed API creation by registering my service (HealthClinicMobileAppServiceBackend) as the backend API.
When you register an API, you’re registering the API to your app service environment. Once in the app service environment, it can be used by other apps within the same app service environment.
4. You should be able to check it out listed in the list of IT Managed APIs, like in the following list:
5. You can go further and configure the “Managed API” with additional things like an icon/logo with a public and full HTTP URL to the image file, etc.
So now I see my Managed API with a proper icon:
There are other important properties per Managed API that you can research, like POLICIES, TAGS, etc. like explained in the article “Update an existing API and its properties” but for now we just need to grant access to my user from Azure Active Directory or Active Directory, so I can consume the service from the PowerApps Author Tool.
6. Give users access to the Managed API. Now that the API is created and added to your app service environment, it’s time to give users within your company the permissions to use it. In PowerApps, select your Managed API. For example, I’m selecting the “healthclinicmobileappitmanagedapi” managed API.
Then, select “API user access” menu option and finally hit the “+” link.
7. In this case, in the blade “Add Users” I’m adding my own Active Directory user so I can consume this service from the PowerApps Author tool.
Just hit the “Select” button and we’re all set! We’re finally ready to consume this “IT Managed API” from the PowerApp Author Tool! 🙂
2. Test my new registered PowerApps ‘IT Managed API’ from the PowerApps ‘Authoring Tool’ and create any simple PowerApp mobile app
You can read a lot of info and articles about how to create PowerApps, like the tutorials found from here “Start creating your apps in PowerApps”. Although this type of work will be usually done by Power users rather than developers. But still, we need to test that our services will work for them, right?
For this blog post and because I just want to focus on the developer work you an do when focusing on the Managed API, I’m just going to test the services from the PowerApps Tool, but nothing very fancy.. Actually, this blog post is actually very long.. 😉
Prerequisites
- Install PowerApps from the Store.
- Learn how to configure a control in PowerApps
1. Open the PowerApps app and select “New” –> “Start from Scratch”.
2. Select File –> Connections –> Available Connections and finally your IT Managed API from the list, in my case “healthclinicmobileappitmanagedapi”.
3. Hit the “Connect” button you’ll see on the right panel:
4. This step has created a PowerApps connection listed now under “My connections” in PowerApps app:
But under the covers, it created a PowerApps Connection in Azure. So if you go to the “Connections” in your “IT Managed API” in Azure, you’ll see that connection there with the user and granted rights.
In reality, in PowerApps, it will create a connection per Managed API and user (yes, if you have 50 users for your app, it’ll configure 50 connections), so it can configure user connections in the server/cloud side, cache tokens, etc. The goal is to make really simple the security configuration in the client side. Anyways, here’s the connection that was just created, in the Azure portal:
5. Create a Data Source in PowerApps Author Tool. Before being able to access the services, you also need to create a “Data Source”.
Select the “Data Sources” within the “Content” menu bar:
Then click on the option “Insert your data”
After that, you’ll see your Connections, like the following:
Hit on your Connection and then on the button named “Add Data Source”
After that, you should be able to access to the data coming all the way down from the PowerApps Managed API to the client controls, like the Gallery control that I’m using below.
6. Insert a “Gallery” with data coming from our “PowerApps IT managed API”. Now, go to PowerApps and click on “Insert –> Gallery”:
Then select the “Portrait” gallery that would be suitable for a mobile device:
You will have something like the following design with some test data:
6. Set the connection link from the control. Now we just need to set the connection so we access our Managed API.
Click on the “function edit box” where it has now written “TextualGallerySample” and change that text to the name of your connection, something like
healthclinicmobileappmanagedapi!
You’ll see that when writing the ! symbol, you’ll get all the operations available for that connection/service. That is precisely coming from the Swagger schema.
I can select for instance the operation named “DoctorGetAllDoctorsThroughTablesRoute” and then if you write “()” at the end and yet another “!” you’ll see all the possible fields/properties from the data that will be coming back:
For now, just select/type the call to the whole operation: “healthclinicmobileappmanagedapi!DoctorGetAllDoctorsThroughtablesRoute()”.
7. Configure the fields so you show the data you want in a proper way.
If you change the list item to show the field “name” then you see we’re getting the names of the Doctors.
It is cool that even in design mode we can see the data coming all the way down and being showed in the controls after playing just a few seconds with it and adding a few more fields to the gallery:
8. Run the PowerApp!
Finally, you can run the app by hitting the “play” button or hitting the F5 key:
Here you have a fancier PowerApp so you get a glimpse of what can be done if you are a better visual designer than me! 😉
Notice that the PowerApps client apps are cross-platform, so it could run on any device (iOS, Android or Windows).
What else? well , go to the PowerApps site (https://powerapps.microsoft.com/en-us/tutorials/get-started-test-drive/) and learn how to create more compelling apps than this super simple app that I just created! 
If you send me feedback through my blog, I’ll forward it to the PowerApps team, as my focus is not really PowerApps “per se” but the developer work from Visual Studio and Microsoft Azure.
Have fun! 
Light
Dark
0 comments