ランダムなデータを生成する JSON API

Random Data Web API というものを作成しました (正確には、2014 年に作成したものを最近改修しました)。
ランダムなデータを生成するための JSON Web API です。以下のデータを生成できます。

  • アルファベット
  • アルファベットと数字
  • バイト列
    • 16進数形式、Base64 形式
  • UUID (GUID)
  • 時刻順の ID
    • 現在の時刻をもとに、並べ替え可能な GUID を生成
    • SQL Server の uniqueidentifier 型にも対応

内容自体はとくに変哲のない API です。時刻順の ID は少し珍しいかもしれませんが。
また、仕様が記述されたヘルプページ、および jQuery を利用したテストページが付属しています。

Test page

さて、従来の一般的な Web API の問題点として、利用する開発者の意思に反してサービスが終了してしまうということがよくあります。
無償・有償を問わずサービスが永久に提供されるとは限らないため、
なるべく自身のアプリをそれに依存させず、自身でサービスを運用することが望ましいでしょう。

そこでこの Web API では、ソースコードをオープンソース ライセンスのもとで提供し、
それを利用する開発者自身がサービスをホストすることを想定します。
例えば Azure Web App などの PaaS を利用すれば GitHub から直接ビルドおよびデプロイができるため、
簡単な手順でサービスの運用を開始させることができます。
またこの場合は継続的デプロイが構成され、fork したリポジトリが更新されれば Azure Web App も自動的に更新されます。

詳細の方法については Azure Web App にデプロイする手順にまとめてあります。
なお、randomdata.azurewebsites.net は配置例として提供しているものです。このサイトに保証・サポートはありません。

Deployment Option

技術的な特徴としては、以下が挙げられます。

  • ASP.NET Web API
    • XML Formatter を無効化して、JSON 形式のみをサポート
  • ASP.NET Web API Help Page
    • ソースコード内のコメントから自動生成
    • いろいろカスタマイズして利用
  • ASP.NET Web API Cross-Origin Support
    • CORS (Cross-Origin Resource Sharing)
  • HTTPS 必須化

ヘルプページの多言語対応については、ブラウザーの翻訳機能を利用すれば何とかなるでしょう。

Help Translation

バージョン情報

  • .NET Framework 4.5
  • ASP.NET Web API 5.2.3
  • ASP.NET Web API Help Page 5.2.3
  • ASP.NET Web API Cross-Origin Support 5.2.3
  • Blaze 1.1.10

参照

広告

Azure と VSTS で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。

 

[デプロイ オプション] を設定する方法については前回の Azure と GitHub で継続的デプロイ (2017) で書きました。
今回は Visual Studio Team Services (VSTS) の Git リポジトリに対して [継続的配信] を設定してみます。

まず VSTS の Git リポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

 

次に、Azure で Web App を作成します。

image

作成が完了したら、その Web App の [継続的配信] を構成していきます。

image

ソースとして VSTS を選択し、アカウント、リポジトリ、ブランチを選択します。

image

 

基本的な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。 
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

VSTS のリポジトリの [Services] で、Azure Web App と連携していることを確認できます。

image

 

VSTS の Web 画面で、ビルド定義の表示・編集ができます。詳細の設定はここでできます。
なお、Visual Studio 上での表示・編集はできなくなっているようです。

主に使われる設定としては以下が挙げられるでしょう。

  • ビルド定義の名前の変更
  • .sln ファイルのパスの指定
  • ブランチの変更
  • 継続的デプロイか、手動デプロイか (Enable continuous integration)
  • ビルド番号の形式

image

image

image

ビルドで生成された実行ファイルは [Artifacts] で取得できます。

image

[Release] から、過去のバージョンを選択して再デプロイすることもできます。

image

 

注意点:

  • VSTS 以外の Git (GitHub など) でも同様の手順で構成できますが、
    ビルド定義を VSTS のリポジトリに保存するため、VSTS のアカウントが必要です。
  • 管理者権限を与えられた別の Azure アカウントだと、エラーが発生して [継続的配信] を設定できませんでした。

 

前回:Azure と GitHub で継続的デプロイ (2017)

参照
Build and deploy to an Azure Web App

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

Azure と GitHub で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。
Web アプリケーションが 1 つしか含まれていないリポジトリをシンプルに運用したいのであれば、[デプロイ オプション] でよいでしょう。

 

以下では GitHub のリポジトリに対して [デプロイ オプション] を設定してみます。
なお、GitHub 以外の Git (VSTS など) でも同様の手順で構成できます。
[継続的配信] については次回の Azure と VSTS で継続的デプロイ (2017) で書いています。

まず GitHub のリポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

リポジトリはパブリックでもプライベートでもかまいませんが、
自分が所有しているリポジトリでなければならないため、他の人のリポジトリであれば fork しておきます。

 

次に、Azure で Web App を作成します。

image

作成が完了したら、[デプロイ オプション] を構成します。
ソースとして GitHub を選択すると、アカウント承認の画面が現れます。
さらにリポジトリとブランチを選択します。

image

 

必要な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。
[継続的配信] では数分かかるのに対して、かなり早く完了します。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

過去のバージョンを選択して再デプロイすることもできます。

image

GitHub のリポジトリの [Settings] – [Webhooks] で、Azure Web App と連携していることを確認できます。

image

 

次回:Azure と VSTS で継続的デプロイ (2017)

参照
Azure App Service への継続的なデプロイ

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

カテゴリー: ALM, クラウド. タグ: , . 3 Comments »

Logic Apps から Slack に通知する

以前に Bot Framework で Slack の bot を構成するを書きましたが、
今回はこの素因数分解の bot を Logic Apps で作成してみます。
自然数をランダムに生成して素因数分解してその結果を Slack に通知する、
というのを 10 分間隔で実行することにします。

まず、Azure ポータルで Logic App を作成します (手順は初めてのロジック アプリの作成を参照)。
名前は、グローバルに一意である必要はありません。

次に、デザイナーでロジックを追加していきます。
完成したワークフローを先に示します。

 

以下は、各アクションについての説明や注意点です。

(1) 繰り返し (Recurrence)
最初のトリガーとして [繰り返し] を選択し、10 分間隔で実行されるようにしています。

(2) Azure Functions
アクションとして [Azure Functions] を選択すると、同じアカウント内で作成済みの関数を選択できます。
([HTTP] というアクションで URL を指定する方法もあります。)

Logic-Apps-Functions

ここでは、前回の Azure Functions で Web API を作成するで用意した Azure Functions の 2 つの関数を利用します。

(3) データ操作 – JSON の解析
前の関数からは

{ "result": "5439 = 3 ・ 7^2 ・ 37" }

という形式の JSON が返るため、あとで必要になる文字列 (result プロパティの値) を取り出すためにこれを解析します。
[スキーマ] は、この JSON を入力すれば作成されます。

(4) Slack – 投稿メッセージ
投稿先のチャネルとメッセージを指定します。
初回の設定時にはアカウントを認証する必要があります。Logic Apps 上の画面で失敗する場合は、[API 接続] から設定できます。

Logic-Apps-Slack

 

以上で完成です。
下図は Slack のスクリーン ショットです。

Factorization-Slack

 

前回: Azure Functions で Web API を作成する

参照
Flow、Logic Apps、Functions、WebJobs の比較
Logic Apps とは
Azure Functions を使用したロジック アプリのカスタム コードの追加と実行

Bot Framework で Slack の bot を構成する

Azure Functions で Web API を作成する

Azure Functions では、単機能の Web API やバッチを作成することができます。
とくに、Web アプリケーション全体を構築する必要がなく、開発者が管理するのは関数のソースコードのみで済むという利点があります。

Azure Functions で関数を作成するための詳細の手順は Azure Portal で初めての関数を作成するに記載されていますが、
概略は以下の通りです。

  • Function App を作成する
    • この段階では、Web サイトが作成されるのみ
    • Web サイトとして作成されるため、名前はグローバルに一意でなければならない
  • 関数を作成する
    • 一つの Function App に、複数の関数を作成できる
    • シナリオに応じてテンプレートを選択する
    • 言語が C# の場合、関数は、拡張子が「.csx」のファイルで表される
    • このポータル上で、コードの修正とテストができる

Azure-Functions-App  Azure-Functions-Files

 

以下では、Web API を作成するときに選択できるテンプレートについて書いていきます。
Web API を作成するには、「HTTP トリガー」を利用することになります。

Azure-Functions-Templates-API

HTTP トリガーでは、以下のことができます。

  • 利用できる HTTP メソッド (GET, POST など) を指定できる
  • 「Shops/{id:int?}」 のように URL ルーティングを指定できる (パラメーターは Run メソッドの引数になる)
  • 応答の本文は JSON になる。new { message = "Hello." } のようなオブジェクトも指定できる

HTTP トリガーには、以下のテンプレートがあります。

  • HttpTrigger
    • 汎用の HTTP トリガー
  • HttpTriggerWithParameters
    • パラメーターとしてクエリ文字列を利用する場合のテンプレート
    • HTTP メソッドは GET のみ有効
  • GenericWebHook
    • Webhook のテンプレート
    • 規約上は POST で本文に JSON を送るものだが、かまわず通常の HTTP トリガーとしても使えるっぽい

 

例として、簡単な Web API を作ってみます。

こちらはランダムに自然数を生成するもので、入力データを必要としていません。
HttpTrigger テンプレートから作っています。

次は、入力された自然数を素因数分解する関数です。
以前に Bot Framework で Slack の bot を構成するで作成したメソッドを再利用しています。
こちらは GenericWebHook テンプレートから作っており、要求の本文に { "n": 123 } のような JSON が渡される想定です。

本文がテキストの場合は req.Content.ReadAsStringAsync() としてもよいですが、JSON の場合は

dynamic data = await req.Content.ReadAsAsync<object>();

とすればよいでしょう。

また、クエリ文字列からの入力は req.GetQueryNameValuePairs() で読み込むことができます。

 

なお、下図はデータと連携したバッチを作成するときのテンプレートです。

Azure-Functions-Templates-Data

 

次回は、これらの関数を使って Logic Apps で Slack bot を作ってみます。

次回: Logic Apps から Slack に通知する

作成したサンプル
AzureFunctionsSample (GitHub)

参照
Azure Functions の概要
Azure Functions における HTTP と Webhook のバインド

Bot Framework で Slack の bot を構成する

カテゴリー: クラウド. タグ: . 1 Comment »

Bot Framework で Slack の bot を構成する

Microsoft Bot Framework を利用した bot API を公開して、Slack をクライアントとして使えるように構成してみました。
その構築手順と注意点の簡単なメモを残しておきます。

基本的には、次の 2 つの記事をもとにしています。

(1) 環境設定

(2) bot を Web API として開発

  • テンプレートからプロジェクトを作成する
  • プロジェクトのプロパティで [アセンブリ名] を変更する
  • NuGet で Bot Framework を更新する

(3) Azure App Service に配置

  • Visual Studio から発行する

(4) Bot Framework サイトに登録

  • Web.config の appSettings にアカウント情報を設定するには、Azure Portal の [アプリケーション設定] を利用する
  • Web Chat を構成する
    • HTML に Web Chat を埋め込む
  • Slack bot を構成する
    • Slack の設定を追加するときに表示される手順の通りに進める

 

以下は注意点です。

(1) 開発環境における実行について

ローカルの開発環境においては、
Visual Studio で開始した bot API に Bot Framework Channel Emulator から接続することになりますが、
[デバッグなしで開始 (Ctrl+F5)] では 401 エラーとなります。
[デバッグの開始 (F5)] で実行すれば接続できます。

これは、Controller に BotAuthentication 属性が付けられていることによって、
デバッガーにアタッチされているときは認証不要になるためです。
したがって、開発環境では [デバッグの開始 (F5)] で実行しましょう。

(2) クライアント上でのテキストの表示について

テキストは既定で Markdown 形式です。したがって、記号などを使用するときは注意が必要です。
なお、reply.TextFormat を plain に設定しても、Web Chat では無効のようです。
また、reply.TextFormat を plain に設定しても、Slack ではなぜか * が _ と表示されます。

(3) Activity.Type について

Slack からは、activity.Type が ActivityTypes.Message でない要求が送られてくることがあります。
activity.Type の値により処理を分岐させないと、応答メッセージが重複して表示されてしまいます。

(4) URL の送信について

Slack から URL を送信すると、bot 側で受信するテキストでは、URL が < と > で括られます。

 

素因数分解 bot API のコードを示します。
全体のソースコードは、FactorizationBotApi (GitHub) にあります。

 

Slack で実行したときのスクリーン ショットです。

Factorization bot

 

表情分析 bot については、Bot Framework で Slack bot 構築メモ (Qiita)に書きました。

作成したサンプル
BotSample (GitHub)

バージョン情報
.NET Framework 4.6
Microsoft.Bot.Builder 3.3.0

参照
人工知能パーツ Microsoft Cognitive Services を使った表情分析アプリを作ろう! (Emotion API × Bot Framework 編)
Azure で Web 公開&お手軽 Web Chat を試す
Microsoft Cognitive Services & Bot Framework 概要
Bot Framework Overview

Bot Framework で Slack bot 構築メモ

カテゴリー: クラウド. タグ: , . 2 Comments »

Azure Web ジョブでバッチを実行する

Azure Web ジョブでバッチを実行するための簡易的な作業手順と、タイムアウトなどの注意点について記述します。

まず、Azure Web ジョブを配置するまでの基本的な流れは次の通りです。

  • ストレージを作成する
  • Web App を作成する
  • Web ジョブを開発して配置する

これらについて、以下に詳細を書いていきます。

■ ストレージを作成する

Azure ポータルで、ストレージを 1 つ作成します。
厳密には、

  • ログを格納するためのストレージ (AzureWebJobsDashboard)
  • バッチが利用するストレージ (AzureWebJobsStorage)

の 2 種類なのですが、1 つのストレージに両方の役割を持たせてもかまいません。
また、後の手順で接続文字列を使うため、[キー] からコピーしておきます。

■ Web App を作成する

Azure のポータルで、Web App を作成します。
[アプリケーション設定] の [接続文字列] で、「AzureWebJobsDashboard」をキーとする設定を追加します。
これで、WebJobs ダッシュボードを利用できるようになります。

接続文字列

 

■ Web ジョブを開発して配置する

Visual Studio で、新規のプロジェクトを [Azure WebJob] のテンプレートから作成します。
App.config を開くと、接続文字列の設定が 2 種類あります。
この両方に、先ほどと同じ接続文字列を設定します。

接続文字列

以下、Web ジョブの開発の流れを簡単に書いておきます。
なお、今回作成したサンプルは TaskWebJob (GitHub) にあります。バッチ処理の題材として、素数を求めています

(1) 手動またはスケジュールで開始する場合
詳細は Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法などを参照。

  • メソッドに [NoAutomaticTrigger] を付ける
  • JobHost.Call メソッドで、そのメソッドを呼び出す
  • Azure WebJob として発行する
    • オンデマンド実行またはスケジュール実行を選択する
  • 実行するには、ポータルの Web App の [Web ジョブ] で実行する

(2) キューをトリガーとして開始する場合
詳細は Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法などを参照。

  • メソッドの引数に [QueueTrigger] を付ける
  • JobHost.RunAndBlock メソッドを使う
  • Azure WebJob として発行する
    • 連続実行を選択する
  • 実行するには、指定したキューにメッセージを追加する
    • 引数を渡すこともできる

 

以上で、Azure Web ジョブにバッチを配置することができました。
さて、バッチを実際に実行してみると、タイムアウトしてしまうことがあります。
以下では、タイムアウトについて書いていきます。

■ 有料プランの場合

既定では Web App の [アプリケーション設定] の [常時接続] がオフに設定されており、
Web App (というより Kudu?) が 20 分ほどでタイムアウトしてしまいます。
[常時接続] をオンに設定すれば解決します。

■ 無料プランの場合

無料プランでは、[常時接続] をオンにできません。
バッチの実行がタイムアウトする原因は 2 つあります。

  • Web App のタイムアウト
    • タイムアウトは 20 分ほどです。
    • Kudu への要求が連続的にされていれば、タイムアウトは延長されます。
  • CPU 時間の制限
    • 実際の時間ではなく、CPU を使用した時間です。
    • 例えば、連続して 3 分使うと、Web App が停止します。

したがって、WebJobs ダッシュボードなどを表示したままにして、
かつ CPU 使用率の低いバッチであれば実行可能ということになります。

そこで、例えば Thread.Sleep メソッドをコードに含めるという方法があります。
Thread.Sleep などでスレッドを中断しながら実行すると、CPU 利用率を激減させることができます。

CPU 時間の使用量は [クォータ] で見ることができます。

クォータ

 

作成したサンプル
TaskWebJob (GitHub)

参照
Azure Web ジョブのリソース
Azure App Service に .NET Web ジョブを作成する
Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法
Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法
Web ジョブでバックグラウンド タスクを実行する
Visual Studio を使用して Web ジョブを展開する

LINQ で素数を求める (C#)

カテゴリー: クラウド. タグ: , . Leave a Comment »