Microsoft Azure News, Entwicklungen, Updates, HowTos - Seite 258 von 261

This post series will provide the latest updates and news for Visual Studio Team Services and will be a great way for Azure users to keep up-to-date with new features being released every three weeks. Visual Studio Team Services offers the best DevOps tooling to create an efficient continuous integration and release pipeline to Azure. With the rapidly expanding list of features in Team Services, teams can start to leverage it more efficiently for all areas of their Azure workflow, for apps written in any language and deployed to any OS.

New features released in August 2016

Fall is upon us but the sun is always shining for Team Services users. In August, users got treated with a host of exciting Team Services updates – a major redesign of social coding with Git (new pull requests UI, comments with markdown and emoji, auto complete pull requests), a new clone in Git Tower option, a host of build and CI enhancements and updates in Agile tools and testing.

New navigation – get around Team Services faster

A new Team Services navigation offers a more efficient way of browsing around the various hubs within Team Services, so you can get to where you want in fewer clicks than before

Using Team Services with Jenkins gets easier

With the new improvements in the Jenkins tasks in Team Services, it has become even easier to perform common scenarios such as:

Use Jenkins to validate your Team Services pull requests
Use Jenkins continuous integration for your Team Services Git repository
Use Jenkins to test or deploy your Team Services build
Download Jenkins build artifacts for use in a Team Services test, build, or release

Copying/uploading files to deploy to Linux gets simpler too!

Updates in Team Services now make it easier to copy files over SSH during CI and CD. The following guides are great pointers on enabling deployment to Linux from Team Services/TFS.

Deploy an Azure Red Hat Linux VM running Apache Tomcat.
Deploy an Azure Ubuntu Linux VM running Apache Tomcat.

If you prefer uploading files via FTP, the new FTP upload task will make it easier to do so as part of a build.

Track requirements quality right on the team Services Dashboard

It is now easier to link your automated tests to requirements and use Dashboard widgets to track the quality of each requirements you want to track.

Team Services build pool gets .NET Core agent and more

The hosted build pool has been updated with new Xamarin versions and a .NET Core agent.

New extensions for Team Services

See the extensions monthly roundup for a preview of Definition of Done, Personas and Product Vision extensions.

Inside Team Services – Summer Interns and Package Management

See what three awesome interns are doing to improve the Package management experience in Team Services.

Quelle: Azure

1. September 20161. September 2016

da Agency

Microsoft enabling customers to "go to" MARS-E

We’re not referring to the planet (maybe one day?), but we are still excited to announce Microsoft Azure is the first hyper-scale #cloud computing platform to enable Affordable Care Act (ACA) Administering Entities (AEs) to address the Minimum Acceptable Risk Standards for Exchanges (MARS-E) 2.0 security and privacy control requirements.

Azure provides controls and capabilities that can be used by customers to help manage MARS-E 2.0 control requirements, reaffirming Microsoft’s continued commitment to enable healthcare industry customers to meet their security, legal, and regulatory needs.

Microsoft Azure enables our customers who process healthcare information to meet their obligations for protecting data in a manner that is compliant with MARS-E security requirements. Microsoft offers a comprehensive portfolio of authorizations and achieving MARS-E compliance complements our existing FedRAMP, HIPAA/HITECH, and HITRUST-certified offerings, strongly positioning us to help our customers comply with a myriad of healthcare industry requirements.

MARS-E was originally published in 2012 and contains the information security guidance, requirements, and templates for AEs including state and federal Health Insurance Exchanges (HIX) or marketplaces who facilitate purchase of health insurance by consumers and small businesses. The exchanges handle Personally Identifiable Information (PII), Protected Health Information (PHI) or Federal Tax Information (FTI) of U.S. citizens. MARS-E provides guidance for state and federal HIXs and their contractors regarding the minimum-level security controls that must be implemented to protect information and information systems that Centers for Medicare and Medicaid Services (CMS) oversees. The new MARS-E 2.0 framework has been effective as of September 2015, and includes significant updates to security and privacy controls.

While we are still grounded here on Earth, healthcare industry companies can now operate and build in an environment when leveraging the Microsoft Azure platform, which has a layer of assurance specifically enforcing the type of data protection critical to the healthcare industry and its regulators. This milestone is another example of our commitment to being the leader in providing trusted cloud solutions. Visit the Microsoft Trust Center for more information.
Quelle: Azure

31. August 201631. August 2016

da Agency

Azure SQL Data Warehouse general availability expanding to 18 regions worldwide

We are excited to announce the general availability of Azure SQL Data Warehouse in four additional regions—North Europe, Japan East, Brazil South, and Australia Southeast. These additional locations bring the product worldwide availability count to 18 regions – more than any other major cloud provider.

SQL Data Warehouse is your go-to SQL-based view across data, offering a fast, fully managed, petabyte-scale cloud solution. It is highly elastic, enabling you to provision in minutes and scale up to 60 times larger in seconds. You can scale compute and storage independently, allowing you to range from burst to archival scenarios, and pay based off what you’re using instead of being locked into a confined bundle. Plus, SQL Data Warehouse offers the unique option to pause compute, giving you even more freedom to better manage your cloud costs.

With general availability, SQL Data Warehouse offers an availability SLA of 99.9% – the only public cloud data warehouse service that offers an availability SLA to customers. Geo-Backups support has also been added to enable geo-resiliency of your data, allowing SQL Data Warehouse Geo-Backup to be restored to any region in Azure. With this feature enabled, backups are available even in the case of a region-wide failure, keeping your data safe. See this blog post for more info on the capabilities and features of SQL Data Warehouse.

Getting started with SQL Data Warehouse is easy and you can provision a data warehouse within minutes. It easily integrates with business intelligence tools like Power BI and with Azure Machine Learning for predictive analytics. Begin today and experience the speed, scale, elasticity, security and ease of use of a cloud-based data warehouse for yourself.

Azure SQL Data Warehouse regional availability

Azure SQL Data Warehouse is generally available in the following regions: North Europe, Japan East, Brazil South, Australia Southeast, Central US, East US, East US 2, South Central US, West Central US, West US, West US 2, West Europe, East Asia, Southeast Asia, Central India, South India, Canada Central, Canada East.

Learn more about Azure services availability across regions on Azure’s regional information page.

Share your feedback

We would love to hear from you about what features you would like us to add. Please let us know on our feedback site what features you want most. Users who suggest or vote for feedback will receive periodic updates on their request and will be the first to know when the feature is released.

Learn more

Check out the many resources for learning more about SQL Data Warehouse, including:

What is Azure SQL Data Warehouse?
SQL Data Warehouse best practices
Video library
MSDN forum
Stack Overflow forum
Quelle: Azure

31. August 201631. August 2016

da Agency

Azure Storage PowerShell v.1.7 – Hotfix to v1.4 breaking changes

Breaking changes were introduced in Azure PowerShell v1.4. These breaking changes are present in Azure PowerShell versions 1.4-1.6 and versions 2.0 and later. The following Azure Storage cmdlets were impacted:

Get-AzureRmStorageAccountKey: Accessing keys
New-AzureRmStorageAccountKey: Accessing keys
New-AzureRmStorageAccount: Specifying account type and endpoints
Get-AzureRmStorageAccount: Specifying account type and endpoints
Set-AzureRmStorageAccount: Specifying account type and endpoints

To minimize impact to cmdlets, we are releasing Azure PowerShell v1.7 – a hotfix that addresses all of the breaking changes with the exception of specifying the Endpoint properties for New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount. This means no code change will be required by customers where the hotfix is applicable. This hotfix will not be present in Azure PowerShell versions 2.0 and later. Please plan to update the above cmdlets when you update to Azure PowerShell v2.0.

Below, you’ll find examples for how the above cmdlets work for different versions of Azure PowerShell and the action required:

Accessing keys with Get-AzureRmStorageAccountKey and New-AzureRmStorageAccountKey

V1.3.2 and earlier:

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key1

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key2

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key1

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key2

V1.4-V1.6 and V2.0 and later:

The cmdlet now returns a list of keys, rather than an object with properties for each key.

# Replaces Key1
$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[0].Value

# Replaces Key2
$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[1].Value

# Replaces Key1
$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[0].Value

# Replaces Key2
$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[1].Value

V1.7 (Hotfix):

Both methods work.

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key1

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[0].Value

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key1

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[0].Value

Specifying account type in New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount

V1.3.2 and earlier:

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

V1.4-V1.6 and V2.0 and later:

AccountType field in output of this cmdlet is renamed to Sku.Name.

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

V1.7 (Hotfix):

Both methods work.

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

Specifying Endpoints in New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount

V1.3.2 and earlier:

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

$blobEndpoint = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

$blobEndpoint = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

V1.4-V1.6 and V2.0 and later:

Output type for PrimaryEndpoints/Secondary endpoints blob/table/queue/file changed from Uri to String.

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

$blobEndpoint = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

$blobEndpoint = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

Note: The ToString() method for these cmdlets will continue to work. For example:

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.ToString()

V1.7 (Hotfix):

No hotfix was provided for this breaking change. The return value’s endpoints will have to continue to be string, as changing these back to Uri would introduce an additional break.

Next steps

Download Azure PowerShell v1.7 (hotfix).
View all Azure PowerShell releases.
See migration guide for Azure PowerShell 2.0.

Quelle: Azure

31. August 201631. August 2016

da Agency

Exploring HockeyApp data in Application Insights: introducing the Bridge App

In a previous blog, we announced that soon, the data from any app in HockeyApp would be accessible through the Analytics, and Continuous Export features in Application Insights. This functionality is now available to you through the new HockeyApp Bridge App! With it, you will now be able to query raw HockeyApp data and gain insights from it, as well as export it to your own data store for warehousing purposes. In this blog post, we’ll see how to take advantage of this new feature as well as answer common questions about how to instrument your applications going forward.

The HockeyApp Bridge App

HockeyApp is a great tool for instrumenting your mobile and desktop applications. It has powerful facilities for tracking distribution, adoption, crash reporting, feedback, and other data. It also has a collection of dashboards through which this data can be explored. Sometimes, however, you need to access, analyze, and visualize your data in ways other than are presently exposed in HockeyApp. This is where the new HockeyApp Bridge application type in Application Insights comes in! Your HockeyApp data will be available to you in its raw form to query and analyze using Analytics and export to your own data store via Continuous Export!

Creating a HockeyApp Bridge App in Application Insights

The HockeyApp Bridge App is the core feature that will enable you to access your HockeyApp data in Application Insights through the Analytics and Continuous Export features. Data collected by HockeyApp after the creation of the HockeyApp Bridge App will be accessible from the aforementioned features. All you need to set up a Bridge App is to create a new Application Insights resource with the “HockeyApp Bridge Application” app type. You will need to provide an API key that you can obtain from your HockeyApp settings, and soon after creating it, the Analytics and Continuous Export features will be accessible to you against your HockeyApp data.

Please see our documentation for a detailed walkthrough of setting up a HockeyApp Bridge App, as well as to learn more about the various ways to access your data.

Using the HockeyApp Bridge App

Let’s look at a simple practical example of using the HockeyApp Bridge App. In this case, we’ll be looking at telemetry generated by an iOS app that was created for the Xamarin Evolve 2016 conference (App Store link). This app was instrumented using the iOS HockeySDKs.

First, let’s create a HockeyApp Bridge App per the instructions above:

Now, let’s press the Analytics button to open a new Application Insights Analytics window. Once loaded, let’s open a new tab, type in the following query, and press “go”:

customEvents
| summarize country_Count = count() by client_CountryOrRegion
| order by country_Count
| render piechart

And just like that, we now have a pie chart of the country of origin of our users!

This is a very simple scenario, but building on it with the extensive querying capabilities in Analytics, you can begin to really investigate and gain insights about your HockeyApp applications. In parallel, you can configure Continuous Export to store this data in your warehouse, to later join with other data sources. All of these possibilities and more are now possible with the new HockeyApp Bridge App in Application Insights!

FAQs

Over the last several blog posts around instrumenting mobile and desktop apps, we’ve received some common questions:

Can you summarize how to instrument my applications going forward?

Please refer to the simple flowchart below to determine how to instrument your applications and access your data going forward (click for a large version):

Should I use Application Insights or HockeyApp to instrument my mobile and desktop applications?

You should use HockeyApp to instrument mobile and desktop applications going forward. HockeyApp provides great capabilities for these types of apps including distribution, adoption, crash reporting, and feedback tracking.

What if I need more information than the dashboards in HockeyApp provide?

Should you need to access or analyze the raw data from HockeyApp beyond the pre-made dashboards available there, you should create a HockeyApp Bridge App as described in this blog post. You can then further interact with your data through the Analytics and Continuous Export features in Application Insights.

What SDKs should I use for my mobile and desktop applications?

While the Application Insights SDKs for mobile and desktop applications will continue working for the foreseeable future, you should use the HockeyApp SDKs going forward. More details about this are available in our previous blog post.

How do I track handled exceptions in my mobile and desktop applications?

Tracking of handled exceptions is not natively available for mobile and desktop apps. It is however easy to implement via the Custom Event mechanism. To do this, a helper method can be created as described in the HockeyApp KB repository.

Next steps

Instrumenting your mobile or desktop application is easy – use HockeyApp and the HockeySDKs, and create a HockeyApp Bridge App in Application Insights if you need to analyze or access your raw data. Continue using Application Insights and the Application Insights SDKs for all other application types.

As always, please share your ideas for new or improved features on the Application Insights UserVoice page, and for any questions visit the Application Insights Forum or HockeyApp Support!
Quelle: Azure

30. August 201630. August 2016

da Agency

Build your data science skills–and your network–in Atlanta

Over the last decade, data science has gone from a murmur to a deafening roar.

The demand for skilled data scientists is showing up everywhere—in every industry. And whatever their titles, the community of people who can do analysis, machine learning, big data, or visualization have never been more universally valued.

It’s a good time to be a data scientist.

As a senior recruiter in AI and machine learning at Microsoft, I’ve experience this rapid evolution from the front row. We now have approximately 5,000 members that belong to the company’s internal Machine Learning and Data Science community, sharing insights and technical expertise across nearly every team and discipline. They’re woven into our very DNA.

A lot of these folks will be in Atlanta this September 26–27 at the Microsoft Data Science Summit—together with leading thinkers, researchers, and experts from across data science and machine learning. They’ll be sharing strategies, tools, tips, and breakthroughs with the data science community.

Build your skills, see what your peers are up to, and get hands on with the latest tech.

Data scientists of all stripes are integral for driving business forward, understanding customers, and helping organizations innovate. And right now, new tools are emerging quickly to help you move even faster. In Atlanta, you’ll get an insider’s look at the new ways that Microsoft and other businesses are applying these technologies, and get hands-on training in using them yourself. Questions about Cortana Intelligence Suite, SQL Server, or Microsoft R? This is the place to deepen your expertise. Set up a 1:1 meeting with the people who build and run these technologies to get answers that fit your particular scenario.

Data science is exploding in so many directions that there’s a breathtaking array of demos and real-world examples awaiting you as well. Come see what others are doing. Share ideas, puzzles, and successes with your peers and Microsoft presenters. And discover new ways to help your organization and expand your career.

But register soon! The Microsoft Data Science Summit is coming up fast.

26. August 201626. August 2016

da Agency

Networking for a hybrid application environment

Supporting a network in transition: Q&A blog post series with David Lef

In a series of blog posts, this being the fourth and last, David Lef, Principal Network Architect at Microsoft IT, chats with us about supporting a network as it transitions from a traditional infrastructure to a fully wireless #cloud computing platform. Microsoft IT is responsible for supporting 900 locations and 220,000 users around the world. David is helping to define the evolution of the network topology to a cloud-based model in Azure that supports changing customer demands and modern application designs.

David Lef identifies the considerations and challenges of supporting a network environment as line of business applications move from an on-premises environment to the cloud using Azure.

Q: Can you explain your role and the environment you support?

A: My role at Microsoft is principal network architect with Microsoft IT. My team supports almost 900 sites around the world and the networking components that connect those sites, which are used by a combination of over 220,000 Microsoft employees and vendors that work on our behalf. Our network supports over 2,500 individual applications and business processes. We’re responsible for providing wired, wireless, and remote network access for the organization, implementing network security across our network (including our network edges), and connectivity to Microsoft Azure in the cloud. We support a large Azure tenancy using a single Azure Active Directory tenancy that syncs with our internal Windows Server Active Directory forests. We have several connections from our on-premises datacenters to Azure using ExpressRoute. Our Azure tenancy supports a huge breadth of Azure resources, some of which are public-facing and some that are hosted as apps and services internal to Microsoft, but hosted on the Azure platform. We currently host forty percent of our LOB apps using Azure, and that number is continually increasing.

Q: Can you give me a quick history of how this migration has happened and how the network teams have supported it?

A: It started with Azure platform as a service (PaaS), which we were using for internal and external app and service solutions. PaaS was the first primary component that was offered on Azure, so we naturally started there when developing solutions. Most of our early applications were hosted completely in Azure. The hybrid scenario wasn’t fully developed or supported, so we didn’t implement that in our solutions.

However, as Azure networking and infrastructure as a service (IaaS) components have been introduced and matured, we’ve had much more flexibility in how we implement Azure-based solutions and how those solutions interact with each other and our on-premises infrastructure.

We adopted a strategy for Azure migration that addressed the most logical migration scenarios first: basic web apps, any new solutions, and any solutions that were targeted for redesign. Next, we looked at some more challenging apps, such as those with large bandwidth or resource usage requirements, or those that had regulatory implications or significantly affected business-critical operations. Finally, the most difficult and costly apps are left, such as customized legacy solutions with code that is difficult to update.

The main enablers for hybrid line of business (LOB) apps were the addition of ExpressRoute, which gives any Azure tenant the ability to obtain a private, dedicated connection to Azure from their datacenter, and the maturation of Azure IaaS, which has enabled us to take on-premises infrastructure and migrate it directly to Azure-hosted virtual machines without having to modify the components of the infrastructure. We have also widely adopted software as a solution (SaaS) solutions, such as Office 365.

Our primary support channel has been to facilitate the connectivity required by hybrid solutions. A lot of the connectivity is on the back end through ExpressRoute and the configuration and management required to connect our datacenters to Azure, but we also manage networking within Azure. There are some important security and compliance considerations when cloud and on-premises mix, and we’ve been diligent in ensuring that our data and infrastructure in the cloud is as secure as it is in our datacenters. Most of our Azure apps and services are available from some Internet touch-point, so it’s important for us to delineate between front end and back end within our solutions. We don’t want our infrastructure living in IaaS exposed to the public Internet.

Q: Have the challenges changed through this journey?

A: They’re always changing! Change is the nature of the cloud, and that’s really the first challenge we faced: understanding that solutions, processes, and methods are fluid and changing in Azure. There is a continuous stream of features being offered and changed; some of them can be inconsequential to a solution, while others can be game changers.

We understand that there are many ways to connect to Azure, from the datacenter perspective and from the user perspective. As much as possible, we try to provide the freedom to allow our application owners in Azure the choice in how they connect their apps to the datacenter and to their customer.

As an organization, we’ve had to learn how to modify our strategies to focus on the cloud first. Hosting LOB apps in Azure is a fundamental change in how the apps are used and supported. We’ve been diligent in keeping support and communication channels open with our application owners and our customers, and it’s critical that they understand the nature of the cloud and what that means to them and their business. Our cloud-first, mobile-first strategy means that everything is directed to Azure first, and it’s a cultural change that has been spearheaded by our CEO, Satya Nadella, and cascaded down through the rest of the organization. There is an excellent article that highlights the continuing evolution of our cloud strategy.

From a technical perspective, we have a lot of tools and processes in place to help us manage our Azure resources in a way that matches the fluidity of the environment. The integration of Azure Resource Manager (ARM) has been critical to centralizing and standardizing solution management and configuration within Azure. Resource groups and ARM templates provide the functionality we need to configure things properly and ensure they stay configured properly through changes to app requirements or Azure functionality. It’s a constant challenge to maintain both the datacenter and Azure concurrently, both technically and logistically. Migrations to Azure are a constant stream, so the configuration of our datacenters and Azure environments are in constant flux. We have and will have a long legacy tail that will be carried around for a while, so we have to ensure that we’re providing and managing communications between Azure and our on-premises environments as proactively as possible, and educating our tenants and users on how to use both effectively.

Learn more

JSON support is generally available in Azure SQL Database

We are happy to announce that you can now query and store both relational and textual data formatted in JavaScript Object Notation (JSON) using Azure SQL Database. Azure SQL Database provides simple built-in functions that read data from JSON text, transform JSON text into table, and format data from SQL tables as JSON.

You can use JSON functions that enable you to extract value from JSON text (JSON_VALUE), extract object from JSON (JSON_QUERY), update some value in JSON text (JSON_MODIFY), and verify that JSON text is properly formatted (ISJSON). OPENJSON function enables you to convert JSON text into a table structure. Finally, JSON functionalities enable you to easily format results of any SQL query as JSON text using the FOR JSON clause.

What can you do with JSON?

JSON in Azure SQL Database enables you to build and exchange data with modern web, mobile, and HTM5/JavaScript single-page applications, NoSql stores such as Azure DocumentDB that contain data formatted as JSON, and to analyze logs and messages collected from different systems and services. Now you can easily integrate your Azure SQL Database with any service that uses JSON.

Easily expose your data to modern frameworks and services

Do you use services that exchange data in JSON format, such as REST services or Azure App Services? Do you have components or frameworks that use JSON, such as Angular JS, ReactJS, D3, or JQuery? With new JSON functionalities, you can easily format data stored in Azure SQL Database as JSON and expose it to any modern service or application.

Easy ingestion of JSON data

Are you working with mobile devices or sensors, services that produce JSON such as Azure Stream Analytics or Application Insight, or systems that store data in JSON format such as Azure DocumentDB or MongoDB? Do you need to query and analyze JSON data using well-known SQL language or tools that work with Azure SQL Database? Now, you can easily ingest JSON data and store it into Azure SQL Database, and use any language or tool that works with Azure SQL Database to query and analyze loaded information.

Simplify your data models

Do you need to store and query both relational and semi-structured data in your database? Do you need to simplify your data models like in NoSQL data platforms? Now you can combine structured relational data with schema-less data stored as JSON text in the same table. In Azure SQL Database you can use the best approaches both from relational and NoSQL worlds to tune your data model. Azure SQL Database enables you to query both relational and JSON data with the standard Transact-SQL language. Applications and tools would not see any difference between values taken from table columns and the values extracted from JSON text.

Next steps

To learn how to integrate JSON in your application, check out our Getting Started page or Channel 9 video. To learn about various scenarios that show how to integrate JSON in your application, see demos in this Channel 9 video or find some scenario that might be interesting for your use case in these JSON Blog posts.

Stay tuned because we will constantly add new JSON features and make JSON support even better.
Quelle: Azure