てすとぶろぐ

ずっと以前にも利用していた ReportViewer ですが、最近また触れる機会が訪れたので備忘録的な意味も込めてまとめておきます。

必要となる環境は、有償/無償で若干異なります。Visual Studio Pro 版以上を用意できる場合は、特に追加で用意するものはありませんが、Express な無償のみで作成する場合は、別途 RDL/RDLC な ReportViewer 用帳票作成ツールが必要です。

スタンドアロンで帳票定義を作成する場合、Report Builderがちょうどよいかと思います。SQL Server のバージョンや SP のリリースに合わせて更新されるようですので、できる限り最新のものを利用するのがベターです。

Report Builder は SQL Server の関連ツールとして無償提供されているもので、基本機能としては SQL Server Reporting Service に直接デプロイできたりする、対サーバー用のツールです。

SSRS を利用しない、クライアント側で全ての処理を行うローカルレポートの場合、Report Builder で作成する rdl ファイルをそのままでは利用できませんが、拡張子の変更と後述しますが内部の記述を若干変更することで利用可能です。

帳票を作成する流れはおおまかに書くと以下の通りとなります。

帳票で扱う DataSet 等のデータモデルを設定する
帳票をデザインする
出力結果を確認する

まずデータモデルですが、DataSet（DataTable）に限らずオブジェクトをバインドすることも当然可能です。Report 上では特に区別せずに「データセット」という名称で、これを扱っています。名前からすると DataSet でなくてはいけなさそうですが、そんなことはありません。

Report Builder ではツール上でデータセットの設定を行いますが、Visual Studio の場合はモデルとなるデータクラス（通常のクラスやプロジェクトに追加した DataSet）を作成後、一度ビルドしておく必要があります。ビルドしないとデザイナ側で認識できません。

Report Builder 上でデータセットの設定を行う場合は、次のように設定します。

レポートデータタブにあるデータソースを右クリックして、データソースの追加をクリック。

レポート全体におけるデータに対する接続を管理するデータソースを先に作成します。サーバーレポートの場合や、レポート上でデータベースに接続して結果を抽出したい場合には、対象となるデータベースへの接続設定を登録します。プログラム上でデータも作成してそれを出力する場合などでは、データソースの定義のみ必要となりますので、名前を入力するだけで大丈夫です。

データソースを作成後、データセットを設定します。同様に右クリックからデータセットの追加をクリック。

設定ダイアログが表示され、このデータセットで利用するデータソースを求められますので、「レポートに埋め込まれたデータセットを使用します」を選択し、先ほど作成したデータソースをコンボボックスから選択します。

データソースを選択後、左側に表示されている一覧から「フィールド」をクリック。

ここで帳票上で利用するデータ項目を定義します。基本は「クエリフィールド」を利用し、それらの値を事前に計算したい、SQL Server でいう計算列のような項目の場合には「計算フィールド」をクリックします。

ここでは、フィールド名とフィールドソースの二つが必要になります。フィールド名は、帳票上で扱う場合の名称、フィールドソースはバインドしたものの中での名称となります。DataTable であれば DataColumn.Name の値がフィールドソースです。

フィールドを定義し、OKをクリックするとレポートデータタブ上に設定したフィールドが一覧で表示されます。

基本はこの一覧からドラッグ＆ドロップすればよいのですが・・・

単にドロップした場合、バインドしたデータの1件目を表示するように設定されますので、レコードの明細部などでは作成したテキストボックスを入力可能状態にして、そこへドラッグ＆ドロップしてあげる必要があります。なお、この部分はなぜかプロパティタブには表示されていないのがちょっと不便なところです。

このような形で帳票を作成していきます。

前のコンテンツの続きです。

今回は Report Builder で作成した rdl ファイル（サーバー用レポートファイル）を編集し、ローカルレポートとして扱えるようにします。

サーバー用の rdl ファイルと、ローカル用の rdlc ファイル。拡張子が違いますが、その内部はどちらも SQL Server Reporting Service の機能を利用しているために、殆どが同一の記述となる XML ファイルです。

Visual Studio 上で作成した場合は、最初から rdlc ファイルとして作成できるのでこの作業は不要ですが、Report Builder 等のサーバー用ファイルを作成するツールの場合、以下の変換作業を行う必要があります。

変換する必要があるのは 2 箇所です。データソースについてと、データセットについての箇所を変更することになります。

   1:<DataSources>

   2:<DataSourceName="DataSource1">

   3:<rd:SecurityType>None</rd:SecurityType>

   4:<rd:DataSourceID>02ac4784-febf-4de8-a38b-e07c20d83339</rd:DataSourceID>

   5:</DataSource>

   6:</DataSources>

   7:<DataSets>

   8:<DataSetName="DataSet1">

   9:<Query>

  10:<DataSourceName>DataSource1</DataSourceName>

  11:<CommandText/>

  12:</Query>

  13:<Fields>

  14:<FieldName="Field01">

  15:<DataField>DB_Field01</DataField>

  16:<rd:UserDefined>true</rd:UserDefined>

  17:</Field>

  18:<FieldName="Field02">

  19:<DataField>DB_Field02</DataField>

  20:<rd:UserDefined>true</rd:UserDefined>

  21:</Field>

  22:</Fields>

  23:</DataSet>

  24:</DataSets>

作成されたばかりの rdl ファイルにおける、データソースとデータセットの記述が XML の最初の方にあります。作成した内容にもよりますが、大体はこのような形です。

データソースの箇所は次のように修正します。

   1:<DataSourceName="DataSource1">

   2:<ConnectionProperties>

   3:<DataProvider>System.Data.DataSet</DataProvider>

   4:<ConnectString>/* Local Connection */</ConnectString>

   5:</ConnectionProperties>

   6:<rd:DataSourceID>02ac4784-febf-4de8-a38b-e07c20d83339</rd:DataSourceID>

   7:</DataSource>

バインドしたデータを参照するためのプロバイダクラスを指定します。今回のサンプルでは DataTable の値を扱うように考えていますので、System.Data.DataSet を記載します。
ConnectionString にはコメントしか記載していないですが、要素としては必要に見られている「かもしれない」のでこのように記載しています（多分、なくても問題ないとは思います…）

   1:<DataSets>

   2:<DataSetName="DataSet1">

   3:<Query>

   4:<DataSourceName>DataSource1</DataSourceName>

   5:<CommandText>/* Local Query */</CommandText>

   6:</Query>

   7:<Fields>

   8:<FieldName="Field01">

   9:<DataField>DB_Field01</DataField>

  10:<rd:TypeName>System.String</rd:TypeName>

  11:</Field>

  12:<FieldName="Field02">

  13:<DataField>DB_Field02</DataField>

  14:<rd:TypeName>System.String</rd:TypeName>

  15:</Field>

  16:</Fields>

  17:</DataSet>

  18:</DataSets>

続いてデータセットの部分です。こちらでは利用するデータソースに対しての記述と、扱うフィールドについて、それぞれを修正します。

Query の CommandText、rdl では空要素となっていたので、これもわざわざ値をコメントとして追加しなくても良い気もします……。

フィールド部では、各フィールドの型を追記します。ここで指定したタイプによって、帳票上での扱われ方が異なる点がありますので注意が必要です（Null の場合など）。

これだけの修正で、作成した rdl ファイルを rdlc ファイルとして利用することが可能です。

ここまでの内容でローカルレポートとなる rdlc ファイルの作成ができたので、次はプレビュー画面を表示させます。といっても大したことはなく、提供されている ReportViewer コントロールを利用することで、WinForms または WebForms であれば簡単に帳票プレビューが行えます。

一つ注意が必要なのは、ReportViewer コントロールに対しての参照設定です。

Report Viewer 2010 までは Visual Studio 側でも認識しており、ツールボックスにもすぐ表示できるのですが、Report Viewer 2012 からは手動で参照設定する必要があります。

その点だけ気を付ければ、あとは利用するバージョンに関わらず同様のコーディングとなります。

   1:'Form に貼り付けた ReportViewer コントロールの名前を rptViewer としています

   2:Dim rdlc As LocalReport = Me.rptViewer.LocalReport

   3: rdlc.ReportPath = "Sample.rdlc"

   4:Me.rptViewer.ProcessingMode = ProcessingMode.Local

5:

   6:'レポートで利用するデータセットの登録

   7:Dim dt AsNew DataTable = GetSampleData()

   8: rdlc.DataSources.Clear()

   9: rdlc.DataSources.Add(New ReportDataSource("DataSet1", dt))

10:

  11:'表示モード指定とデータセット反映

  12:Me.rptViewer.SetDisplayMode(DisplayMode.PrintLayout)

  13:Me.rptViewer.RefreshReport()

ReportViewer コントロールでは、ServerReport と LocalReport においてアクセスするためのプロパティを分けてあります。SQL Server Reporting Service を利用する場合は、ServerReport プロパティを通した処理を、今回のように全てをローカルで行う Local Report の場合は LocalReport プロパティを通して処理を行います。

2～4 行目で利用する rdlc ファイルを指定し、処理モードを Local に設定しています。

7~9 行目ではレポートで利用するデータ（今回は DataTable）をセットしています。この際、ReportDataSource クラスを利用するのですが、ここで設定する名称は rdlc 側で定義してあるデータセット名となります。データソース名ではないので注意してください。

最期に 12 行目で初期表示モードを指定しています。ReportViewer では印刷時モードと論理モードがあるのですが、個人的には論理モードの使い道をわかっておらず、基本印刷時モードで表示しています。

以上のようにすることで、ReportViewer を利用したアプリが作成できます。
Visual Studio Pro 版以降を所有しておらず、Express 版を利用してツールに費用をかけないで開発しなくてはならない場合では参考になるかと思います。

2015/11/28 に JAZUG 北海道（きたあず）の勉強会に参加しまして、そこで LT を行ってきました。VB.NET 使いとして日頃感じる不満を表現してきました（

LT_20151128—Ahf(Tomoyuki Obi)

VB.NET でも問題なく ApiApps のデプロイまで成功していますので、問題なく開発ができると思います。テンプレートはこちらからどうぞ。

やっている内容としては、もともと C# 用だった ApiApp のテンプレートを、VB 用とするためにソースのコンバートや、proj ファイルの編集を行った程度ですが、これでテンプレートがないから、といって ApiApp を触っていなかった方でも開発を試すことができるのではないでしょうか。

久々の勉強会参加という事もあり、非常に楽しんできました！久しぶりにお会いできた No.1 やがりっち、そしてついにお会いできた世界のやまさ！

かねてよりその将来性を見込んで楽しみにしている Azure LogicApps が（けっこう大規模に）アップデートされました！

今まで苦汁をなめていた日本語も問題なく取り扱えるようになり、非常に面白いものへと仕上がっています。

まだ既存のコネクタを元に色々遊んでいるところですが、コネクタの選択がちょっと一癖あったのでメモ。

パッと見るとコネクタが減ったのかな、と思えますが・・・

検索ボックス上で検索しないと出てこないようになっていました。初期状態では基本コネクタというか、頻度の高そうなものなどが選ばれている状態のようです。

こういう感じに楽しめるものが出てきましたので、これからしばらくは LogicApps をいじくってみようと思います。

このようにしゃべらせるためのコネクタもあったりと非常に面白そうです！

LogicApps 楽しいので日々触っていますが、なかなかうまく意図したとおりにできなかったりと難しいところも結構あります。その中でまずは、Twitter のツイートに反応させることができたので、メモしておきます。

まずは実際の Logic 部分です。

トリガーとして Twitter Connector を利用し、特定の検索条件（ここでは Nawa ）に該当するツイートを検索させるようにします。

ここで何かしらのツイートが検索できた場合に、次のコネクタが呼び出され「気配を感じた・・・ざわ・・・ざわ・・・」とツイートすることになります。

ちゃんと「Azure AppService Logic Apps」と表示されているのが確認できると思います。
（本題からそれますが、公式サイトでこれを確認をどうすればいいのかわからなかったり・・・）

最初の検索で「検索できた場合」と言いましたが、これは Twitter Connector がそのように作成されているからです。検索できなかった場合には Logic の実行が失敗とさせ、以後のコネクタが呼び出されないようになっています。

この挙動については、LogicApps ブレードの Trigger histories にて確認が可能です。

今回は何かしら検索にひっかかった場合、一覧上で[ Fired ]と記載されているように、イベントが発生したことを表しています。ここに記載がない場合は検索しても、何も抽出できなかった場合で、後続処理は行われません。

また All runs として、どの程度の頻度で Twitter の検索が実行されているかも確認できます。これを見る限り、不定期ですが 1 分間に 3 度ほど、検索していることが確認できます。これまでのトリガを利用した場合、最短で 1 時間に 1 度までしか指定できない（それ以上短い間隔は、恐らく有償プランが発表されてからと思われます）のと比較すると、かなりの頻度です。

ただし、これは実際には「そのようにコネクタが作成されている」からだったりします。

今回の Logic のコードを表示させてみると、それがわかります。

上記がそのトリガ部分です。frequency 値として Hour、interval 値として 1 が指定されており、1時間単位で動作することが指定されています。

このように色々とコネクタの仕様に影響するところは大きいですが、当初の目的は非常に簡単に達成できています。自前で ApiApps を作り LogicApps から利用するだけでも、簡単に色々なことができるようになるのがわかるかと思います。

新しくなった LogicApps ですが、色々なところが変更になったこともあり今までとは挙動が変わっているところも多々あります。今一部で最もホットなコネクタ、Twitter Connector ですが、微妙な挙動がありよくわからないというのが本当のところです。

基本的な挙動としては、トリガとなるコネクタに依存すると思われるのですが、実際に利用している限りは、Recurrence トリガを指定している場合と同じ動作を示すことが多いです。

Recurrence コネクタは「定期的に LogicApps を実行する」ためのトリガコネクタで、無償プランでは 1 時間に 1 回より長い間隔でのみ指定が可能です。有償プランではもっと短いスパンでの動作もできるようですが、このあたりはプレビュー版ということもありまだはっきりしていません。

ところが、先日試していて発生していたのは次のような状態です。

[image%255B24%255D.png]

このように動くときは結構短い頻度で動きます。ですが、

このように 1 時間ごとに動いたりもし、何が原因で動作が安定していないのかは測りかねる状態です。

ただ、今のところは、

Twitter Connector で検索できた結果数分、API のインスタンスが生成される

というように思えます。このあたり、色々試してはっきりしたらまたまとめたいと思います。

前回の試行錯誤で悩んでいた件ですが、気が付けば再現しないようになっていましたｗ

そこで今回は LogicApps を使って簡単な Twitter BOT を作成する流れをまとめておきます。

LogicApps を作成し、デザイナーにて以下のように設定します。

まずはトリガとなる Twitter Connector です。トリガとして利用する場合は、上記のように何かツイートを検索してその結果が発生したら、という場合に限り処理を行うことになります。

この際に指定できる文字列ですが、Twitter 検索のパラメータが利用できるとなっており、詳しくは試せていませんが恐らくは =q の後に記載するパラメータがそのまま利用できるのではないか、と思われます。今回の例では @botkumaa とあるように、このアカウントに対して何かしらリプライを送ったものを検索するように設定します。

現在の Twitter Connector では内部に前回検索した ID を保持しているので、今回検索して抽出できたもの以降が、次回の検索にて対象となるようになっています。

続いての例としては Condition コネクタを利用して、検索できたツイートに特定のキーワードが含まれているかを判断させています。ここで OBJECT NAME に指定するのは検索対象となるものを指定するのですが、ここまでに利用しているコネクタが提供している出力については、画面に表示されているようにクリックするだけで選択が可能です。上記の例では、Twitter Connector が返却する値の中で、「ツイートされたテキスト」である Tweet Text をクリックしています。

RELATIONSHIP では判断条件を設定します。上記の例では Contains を選択しており、後続の ALUE 値が OBJECT NAME に含まれているかどうかを判定させています。ここで指定できる条件は一般的なプログラムで利用できるような条件がそろっています。

利用できる条件については、以下の通りです。

英語表記ですが、なんとなくはわかるのではないかと思います。

Condition コネクタによって特定のツイートを含んでいた場合の条件判定ができますので、今回はサンプルで何か適当な返事をさせてみます。

このように Condition コネクタの後には、条件を満たした場合に実行するものと、満たさなかった場合に実行するコネクタを設定できます。残念なのは、ここで Condition コネクタをネストさせるような使い方ができないという点です。これを現在行おうとした場合は、別に LogicApps を作成し、それを呼び出すなどの方法を採用する必要があります

このような形で設定することで、簡単な BOT が実装できるのは伝わったことと思います。力技になりますが、Condition コネクタを大量に羅列することで、もっと反応する幅を広げることができるようにもなります。

実際に私が用意した BOT の場合、別の Web サービスを利用してもう少し色々返事をできるようにしていますが、それについては後日公開します。

Azure LogicApps は既存サービスを色々組み合わせることで、比較的楽に目的を達成するアプリを作成することができますが、その際に色々と気を付けなくてはならない点があります。

外部サービスを呼び出すためのコネクタは HTTP コネクタか HTTP + swagger コネクタになります。swagger による API 設定がないサービスの場合は HTTP コネクタを利用することになります。

HTTP コネクタでは、通常の HTTP 呼出しを行いますので、サービスの呼出し以外にも Web サイトの取得など、HTTP アクセス全般が可能となっています。

このように、HTTP アクセス時の動詞指定や、ヘッダ、ボディに設定する情報を記載できるようになっています。もちろんここでは、ここまでに利用しているコネクタが提供している値を利用できますので、上記の例のようにTwitter Connector が提供する値をそのまま利用することも可能ですし、編集して渡すことも可能です。

対して swagger が存在する場合は HTTP + swagger コネクタを利用します。こちらの場合は、まず提供されている swagger doc のアドレスを指定します。ですが、ここには一つ注意する点があります。

昨今のセキュリティ事情もあり、API は呼び出し可能なアドレスを定義する CORS というものがあるのですが、そこに LogicApps の呼び出し元となるアドレスを指定する必要があります。ですが、このアドレスは Azure App Services を良く知っている人でなければ探すことすらできないという代物で、私は見つけられませんでした。

特に Azure APIApps として同じサブスクリプションに作成しているものであっても、この CORS 設定は必要となっているので注意が必要です。

そこで教えてくれたのは、われらがしばやん先生！さすがこのあたりの挙動についても、すぐ調べられることができるあたり、さすがです！このアドレスを CORS として設定することで、LogicApps からの呼出しに応答できるようになります。

無事に swagger で定義された内容を取得できると、コネクタの表示が変わり、定義にそった入力欄が表示されます。ここで値を記述、または指定することで API に対して値を受け渡すことが可能です。

LogicApps 上でコネクタを選択する際、同じサブスクリプションにある APIApps は選択しやすいように、「Show APIs for Services in my subscription」を選ぶことで自分がアップしているもののみに、選択肢を限定することができます。

このような形でコネクタを利用することで、外部サービスや、同じサブスクリプションに用意した Azure ApiApps を呼び出すことが可能です。

以前の LogicApps で利用できていた BizTalk 関係の Api コネクタですが、現在はどこにも見当たらない状態になっています。

LogicApps を作成する際に、上記のようなサービスプラン選択を行う箇所があるかと思いますが、、この中の Premium ものについては画面のように「BizTalk Services」の記載があり、さもこれを選べば利用できそうな気配を漂わせています。

が。

これは Api としての BizTalk とはまったく関係のないものですので、現状は LogicApps 上から BizTalk 関係の APIApps を呼び出すことはできません。

現在のドキュメントの類を読む限りは、PowerApps で利用可能なようなので、日本に来るのを気長に待つことになりそうです。

たわいない点でエラーになっていたのでメモとして。

LogicApps では Azure Storage の Blob へ簡単にファイルを作成することができるようになっています。

コネクタとして Azure Blob というそのものなものが用意されているのでそれをクリックすると、資格情報の入力が求められます。ここで入力した情報を用いて Blob へとアクセスします。

必要となるのは「アカウント名」と「アクセスキー」です。Connection Name は適当な名前で構いません。これら二つの情報は、Blob の設定ブレードから確認できます。

なお、接続については、同じ Logic 上であれば共通となります。
ここに表示されている値を先ほどの設定に記載すると、次のように表示が切り替わります。

ここで、出力先のパスとファイル名、そして出力する内容を設定するのですが、パスについてだけ今の時点では注意が必要です。

このように出力先を選択できるのですが、ルートフォルダとなる AzureBlpb には出力できません。選択できてしまうのでいけそうに思えるのですが、これを選択して出力しようとすると、「無効な文字がパスに含まれている」とエラーになってしまいます。

そのため、ルート以外となるようにフォルダを作成し、そこに出力するようにすれば問題なく利用可能です。

これ、選べてしまうのが問題な気がします・・・。

今の今までずっと悩んでいた LogicApps 上だけで JSON 値を触る方法ですが、ようやく見つかりましたのでメモしておきます。

海外でも同様の事例で悩んでいる人は多いようで、Stack Overflow 上で同じ話題のスレッドがありました。この中で、「parse 関数用意されてるから使えばいけるよ！」という回答があったので、それに従ってやってみたところ、エラーになったので中身を確認してみると・・・。

INPUT / OUTPUT ともにないという結果に。この状態の場合、Logic 上で記載している内容にエラーがあるが定義としてはエラーではない（デザイナー上でエラーにならない）場合を示しています。実際のエラー内容は、下段にある ERROR のところに出漁されているのでこれをコピペして確認してみると次のようになっていました。

{"code":"InvalidTemplate",
"message":"Unable to process template language expressions in action 'Create_file' inputs at line '1' and column '11': 'The template function 'parse' is no longer supported in schema version '2015-08-01-preview'. It has been replaced by the 'json' function since version '2015-08-01-preview'.'."}

簡単にまとめると、parse 関数は 2015-08-01 版では json 関数に名前が変わったからそちらを利用してください、ということです。

MSDN のドキュメントを見てみると、確かに一番最後にそういう記載が・・・

ということで現在の LogicApps では json 関数を、以前の版で利用する場合は parse 関数を利用することで json 値を操作できるというのがわかりました。実際の記載方法は次のようになります。

FILE CONTENT のところに記載したのが json 関数を利用している箇所です。グレーアウトされていることから察することができるかと思いますが、今の時点ではデザイナ上から正しく記載することができず、Code View から直接記載することで利用ができている状態です。これはまぁ、そのうち改修されていくものと思います。

上記画像の Create File コネクタの Code は次のように記載されています。

サンプルとして記載したのは、testvalue と test2 という二つの値を持つ JSON から、testvalue の値を取得し Azure Blob に出力しています。サンプルでは直接 JSON の値を記載していますが、もちろんここは別の API の結果をそのまま指定したりすることが可能です。

このような形で JSON 値も扱えることがわかったので、LogicApps だけでできることがさらに広がったのではないかと思います。

現状の LogicApps デザイナーで早いうちに何とかしてもらいたいのがこれです。

このような形で自作の ApiApps を呼び出すように設定したとします。

CodeVIew 上でも正しく値が設定されています。再度デザイナーに戻ると・・・。

このように設定された値が表示されなくなっています。Code 上ではどうかと確認してみると・・・。

設定した値が破壊されているのがわかるかと思います。早く修正されるといいなぁ・・・。

MSDN Blog に書かれている内容で、過去コネクタとして提供されていたものを現在の LogicApps から呼び出す手順がまとめられていたので、実際に試してみました。

まずは API としてデプロイされていないといけないので、MarketPlace から導入します。

旧コネクタ群は上記のように MarketPlace 上にあるので、利用したい API を選択、導入します。

「すべての設定」から「Appilcation settings」と選択肢、Access Level を「Public(anonumous)」に設定します。ただ、本来であれば AD を絡めて認証を用意するなどが必要なことを忘れないでください。

認証を設定した次に、API の CORS 設定を行い、LogicApps デザイナーからアクセスできるよう設定します。ただし、ここで設定するアドレスですが、MSDN の一部では * 設定にして、といった記述も見受けられますが、先ほどの認証同様基本的には制限をかけておくのが是となるかと思います。

CORS の設定方法ですが、API Host に対して行います。

デプロイした API のブレードから、API Host として表示されているアドレスをクリックすると、API Host のブレードが表示されます。

そこから「すべての設定」をクリックすることで CORS の設定が呼び出せるようになります。

デザイナーのアドレスは https://ema1.exp.azure.comになるとのことです。設定し、保存をクリックしてください。

この状態にすることで、LogicApps デザイナーから参照が可能になります。

HTTP + swagger コネクタを利用するのですが、この際に設定するアドレスは以下の通りです。

https://{apiHostName}.azurewebsites.net/swagger/docs/1.0

API Host のアドレスは HTTP なので HTTPS にしてもらうのと、アドレス末尾に swagger/docs/1.0 と付与してもらうことで BizTalk 関係の場合は API 定義を参照できます。

参照できると上記のように利用する API 種類を選択できますので、以後はパラメータの指定などを行えば利用可能です。

Build 2016 で唐突に発表された Azure Functions ですが、仕組み上は ApiApps とほぼ同様なのもあり、LogicApps からも非常に簡単に利用することができます。

呼び出したい Function Apps 側では、先に CORS の設定が必要です。

上部にある「Function app settings」をクリックすると、次のような表示になります。

Configure CORS をクリック。

https://ema1.exp.azure.comを追加。これは先の ApiApps を呼び出す場合の設定と同様の、LogicApps デザイナーのアドレスです。

あとは LogicApps 側で呼び出すように記述するだけですが、デザイナーが同時期にバージョンアップされており、Function Apps も楽に設定できるようになっています。

上記のように MS 公式コネクタ、ApiApps 、そして Functions が選択できるようになっていますので、ここで Functions を選択します。

自分のサブスクリプション上で、既に作成されている Function Apps が一覧から選択できますので、まずはコンテナとなるものをクリック。これは、Function Apps を新規作成する際に入力した、アプリ名となります。

コンテナをクリックすると、現在利用できる Function Apps が一覧表示されますが、Create New Function は表示されていますけれども、不具合だと思いますｗ

今回呼び出そうとしている Function はサンプルそのままの以下のものです。

ここの 12 行目で req.Content.ReadAsStringAsync で呼び出したい値を、LogicApps 側で記載します。

これだけで Function Apps を LogicApps から利用できるので、ApiApps を作るまでもないものであれば、こちらを利用してしまうのが便利かな、と思います。

Build で発表された内容のうち、もう一つ気になっていた Bot Framework ですが、案の定 Vb 版についてはテンプレートが用意されていませんでしたので、作りました。

ダウンロードはこちら

一応エミュレータとテスト実行してみて、動作が一緒なのは確認していますので、「また VB 構われてねぇよ」とやさぐれるまえに、一度お試しください。

定期的に LogicApps を実行する際に利用する Recurrence トリガーですが、実際に利用するとなると「09:00 から 1 時間ごとに」というように動かしたい場合がほとんどだと思います。

その場合 Recurrence トリガーの STARTTIME に指定することで、初回起動時間が指定可能です。

上記のように指定することで、UTC による指定が可能です。タイムゾーンを加味した指定を行う場合は、TIME ZONE 設定を指定すればよいのですが

タイムゾーンなので TOKYO を選択する必要があります。

このような形で指定すると

上記のように有効にしたタイミングが 17:25 であっても

このように 17:30 に実行（細かい時間はずれるもの？？）されるようになります。

LogicApps 公式チームの Blog などにも何も書かれていないのですが、いつの間にか LogicApps でほんの少し変更が加えられていました。

MailChimp コネクタの追加

メールマガジンを提供することのできるサービス MailChimp 向けコネクタが追加されていました。トリガとしては「購読者が増えた」と「あたらしい ML が増えた」というのが用意されているようです。そのうちアカウント作って試してみますかね・・・。

検索単位が「サブスクリプション」から「リージョン」へ

これまでコネクタを検索する際の条件は「サブスクリプション」単位だったのですが、今では「リージョン」単位と変わっています。基本は同一リージョンであれこれするのが多いで、あまり大きい変更ではありませんが、複数リージョンをまたぐ Logic の作成が原則なしになったということかと思います。

別リージョンの ApiApps や LogicApps 呼ぶときは HTTP で REST API を呼び出せ、ってことなんでしょうね。

直前のアップデートで、LogicApps を呼び出すための URL が取得しやすくなったのもあり、外部から LogicApps を呼び出し、その結果を受け取るというのをやってみました。

まず先に呼び出される LogicApps 側を用意しておきます。

Manual トリガーを用意し、すぐに Response を返すというサンプルです。Manual トリガーを設置した後に、一度保存することで Manual トリガーコネクタに、呼び出し用のエンドポイントアドレスが表示されますので、それをコピーします。

呼び出す側のロジックはとりあえず次のように作成してみました。

Open Live Writer で早くコードを張り付けられるプラグインがほしいところです（

サンプルを見てわかる通り、「特定のアドレスに対して POST を行う」ことで LogicApps の呼び出しができてしまいます。認証云々は関係なく呼び出せるので、取り扱いには注意が必要です。

なお、実行結果は次のようになります。

意外と簡単に LogicApps を呼び出し、その結果を受け取れているのがわかると思います。

恐らく 2016/04/24 か 04/25 のあたりで SendGrid コネクタが突然追加されていたので、実際に利用してみました。非常に簡単に SendGrid を用いたメール送信ができるので素晴らしいです。

追加されているコネクタの機能は、上記 2 種類となっています。今回は Send email な機能を利用してメール送信を行います。

コネクタを選択すると、まず接続設定を求められます。 Connection Name はこの LogicApps ワークフロー上で利用する際の接続名で、適当に名付けして OK です。

もう一つは SendGrid を利用するための API Key ですが、これは SendGrid のアカウントで SendGrid の管理コンソール上で発行する必要があります。

アカウントを保有していない場合は、新規作成の開発者向けサービスに SendGrid がありますので、こちらから作成します。

作成したアカウントを開くと、上のようなブレードが表示されますので、Manage と書かれている一番左のアイコンをクリックします。

SendGrid のコンソールがブラウザ上に表示されます。

※最初の Hi、Reseller! なところって、登録した際のメールアドレスに何かメールを送るのですが、Azure Portal からの場合、謎メールアドレスなので右上の「X」をクリックして閉じてしまうのですが、これでいいのかな・・・？

左側のメニュー一覧に Settings があるので、そこをクリックすると API Keys の項目が表示されますので、さらにクリック。

現在保有している API Key の一覧が表示されますが、注意する必要があるのはここでは実際の Key を確認することはできません。セキュリティの問題から、SendGrid の API Key は発行時にのみその値が取得でき、以後は再取得できません。

右上の Create API Key をクリックすると、必要とする権限についての設定を求められます。

今回はメール送信だけ行うので、Mail Send に対して Access 可能に選択します。
（Mail Send の Full Access を選択する）

権限を設定した後に右上部の Save をクリックすると、このように API Key が作成されます。
図の中で黒塗りしている部分に文字列が表示されていますが、ここをクリックするとクリップボードにコピーされます。これで SendGrid 側の準備は終了です。

その後、LogicApps 側で API Key を入力、接続を作成するとコネクタの表示が切り替わります。

実際に設定可能な項目はほかにもあり、コネクタ下部の［．．．］をクリックすると表示されます。添付ファイルを付けたりとか、送信者名を記載するとか色々設定可能ですので、ここは実際に見てみるのがよいと思います。

ここまでの設定を行うことで、LogicApps から SendGrid を利用してメール送信が行えます。

ロジックを一つも書かなくとも、メール送信を好きに行えるようになるのは、非常に大きなメリットではないでしょうか。例えばこれで、OneDrive にファイルがアップロードされたらメールで通知する、なんていうものが簡単に作成できるようになります。

LogicApps のトリガが増えることにより、さらに使い道もますのでますます楽しくなってきました。

ReportViewer の LocalReport を利用する（１）

ReportViewer の LocalReport を利用する（２）

ReportViewer の LocalReport を利用する（３）

Azure ApiApps の VB.NET テンプレート

Azure LogicApps がアップデートされました

Azure LogicApps で Twitter に反応させる

新版 Twitter Connector の動作感覚

Azure LogicApps で Twitter BOT を作る

Azure LogicApps で外部 HTTP サービスを呼び出す

BizTalk 系統の ApiApps の行方

LogicApps で Azure Blob へファイルを作成する

LogicApps 上で JSON 値を取得する

LogicApps デザイナー上で設定した値が再表示の際に破壊される件

ApiApp V1 な旧コネクタを LogicApps 2015-08-01 preview から呼び出す設定

Azure Function Apps を Logic Apps から呼び出す

Bot Framework の VB 版テンプレート

LogicApps の開始時刻を指定する

LogicApps がこっそりとアップデートされてました

LogicApps を外部から呼び出し結果を受け取る

LogicApps に SendGrid コネクタが増えていたので試してみた