約1年のご無沙汰になってしまいました。
すでにお知らせしたとおり、日本マイクロソフトの一員としてAzureと常に向かい合う日々を過ごしております。
言ってみれば、私にとっては夢のような世界(?)に居るわけです。
5月にはde:codeにも登壇させていただき、App Serviceの活用に関するセッションを担当させていただきました。
セッションの準備をする中で、私自身がLogic Appsの魔力(?)に取り憑かれてしまいました。
かねてより「箱と線で表現する世界」が大好物な私ゆえ、ど真ん中のストライクだったわけです。
Flowとどう使い分ける？
実は、Office 365のサービスとして登場したMicrosoft FlowとLogic Apps、、、酷似しております。
デザイナーに関しては全く同じものであるといってよいと思います。
そのため「どっちを使ったらよいの？」と迷われる方もいらっしゃると思います。
これは明確な回答があります。
個人の生産性向上or エンタープライズシステムとして利用で考えれば、自ずと答えが出ます。
私のように企業ユーザーを担当させていただいている場合は、ほぼLogic Appsに落ち着くことになります。
特に、ワークロードに応じてスケールアップ&スケールアウトできることやロジックにRBACやリソースロックが掛けられることなど、エンタープライズで安全に利用するための機能があるなどの特徴があります。
Logic Appsは便利だけれど・・・
安全にお使いいただけるだけでなく、容易にロジックを記述することが可能なLogic Appsですが、使っていて「おや？」となることがありませんか？
少なくとも私はなることがあります。
例えば、ロジックに変更を加えたい場合です。ロジックの中に新たなアクションを挿入したい場合、挿入場所以降のアクションや条件をすべて削除した上でロジックを挿入する必要があります。
また、アクションの名称を後で変更することができないため、途中で「イケてない名前を付けてしまった」と後悔しても時すでに遅し、、、だったりします。
ご安心ください。そんな時でも安心の対処方法が存在します。
それは「コードビューで直接jsonを編集してしまう」ことです。
そのため、まずはLogic Appsのコードの構造を理解することから始めていきましょう。
Logic Appsコードは以下のような3つのセクションから成り立っています。
最初のパートのコネクションの定義情報は「 “$connections”: {} 」で囲まれたブロックに存在します。
ここでは、TwitterやOneDriveなどの外部APIの接続情報が定義されている、リソース情報を指定します。
そのため、あらかじめリソースグループ内にこれらのリソース定義が存在している必要があります。
接続情報は「 “value”: {} 」で囲まれたブロック内に記述し、各接続情報は3種のパラメーターを持ちます。
- connectionId：接続情報のリソースID
- connectionName：接続情報のリソースグループ内名称
- id：リソースの種別（/subscriptions/[サブスクリプションID]/providers/Microsoft.Web/locations/[リージョンID]/managedApis/[API種別] ）
これをLogic Appsで利用するものすべてを定義します。
次にアクションの定義を見てみましょう。
ここはアクションの種別によって異なりますが、概ね以下の通りに構成されています。
- “conditions”：アクションの前提となるアクション。フローの直前のアクション名が定義される
- “inputs”：アクションのパラメーターやURIなどが定義される。内容はアクションの種別により異なる
- “type”：アクションのタイプ
アクションによっては、inputブロック内にメソッドタイプ(get、post等)を記述するものや、独立した”method”定義をするものがあります。
また、”metadata”を含むものもありますので、これらはソースをよく見て何が定義されているかを確認してみることをお勧めします。
例えば、HttpによるAPI AppsのCallは以下の内容が定義されています。
“[アクション名]”: {
“conditions”: [
{
“dependsOn”: “[直前のアクション名]”
}
],
“inputs”: {
“method”: “get”,
“queries”: {
[パラメーターの列挙]
},
“uri”: “[APIのURI]”
},
“metadata”: {
“apiDefinitionUrl”: “[swaggerのURL] “,
“swaggerSource”: “website”
},
“type”: “Http”
},
このルールさえ分かってしまえば、名前を変えたり順序を入れ替えたりすることが簡単だという事がわかりますよね？
さて、アクションの定義は分かったかと思いますが、条件分岐はどこに記述すべきでしょう？
それは、アクションの”conditions”ブロック内に”expression”を記述します。
例えば、以下のような感じで記述します。
“conditions”: [
{
“expression”: “@not(equals(body(‘[判定条件となるアクションの出力]’), ”))”
}
],
この例は前段のアクションの結果が空でなかった場合に実行できるという記述です。
なお、アクションの定義の順序に規則はありません。あくまで”conditions”ブロックの”dependsOn”でつながってさえいればOKです。
つまり、この記述を変更すれば順序の入れ替えも可能になってくるわけです。
さて、最後にトリガーの定義を見てみましょう。
トリガーは”triggers”ブロックに記述されます。パラメーターはトリガーの種別により異なります。
例えば、Service Busトピック/サブスクリプションのメッセージを受信した際にロジックを開始するトリガーは以下のように記述します。
“triggers”: {
“[トリガー名]”:
{
“conditions”: [],
“inputs”: {
“host”: {
“api”: {
“runtimeUrl”: https://logic-apis-westus.azure-apim.net/apim/servicebus
},
“connection”: {
“name”: “@parameters(‘$connections’)[‘servicebus_1’][‘connectionId’]”
}
},
“method”: “get”,
“path”: “/@{encodeURIComponent(string([ServiceBusトピック名]))}/subscriptions/@{encodeURIComponent(string([サブスクリプション名]))}/messages/head”
},
“recurrence”: {
“frequency”: “Hour”,
“interval”: 1
},
“type”: “ApiConnection”
}
}
この定義では、以下のブロックで構成されています。
- “inputs”：ランタイムURLおよび接続情報、メソッド種別、メッセージPath
- “recurrence”：トリガーの実行単位(毎時/毎分等)、とインターバル
- “type”：”ApiConnection”(固定値)
これで大まかなLogic Appsの構成は理解できましたでしょうか？
この原則さえ分かってしまえば、jsonの編集も怖くないですよね！？
Comments are closed here.