all the tutorial videos of azure shows the data tab in mobile services but in real it is not present there.
https://drive.google.com/file/d/0BxhoXvChLA34dDB1Mm1KVFIwRUU/edit?usp=sharing
When using the .NET backend, creating tables and custom APIs are done code first and you can't control them via the portal.
For tables start here: http://www.windowsazure.com/en-us/documentation/articles/mobile-services-dotnet-backend-windows-store-dotnet-get-started-data/
I don't see any tutorials up yet on the custom API path yet but I may have missed them.
Related
I have .net application with me. Inside the application I want to add a functionality like the users can communicate between themselves by connecting to MS Teams. So I need my user to connect to MS Teams via my application. Please provide a step by step execution on this.
I don't have any idea on how to integrate my application with MS Teams. Somewhere I heard that it can be done using MS Graph API.
Please take a look at this api first to check if the feature was what you want.
Per my understanding, what you want maybe a web application and you can send messages in the webpage and finally it will be send to Teams. If I was right, then the API may help you. Microsoft graph api has the ability to Send a new chatMessage in the specified channel or a chat.
If you want to use this api, you need to have an Azure AD application then add api permission for this app. Then register this app to your web application, so that you can sign in your app to authenticate and authorize the graph api. Then you need to compose your app to prepare the message content to be sent by the api.
Here's an official sample to create web application and register aad app into the web app and call graph api.
I am new to PowerApps development. I am trying to connect PowerApps to my custom APIs (Azure app api) and getting results of "resource not found". I can call the api from browsers, postman no problem. The .json file I use for PowerApps is the same as the one I use for editor.swagger.io (for testing). I checked the log file of the application on azure, all of the requests from browsers logged but not the ones from PowerApps. My question is, how PowerApps calls APIs and what is the right format of the .json file used for PowerApps app?
Thank you.
I would recommend trying again, we had a small issue on our backend that was causing some 404's at times. A fix for it has been deployed so you might see it work.
PowerApps uses Swagger to determine the shape of the REST api to be able to project those APIs into "formulas" that can be used easily in the client.
Also, for development/troubleshooting purposes I highly recommend using Fiddler to see exactly the REST call that PowerApps is doing and making sure the URL and parameters are correct. If not then look into your swagger definition and make sure there are no issues with the paths provided there.
You might also check that your Azure App API has either:
The PowerApps IP Addresses Whitelisted OR
If available, the "Allow Access to Azure Services" option toggled
When building Azure SQL backends for PowerApps, one of these paths must be followed.
I am trying to port my Android application into a Cloud based one. Where I wanted the data stored in cloud. I am a .NET guy so looking into Azure. I see Azure Mobile services which allows me to create tables and ability to authenticate. I also Looked into Azure SQL database.
I would like to know what is the difference between these two services and what are the scenarios using mobile services gives values than using Azure SQL database
Actually, the tables you see listed in Azure Mobile Services are actually tables that are in an Azure SQL Database instance. The Mobile Services provides an abstraction layer on top of the tables in SQL Server. If you use the current JavaScript back-ended mobile services you'll see the table in the management portal and it uses the dynamic nature of JavaScript to provide what appears to be a NoSQL like experience with Azure SQL DB in that you can send in an object and properties it doesn't recognize will be added to the table schema (you turn this off when you ship to production :) ). The big thing to remember is that under the hood the database is an Azure SQL DB, so you should have access and do anything via the one created by Azure Mobile Services as you can with the raw Azure SQL DB.
By using Azure Mobile Services you get an API hosting layer that you can use to do direct access to the tables (based on the permissions you hinted at) but also to just about anything utilizing the custom API feature.
If you chose to bypass the Azure Mobile Services you'd likely want to have some API layer between your Android app and the data for a variety of reasons (security, abstraction of data location, etc.). In which case you'd have to write and host that API layer somewhere. Other options within Azure would be a Web API site in Azure Web Sites, an API hosted in an Azure Cloud Service or all the way up to an Azure VM; however, as you slide up that scale you're taking on more and more responsibility and work.
The scenario that is useful to use Azure Mobile Services over the Azure SQL DB is pretty much the scenario you have. You don't have to maintain your own hosting API layer, just the code the API layer executes. You can scale an necessary (to a very large scale indeed) and also get features like the push notifications and web jobs (though those are also things you can do via other services in Azure if you'd like). Thinks of Azure Mobile Services as a higher level grouping of Azure services that are helpful to mobile developers.
Mobile services provide you with built-in push notification features and other such mobile friendly features too. They are more mobile oriented in a way.
I have SOAP services with data. I want to download all data from that service and upload it to my own server and then use these data from my server (don't worry I have permission for that). I want to do it because now I don't have function from that service which I need.
I want to use Windows Azure for this and I think SQL Database scenario would be best. Now I have classes for previous SOAP service so I think EF Code first would help me with creating database and I upload data somehow. But what about API? How can I access my data from windows phone or tablet? Is azure database enought or I must create more? Is there any good article for that?
I think what you are saying, is that you are aggregating data from several sources and storing the information in your own database. And, you would like your database to be Azure Database. Then, you want to build an API to expose the data you retrieved.
If this is indeed your goal, then yes, Azure will do everything you need. I'd recommend checking out Web API in conjunction with your Azure deployment. I've used this scheme with some success over the past year.
Warning: You should know that Azure Database does not have an SLA which means that Microsoft does not guarantee any level of performance including transactions/second. This means that if your API has a high load, you could end up getting throttled heavily in an unpredictable way. I've been bitten by this before and ended up moving my data to Azure Table Storage instead.
Windows Azure gives you a few options to expose an API to your mobile clients:
You could build an API yourself with the ASP.NET Web API (and use SQL Azure as backend): Mobile-friendly REST service using ASP.NET Web API and SQL Database
You can use Windows Azure Mobile Services, this does all the heavy lifting of building a backend for you
I am developing a Flex application that will need to 'pull' information from an ERP system such as SAP or Peoplesoft via the clients web service.
My application will need to pass credentials & query to a Query_URL and receive the returned data. I saw a Flash Builder 4 presentation where the Adobe evangelist created a similar application using Twitter.
Insights or links to example code would be appreciated.
Tour de Flex contains some examples for making SOAP and plain old XML Web Service requests (under Data Access). This is the typical way that requests are made to a back-end ERP (or similar) system.