はじめに
キューとトランザクションの概念ですが、普段利用しない場合は使わなくても全く問題ない概念です。
一方で便利な側面もあるので必要最低限の設定と使い方を紹介します。
他のサイトでも解説があったりしますが、細かい設定なども詳しく書かれているため、詳しい人にはありがたいですがとっつきにくい感じがあります。(自分がそうでした)
そのあたりをすべて排除して必要最低限の紹介をしたいと思います。
キューの準備
権限の設定について
前提としてOrchestratorにてキューに関する権限を付与したアカウントを用意しましょう。
検証目的であれば一番強い権限を持たせておけばよいと思います。
キューの作成
Orchestratorでフォルダを開き、キューにアクセスした後にキューを追加でキューを事前に作成しておきます。
設定はいろいろごちゃごちゃしていますが、まずは名前だけでOKです。
任意の名前を付けたら追加を押してキューを作っておきます。
ディスパッチャーの設定
キューを追加するためのワークフローをディスパッチャーと呼びます。
一番簡単なディスパッチャーの例は以下の通りです。
「キューアイテムを追加」を設置し、フォルダーパスやキュー名、アイテム情報を設定します。
アイテム情報には任意のキー(後で呼び出すときに利用)とそのキーに設定する値を決めます。
設定が完了したら実行してみましょう。
トランザクションの確認
キューアイテムを追加するとトランザクションとしてデータが保存されます。
Orchestratorのキューからトランザクションを表示で確認しましょう。
※キューの画面は更新に少し時間がかかるようで、すぐに「残り」の数値に反映されるわけではないようです。
そのため今現在登録されているものを確認するにはトランザクションを確認するのがよいです。
キューが登録されているのがわかると思います。
右側の点から詳細を確認すると、詳細の固有データ部分に先ほど登録した情報が載っているのがわかると思います。
これで間違いなく登録されていることがわかります。
パフォーマーの設定
キューからトランザクションを取得して実際に処理するワークフローをパフォーマーと言います。
パフォーマーのワークフロー設定例は次のような感じになります。
ここでQueueDataというQueue型の変数を用意して設定してます。
トランザクションに保存されたデータの呼び出しにはSpecificContentという設定を行います。
例えばメッセージをログでQueueData.SpecificContent(“TESTDATA1”).ToStringと設定すると、
トランザクションに保存されたTESTDATA1の中身であるDATA1が呼び出すことができます。
最後に処理が完了したら「トランザクションのステータスを設定」でステータス成功にしておきましょう。
引数が多すぎるといったエラーが表示された場合
SpecificContentの検証していると引数が多すぎるというエラーが表示される場合があります。
この時は名前空間がインポートされていない場合があります。(原因はよくわかりませんでした)
対処方法として、エラーが出ている状態でパッケージを管理の画面から任意のパッケージを更新すると更新ついでに名前空間をインポートしてくれるようです。
※もしかするとプロジェクトを開きなおしてもインポートしてくれるかもしれません。
インポートが完了するとエラーが直っているはずです。
終わりに
キューの概念はわかりにくいですが、うまく使いこなすと処理の定義用端末と実際の処理を行う端末を分けたり、実際の処理を行う端末が複数ある場合は分担して処理を行えたりと何かと便利です。
なくても困りはしませんが知識としては持っておいても損はないと思うので簡単な検証レベルの知識を持っておくことをお勧めします。
コメント