Quantcast
Channel: MSDN Blogs
Viewing all 5308 articles
Browse latest View live

Azure Functions と Cosmos DB によるサーバーレス・コンピューティング

$
0
0

Microsoft Japan Data Platform Tech Sales Team

森本 信次

Azure Functions とは?
まず始めに簡単に Azure Functions について触れておきます。Azure Functions は 小さなプログラムコードを、「関数」(Function)として定義・実行することができます。アプリケーション全体や、プログラムを実行する仮想マシンなどの環境を意識しなくてもよいので、サーバレス・コンピューティングとも呼ばれていて、手軽に実行することができます。機能の詳細についてははこちらのドキュメントをご参照ください。

サーバーレス・コンピューティングを体感してみましょう
前回は フルテキスト検索機能を提供する Azure Search と Cosmos DB の連携について取り上げましたが、今回は Azure Functions と Cosmos DB を連携させることで、従来の手法よりもはるかに少ないコードですばやく簡単に Cosmos DB にデータを格納できる様子を Step 1~3 の流れに沿ってご紹介します。

Step 1. Azure Cosmos DB アカウントを作成
Azure Portal から 前回同様 Cosmos DB アカウント ("planet-cosmos")を作成します
CosmosDB_CreateAccount

Step 2. Azure Functions の作成と設定
Azure Portal から Azure Functions (planet-cosmos-funcapp)を作成します。
AzureFunctions_01
関数を新規に作成します。
AzureFunctions_03
[webhook + API] を選択後 [この関数を作成する] を選択します。今回は CSharp (C#) を言語として使用します。
AzureFunctions_04

webhook とは?
ここで “webhook” という見慣れない言葉で出てきましたが、webhook は Web アプリケーションでイベントが実行された際、外部サービスに HTTP で通知する仕組みです。今回の例では、イベントが HTTP Request で、外部サービスが Cosmos DB に相当します。
AzureFunctions_webhook_01


webhook 要求を受け取る度に実行される関数用のC#テンプレートを選択します。関数名として “MyTaskList” としました。
AzureFunctions_07_01
新しい出力として “Azure DocumentDB ドキュメント” を選択します。
AzureFunctions_09
Step 1. で事前に準備しておいた CosmosDB アカウント情報を指定して、データベース名、コレクション名を指定します。
AzureFunctions_11
作成した関数 “MyTaskList” のパラメータを JSON 形式のデータとして組み立てて Cosmos DB に保存するためのコードを記述します。
AzureFunctions_12
[関数] タブで、ポータルの右側にある [テスト] リンクをクリックし、パラメーターの追加 で 次の HTTP クエリ文字列を入力して、[保存] します。

AzureFunctions_15


Step 3. テストを実行してデータが格納されているかを確認
最後に Azure Portal から Step 2 で作成した Azure Functions ("planet-cosmos-funcapp") のテスト実行を行い、Cosmos DB にデータが格納されているかを確認します。
CosmosDB_Result
作成した Azure Functions を他のアプリから呼び出すには、Azure Functions の [関数のURLの取得] から入手できる URLにアクセスします。
AzureFunctions_18

最後に
いかがだったでしょうか? 今回は Azure Functions を使用して Cosmos DB にデータを格納する流れをご紹介しました。開発者にとっての Azure Functions を使用するメリットは C#, F#, Node.js, Java, PHP などの開発言語を引き続き使用できる一方で、OS やミドルウェアを意識する必要がなくなり、アプリケーションロジックのみに集中できるようになることです。今回は C# のコーディングを一例としてご紹介しましたが、これ以外の言語についてもこちらにサンプルが公開されていますので、お好みの言語を使って サーバーレス・コンピューティングを体感頂ければと思います。


Skype-a-Thon Wrap Up 2017

$
0
0

 

 

 

 

 

November 28th and 29th 2017 Microsoft held our Global Education Skype-a-Thon 2017 to open hearts and open minds which was a huge success! Together, we've connected nearly half a million students and travelled over 14,500,000 virtual miles in 48 hours! Thank you to all the teachers, speakers, and students who made this achievement possible. A special thanks comes from the Microsoft Edu Team in the UK, going out to all our amazing educators and MIEExpert community in the UK who participated in this amazing experience.

Be inspired by innovative educators bringing incredible experiences to the classroom, like Mystery Skype, Virtual Field Trips, Guest Speakers and a range of other activities as we travel virtually around the world. Watch the video below to see this year's amazing Global Journey, featuring some of our amazing Microsoft Showcase schools here in the UK, St Joseph's RC CofE Primary and Nursery School in Derbyshire and Ark Swift Primary in London. 

During Skype-a-Thon St Joseph's, a small primary school in Derbyshire, travelled on a Virtual Field Trip to Lisbon Zoo in Portugal where they completed an exciting quest to locate the Princess' crown! Following their adventure, the children also Skyped with the Director of Education in the UK, Ian Fordham, and told him about their inspiring Skype-a-Thon experiences and asked him questions about his job at Microsoft.

Over the two days, Ark Swift Primary, part of the Ark Academy, visited Microsoft HQ in London Paddington to also participate in Skype-a-Thon adventures. They connected with Anthony Salcito, Vice President of Worldwide Education at Microsoft, over Skype and again shared their virtual travels and asked him questions about his work with Microsoft. In addition, Cindy Rose, CEO of Microsoft in the UK, visited the children in person to see their excitement and share in the experience with them.

Participate in Skype-a-thon 2018 at https://education.microsoft.com/skypeathon.

Azure Content Spotlight – Azure Logic Apps On-premises Data Gateway

$
0
0

Welcome to another Azure Content Spotlight! These articles are used to highlight items in Azure that could be more visible to the Azure community.

This weeks Content Spotlight is about the on-premises Data Gateway for Azure Logic Apps.

With the on-premises Data Gateway you can connect your Azure Logic App to on-premises APIs. The Gateway acts as a bridge that provides quick data transfer and encryption between data sources on premises and your logic apps. Learn more about how the data gateway works.

The gateway supports below on-premises data sources:

  • BizTalk Server 2016
  • DB2
  • File System
  • Informix
  • MQ
  • MySQL
  • Oracle Database
  • PostgreSQL
  • SAP Application Server
  • SAP Message Server
  • SharePoint
  • SQL Server
  • Teradata

 

To call the above data sources from a REST or HTTP connector using the Data Gateway, you can simple check the box in your connector settings!

 

 

 

 

 

Check the following urls for more information about, and how to get started with the Azure Logic Apps Data Gateway:

 

-Sjoukje

Must use, must know WinDbg commands, my most used

$
0
0

I like to write stuff.  As I personally use it for reference, instead of keeping it to myself, I often post it onto my blog here.  Here is my list of most used WinDbg commands and what information I get for them.

I was a big fan of PSSCOR, but since MEX is now a public WinDbg extension, the need for that is much less.  I wrote about MEX here and it is a must have.

There is also a debug extension, SOS, which is provided with the each installation of the .NET Framework, I wrote how to find that on an Azure App Service here.  The SOS.dll is installed into:

  • 4.0, 32-bit –> C:WindowsMicrosoft.NETFrameworkv4.0.30319
  • 4.0, 64-bit –> C:WindowsMicrosoft.NETFramework64v4.0.30319

So, here are the commands I always run when I perform analysis of a memory dump.

  • !sos.threadpool
  • !mex.us
  • !mex.aspxpagesext
  • !mex.mthreads / !sos.threads
  • !mex.dae
  • !sos.finalizequeue
  • !mex.clrstack2
  • !sos.savemodule

When a memory dump is first opened in WinDbg, there exists lots of information, for example:

The number of processes, the bitness and the version of Windows:

  • Windows 8 Version 9200 MP (4 procs) Free x86 compatible
  • Windows 8 Version 9200 MP (2 procs) Free x64
  • Built by: 6.2.9200.16384 (*)

Getting started

What I usually do here is copy the SOS.DLL I have on my workstation:  (this is important enough to mention twice, yes!)

  • C:WindowsMicrosoft.NETFramework64v4.0.30319
  • C:WindowsMicrosoft.NETFrameworkv4.0.30319

or the one provided by the customer into the same directory of the memory dump.  Then in the memory dump console I enter .load D:pathsos.dll which loads the debug extension.  Once the extension is loaded I can execute the extension methods.

Mex on the other hand, I place into the winext folder under the folder where the “Debugging Tools for Windows” is installed.

  • C:Program Files (x86)Debugging Tools for Windows (x86)
  • C:Program FilesDebugging Tools for Windows

To see a list of methods enter the extension name then help.  Ex:  !sos.help or !mex.help

!sos.threadpool

I run this command to see what the CPU consumption is on the machine which the process is running on.  The output, Figure 1 does not mean the CPU consumption consumed by this process, rather the CPU consumption on the machine which the dump was taken from.  You need to have checked in Task Manager to see which process is consuming the CPU and then take a dump of it.  See here for how to do that.

image

Figure 1, must know WinDbg commands, my favorite: !sos.threadpool

*NOTE A special bit of information specifically seen in Figure 1 is that when Garbage Collection is running, the CPU is set to 81% so that no new ASP.NET threads get created.  It is important that new threads are not created and changing the state of memory when GC is running, this makes sense.  Just keep in mind, when you see 81%, it probably is not really 81%, instead GC is running and has set this value to suspend work so the clean up can happen.

!mex.us

Unique Stacks (us).  Before the !us command existed I used ~*e k or ~*e sos.clrstack which would dump our all the stacks of all the threads running in the process.  Then I would have to work through each one to see if I can pull out any patterns.  What !mex.us does is it groups all stacks with the same pattern and groups them together.  This makes it much easier to find patterns and the threads which may be causing the problems.

!mex.aspxpagesext

Executing this command will dump out a short history of ASPX pages which have run and currently running requests.  With this command I can see what are the most common or currently running requests that are running when the memory dump was taken.  This is helpful because many times, just knowing which requests are running can help developers focus in on those requests to see why they would be causing some kind of problem.  Remember, that often users/clients simply escalate that the application is not running good, which is hard to troubleshoot.  This command might lead the investigation to the page/request that is hanging, crashing or consuming too much CPU or memory.

The HTTP status code and the number of seconds in which the request has been running is also rendered.

*NOTE in Figure 2 that the address has a length of 16 digits, take a look at Figure 5, notice that there are only 8 digits that identify the address space.  You can determine the bit-ness using those identifiers as well.  16 digits = 64 bit, 8 digits = 32 bit.

image

Figure 2, must know WinDbg commands, my favorite: !mex.aspxpagesext

!mex.mthreads / !sos.threads

Each one of the requests seen in Figure 2 is or was running on a thread.  Also notice in Figure 2 that there is a ThreadId column, sometimes it is there, cannot say why it is not there in my example, it is hard to get a single dump that can explain all scenarios.  This article contains examples from multiple dumps.  If you are fortunate enough to get the ThreadId you can click on it and it would dump the stack running on the thread,  The stack will show the methods running.  This is what you want to find when debugging, I.e. the method that is running which you can then decompile and find out why.

If you do not get the ThreadId then you can dump out all the threads, I recommend doing that anyway.  In Figure 3, there exists the ThreadId and the DbgId.  The DbgId is the one I use to set focus to for dumping the stack by using ~98s, for example, will notify the debugger to execute commands on thread 98.

I point out that the Action column, Figure 3 shows that some of the threads are calling Thread.Sleep and others are suspended “waiting for GC”.  Recall from Figure 1, and that the CPU is at 81%, this is what is causing the 81% CPU consumption.  (this shows only in the dump not on any performance counter, I expect)

GC Mode = Preemptive means that the thread will cooperate with the GC and allow it to be suspended regardless of where the execution is.  I have seen notes that anything other than Preemptive mode is unsafe or at least unfriendly.  It means that if I have coded a transaction that I want to finish without interruption of any kind and GC happens to run just then, it must wait until my thread is finished.  Becaus GC suspends other threads, it can end up suspending longer than desired, especially if the thread throws an exception or gets hung.  Then you would need to restart.

image

Figure 3, must know WinDbg commands, my favorite: !mex.mthreads / !sos.threads

!mex.dae

Dump All Exceptions (dae) is useful to see what kind of exceptions have happened over the previous short period of time within the process.  Unhandled exceptions will crash the process so you won’t see them, you’d need to capture that using another method, described here.  However, handled exceptions or those which happen within a try{}…catch{} and you can usually see them after executing !mex.dae.

It is important to note that although you see both System.OutOfMemoryException and System.StackOverflowException in Figure 4, it does not mean that those happened.  Those are holders because if those exceptions happen, there is no place to put the information about the exception, and therefore they are instantiated in advance and ready for population if required.

image

Figure 4, must know WinDbg commands, my favorite: !mex.dae

If you wanted to drill into an exception, for example a System.Web.HttpException, System.Configuration.ConfigurationException or a System.Data.DataException then use !mex.PrintException2 or !sos.pe.

!sos.finalizequeue

If I see that GC has been running or is running, like I see proof of in Figure 1 and Figure 3 I want to look at the finalize queue.  I have stated a few times that the optimal allocation between the 3 generations of GC is 100-10-1.  I.e. a ratio of 100 pinned objects in GEN0, 10 pinned objects in GEN1 and 1 pinned object in GEN2.  As you can see in Figure 5, that the ratio is way off.  It means that the code is keeping a handle on objects for multiple GC allocations and we know that the GC suspends execution so the more often and the longer it runs the more impact it has.  And looking at Figure 5, it is at least running for a second or more as it has to check each object for roots each iteration to determine if the memory is still required.  As there are so many, it might be causing some disruption.

Notice that there are 4 heaps.  Heap 0, Heap 1, Heap 2 and Heap 3.  Each processor on the machine has its own heap, you know the difference between a heap and stack and what variable types are stored into each? (*)

Also, GS Server or GC Workstation plays a role here.

Lastly, if the application can run within a 64 bit process, running in 64 bit can help remove some impact of GC.

Lastly, lastly, the GC process is good, the issue in Figure 5 is caused by holding onto objects in the custom code too long.

image

Figure 5, must know WinDbg commands, my favorite: !sos.finalizequeue

!mex.clrstack2

Once you identify the thread(s) which can be contributing to the issue, you can execute ~71s to change focus to the specific thread.  In this case I am changing focus to thread # 71.  Then I can dump out the CLR stack by using this command.

I show examples of !sos.clrstack in my IIS labs:

This gives you more precise focus on the thread and the stack you think is causing the disruption

!sos.savemodule

I wrote how to execute SaveModule here.  This is actually the most amazing thing ever.

!mex.runaway2 / !sos.runaway

I wrote 2 articles about this one, although I am usually done at this point, if I execute the previous commands and still have not found a direction, then I run runaway for some possible additional clue.

Although in Figure 6 it shows that Thread ID = 1 has been running for 9 seconds, it does not always mean it is the one which is consuming the resources or causing the problem.  You would need to change focus to thread 1, ~1s and then dump the stack.  ~kb 2000 or !clrstack.

image

Figure 6, must know WinDbg commands, my favorite: !mex.runaway2 / !sos.runaway

Other useful commands

Here are some others which are good if you get stuck and need some additional input that might send you in a new direction

  • !mex.cn – just make sure the memory dump was taken from the machine that was having the issue.  Sometimes in a Web Farm environment it is hard to know which server is throwing the error, so you can use this part to see which server the dump was taken on.  If you do not find anything, then it is probable that the issue is from another server. (computername)
  • !mex.cordll – dumps out the version of the .NET CLR in/under which the managed code us running.
  • !mex.ver – dumps out the version of the operating system on/in which the process was running
  • !mex.sqlcn – if the application is making a database connection, execute this MEX command to check the state of the connections

Now my list of must know commands is complete, I no longer need to shift around my OneNote or documents.  It’s all right here.  I hope this helps others.  Rock!

MIEE Spotlight- Rosslyn Lee

$
0
0


Today's MIEE Spotlight focuses on Rosslyn Lee, a Digital Learning Development Officer in Scotland. Within her role, she supports learners and staff in sixty-three schools across the local authority to use a variety of digital technologies including Glow and Office 365.

Rosslyn actively promotes the use of the Microsoft Educator Community for CPD, Office 365 and demonstrates these within her own practice using Sway and Forms. She takes the approach of familiarising educators by engaging them using the Office 365 products by delivering presentations to staff using Sway and using Forms to carry out surveys amongst staff. She also distributes an ICT Newsletter to schools each term either by using Publisher or Sway. In addition, she has used OneNote as a paperless solution for recording progress and SharePoint sites to promote sections of Education. Rosslyn also uses Microsoft Video as an ideal way of sharing large video files with staff across the authority that previously wasn't easily facilitated by existing technology.

 

You can follow @RosJLee on Twitter  to keep up to date with the amazing work she is doing using Microsoft technologies.


Interact with the Sway below to see how Rosslyn is engaging her students with Microsoft technologies in her own words!


Follow in the footsteps of our fantastic MIEE's and learn more about how Microsoft can transform your classroom with the Microsoft Educator Community.

Analyze Network Latency Impact on Remote Availability Group Replica

$
0
0

Multisite availability groups allow customers to deploy copies of business data across multiple sites, for disaster recovery and/or for reporting purposes, offering near real-time changes available to the copies of the production data at remote locations.

If secondary replicas are hosted greater distances from the primary replica, network latency can begin to impact availability group synchronization’s ability to keep the secondary up to date with the changes made at the primary replica.


Symptom - Sustained or Growing Log Send Queue

When network latency becomes an issue the most common symptom you will observe is sustained or growing log send queue. Simply defined, log send queue is the changes stored in the transaction log of your availability group database on the primary replica that have not yet arrived and hardened to the transaction log of the availability group on the secondary replica.

Why should you care? The log send queue represents all the data that can be lost from a catastrophic failure. If your primary replica was lost in a sudden disaster, and you were forced to fail over to the secondary replica where these changes have not yet arrived, your business would incur data loss.

Log send queue is a per-database measurement. Here are ways you can actively monitor your availability group database log send queue.

Add the Log Send Queue size (KB) column in AlwaysOn Dashboard In SQL Server Management Studio Object Explorer, right click on your availability group and choose Show Dashboard. The dashboard will appear in the right pane. Right-click the column header above the list of databases in your availability group and choose to add Log Send Queue Size (KB).

image


The column is added and reports the current queue size in KB.

image


Add the SQLServer:Database Replica:Log Send Queue Counter On the secondary replica, add the SQLServer:Database Replica:Log Send Queue counter for the database instance whose log send queue you are monitoring.

image


Measure Network Latency Impact Using Performance Monitor

In the following demo we measure the impact of network latency on log send queue growth. We can use SQL Server performance monitor counters on the primary and secondary replicas during synchronization of a load which results in log send queue growth. Compression is disabled during this load test in order to put more load on the network.

On the secondary replica, launch Performance Monitor and add the following counters:

SQLServer:Database Replica:Log Bytes Received/sec for appropriate database instance

SQLServer:Database Replica:Recovery Queue for appropriate database instance

On the primary replica, launch Performance Monitor and add the following counters:

SQLServer:Databases:Log Bytes Flushed/sec for appropriate database instance

Network Interface:Sent Bytes/sec for appropriate adapter instance

Once you have Performance Monitor running, initiate the load that leads to log send queuing, and monitor the counters.

Review the performance monitor counters on the secondary, we can see Log Bytes Received/sec for our availability group database is averaging 2.1 mb/sec. Note that the Log Send Queue for the database is continually growing meaning that there are a growing number of changes that have occurred at the primary replica that are stored in the transaction log there that have not yet arrived and hardened on the transaction log of the local database on the secondary replica.

image


Now, on the primary replica, check the availability group database’s Log Bytes Flushed/sec. We see that our load is generating and hardening on average 7.1 mb/sec to the local transaction log.

image


Clearly, if we are generating over 7 mb/sec of logged changes at the primary but only receiving 2 mb/sec of changes at the secondary, we can expect log send queue growth. These observations can lead us to begin to consider network latency as a possible cause for our growing log send queue.

On the primary, check the Network Interface:Bytes Sent/sec for the correct network adapter instance. On average, the primary is sending 2.2 mb/sec, and we can expect that nearly all of that is to the secondary replica where we observed comparable Log Bytes Received/sec.

image


Measure your network throughput independently of SQL Server

In order to better understand how fast an application can push changes to the remote server, use a third party network bandwidth performance tool, like iPerf or NTttcp. The following demo is using iPerf on the same operating environment as the prior demo.

These tools use a default port to communicate with each other, so it may be necessary to open that port, in the case of iPerf, it uses 5201 by default.

IMPORTANT It is important to configure the tool to use a single connection to send data, since SQL Server uses a single connection to send synchronization changes from the primary to the secondary replica.

Test network throughput with iPerf

On the remote secondary replica, launch iPerf with the –s parameter and it will begin to listen for a connection over port 5201.

iperf3 –s

image


On the SQL Server hosting the primary replica, launch iPerf using the following parameters, and it will begin a transmission with the remote SQL Server.

Here are the parameters.

-c ip address of destination server

–P 1 Use a single connection in the test

–t 10 Perform 10 one second transfers

Here is the command line;

iperf –c <<secondaryipaddress>> –t 10 –P 1

iPerf is reporting it can send between 2.12 and 2.50 mb/sec to the remote secondary server. This rate is very comparable to the rates we observed above in our load test using SQL Server.

image


Testing a server that is closer to your primary replica can provide a useful foil when doing this test. Below, I run the same test from the primary this time to a destination server in the same data center and subnet as the primary server. Here are the test results, noticeably higher throughput when the destination server is in closer proximity and same subnet.

image


Test network throughput with NTttcp

Below is a demonstration of using NTttcp.exe in the same environment as above.

On the remote secondary replica (the receiver), launch NTttcp as follows, here –m 1 is for single threaded, and the IP address of the local receiver server.

NTttcp.exe –r –m 1,0,10.1.0.4 –rb 2M –a 16

image

On the primary replica (the sender), initiate the test by executing the following, again supplying the IP address of the receiver. This test is for 10 seconds (-t 10):

NTttcp.exe –s –m 1,0,10.1.0.4 –l 128k –a 16 –t 10

The results report about 2.7 mb/sec which is similar to the testing results obtained from iPerf and from our performance monitor log.

image

In Conclusion

This testing can help you to determine if network latency is impacting log send queue for remote asynchronous replicas in your availability group. Log send queuing can impact your recovery point objective (RPO) and as described earlier in this blog translate to potential data loss.

For more information on recovery point objective and the potential for data loss see

Monitor Performance for AlwaysOn Availability Groups

If you find that network latency is having an impact, consider using netsh or another network trace tool to check for retransmits, dropped packets, etc.

Make your Dynamics NAV solution GDPR compliant

$
0
0

Microsoft is dedicated to helping our partners and customers meet the requirements of the upcoming General Data Protection Regulation (GDPR) that applies to all EU citizens and businesses. By May 2018, all supported versions of Dynamics NAV will be updated for GDPR compliance. We are also working on a whitepaper that will help you make your solution compliant.

The following links provide additional information and will be updated over time. Also, we expect to publish more information here on the blog in Q1 of 2018.

Microsoft Trust Center: https://www.microsoft.com/en-us/trustcenter/privacy/gdpr/solutions#dynamics-365

Microsoft GDPR Assessment: https://www.gdprbenchmark.com/

Get GDPR compliant with the Microsoft Cloud: https://blogs.microsoft.com/on-the-issues/2017/02/15/get-gdpr-compliant-with-the-microsoft-cloud/

Dynamics NAV Lifecycle: https://support.microsoft.com/en-us/lifecycle/search?alpha=Dynamics%20NAV

 

What’s new in Universal Resource Scheduling for Dynamics 365 December Update 1

$
0
0

Applies to Universal Resource Scheduling solution (version 2.2.x), Field Service application (version 7.2.x), Project Service Automation application (version 2.2.x) On Dynamics 365 version 9.0.x)

 

A few days ago, we put out our release notes on Universal Resource Scheduling December Update 1, but for those of you who rely on the CRM Blog for updates, I wanted to make sure the updated content on the docs site flows through the blogosphere as well.

We are excited to announce the newest updates released in December 2017. Ranging from improvements to screen layout, all the way to more powerful search queries for resource scheduling, and more. You asked; we listened.

Here's a quick overview of what's included:

  • Increased threshold allows for search of more resources at once
  • More screen real estate and better screen layout
  • Ability to drag-and-drop across resource summary cells to book
  • Schedule board detail panel now available with the pop-out schedule board
  • Improved zoom on the schedule board
  • New sort option by total available time
  • Ability to include schedule board date ranges in custom queries

Click here for the details

For a detailed list of bug fixes, check out our release notes blog post

 

We hope you enjoy these enhancements as they are driven by you, our customers and partners!

 

Happy Scheduling!

 

Dan Gittler

Sr. Program Manager, Dynamics 365 Engineering.

 

 


What’s new in Universal Resource Scheduling for Dynamics 365 December Update 2

$
0
0

Applies to Universal Resource Scheduling solution (version 2.3.x), Field Service application (version 7.3.x), Project Service Automation application (version 2.3.x) On Dynamics 365 version 9.0.x)

 

 

From investments in bug fixes and performance, to usability and new features, this Universal Resource Scheduling update is directly driven by feedback we have received from you, our customers and partners. We hope you enjoy!

 

For a list of bug fixes, read this post

 

Major Performance Improvements when searching for resource availability

 

When using the schedule assistant, we know you need the results fast! And sometimes fast needs to be even faster! We have made major improvements in this area. We have greatly decreased the wait time from the time you click "find availability" until the results are returned and actionable. The most drastic improvements are in scenarios where you are searching many resources. Here are a few sample scenarios to share the improvements.

 

There are many factors that play a role in search performance many of which are data related, so please treat this as general examples.

 

When searching for a 30 minute requirement across one day, when searching 500 resources, we are getting results back four times faster. For 1000 resources the results are 18 times faster!!

 

When searching for a 30 minute requirement across seven days, when searching 500 resources, we are getting results back three times faster. For 1000 resources the results are 12 times faster!!

 

When searching for a 25 hour requirement across 30 days, when searching 500 resources, we are getting results back two and a half times faster. For 1000 resources the results are five times faster!!

 

To learn more about searching for 1000 resources, here is a blog post if you are interested in the details.

 

Enhanced Support for Partially Available Resources

 

Resources that do not have the entire duration being searched can now easily be returned when searching for availability!

 

Previously, when searching for availability, in order for a resource to return in the schedule assistant results, the resource had to have availability for the entire duration being searched, within the date range being searched.  Meaning if there are 125 hours needed across one week, regardless of how the breakdown of the requirement is structured, only resources with at least a total of 125 hours of availability across that week would return.

 

Resource available for entire duration

 

We still showed resources that may be partially available for a specific segment within the requirement, but the resource needed to have all the requested hours over the date range.

 

Resource partially available

 

Now, when searching for availability, as long as the resource has a certain percent of the hours available within the searched date range, they can return in the results. For example, when searching for 100 hours of availability in the month of January, while you would prefer to find a resource with all 100 hours, you may still want to consider resources that have at least 50 hours available.

 

This is completely configurable on a per "schedulable entity" basis. Perhaps for work orders, which are typically a few hours' worth of time, you only want resources who can fulfill the entire duration, but for projects, typically longer, you would like to see resources who only have partial availability.

 

To enable partial availability, navigate to the sitemap:

 

Resource Scheduling>Administration>Enable Entities for Scheduling

 

Enable entities for scheduling

 

Then, double click the entity you would like to change for partial availability and set the "Available Duration Minimum(%)".

 

Track Proposed Hours for Requirements

 

We have added an attribute that tracks the total proposed hours on a given requirement giving users a clear picture of where a requirement is in the fulfillment process when viewing a requirement form or view.

 

We have been storing the Total Duration, the Fulfilled Duration, and the Remaining Duration. Now that we have added tracking of the total "Proposed Duration", the full picture is at your fingertips.

 

Tracking total proposed duration

 

Tracking total proposed duration

 

 

We know that you already have existing requirements, don’t worry, when you upgrade, an upgrade script will run and set the proposed duration for you on existing requirements.

 

Usability Improvement for Booking Creation

 

In our July 2017 Major update, we introduced a new set of booking options when scheduling a multiday requirement. We introduced booking methods called "Remaining Requirement" and "Full Requirement" and options to "double book a resource if needed" as well as "cancel existing bookings" for that requirement.

 

These options added a ton of power, flexibility, and choice to users, but we received some feedback that understanding all the options was a bit complex.

 

While the functionality remains the same in this release, we made a change to help users understand the intent of these options a bit better.

 

Now, when you change your booking method, or change the "double book if needed" flag, the duration field updates to reflect what will happen when you book.

 

For example, below, there are 6 requirement hours remaining to be booked on Wednesday 12/20. Allison only has 2.2 hours of capacity remaining. Since we are not double booking the resource, we will only book up to the hours Allison is available since that is the fewer of the two numbers.

 

You can see that by default when we select Wednesday for Allison, the duration to book defaults to 2.2, Allison's remaining capacity, but when the user "checks" the double book if-needed option, this now changes to the remaining hours for the requirement in that date range (6), since you are trying to book the remaining hours of the requirement within that range, and are willing to double book the resource. As you check or uncheck the box, the duration changes making it clearer to the user what will happen.

 

Requirement hours remaining to be booked

 

 

Below you will see that if the user changes the booking method to "full requirement", this means that don't care about what is already booked, rather they still want all 8 hours and will figure out what to do with the hours that have already been booked. (they can check the "cancel existing booking" option as an example).

 

So when the user changes the booking method, the duration changes to 8 since that is the requirement duration for that date range. But when the user unchecks the "double book if needed" option, then the duration changes back to 2.2 since that is the total capacity the resource has.

 

Duration change when user changes booking method

 

 

Easily see how many requirements are in your booking requirements tab.

 

We have exposed the record count for the booking requirements tab on the bottom of the schedule board so you can easily identify how many requirements there are in a particular view being.

 

Easily see how many requirements are in booking requirements tab

 

 

Enhanced Legend Capabilities

 

We know that when you use a new product, it can take a few runs before you learn some of the changes in user interface. That is why we have expanded our legend.

 

Enhanced legend capabilities

 

The legend now explains the resource summary cells.

 

Schedule Board:

 

Schedule board

 

Schedule Assistant:

 

Schedule assistant

 

Expand and Collapse Resource Rows on Schedule Board with One Click

 

We know that sometimes you want to see the bookings for many resources at once from the schedule board. Instead of expanding each resource one at a time to see their bookings, you can now do this all at once!

 

Just click the expand and collapse buttons on the top of the board.

 

Expand and Collapse Resource Rows on Schedule Board

 

 

Non-Intrusive Error Messaging

 

When using the schedule board, there are circumstances where we need to display messages to users. Previously, these messages blocked the user from continuing to use the schedule board until clicking "ok" on the error message. While some circumstances require input from users, when there is no input needed, we will display these notifications in a non-intrusive manner.

 

Non-Intrusive Error Messaging

 

Non-Intrusive Error Messaging

 

Specify Pattern tooltip

 

When using the specify pattern feature, we made a tweak to help with discoverability for users. When hovering over the specify pattern board, you will now see a tooltip explaining that you can drag on the empty space to create a requirement detail.

 

Specify Pattern tooltip

 

We hope you enjoy these enhancements as they are driven by you, our customers and partners!

 

 

Happy Scheduling!

 

Dan Gittler

Sr. Program Manager, Dynamics 365 Engineering.

 

Just in case you missed it, here is a link to “What’s new in December Update 1” 

 

 

 

Compose Your Own Music with Small Basic

$
0
0

Hi everyone.

I wrote two programs to compose music (?).

The first one shows the MML.  The program ID is SXM582.

Screen shot of a program MML Composer.

The second one shows the keys with animation.  The program ID is LFD762.

Screen shot of a program Re# So La# Do

Let's compose with Small Basic!

Data Factory による SQL Server と Cosmos DB のデータ連携

$
0
0

Microsoft Japan Data Platform Tech Sales Team

 

 

森本 信次

 

今回は、クラウドベースのデータ統合サービス Azure Data Factory (以降 ADF) を使って Azure IaaS 環境の SQL Server のデータを Cosmos DB へコピーする手順を、Step 1 ~ 6 に沿ってご紹介します。ADF を使えば、データの移動や変換をオーケストレート自動化を、データが存在する場所(クラウド、オンプレミス)、データ型やデータ ソース(SQL, NoSQL, Hadoop 等)を意識することなくデータ統合を簡単に実現できます。

データ統合のシナリオの全体感としては下図のようになります。
adfv2_senario


Step 1. Azure Data Factory (v2) を作成し、統合ランタイムを設定
まず始めに Azure Portal から ADF を作成し、統合ランタイムの設定を行います。今回使用する Azure Data Factory バージョン 2 (プレビュー) では、現行の ADF のデータ移動と変換サービスを基に構築されていますが、データの増分読み込みやイベントトリガー型の実行のサポート、および既存の SSIS パッケージをクラウドに移行することができるようになるなど、対応できるデータ統合シナリオの幅が広がりました。バージョン 2 の変更点については詳しくは こちらをご参照ください。

1.1 Azure Portal から 新しく Data Factory を作成
adfv2_step1.1


1.2 PowerShell を起動して、作成した Data Factory に対して自己ホスト型統合ランタイムを設定

次の Set-AzureRmDataFactoryV2IntegrationRuntime コマンドレットを実行します。リソースグループ、データファクトリ および 統合ランタイムの名称は適宜変更ください。

$resouceGroupName = "mydfv2-rg"
$dataFactoryName = "my1stdfv2"
$selfHostedIntegrationRuntimeName = "myirforadfv2"

Login-AzureRmAccount

Set-AzureRmDataFactoryV2IntegrationRuntime
 -ResourceGroupName $resouceGroupName
 -DataFactoryName $dataFactoryName
 -Name $selfHostedIntegrationRuntimeName
 -Type SelfHosted
 -Description "selfhosted IR description"

1.3 Data Factory に設定した統合ランタイムの使用に必要となる認証キーを取得

 

次の Get-AzureRmDataFactoryV2IntegrationRuntimeKeyコマンドレットを使用して認証キーを取得します。

Get-AzureRmDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resouceGroupName -DataFactoryName  $dataFactoryName -Name 'myirforadfv2


コマンドレットの実行結果、認証キーが表示されるのでコピーしておきます。
adfv2_ir_4


Step 2. SQL Server 環境 および 使用するサンプルデータの準備
SQL Server の仮想マシン (IaaS) を Azure 上にデプロイします。使用するデータについては、サンプルデータベース “AdventureWorks” のバックアップファイルをこちらからダウンロードしてリストアしておきます。

2.1 Azure Portal から SQL Server の仮想マシンをデプロイします。
adfv2_step2.1

2.2 こちらからファイルをダウンロードして解凍後、サンプルデータベース “AdventureWorks” のバックアップファイルをローカルのフォルダなどに保存しておきます。

adfv2_step2.2

2.3 SQL Server Management Studio などから SQL Server に接続してバックアップファイルを使用してサンプルデータベース “AdventureWorks” をリストアします。
adfv2_step2.3



Step 3. 統合ランタイムのダウンロードおよびインストール


統合ランタイムをダウンロードして、Step 2 で準備した SQL Server (IaaS) 環境にインストールします。統合ランタイム(IR)は、異なるネットワーク環境間で、データ移動、アクティビティのディスパッチ、SSIS パッケージの実行などのデータ統合機能を提供するためのコンピューティングインフラストラクチャーです。

既定のインストールで進めます、完了すると 構成マネージャーが起動します。


adfv2_ir_1


構成マネージャーでの統合ランタイム(セルフホスト)の登録には認証キーが必要です。Step 1 で保存しておいた認証キーを貼付けます。
adfv2_ir_2


[登録]を行います。
adfv2_ir_3

Step 4. Azure Cosmos DB 環境の準備
データのコピー(Sink )先となる Azure Cosmos DB のアカウントおよびコレクションを作成します。Azure Portal から Azure Cosmos DB  アカウントを 作成します、この例では Cosmos DB アカウント名を “planet-cosmos“ 、コレクション名を “PersonAddress”、パーティションキーとしては “/AddressID” としています。Azure Cosmos DB アカウントの作成方法については、こちらのBlogをご覧頂ければと思います。

adfv2_step4.1



Step 5. リンクされたサービス、データセット、パイプラインの定義および登録
リンクされたサービスは、接続文字列によく似ており、Data Factory が外部リソースに接続するために必要な接続情報を定義します。データセットとは、アクティビティで入力と出力として使用するデータを単に指定または参照するデータの名前付きビューです。パイプラインは、1つのタスクを連携して実行するアクティビティの論理的なグループです。パイプライン内の複数のアクティビティは、データに対して実行するアクションを定義します。

例えば、コピー アクティビティを使用して、オンプレミスの SQL Server から Azure Blob Storage にデータをコピーすることができます。 その後、Azure HDInsight クラスターで Hive スクリプトを実行する Hive アクティビティを使用して、Blob Storage のデータを処理し、出力データを生成できます。 最後に、別のコピー アクティビティを使用して、ビジネス インテリジェンス (BI) レポート ソリューションが構築されている Azure SQL Data Warehouse に出力データをコピーできます。詳細についてはこちらをご参照ください。以降で使用する JSON ファイルはこちらからダウンロード頂けますので、ご自身の環境に合わせて適宜変更してご利用ください。


5.1 SQL Server にリンクされたサービスとデータセット
SQL Server にリンクされたサービスの定義 JSON ファイル (SqlServerLinkedService.json)です、この例ではSQL認証を使用しています。

{
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": {
                "type": "SecureString",
                "value": "Server=xxx;Database=AdventureWorks;User ID=sa;Password=xxx;Timeout=60"
            }
        },
        "connectVia": {
            "type": "integrationRuntimeReference",
            "referenceName": "myirforadfv2"
        }
    },
    "name": "SqlServerLinkedService"
}


リンクされたサービスの定義には Set-AzureRmDataFactoryV2LinkedService コマンドレットを使用します。

Set-AzureRmDataFactoryV2LinkedService
 -DataFactoryName $dataFactoryName
 -ResourceGroupName $resouceGroupName

 -Name "SqlServerLinkedService"
 -File ".SqlServerLinkedService.json"


SQL Server 用データセット定義の JSONファイル (SqlServerDataset.json)です。

{
   "properties": {
        "type": "SqlServerTable",
        "typeProperties": {
            "tableName": "Person.Address"
        },
        "structure": [
             {
                "name": "AddressID",
                "type": "Integer"
            },
            {
                "name": "AddressLIne1",
                "type": "String"
            },
            {
                "name": "PostalCode",
                "type": "String"
            }
        ],
        "linkedServiceName": {
            "referenceName": "SqlServerLinkedService",
            "type": "LinkedServiceReference"
        }
    },
    "name": "SqlServerDataset"
}

SQL Server のデータセットは Set-AzureRmDataFactoryV2Dataset コマンドレットを使用して定義します。

Set-AzureRmDataFactoryV2Dataset
 -DataFactoryName $dataFactoryName
 -ResourceGroupName $resouceGroupName
 -Name "SqlServerDataset"
 -File ".SqlServerDataset.json"


5.2 Cosmos DB にリンクされたサービスとデータセット


Cosmos DB にリンクされたサービスの定義 JSON ファイル(AzureCosmosDbLinkedService.json)
です。

{
    "name": "AzureCosmosDbLinkedService",
    "properties": {
        "type": "CosmosDb",
        "typeProperties": {
            "connectionString": {
                "type": "SecureString",
                "value": "AccountEndpoint=xxx;AccountKey=xxx;Database=PersonAddressDB"
            }
        },
        "connectVia": {
            "referenceName": "myirforadfv2",
            "type": "IntegrationRuntimeReference"
        }
    }
}


同様に
Set-AzureRmDataFactoryV2LinkedService コマンドレットを使用します。

Set-AzureRmDataFactoryV2LinkedService -DataFactoryName $dataFactoryName
 -ResourceGroupName $resouceGroupName -Name "SqlServerLinkedService" -File ".SqlServerLinkedService.json"


Cosmos DB のデータセット定義の JSON ファイル (AzureCosmosDbDataset.json)です。

{
    "name": "AzureCosmosDbDataset",
    "properties": {
        "type": "DocumentDbCollection",
        "linkedServiceName":{
            "referenceName": "AzureCosmosDbLinkedService",
            "type": "LinkedServiceReference"
        },
        "typeProperties": {
            "collectionName": "PersonAddress"
        }
    }
}


同様に
Set-AzureRmDataFactoryV2Dataset コマンドレットを使用して定義します。

Set-AzureRmDataFactoryV2Dataset -DataFactoryName $dataFactoryName
 -ResourceGroupName $resouceGroupName -Name "AzureCosmosDbDataset" -File ".AzureCosmosDbDataset.json"

5.3 処理内容(ソースからシンクへのコピー)を定義するパイプライン

{
   "name": "SQLServerToCosmosDbPipeline",
    "properties": {
        "activities": [
            {
                "type": "Copy",
                "typeProperties": {
                    "source": {
                        "type": "SqlSource"
                    },
                    "sink": {
                        "type":"DocumentDbCollectionSink"
                    }
                },
                "name": "CopySqlServerToCosmosDbActivity",
                "inputs": [
                    {
                        "referenceName": "SqlServerDataset",
                        "type": "DatasetReference"
                    }
                ],
                "outputs": [
                    {
                        "referenceName": "AzureCosmosDbDataset",
                        "type": "DatasetReference"
                    }
                ]
            }
        ]
    }
}

 

5.4 Set-AzureRmDataFactoryV2Pipeline コマンドレットを使用してパイプラインを作成します

Set-AzureRmDataFactoryV2Pipeline -DataFactoryName $dataFactoryName -ResourceGroupName $resouceGroupName -Name "SQLServerToCosmosDbPipeline" -File ".SQLServerToCosmosDbPipeline.json”


Step 6. 登録したパイプラインを実行してデータが登録されているかを確認

Step 5 で登録済みのパイプラインを実行して SQL Server のサンプルデータが ターゲットの Cosmos DB にコピーされているかを確認します。

6.1 Invoke-AzureRmDataFactoryV2Pipeline
コマンドレットを使用して Step 4 で作成した “SQLServerToBlobPipeline" パイプラインの実行を開始し、後で監視できるようパイプライン実行 ID をキャプチャ(変数に格納)します。

$runId = Invoke-AzureRmDataFactoryV2Pipeline -DataFactoryName $dataFactoryName -ResourceGroupName $resouceGroupName -PipelineName 'SQLServerToCosmosDbPipeline'


6.2 Azure Portal の Cosmos DBアカウントのデータエクスプローラを開きます。

adfv2_step6.2



6.3 Azure Portal からアクティビティの実行結果を確認

adfv2_step6.3

6.4 Get-AzureRmDataFactoryV2ActivityRun コマンドレットによるアクティビティの実行結果の確認
Step 6.1 で取得しておいた パイプライン実行ID ($runId)を使って、Get-AzureRmDataFactoryV2ActivityRun コマンドレットによるアクティビティの実行結果の確認も行っておきます。

while ($True){$result = Get-AzureRmDataFactoryV2ActivityRun -DataFactoryName $dataFactoryName -ResourceGroupName $resourceGroupName -PipelineRunId $runId -RunStartedAfter (Get-Date).AddMinutes(-30) -RunStartedBefore (Get-Date).AddMinutes(30)
if (($result | Where-Object { $_.Status -eq "InProgress" } | Measure-Object).count -ne 0) { Write-Host "Pipeline run status: In Progress" -foregroundcolor "Yellow" Start-Sleep -Seconds 30 } else { Write-Host "Pipeline 'SQLServerToCosmosDbPipeline' run finished. Result:" -foregroundcolor "Yellow" $result break } }

 

adfv2_step6.4

最後に
いかがだったでしょうか? 今回は SQL Server と Cosmos DB のデータ連携 を Azure Data Factory によってどのように実現可能かをご紹介しました。今回、使用した SQL Server の環境は Azure 上の IaaS ですが、自社オンプレミス環境で稼働している SQL Server の場合についても、基本的な設定の流れは変わりませんので、オンプレミス と クラウド 間のデータ連携のニーズがある場合には、Azure Data Factory の使用を選択肢の一つとしてご検討頂ければと思います。

 

Créer et interroger votre service web avec Azure ML

$
0
0

 

Azure Machine Learning Studio permet depuis ses débuts de déployer un service web pour pouvoir interroger votre modèle préalablement entrainé. Vous pouvez bien évidement faire de même avec le service de gestion des modèles d'Azure Machine Learning (Azure ML).

C'est ce que nous vous proposons d'aborder dans ce billet qui s'inscrit dans la continuité de la série de billets que nous avons initiée depuis cet automne sur les nouveaux services d'Azure ML.

J'en profite pour remercier Paul Jenny actuellement en stage de fin d'étude au sein de Microsoft France pour cette contribution.

Le service de gestion des modèles

En complément du service d'expérimentation d'Azure ML, ce nouveau service vous permet de gérer, comme son nom le suggère, différentes versions de vos modèles, de les déployer dans différents environnements que ce soit sous forme de conteneurs Docker ou de service web HTTP pour être facilement réutilisable via un simple appel de type REST. Comme mentionné ci-avant, nous nous intéressons ici au second cas de figure.

Dans la pratique, 4 étapes sont nécessaires pour pouvoir créer tel un service web :

  • Enregistrement du modèle auprès du service de gestion des modèles ;
  • Création d'un manifeste spécifiant les dépendances associées à un modèle ;
  • Création de l'image docker basé sur un manifeste ;
  • Déploiement du conteneur docker sous forme de service web en temps réel.

Quelques prérequis

Pour pouvoir déployer vos modèles, vous devez avoir, au préalable, préparer un environnement de déploiement. Si vous ne l'avez pas encore fait, nous vous invitons à lire la partie « Préparation de l'environnement de déploiement » dans le billet Mise en place d'un environnement de cette série.

Vous devez avoir aussi, bien évidemment, sauvegardé votre modèle entrainé sous forme d'objet Python sérialisé dans un fichier.

Le fichier de score du service

La première étape consiste à créer le fichier de score qui permettra à votre service web de donner un score aux données reçues en entrée. Celui-ci doit être composé d'au moins deux fonctions indispensables :

  • init() : cette fonction est appelée au démarrage du service web pour pouvoir, par exemple, récupérer le modèle entrainé ou encore activer la fonctionnalité de collecte des données d'entrée et de sortie du service pour archivage des entrées / sorties.

     

def init():

from sklearn.externals import joblib

global model, inputs_dc, prediction_dc

# Chargement d'un modèle entrainé sur scikit-learn (plus rapide que pickle)

model = joblib.load('model.pkl')

 

# Activation de la collecte de données en entrée

inputs_dc = ModelDataCollector('model.pkl',identifier="inputs")

# Activation de la collecte de données en sortie

prediction_dc = ModelDataCollector('model.pkl', identifier="prediction")

 

  • run() : cette fonction est utilisée à chaque réception d'une requête HTTP en entrée. La validation du format de la requête est effectuée en amont de celle-ci si vous avez généré le schéma (Cf. section suivante). Celle-ci doit retourner la réponse du service web, c'est-à-dire la prédiction :

def run(input_df):

global clf2, inputs_dc, prediction_dc

try:

# Prédiction du modèle

prediction = model.predict(input_df)

# Collecte des données d'entrée

inputs_dc.collect(input_df)

# Collecte de la prédiction

prediction_dc.collect(prediction)

return prediction

except Exception as e:

return (str(e))

La création du schéma du service web (optionnel)

Il est possible de demander au service de valider automatiquement les entrées et les sorties de votre service web pour vous assurer du bon fonctionnement de celui-ci. Pour cela, il faut spécifier les formats attendus dans un fichier JSON.

Il est préférable de le générer directement depuis votre fichier score dans la fonction main(), par exemple, pour pouvoir conserver un format à jour.

Tout d'abord, il est nécessaire d'importer 3 bibliothèques d'Azure ML dans un fichier Python :

from azureml.api.schema.dataTypes import DataTypes

from azureml.api.schema.sampleDefinition import SampleDefinition

from azureml.api.realtime.services import generate_schema

Ensuite, vous devez spécifier le type de données attendu avec un exemple de données d'entrée :

  • Pour un tableau Numpy :

    inputs = {"input_array": SampleDefinition(DataTypes.NUMPY, yourinputarray)}

  • Pour un tableau Spark :

    inputs = {"input_array": SampleDefinition(DataTypes.SPARK, yourinputarray)}

  • Pour un tableau Pandas :

    inputs = {"input_array": SampleDefinition(DataTypes.PANDAS, yourinputarray)}

Et enfin, il convient de générer le schéma associé :

generate_schema(run_func=run, inputs=inputs, filepath='service_schema.json')

Remarque : le paramètre run_func correspond à la fonction run() d'un fichier de score d'un service web. C'est pourquoi il est préférable d'ajouter ces lignes directement dans celui-ci.

L'enregistrement de son modèle

Une fois le fichier de score créé, vous pouvez enregistrer votre modèle auprès du service de gestion des modèles. Cela permet de le sauvegarder dans le cloud pour une utilisation future et de le déployer dans différentes cibles (notamment en tant que service web).

Pour effectuer cette opération, vous devez utiliser le CLI intégré dans Visual Studio Code (si l'extension Visual Studio Tools for AI est installée) ou depuis Azure ML Workbench.

La commande est suivante :

az ml model register

–model [chemin vers le modèle .pkl - requis]

–name [nom du modèle - requis]

–description [description du modèle - optionnel]

–tag [libellé associé à ce modèle – optionnel]

Dans le résultat de la commande, vous obtiendrez l'identifiant du modèle. Celui-ci vous permettra de le réutiliser dans la suite de cet article.

Une fois cette commande effectuée, vous pouvez apercevoir une nouvelle version de votre modèle via l'utilisation d'Azure CLI avec la commande az ml model list ou du portail de gestion Azure :


La création du manifeste du/des modèle(s)

Le manifeste représente le lien entre un ou plusieurs modèles, les dépendances associées, le fichier de score ainsi que le schéma des données en entrée et en sortie du service web.

Celui-ci est ensuite utilisé pour construire l'image Docker associée.

Il se crée, lui aussi, à l'aide d'une commande via l'utilisation d'Azure CLI comme suit :

az ml manifest create

--manifest-name -n [nom du manifeste – requis]

-f [chemin vers le fichier de score - requis]

-r

--model-id -i [identifiant du modèle – requis]

--conda-file -c [chemin vers un fichier YML contenant les dépendances Conda - optionnel]

--dependency -d [Fichiers et répertoires requis par le service - optionnel]

--manifest-description [description du manifeste – optionnel]

--schema-file -s [chemin vers le schéma du service web – optionnel]

Plusieurs modèles et plusieurs dépendances peuvent être spécifiés dans un même manifeste en multipliant les arguments -i et -d respectivement. Dans le résultat de la commande, vous obtiendrez l'identifiant du manifeste qui est utile pour la suite de ce billet.

Tout comme les modèles enregistrés dans le service de gestion des modèles, vous pouvez apercevoir votre manifeste dans le portail Azure ou en utilisant Azure CLI avec la commande az ml manifest list :

La création de l'image Docker du manifeste

Une fois le manifeste créé, pour pouvoir déployer le modèle dans différents environnements, il est nécessaire pour cela de créer l'image Docker associée.

Remarque : Cette opération peut aussi être effectuée depuis le portail Azure dans votre ressource de gestion des modèles en cliquant sur le manifeste qui sera utilisé pour créer une image puis Create Image :

La commande à utiliser pour créer une image Docker est la suivante :

az ml image create

--image-name -n [image name - requis]

--manifest-id [identifiant du manifeste - requis]

--image-description [description de l'image – optionnel]

Le résultat de la commande contient l'identifiant de l'image qui peut être utilisé ensuite pour pouvoir créer un service web.
De plus, tout comme les modèles et les manifestes enregistrés, vous pouvez apercevoir la création de l'image dans le portail Azure ou avec la commande az ml image list :


Le déploiement sous forme de service web

Une fois l'image créée, il ne reste plus qu'à la déployer sous forme de conteneur dans Azure.

Remarque : Cette opération peut aussi être effectuée depuis le portail Azure dans votre ressource de gestion des modèles en cliquant sur le manifeste ou l'image qui sera utilisé(e) pour créer le service web puis Create Service :

Pour créer un service avec une image Docker déjà enregistrée auprès du service de gestion des modèles comme dans notre cas de figure, la commande Azure CLI à utiliser est la suivante :

az ml service create realtime

-n [nom du service web – requis]

–image-id [identifiant de l'image à utiliser – requis]

–autoscale-enabled [mise à l'échelle automatique selon les besoins, désactivé par défaut. True | False – optionnel]

–autoscale-max-replicas [si mise à l'échelle automatique activée, nombre max de répliques – optionnel]

–autoscale-min-replicas [si mise à l'échelle automatique activée, nombre min de répliques – optionnel]

--autoscale-refresh-period-seconds [si mise à l'échelle automatique activée, intervalle de temps pour évaluer si mise à l'échelle nécessaire - optionnel]

–collect-model-data [collecte des données en entrée et en sortie, désactivé par défaut. True | False – optionnel]

–cpu [nombre de cœurs CPU réservés par réplique (fraction autorisée) – optionnel]

–enable-app-insights -l [métriques sur les requêtes, désactivé par défaut ; true | false – optionnel]

–memory [mémoire réservée par réplique en M ou G (1M ou 10G) – optionnel]

–z [nombre de répliques pour un service Kubernetes - optionnel]

Remarque : Nous vous recommandons d'activer les métriques sur les requêtes ainsi que la collecte et l'archivage des données en entrée et en sortie pour pouvoir monitorer votre service web et ainsi réagir en cas d'erreurs.

Le service web est automatiquement déployé dans votre environnement de déploiement configuré dans votre Azure CLI.

Encore une fois, vous pouvez accéder à votre service web dans le portail Azure ou via Azure CLI avec la commande az ml service list realtime :

La consommation du service web

Pour pouvoir consommer un service web, il faut au préalable récupérer les informations à propos de celui-ci comme l'URL avec la commande :

az ml service usage realtime -i [identifiant du service web]

Pour tester le service web, la commande à utiliser est la suivante :

az ml service run realtime -i [identifiant du service web] -d "vos données en entrée en format JSON"

Si vous souhaitez consommer le service web via un appel HTTP depuis un programme, vous devez au préalable récupérer les clés d'authentification du service :

az ml service keys realtime -i [identifiant du service web]

La clé d'authentification est à insérer dans l'en-tête d'authentification sous la forme "Authorization : Bearer [clé d'authentification du service]".

Vous devez aussi paramétrer l'en-tête Content-Type en application/json.

Si vous avez aviez soumis un schéma du service web lors de sa création, vous pouvez récupérer le document Swagger associé situé à :

http://<ip>/api/v1/service/<service name>/swagger.json

Vous pouvez retrouver des exemples de scripts en C# et Python dans la documentation officielle (en anglais).

La surveillance du service web

La surveillance de l'utilisation du service

Si vous avez activé les métriques sur les requêtes via l'argument –enable-app-insights lors de la création du service web, vous pouvez surveiller son utilisation directement depuis le portail Azure en accédant à votre service web via votre service de gestion des modèles avec le service Azure Application Insights.

Vous pouvez récupérer l'URL d'Azure Application Insights directement depuis Azure CLI avec la commande :

az ml service usage realtime -i [identifiant du service web]

La récupération des données d'entrée et de sortie du service

Si vous avez activé la collecte et l'archivage des données d'entrée et de sortie de votre service web via l'argument –collect-model-data lors de sa création, vous pouvez récupérer alors ces données pour les étudier en cas de problèmes.

Pour cela, vous pouvez les récupérer depuis le portail Azure puis aller dans la catégorie Comptes de stockage. Si celle-ci n'est pas présente, vous pouvez la retrouver en utilisant la recherche dans Tous les services.

Pour déterminer le compte de stockage associé à votre environnement de déploiement, vous devez entrer la commande az ml env show -v et lire le paramètre storage_account.

Une fois dans le compte de stockage, accédez à la section Parcourir les objets blob puis accédez au conteneur modeldata. L'ensemble des données archivées sont dans un fichier CSV sous l'URL suivante :

/modeldata/<subscription_id>/<resource_group_name>/<model_management_account_name>/<webservice_name>/<model_id>-<model_name>-<model_version>/<identifier>/<year>/<month>/<day>/data.csv

Les données provenant d'Azure Blob peuvent être consommées de différentes façons :

  • Azure Machine Learning Workbench ;
  • Microsoft Excel ;
  • Microsoft Power BI (création de graphiques) ;
  • Et d'autres…

Remarque : Les données peuvent mettre jusqu'à 10 minutes après la requête pour être propagées dans votre compte de stockage.

En guise de conclusion

A travers ce billet, vous avez pu découvrir - si tel n'était pas encore le cas - le service de gestion des modèles d'Azure ML qui permet, entre autres, la création d'un service web basé sur un modèle entrainé en quelques étapes seulement.

Néanmoins, vous pouvez aussi déployer votre modèle dans des périphériques en bordure avec Azure IoT Edge. Ce point sera traité dans un autre billet de cette même série prochainement.

Enfin, si vous avez le moindre problème lors du déploiement de vos modèles, vous pouvez vous référer au Guide de résolution des problèmes liés au déploiement ici.

Déployer un modèle sur Azure IoT Edge

$
0
0

Dans le billet précédent de cette série billets sur les nouveaux services d'Azure Machine Learning (Azure ML), nous avons illustré la façon de déployer un modèle empaqueté dans un conteneur Docker sous forme de service web dans Azure.

Avec la nouvelle version de ce mois de décembre 2017 du service de gestion des modèles d'Azure ML, vous pouvez dorénavant déployer ce conteneur sur un appareil au plus près de la source des données typiquement pour les scénarios liés à l'Internet des objets (IoT). Au-delà d'un cloud « intelligent », cette approche permet de porter l'« intelligence en bordure ». C'est en particulier l'un des scénarios que permet d'aborder Azure IoT Edge, actuellement disponible en version préliminaire publique

Je vous propose d'aborder tout cela dans ce billet et j'en profite pour remercier Paul Jenny actuellement en stage de fin d'étude au sein de Microsoft France pour cette contribution.

Une rapide présentation d'Azure IoT Edge

Les appareils connectés qui composent ce qu'il convient d'appeler l'IoT sont typiquement situés en bordure du cloud. Ils n'ont généralement qu'une faible puissance de calcul ainsi des capacités de connexion réseau vers l'externe limitées (protocole(s) pris en charge, consommation induite, etc.).

Ainsi, les rendre « intelligents » avec l'Intelligence Artificielle (IA) devient vite compliquée à mettre en place dû à ces deux contraintes (calcul, réseau).

Afin de s'affranchir de ces contraintes, Azure IoT Edge permet d'apporter l'intelligence jusqu'en bordure du cloud afin d'offrir un ensemble de services cloud intelligent. Vous pourrez ainsi déployer vos propres applications ou des modèles (dans ou) au plus près de vos objets connectés en bordure et traiter en local les différentes données provenant de sources locales à l'objet considéré (capteurs de température, de pression, détecteur de présence, etc.. Un cas d'exemple serait l'utilisation d'Azure IoT Edge sur un moteur d'avion pour effectuer de la maintenance prédictive en cas de détection d'un risque élevé de panne proche.

La mise en place d'Azure IoT Edge

Pour pouvoir déployer sur Azure IoT Edge, il faut au préalable avoir configuré un hub Azure IoT ainsi qu'avoir configuré un module.

Remarque : Vous avez besoin d'un abonnement Azure pour pouvoir effectuer la suite de ce tutoriel. Si vous n'avez encore de compte Azure, vous pouvez créer un compte gratuit ici. Nous supposons que vous disposez à ce stade d'un tel compte.

La première étape est de configurer votre ordinateur ou votre machine virtuelle pour simuler un appareil IoT. Pour cela, vous devez installer Docker pour Windows et Python 2.7 . Ensuite, via une invite de commandes, vous devez installer le paquet de contrôle d'Azure IoT avec pip :

pip install -U azure-iot-edge-runtime-ctl

Vous devez ensuite créer un hub Azure IoT sur le portail Azure afin de pouvoir inscrire un appareil dans ce hub. Pour cela, vous pouvez passer par Azure Cloud Shell, le Shell intégré au portail d'Azure ou plutôt effectuer les mêmes opérations graphiquement.

La création de hub avec Azure Cloud Shell

Une fois connecté au Portail Azure, vous pouvez sélectionner dans la barre de tâches en haut du portail le Shell Azure en PowerShell ou Bash :

Il est recommandé de créer un groupe de ressources pour chaque projet afin de gérer au mieux vos ressources sur Azure. Dans le Shell situé ci-dessous, vous devez saisir la commande suivante :

az group create --name iotedge --location westeurope

Cette commande permet de créer un groupe de ressources nommé « iotedge » situé par exemple ici dans la région Azure en Europe de l'Ouest.

Remarque : Le nom d'un groupe de ressources doit être unique à travers Azure. Il se peut ainsi que ce nom puisse déjà être utilisé par quelqu'un d'autre.

La seconde étape est de créer l'hub Azure IoT dans ce groupe de ressources :

az iot hub create --resource-group iotedge --name moniothub --sku F1

Cette commande permet de créer un hub IoT dans le groupe de ressources iotedge avec pour nom moniothub et le plan de tarification F1 pour les besoins de ce tutoriel (gratuit, limité à un par abonnement Azure).

Créer le hub depuis le portail Azure

Une fois connecté au portail Azure, vous pouvez sélectionner sur la droite Créer une ressource :

Recherchez ensuite IoT Hub :

Puis sélectionnez la ressource IoT Hub et enfin Créer.

Dans le formulaire, vous devez indiquer le nom de votre hub IoT (il doit être unique). Choisissez ensuite le niveau de tarification F1, correspondant au niveau gratuit, suffisant pour effectuer nos tests (limité à un par abonnement Azure).

Concernant le groupe de ressources, il est recommandé de créer un groupe de ressources pour chaque projet sur Azure afin de pouvoir organiser les ressources au mieux. Vous pouvez néanmoins en utiliser un existant si vous le souhaitez. Une fois tout ceci fait, il suffit de cliquer sur Créer.

Il faut maintenant attendre le déploiement de cette nouvelle ressource dans Azure.

L'inscription d'un appareil IoT Edge

Une fois votre hub IoT déployé, vous pouvez maintenant ajouter un appareil IoT Edge dans celui-ci. Sur le portail Azure, sélectionnez votre hub sur le tableau de bord sinon recherchez-le via le menu Toutes les ressources à gauche :

Une fois le panneau du hub ouvert, sélectionnez IoT Edge (preview) dans le menu à gauche :

Il faut maintenant ajouter un appareil IoT à votre hub avec le bouton Add IoT Edge Device :

Dans l'approche suggérée ici pour les besoins de notre illustration, cet appareil est votre ordinateur ou votre machine virtuelle. Dans le formulaire qui vient de s'ouvrir sur la droite, vous devrez insérer l'ID de l'appareil. Celui-ci doit être unique et doit être composé de caractères alphanumériques. Ensuite, il est préférable de laisser Azure générer automatiquement les clés SSH associées à votre appareil pour la connexion.

Une fois l'appareil ajouté, il faut le configurer pour accéder à votre hub IoT. Pour cela, il convient au préalable récupérer les clés de connexion. Pour ce faire, sélectionnez-le dans la liste des appareils de votre hub IoT :

Dans la nouvelle fenêtre, copiez la Chaîne de connexion - clé primaire et conservez-la dans votre presse-papiers.

Vous pouvez maintenant passer à la configuration de votre appareil IoT. Ouvrez maintenant un terminal de commandes sur votre ordinateur ou machine virtuelle puis saisissez la commande suivante :

iotedgectl setup --connection-string [VOTRE_CHAINE_CONNEXION] --auto-cert-gen-force-no-passwords

Cette commande permet de configure votre appareil IoT avec votre hub IoT Azure. Deux modules (sous forme de conteneur Docker) sont ainsi déployés, à savoir :

  1. L'agent IoT Edge qui gère le déploiement et la surveillance des modules de votre appareil IoT
  2. L'agent hub IoT qui gère la communication entre vos modules et votre hub IoT.

La dernière étape consiste enfin à lancer vos modules IoT avec la commande suivante :

iotedgectl start

Vous pouvez vérifier que tout fonctionne bien avec la commande Docker qui permet de lister les conteneurs actifs :

docker ps

Vous devez avoir le conteneur basé sur l'image « microsoft/azureiotedge-agent:1.0-preview » qui fonctionne.

La création de votre image Docker

Pour pouvoir déployer votre modèle sur votre module IoT, la première étape est de créer l'image Docker associée à celui-ci.

Si vous n'avez pas lu l'article sur le déploiement d'un modèle sous forme de service web ici, nous vous invitons à le consulter au préalable. Les différentes étapes et explications sont décrites dans ce billet.

Pour les besoins de ce billet, vous pouvez utiliser l'exemple fourni par le tutoriel officiel en téléchargeant le fichier score ici et le modèle ici. Ensuite, il vous suffit avec une invite de commandes de saisir la commande ci-dessous dans le dossier contenant les deux fichiers précédents :

az ml service create realtime –model-file model.pkl -f iot_score.py -n machinelearningmodule -r python

Cette commande permet de créer le manifeste, de générer l'image Docker associée et enfin de publier le service web. Celui-ci est appelé machinelearningmodule tout comme l'image Docker.

Le déploiement de votre modèle en module IoT

Pour pouvoir récupérer l'image Docker de votre modèle, il faut ajouter la connexion au répertoire Docker à votre appareil IoT. Pour cela, il faut au préalable récupérer les identifiants de connexion de votre Azure Container Registry qui a été créé lors de la création de votre environnement de déploiement :

Pour ce faire, rendez-vous sur le portail Azure et accédez au menu Toutes les ressources situé à droite :

Si vous possédez plusieurs environnements de déploiements, vous pouvez utiliser la commande suivante depuis un invite de commandes pour rechercher rapidement le groupe de ressources associé à votre registre de conteneurs où l'image Docker a été déployé, :

az ml env show -n [VOTRE_ENVIRONNEMENT] -v

Recherchez dans le résultat de la commande la propriété containerRegistry
, puis resourceId. L'URL est sous la forme :

[VOTRE_ID_ABONNEMENT] / resourcegroups / [VOTRE_ID_GROUPE_RESSOURCES] / providers / ….

La partie importante ici est [VOTRE_ID_GROUPE_RESSOURCES]. Par exemple, ci-dessous, le groupe de ressources serait PaulML-azureml-7f27d :

Une fois que vous disposez du groupe de ressources dans lequel se trouve votre registre de conteneurs, il vous suffit de le sélectionner sur le portail Azure :

Dans la nouvelle fenêtre, accédez au menu Clés d'accès :

Vous aurez ainsi besoin du serveur de connexion et du nom d'utilisateur et mot de passe associés :

Vous allez enfin pouvoir ajouter la connexion à ce répertoire Docker à votre appareil IoT. Pour cela, dans une invite de commandes, saisissez la commande suivante en remplaçant les valeurs avec les données que vous avez récupérées ci-dessus :

iotedgectl login –address [SERVEUR_CONNEXION] –username [NOM_UTILISATEUR] –password [MOT_DE_PASSE]

Une fois ceci fait, vous pouvez passer au déploiement en tant que tel du module contenant votre image Docker sur votre appareil IoT. Pour cela, toujours sur le portail Azure, allez sur votre hub IoT puis dans le menu IoT Edge (preview) puis sélectionnez votre appareil IoT. Cliquez ensuite sur Set Modules située en haut du menu :

Nous allons à présent ajouter le module à cet appareil IoT en cliquant sur Add IoT Edge Module :

Dans le menu déroulant à droite, vous devez donner un nom à ce module IoT puis indiquer l'image Docker sur lequel le conteneur sera basé. L'URI vers l'image est sous la forme :

[SERVEUR_CONNEXION_DOCKER] / [NOM_IMAGE] :1

Par exemple, ici, avec le nom d'image que nous avons utilisé auparavant, ce serait :

mlcrparc4ff11505f691.azurecr.io/machinelearningmodule :1

Une fois le formulaire rempli, cliquez sur Next.

La seconde étape permet de créer des routes personnalisées inter-modules ou avec l'hub IoT. Ici, le service web devrait fonctionner de lui-même sans personnalisation supplémentaire.

Puis cliquez sur Next et enfin Submit. Une demande de déploiement sur votre appareil IoT est ainsi créé. Une fois celui-ci achevé, vous aurez une notification dans le portail Azure :

Ensuite, pour pouvoir envoyer des messages à votre module IoT afin de prédire des données, deux options s'offrent à vous : i ) utiliser le portail Azure ou ii) développer votre propre solution.

L'envoi des messages vers votre module IoT

Via un code personnalisé

La documentation officielle recense différents exemples pour pouvoir contacter votre module IoT dans plusieurs langages.

  • Un exemple en .NET ;
  • Un exemple en Java ;
  • Un exemple en NodeJS.

Via le portail Azure

Vous pouvez envoyer des messages depuis le portail Azure avec votre hub IoT. Pour cela, retournez dans la configuration de votre hub IoT. Sélectionnez ensuite le module vers lequel vous souhaitez envoyer un message puis cliquez sur Message à l'appareil :

Entrez dans le Corps du message les données que vous souhaitez prédire selon le format attendu par votre service web :

En guise de conclusion

Nous espérons que ce billet vous aura permis de découvrir comment déployer un modèle d'Azure ML vers un module IoT empaqueté dans un conteneur Docker sous forme de service web. Ceci clôt notre billet.

Enfin, si besoin, vous pouvez retrouver la documentation officielle d'Azure IoT Edge ici ainsi que le tutoriel de démarrage ici associé.

Top stories from the VSTS community – 2017.12.22

$
0
0

Here are top stories we found in our streams this week related to DevOps, VSTS, TFS and other interesting topics.

TOP STORIES

  • How to setup a VSTS pipelines for Azure Service Fabric and its containing services - Clemens Reijnen
    Sven wrote a detailed How To covering the creating of a release pipelines for a secure Azure Service Fabric cluster and the containing services, based on a project we did together.
  • How to Make Git Work with Self-Signed SSL Certificates on TFS2018 - Ben Day
    When you install Team Foundation Server 2018 (TFS2018), the installer gives you the option to configure TFS to use HTTPS with a self-signed SSL certificate. This is a good thing.
  • Using TypeScript for your VSTS extension walk through - Erick Segaar
    One of my targets of this year was to start writing TypeScript and experience the usability compared to my experience writing JavaScript over 20 years ago.
  • Configure Git repository for automatic pull –rebase - Ricci Gian Maria
    I’m not a great fan of Git Graphical User Interfaces, I use mainly command line, but I needed to admit that, for novice user, the ability to use a GUI is something that can ease the pain of transition to a new tool.
  • The impact of an upgrade to Team Foundation Server 2018 - Matteo Emili
    Usually upgrading Team Foundation Server is smooth and easy, but there is an exception this time around. It is not strictly related to TFS per-se, instead the issue lies with the new deprecations introduced with version 2018.
  • TFS 2017 – Sometimes we must look back before we can move forward! – Part 1 - Chuck Goodspeed
    This is the first of a series of posts, focusing on the challenges encountered in migrating/evolving TFS 2005/2008/2010 installations a full decade forward into TFS 2017 and/or VSTS. Experiences and situations encountered at multiple customer installations provide real-life NOT “out-of-the-box experiences”, [! OOB} which can be built upon to avoid common pitfalls.
  • Azure ARM template function internals - Ed Elliott
    I have been working with azure arm functions for quite a while and they are exceptionally useful but also quite a pain to work with, visualizing what it is that the functions will resolve to is often hard.
  • Help! My TFS automatically redirects HTTPS to HTTP! - Matteo Emili
    If you are deploying HTTPS to TFS and you want to keep HTTP for a while, you might experience a strange behaviour: despite following the documentation, every time you browse to your TFS Web Access with HTTPS you are redirected to HTTP.


HOLIDAYS - We wish you all a safe and restful holiday with your friends and family!


TIP: If you want to get your VSTS news in audio form then be sure to subscribe to RadioTFS .

FEEDBACK

What do you think? How could we do this series better?
Here are some ways to connect with us:

  • Add a comment below
  • Use the #VSTS hashtag if you have articles you would like to see included

Dynamics 365, version 9 への顧客主導更新 (CDU) について

$
0
0

みなさん、こんにちは。

今回は、Dynamics 365, version 9 への顧客主導更新 (CDU) について紹介します。
本記事の内容は、弊社が提供しているブログ Microsoft Dynamics 365 Team blog の記事を翻訳したものです。

情報元: Customer Driven Upgrade for Dynamics 365, version 9.0 is coming

====================================================

Dynamics 365, version 9 へ顧客主導更新 (CDU) が間もなくスケジュール出来るようになります。
現時点では、2018 年 1 月頃設定が可能となり、2 月から 8 月の期間内に更新のスケジュールを設定できる見込みです。

Dynamics 365 管理者には、Office 365 メッセージ センターを介して案内がなされ、
更新がスケジュール可能となった際に電子メールが送信されます。

更新の可否を確認するには、Dynamics 365 管理センターの [更新] タブを確認します。
アップグレードの対象となるインスタンスには、状態に「使用可能な更新プログラム」と表示されています。
この場合、更新のスケジュールを設定でき、更新希望の日程と代替の日程を設定します。

Dynamics CRM 2016, version 8.0 または Dynamics CRM 2016 Update 1, version 8.1、
Dynamics 365, version 8.2 のバージョンから Dynamics 365, version 9 へ アップグレードが可能です。

詳細: 更新プログラムの管理

====================================================
ご案内

Dynamics CRM 2016 Update 1, version 8.1 をご利用中にて
Dynamics 365, version 8.2 へアップデートを実施しない場合、
年 1 回アップデートのポリシーにより、Dynamics 365, version 9 へのアップデートは必須となります。
お早目にアップデートの検証を実施いただくことを推奨いたします。

また、Dynamics CRM 2016 Update 1, version 8.1 から Dynamics 365, version 8.2 へアップデートする場合、
現時点では 2018 年 1 月まで更新のスケジューリングが可能です。
Dynamics 365, version 8.2 へアップデートを計画されている場合、お早目に更新をスケジューリングください。

- Dynamics 365 サポート 早坂 圭弘

※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります


Weihnachstgrüße von Codefest.AT und der PowerShell UserGroup Austria

$
0
0

Hallo PowerShell Gemeinde!

Auch im letzten Monat war einiges los bei uns

Künftige Veranstaltungen

Newsletter - die "Schnipseljagd":  Unsere wöchentlichen PowerShell Newsletter kamen regelmäßig raus und beinhalteten folgende Themen:

https://www.powershell.co.at/powershell-schnipseljagd-4517/

  • Webhook anstossen
  • Keine Passwörter im Code – The Azure-way!
  • Try/catch/error blocks in PowerShell – Error Handling wie die Profis
  • Service Accounts: Passwort automatisch verändern
  • GPO – Konflikte erkennen

https://www.powershell.co.at/powershell-schnipseljagd-46-17/

  • FTP
  • Mehrere CSV bearbeiten
  • PowerShell Gallery Informationen auslesen – mit PowerShell
  • Bilder sind auch für Kommandozeilen Enthusiasten wichtig
  • Mehrere PowerShell Fenster anordnen
  • Welche Infos gibt es über mich?

https://www.powershell.co.at/powershell-schnipseljagd-47-17/

  • Neuigkeiten/Unterschiede in PowerShell 6.0
  • Schneller mit Vorlagen
  • Anzahl der Elemente eines Office365 Ordners auslesen
  • Eigene Eigenschaften hinzufügen
  • Sharepoint Recovery

https://www.powershell.co.at/powershell-schnipseljagd-48-17/

  • PowerShell & Azure
  • Colour your Console
  • Sieger des PowerShell Contests
  • Adventkalender
  • Learn to build tools not to code
  • Multi-Valued Eigenschaften in ein CSV exportierren
  • Deep Learning

https://www.powershell.co.at/powershell-schnipseljagd-49-17/

  • PowerShell Countdown Timer
  • Wie man ein Script auf die PowerShell Gallery postet
  • Den Manager eines Benutzers aus dem AD auslesen
  • Rechnen mit PowerShell

https://www.powershell.co.at/powershell-schnipseljagd-50-17/

  • PowerShell in der Wolke (Microsoft Flow)
  • Betriebssysteminformationen auslesen
  • PowerShell Module
  • Microsoft MVP
  • Wo kann man mein Netzwerk verletzen?
  • Pester und Schleifen
  • Adventkalender

Wir hoffen es  war auch für Dich etwas dabei!

Wir wünschen ein Frohes Fest und einen Guten Rutsch ins Jahr 2018!

CodeFest.AT und die PowerShell UserGroup Austria - www.powershell.co.at

Microsoft EDUCATION Roadshow für Hochschulen in Deutschland – 07.-21. Februar 2018

$
0
0

Nach den ersten zwei Veranstaltungen im November 2017 in Stuttgart und Köln, führt Microsoft im Februar 2018 die Microsoft EDUCATION Roadshow für Hochschulen in Deutschland weiter.

Bei diesen Veranstaltungen möchten wir mit Ihnen grundlegende Dinge bzgl. Cloud-Lösungen diskutieren und einen Austausch untereinander fördern. Durch die Digitale Transformation profitieren auch Hochschulen, insbesondere bei der Interaktion von Hochschuldirektion, Hochschulverwaltung, Dozenten und Studenten, bei der Optimierung von administrativen Abläufen, bei der Gestaltung von Bildungsinhalten und bei der Umsetzung von Forschungsprojekten. Cloud Computing bietet Hochschulen einen direkten Zugang zu Anwendungen, die sich beliebig skalieren lassen, mobil zur Verfügung stehen und immer auf dem aktuellen Entwicklungsstand sind.

Zu folgenden Veranstaltungen, die sich inhaltlich nur geringfügig unterscheiden werden, möchten wir Sie herzlich einladen.

Melden Sie sich jetzt kostenlos unter den unten genannten Anmeldelinks an. Nach Ihrer Anmeldung erhalten Sie umgehend eine Teilnahmebestätigung.

07.02.2018 - Microsoft Deutschland GmbH, Walter-Gropius-Str. 5, 80807 MÜNCHEN

08.02.2018 - Technische Universität Dresden, Willers-Bau, Zellescher Weg 14, 01069 DRESDEN

13.02.2018 - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen, Am Faßberg 11, 37077 GÖTTINGEN

14.02.2018 - Microsoft Deutschland GmbH, Siemensstraße 27, 61352 BAD HOMBURG

20.02.2018 - Microsoft Deutschland GmbH, Gasstraße 6a, Geb. M, 22761 HAMBURG

21.02.2018 - Microsoft Deutschland GmbH, Unter den Linden 17, 10117 BERLIN

Änderungen zu den Terminen behalten wir uns vor.

Um einen umfassenden Austausch zwischen unseren Referenten und den Gästen zu gewährleisten, ist die Teilnehmerzahl limitiert. Eine frühzeitige Anmeldung ist deshalb zu empfehlen.

Unten finden Sie die geplante Tagesordnung. Bitte beachten Sie, dass es sich hierbei um eine Rahmen-Agenda handelt. Inhalte können variieren.

Übrigens: Sollten Sie Ihre Teilnahme einplanen und bereits Themen haben, die Sie zusätzlich in dieser Runde diskutieren möchten, schicken Sie uns doch eine kurze Information vorab an Susann.Huettner@microsoft.com. Die Referenten können sich dann auf Ihre individuellen Schwerpunkte vorbereiten.
Wir freuen uns auf Ihre Anmeldung und einen intensiven Austausch.


10:00 – 10:30 Ankunft und Registrierung
10:30 – 10:45 Begrüßung
10:45 – 11:45 Cloud-Anwendungen im Hochschulumfeld
Wie künstliche Intelligenz und andere moderne Cloud-Dienste Verwaltung, Forschung und Lehre bei Hochschulen unterstützen
11:45 – 12:15 GÉANT als Lizenzierungsform von Cloud-Services für Hochschulen
Wie Sie Microsoft Azure über das Deutsche Forschungsnetzwerk (DFN) beziehen können
12:15 – 12:45 Partner-Cloud-Lösungen für Hochschulen
12:45 – 13:30 Mittagessen
13:30 – 14:30 Vorstellung der Microsoft-Devices: Surface und HoloLens
Wie Mixed Reality und moderne Arbeitsgeräte in Bildungseinrichtungen eingesetzt werden
14:30 – 15:15 Microsoft 365 für Education
Wie Windows 10, Security und Office 365 als moderne Kollaborations-Lösung Hochschulen im Alltag unterstützt
15:15 – 15:45 Kaffeepause
15:45 – 16:15 Microsoft Imagine Academy
16:15 – 16:45 Microsoft Premier Services
16:45 – 17:00 Zusammenfassung und Ausblick

Azure PowerShell Get to know about availability of the VM sizes

$
0
0

You may know that all Azure regions does not provide all types and sizes of VMs. So while designing a deployment it is important to understand what is in the store,

A simple PowerShell would give you list of VM Sizes

Get-AzureRmVMSize -location eastus

image

You may also dump this to a .csv file

Get-AzureRmVMSize -location eastus | Export-CSV C:tempVMSize_EastUS.csv

Namoskar!!!

Using Managed Service Identities in Functions to Access Key Vault

$
0
0

In my previous blog post I walked through a scenario leveraging Azure Functions and Event Grid to handle blob replication between storage accounts. There was one piece of that solution that I wasn't particular fond of, and that was the fact that I had the storage account connection string hard coded in the Function itself. This worked fine, but exposes a design flaw from a security standpoint, as you want to avoid putting credentials into code or configuration files if at all possible. We could store these credentials as environment variables in the function app, but we this doesn't provide full separation between the application and the credentials themselves. In this post, we're going to enhance this solution and use the relatively recently announced Managed Service Identity to access the connection string that we'll store in Azure Key Vault, eliminating the need for us to put any sensitive information into code, application settings or configuration files.

Managed Service Identity?

Let's take a minute and talk about what Managed Service Identity is and why it's awesome. Managed Service Identity (MSI) allows you to assign an Azure AD identity to an instance of a supported Azure service. With this identity, you can then take full advantage of RBAC to grant access to resources, and Azure AD handles the full lifecycle of the identity, including credential rolling and cleanup upon deletion. MSI can presently be used in Windows and Linux Azure VMs, App Service, Functions and Data Factory v2 to access any Azure resource that supports AAD authentication. As an example, I can assign a MSI to a Linux VM, grant access to Azure Service Bus to the MSI for the VM, and code running on the VM can use this identity to access Service Bus without having to embed connection strings or credentials in any code or configuration files. This dramatically improves the security of your application and protects your credentials from being exposed. A big win from a security perspective!

One last thing to note is that as of the writing of this blog managed service identities are currently in public preview, so all the usual disclaimers around preview services apply here. I'd expect to see this GA in the not too distant future, and would also anticipate that you'll see many more services introduce MSI support.

Enable Managed Service Identity

Enabling managed service identity on a function is pretty easy. In the Azure portal, navigate to your function app, select the Platform features tab, and click on Managed service identity.

Change the Register with Azure Active Directory option to on, click save, and that's it! We now have an AAD identity that our function can use.

 

Key vault configuration

Now let's get a Key Vault up and running, and configure it so that we can store our connection string. In the Azure portal click + Create a resource, search for Key Vault and click Create. Enter a name for your key vault, put it in a resource group, select the region and select your pricing tier (Standard is appropriate for this demo). Go ahead and click on Access policies, and Add new to add a new access policy. Click on Select principal and search for the name of your function app. In my case I named mine jbstoragereplication, and you can see that it shows up as a principal that I can select. Select your principal and then click Select. Then, in the Secret permissions drop down, check the boxes next to Get and List, which will allow this identity to get the credentials it needs out of this key vault. Click Ok on the panels and then finally click Create.

Now let's add the secrets to the key vault. Go to your primary storage account, then to the Access keys panel and you'll find your connection string. Go ahead and copy the connection string for key one, then hop back over to your key vault.

In the key vault click on the Secrets panel and click + Add to add a new secret. In the Upload options drop down select Manual, give your secret a name (I used sourceStorageConnectionString to match the variable name in our function) and then paste your connection string into the Value box. Click Create to create the new secret. Now do the same steps again to add the connection string for the second storage account. I named this secret destinationStorageConnectionString to match the variable in the function again.

So at this point we have an identity for our function and a key vault containing our connection strings for the storage accounts. Let's finish this up by updating our function to use these services.

Update function code to access key vault

We need to add a couple dependencies to our function so we can use key vault and MSI. This function is written in C# script, so we have to add a new file to pull in these dependencies. If we were using native C# from Visual Studio, we could simply add in dependencies to these libraries and they would be included when the function is deployed. In the code editor for your function, expand the panel on the right and click View files. Click Add to add a new file and name it project.json, then click it to pull it up in the editor. Add in the following text to define the necessary dependencies:

{
    "frameworks": {
        "net46": {
            "dependencies": {
                "Microsoft.Azure.KeyVault": "2.4.0-preview",
                "Microsoft.Azure.Services.AppAuthentication": "1.1.0-preview"
            }
        }
    }
}

Go ahead and click save, then pull up run.csx in the editor. Add the following using statements to the file so we can use these libraries.

using Microsoft.Azure.Services.AppAuthentication;
using Microsoft.Azure.KeyVault;

Then delete the lines that contain your connection string (they start with string sourceStorageConnectionString and string destinationStorageConnectionString) and add the following code in to pull the credentials from key vault, replacing the URL's respectively.

// Pull the connection string out of Azure Key Vault
string sourceStorageConnectionStringKvUrl = "https://jbkvtest1.vault.azure.net/secrets/sourceStorageConnectionString";
string destinationStorageConnectionStringKvUrl = "https://jbkvtest1.vault.azure.net/secrets/destinationStorageConnectionString";
AzureServiceTokenProvider azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
var sourceStorageConnectionStringSecret = await keyVaultClient.GetSecretAsync(sourceStorageConnectionStringKvUrl).ConfigureAwait(false);
string sourceStorageConnectionString = sourceStorageConnectionStringSecret.Value;
var destinationStorageConnectionStringSecret = await keyVaultClient.GetSecretAsync(destinationStorageConnectionStringKvUrl).ConfigureAwait(false);
string destinationStorageConnectionString = destinationStorageConnectionStringSecret.Value;

The values for each of the key vault URLs can be found in your key vault by viewing each secret, and copying the Secret Identifier for each secret. They have the format of https://keyVaultName.vault.azure.net/secrets/secretName/versionIdentifier. You can either specify the exact version with this full URL or by removing the string of characters and numbers you can just get the latest version. In my example I drop the string specifying the version so I can just access the latest version. This makes key rolling easy, as I don't have to update my code to reference a new version of the key.

Save your function and that's it! Now try uploading a file to your primary storage account and you should see it replicate to the secondary, getting the connection strings from the key vault. If you'd like to see the exact values that it's pulling from key vault you can add in a couple of logging entries to output these values.

log.Info($"source connection string: {sourceStorageConnectionString}");
log.Info($"destination connection string: {destinationStorageConnectionString}");

One thing to note is that every function invocation will require a call to key vault, so it might be beneficial to cache this data to reduce the number of calls to key vault. You could use a MemoryCache to cache it across executions on the same server or leverage another caching technology such as Azure Redis Cache. This would be something to consider if the key vault calls are too expensive from a cost or an execution time standpoint, though it is a pretty inexpensive service.

Wrap up

So we've taken a look at what Managed Service Identity is and how you can use it within Azure Functions to eliminate sensitive credentials in code. You can use this across multiple services and I can't wait for more Azure services to adopt this capability. It's easy to use and enhances the security of your Azure resources. Check out the following links for more information.

Managed Service Identity overview - https://docs.microsoft.com/en-us/azure/active-directory/msi-overview
Using Managed Service Identity in App Service - https://docs.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity
GitHub repo with function code - https://github.com/jboeshart/ReplicateBlobAzureFunction/tree/master
Microsoft.Azure.Services.AppAuthentication nuget package - https://www.nuget.org/packages/Microsoft.Azure.Services.AppAuthentication
Microsoft.Azure.KeyVault nuget package - https://www.nuget.org/packages/Microsoft.Azure.KeyVault/2.4.0-preview

Azure Bot サービスとLUIS が GA して変わったこと: その1 Azure Bot サービス

$
0
0

とうとう Microsoft Bot Framework と Azure Bot サービスがいよいよ GA しました!今回から数回で変わった点などを紹介します。今回は Azure Bot サービスについてです。

Azure Bot サービス

Azure ポータルから作成できる Bot のサービスは 3 種類になりました。

image

  • Web App Bot: Web App とボット用のチャネル登録を統合したサービス
  • Functions Bot: Azure ファンクションとチャネル登録を統合したサービス
  • Bot Channels Registration: 既にボット用 API がある場合に使う、チャネル登録サービス

Bot Channels Registration

まずは全てに共通する Bot Channels Registration から見ていきます。これまでポータルでボット登録ができましたが、この機能でほぼ同じことが出来ます。

ウィザードにそって作成すると、以下のことをしてくれます。

  • Microsoft App Id の取得
  • Application Insights の構成 (選んだ場合)
  • ストレージの作成 (選んだ場合)

機能

作成された Bot Channels Registration を開くと以下のメニューが表示されます。

image

概要にはドキュメントとサンプルのリンクがあります。またタグまでの項目は他の Azure リソースと共通です。

以下に個人的に重要な順番でメニューを確認していきます。ほぼポータルであった機能です。

設定

設定ではこれまでポータルで登録できた、アイコンやメッセージングエンドポイントの指定等ができます。

チャネル

Skype や Teams など複数のチャネル設定が行えます。尚、以前は Skype が既定で構成されていましたが、今回から WebChat のみ構成されています。

image

Test in Web Chat

公開済のボットを Web チャットコントロールで検証できます。

分析

Application Insight を利用して収集したデータで、Bot の利用状況を確認できます。

Speech priming

LUIS と連携する場合に設定します。

Bot Service の料金

利用するサービスのレベルを選択できます。S1 にすると SLA がついてくるので、正式サービスは是非こちらで。

image

Web App Bot

次に Web App Bot です。機能としては上記の Bot Channels Registration に Web App がついてきますが、新規作成時に以下のことをやってくれます。

  • Web App の作成
  • メッセージングエンドポイントの設定
  • Microsoft App ID とパスワードの取得およびアプリケーション設定に値を設定
  • 選択した言語でのボットアプリテンプレートの作成
  • Application Insights の構成 (選んだ場合)
  • ストレージの作成 (選んだ場合)

また Bot Channel Registration のメニューに ビルドと App Service の設定が追加されます。

image

image

ビルド

以下の内容が選択できます。ここから自動生成されたコードをオンラインで直接編集することも、ソリューションとしてダウンロードもできます。ダウンロードしたソリューションは、Web App に対する公開設定も含まれているため、簡単に発行が行えます。

image

オンラインエディターを使うと素早くコードの確認と変更が行えます。

image

アプリケーション設定

Web App のアプリケーション設定部分だけ確認、変更が出来ます。Microsoft App パスワードもこちらから確認可能。

すべての App Service 設定

関連付いている Web App へのリンクとなっているため、ワンクリックで Web App に移動が可能です。

Functions Bot

ほぼ Web App ボットと同じですが、Azure ファンクションが作成されます。それに伴いアプリケーション設定の値も Azure ファンクション用のものとなります。

ビルド

ビルドも内容はほぼ同じですが、はじめのメニューが Azure Functions へのリンクとなっています。

image

Bot Framework ポータル

最後に Bot Framework のポータル (https://dev.botframework.com/) ですが、以下のように変わりました。

既存のボット

Migrate ボタンが表示され、ワンクリックで Azure サブスクリプションとの連携および移行が可能です。

image

Migrate 画面では Azure サブスクリプションとリージョンを選択。

image

規約画面

image

完了画面

image

上記ボタンをクリックすると Azure ポータルに遷移します。個の手順で移行した場合、Bot Channels Registration を作成して手動でメッセージングエンドポイントを設定した状態となります。

新規ボット

ボットを作成しようとすると、Azure ポータルに遷移します。

まとめ

Bot サービスが複数あることで一瞬混乱しますが、内容を抑えるととても簡単にかつ迅速に使えることが分かります。是非新しい Bot サービスをお試しください。次回は Language Understanding サービスを見ていきます。

中村 憲一郎

Viewing all 5308 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>