使用して、アップロードされたイメージのサイズ変更を自動化する」のチュートリアルをご覧ください。Triggerが公式ドキュメントでは挙げられています。Storageのファイルを入力としてバインドすることになります。Blobのファイル内容をログ出力するサンプル関数のバインド構成、C#スクリプトコードを以下に示します。{myQueueItem}”);log.Info(myInputBlob);}[/code]バインドではトリガーに”myQueueItem”、入力に”myInputBlob”という名前を与えています。入力パスに”queueTrigger”メタデータプロパティを含むことで、キューに与えられたメッセージと同じ名前のBLOBが入力にバインドされます。これらの設定により関数内にて変数”myQueueItem”でBlobのパス、変数”myInputBlob”でそのパスのファイルの内容をそれぞれ参照できるようになります。StorageにBlobのパスをキューする処理を追加しなければなりません。Triggerなど別のイベントをトリガーに利用した場合も同様で、何らかの方法でクライアント側から関数にBlobの配置を知らせる必要があります。Storageの制限上、順序の保証がされないこと、同じキューが2度以上イベントをトリガーする場合があることには注意が必要です。これらの保証が必要な場合、別のAzureサービスをトリガーに利用することを検討しましょう。Busなどが挙げられます。Busキューは順序、厳密性以外の特性も考慮して選択すべきです。最後にQueueにBlobのパスが渡されたがそのパスにBlobが存在しない場合、バインドされた入力の内容は空になります。これはBlobが存在するが内容が空の場合と挙動が同じため、これらの区別が必要な場合、注意が必要です。Triggerを利用して、準リアルタイムにオブジェクトの配置を検知する方法も考えられます。Triggerなどと異なりクライアント側からBlobの配置を関数に知らせる必要がありません。Functionsの統合機能で入力をバインドすることができません。Storageアクセスのコードが含まれることになります。{blob.Uri}”);log.Info(blob.DownloadTextAsync().Result);blob.DeleteAsync().Wait();}}[/code]例に示す関数では、変数”storageConnectionString”に記述した接続情報を用いてBLOBに接続し、その後CloudBlobContainer.ListBlobsメソッドを用いてコンテナー内の全ファイルを検索します。得られたそれぞれのBLOBについて内容をダウンロードしてログ出力し、その後BLOBを削除します。(上記コードはログの内容が混ざらないよう、非同期処理を即座にWaitしています。ファイルを加工して別のコンテナーにアップロードするなどの場合はawaitを使って並列処理したほうが効率が良いでしょう)Timerをトリガーに利用する場合のその他の注意点として、関数の処理中に次のスケジュールの関数実行が開始されてしまう可能性を考慮した関数設計にしなければなりません。同じBlobに対して処理を何度も行わないよう、Blobを削除や移動する処理を記述する必要もあります。Storageに配置されたファイルに対して処理を行う際の注意点を紹介しました。Triggerを用いると、すべてのイベントがキャプチャされるとは限らず、処理されないファイルが現れる可能性があります。Triggerなどを用いて関数にファイルを探してもらう必要があります。Lambdaでは、オブジェクトストレージをトリガーに利用しても、ファイルが配置された際に少なくとも1回は関数がトリガーされることが保証されており、より素直な構成でファイルの処理を関数に任せることができます。Functionsにはない特徴はやはりトリガーだけでなく入出力のバインドも統合的に管理可能なことですので、トリガーの高機能化、入出力レパートリーの拡充があるとより独自の強みが出るのではないかな、と思いました。Azureもまだまだ成長中ですので、今後のアップデートが見逃せませんね。ここまでご覧いただきありがとうございました。使ってサーバレスなslackボットを作成してみた。Reserved.本サイトに掲載されている社名、製品名、サービス名等は各社の商標または登録商標です。プライバシーポリシーお問い合わせ。