I'm in the process of evaluating App Service and in particular Api apps and logic apps. I want to be able to make use of git deploy for an Api app instance.
This article https://azure.microsoft.com/en-gb/documentation/articles/web-sites-publish-source-control/ mentions that even though it is based on web apps, you can apply the same processes to api apps, however, when I attempted to follow the tutorial using an api app instance, I was unable to see the "deployment" tile on the api app blade in the azure portal. I was able to complete the tutorial for the web app instance.
Does anyone know why I wouldn't be able to see the deployment tile for an api app blade?
I want to use the api app so I can make full use of swagger and the logic app service.
Edit
Thinking about it, do I even need to use an api app or could I get away with using a web app (with swagger meta data) for connecting to logic apps?
Update
Found it - see my own answer.
OK, I found it and it's not a bug. I was being (a bit) dumb. Following this article, I discovered that I needed to click on the Api app host section and then all settings then continuous deployment.
This is, imho, a poor UX decision here, given the blade looks exactly the same as others that do have the deployment tile, but at least I can set up git deploy for my api apps now.
#Simon
This may be a bug - I will poke the Azure Team for it asking that. Even though, WebApp, APIApp and MobileApp are EXACTLY the same service, only changing name. So, if you can see deployment tile for one of them, you should be able to see all others then.
BUT, there is a "invisible business link" around them that make all things working. When you work with Logic Apps, it will search for custom API Apps at - guess what! - you API App list. So, you can host a API application at WebApp, but probably the Logic App will not go for it by default.
Related
I have a web app written in Node and hosted as an Azure web app. I have setup Application Insights web tests for other sites that do NOT require auth and these work fine. Now I need to test a route that requires authentication, but it is not obvious how to do this on the Azure Portal. Can this actually be done? I have seen some posts about doing this through Visual Studio but I really want to avoid that if at all possible.
As per the article here - https://learn.microsoft.com/en-us/azure/application-insights/app-insights-overview - if you don't want to touch code (and hence, redeploy) you cannot do what you are asking in the question.
Looks like diving deep into code is the only way
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
A couple weeks back our Mobile App was migrated from the old portal to the new one and it hasn't behaved properly since.
Our main issues are:
We cannot access any logs files, the tab for Diagnostics logs stopped working entirely on Wednesday but even before that we never got any useful data out of this. When something goes wrong with our nodejs backend we can't find any clue as to what went wrong like we could in our old portal under the logs tab.
We are unable to access the FTP server entirely, it just won't let us login even though the credentials are correct and have been reset multiple times in attempts to get them working.
The server is throwing errors about not having enough disk space left even though we should have 53Gb to go (we're currently using 1.05Gb out of 55Gb)
Our deployments slots are not working at all, when we push our code to the deployment slot it just doesn't work, every request we make to the deployment slots tells us we're not allowed to do anything.
We are running a standard tier Mobile App server. The backend is in NodeJS, our CMS is in ASP.Net and our app itself is in Xamarin Forms.
The issues started after we migrated the server a couple weeks back from the manage.azure.com portal to portal.azure.com.
What can we do?
Edit:
We got through to Microsoft via the payed support plan which we're getting refunded because these are basic functionalities which don't work as advertised after the migration. I've got a call with them in about three hours to get things sorted, if I learn anything we can do ourselves I will update this post to share the knowledge.
This needs to be a support request to Microsoft.
If you can, open an incident with Microsoft Support. If you can't, post a question in the MSDN Community Forum. (We need to ask about particulars of your site and that isn't an appropriate topic for SO)
As the architecture of Mobile Apps is changed from Mobile Services, now the mobile apps migrate to Azure App Services.
Actually the Mobile Apps backend in Node.js is an expressjs project, and the mobile app sdk for node is a middleware of express. So the way for diagnostics and troubleshooting has changed from before we use Mobile Service. You can refer to https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-node-backend-how-to-use-server-sdk/#Debugging for details about Debugging and troubleshooting for mobile services.
Additionally, we can leverage the Visual Studio Team Services editor as the section How to: Edit code in Visual Studio Team Services shows in the link above, we can monitor the output of the Mobile Apps backend application. E.G:
About your FTP issue, please double check your deployment Username, when we login to FTP server on Azure, we need to input the full FTP user name which is "app\username":
You can refer to https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/#enabling-diagnostic-logs for details.
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.