この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、小澤です。
本エントリは2020年アドベントカレンダー『今日からはじめるAlteryx再入門』の17日目のエントリです。
Alteryxではマクロを利用することで、処理の共通化を行ったり繰り替え処理を実装したりといったことが可能になることを14日目～16日目までで見てきました。
そんな便利なマクロですが、いざ自分で作ってみようとすると通常のワークフローとは異なる点で苦労することもあります。 マクロはいずれのタイプであっても、他のワークフローから利用することが前提となるため、作成後使ってみるタイミングで以下のような状況に当たることがあります。
- エラーが出て動かない
- 処理は完了するが出力結果が望んでいるものと異なる
通常、ワークフローから利用する他のツールであれば設定値が適切であるかの確認がメインとなりますが、 マクロの場合、実装した処理が間違っていないかも含めて確認が必要になります。
今回は、そんなときのための確認ポイントを紹介していきます。
マクロの確認はなぜ難しいのか？
Alteryxで通常のワークフローを作成する際、エラーが発生したり出力結果が望んだものと異なっていたりする時にはどこが間違っているのかを確認します。 実際に行うこととしては
- エラーメッセージの内容やエラーが出ているツールおよびその周辺から何が不適切か確認する
- 出力など結果が間違っているところから逆順で辿って不適切な部分を発見する
といった方法で、何が間違っているのかを確認したのち、適切な結果となるようにワークフローを修正していきます。
しかし、マクロとなるとこの方法が出来なくなってしまいます。 その理由としてはマクロは他のワークフローからツールとして利用されたときに、挙動がおかしいとなることが挙げられます。
Macro Inputツールのテンプレートに設定したデータでの動作確認は可能ですが、 実際に利用される際には別データが使われますし、インターフェースツールで変更された設定値を含めての動作確認もそれだけではできません。 また、マクロは利用しているワークフローからAlteryx内で開くことも可能ですが、別ファイルとなっているため、利用したワークフローでのデータの流れと合わせて確認することも出来ません。
マクロの動作を確認する
マクロを利用している側のワークフローで問題が起きた場合、そこから原因を追うのは苦労することが分かりました。 そういった問題に対して、Alteryxではマクロの動きを追うための様々な仕組みが用意されています。
マクロ内の動作も確認する
ワークフローを実行すると、Resultsウインドウに各ツールがどのような動きをしたかや、警告・エラーなどのログが出力されます。 通常であれば、Messageツールなどで明示的に出力している場合を除いて、マクロ内の各ツールの処理までは出力されません。 これに対して、ワークフローの設定にて「Runtime > Show All Macro Messages」にチェックを入れることで、それらも含めて出力されるようになります。
これによってマクロ内のどのツールでどんなエラーが発生したのかが確認しやすくなり、内部の動作を追いやすくなります。
マクロ内にどのようなデータが渡っているのかを確認する
マクロ内のどの辺でエラーが発生してるかを特定できたあとは、マクロの処理フローに問題があるのか、データの渡し方に問題があるのかを確認したくなります。 特にマクロ内でエラー発生個所まで多くの処理が含まれている場合、そこにたどり着くまでに利用時のデータがどのように処理されているってるのか確認できるとありがたいです。
そんな時にAPI Outputツールを使ってみると便利です。
このツールをマクロ内に仕込めば、その段階でのデータをResultsウインドウに表示してくれます。 複雑な処理をしているマクロ内での挙動を調べるにはちょうどいいツールとなっています。 エラー発生個所の近辺から辿って「この辺の処理が怪しい」と思われる個所に差し込んで意図し処理結果になってるか確認できます。
注意点としては、API Outputツールを差し込むのはマクロ本体側になるので確認後は忘れずに消しておく必要があります。
どんな設定値が渡っているのかを確認する
問題が起きている原因として、データではなく設定値が問題である可能性も考えられます。 そんな時にも、API Outputツールを活用してみるという手があります。
設定されている値は、Formulaツールにて変数として取得できるのでその値をAPI Outputに流します。
これで、Resultsに設定された値が表示されます。 List Boxなど、取得される値が複雑化しやすいツールなどで、どう与えられているのかの確認も可能です。
インターフェースにこの値が設定されたら？を確認する
マクロの内容によっては、Macro Inputツールのテンプレートを使って単体で実行してみることが難しい状況もあり得ます。 これは、インターフェースツールに何らかの値が明示的に設定されていないと動作しないような状況です。
よくあるパターンとしては、FormulaツールやFilterツールなどでインターフェースから渡された値を直接変数として利用するようなケースです。
マクロ単体でこの状態のものを実行すると、数値の「0」や空文字などが値として取得されます。 ツールが受け取る値として、これらでは動作確認できないケースはよくあります。
そんな時はワークフローの設定にて「Value」でデフォルトとして利用される値が設定できます。
本格的に調査するならDebugを活用する
ここまでで、問題が起きてる周辺の状況を確認する方法を紹介していきました。 複雑なワークフローで本格的に確認を行う場合は、Debug機能を使うとより便利で色々なことが調べられます。
この記事ではAnalytic Appを対象としていますが、マクロでも同様に利用可能です。
マクロに対してデバッグを行うと、 Macro Inputツールがテンプレートを使ったText Inputツールに、Macro OutputツールがBrowseツールに変換されたワークフローが作成されます。 設定値はAnalytic Appと同様、指定した値になった状態で生成されますし、パラメータリストも確認できます。
この段階で、実際に利用する際と同じ設定がされた処理が出来上がってます。 このまま実行して動きを確認してもいいですし、 ワークフローの直前のデータを一度出力してText Inputをそのデータで置き換えることで、実際の内部の動きをそのまま確認することも可能になります。
ここまで紹介してきた個々のやり方を試すよりも最初からデバッグで動きを確認してしまった方が楽なケースも多いかもしれません。 ただし、実際の動作にデバッグ用のワークフローを修正したとしても、元のマクロにそれが反映されるわけでアありません。 そのため、大がかりな修正が必要になりそうな場面などでは、同じ修正を行っているか注意深く確認する必要が生じます。
Batch Macroのエラーを確認する
ここまではどのタイプのマクロでも使えるやり方でした。 それに対して、Batch MacroやIterative Macroにはそれぞれ固有の難しさもあります。 まずはBatch Macroの場合を見ていきます。
Batch Macroで起こる問題としては以下の2パターンが多いかと思います。
- Control Parameterに指定しているデータのうち特定の値でのみエラーが発生する
- データの結合がうまくいかない
前者の場合は、マクロのデバッグを利用します。 テスト用に入れる設定値には、Control Parameterとして渡す値も指定できるので、 うまくいってるデータとうまくいかないデータでそれぞれデバッグワークフローを実行してみてどの段階でおかしくなってるかを確認すると便利です。
後者の場合、「Output Mode」を確認しましょう。
デフォルトでは「All Iterations will have the same output schema (Error if different)」となっているため、 それぞれの繰り返しでの出力は全てスキーマ(列名や列数)が同じになっている必要があります。 スペースの有無や全角半角の違いなど、パッと見では分かりずらいちょっとの違いでもエラーとなるのでご注意ください。
ここの設定は、とりあえずまずは「Auto Configure by Name」でやってみることをオススメします。 各出力で列名が異なる場合、それぞれが別なものとして列が増えた状態で出力してくれるので、どこがどう違ってそうかの確認にも役立ちます。 そこで一度問題点を洗い出して解消したうえで、適切な設定に変更することで最終的なBatch Macroの完成形とします。
Iterative Macroのエラーを確認する
Iterative Macroは、問題が起きたときに処理内容を確認するのが非常に難しいです。 難しくなってる理由は以下のような点が挙げられます。
- どのような動きをするのかの理解が難しい
- 同じデータを使っての繰り返しになるので途中経過を脳内でシミュレーションするのが難しい
そのため、まずはIterative Macroの動きを改めて確認しておきましょう。
このような流れになるため、2回目のループで渡されるデータは1回目の出力、3回目のループで渡されるデータは2回目の出力... という感じで前回のループが終わるまで何が渡されるかはわからない状態です。 マクロを使う側から見ると、1回目のループに渡した入力と最後の出力しかわからないので、結果がおかしくてもどこで間違ってるのか判断しづらい状態となります。
そのため、Iterative Macroで結果がおかしい場合、ループ回数の限定で動作を確認してみます。 まずはループ回数を1回に絞って...と、やりたいのですが、Iterative Macroで設定できるループ回数は2以上になります。
とはいえ、ループが1回のマクロは普通のStandard Macroと変わりが無いので、まずはyxmcファイルをコピーしてStandard Macroとして実行してみるのがいいでしょう。 あるいは、Debugのワークフローを作成して入力を変更したのち実行してみても問題ありません。
この状態で1回は適切な処理が出来てそうということが分かれば、続いてループ上限を2回にしたマクロで実行してみます。
これで、1回目の入出力と2回目の入出力が比較できます。
ループ対象にしないデータのフィルタ条件が間違っていたり、 2回目に回すデータのスキーマが異なっていたり、 2回目以降のデータを対象とした時に予期していなかった処理があったりするとここで発見できます。
2回だけではわからなくて何回かループさせてみて始めて起こる状況というのも存在します。 最大ループ回数を3回, 4回...と増やしていって確かめるという手もありますが、ループ回数を増やして1回ずつ確認するのはなかなか手間がかかります。 そいうときはデバッグ機能を使って力技の最終奥義を発動させましょう。
まずはIterative Macroのデバッグワークフローを作成します。 1回分のみが作成されていますが、この時赤で囲ったのがループの入出力です。
これに対して以下の操作を行います。
- ループの入力を利用したいデータに変更、出力のBrowseツールを削除
- それ以外の部分をコピペ
- ループの出力からコピペ先に入力として接続
この操作を繰り返すことで、n回分のループと同様のデバッグワークフローが作成できます。 あとは、これを実行すれば任意のループ回数における任意のツールでの状況が確認できます。
ここまで来れば普通のワークフローと同様に何がおかしいのかを確認できますね。 それをもとに共通して使えるループ処理自体を修正するのもまた難しかったりしますが、なんとかIterative Macroも中身を追って動作確認できるようになりました。
おわりに
今回は、マクロの動作があやしかったりエラーで動かなかったりするときに、どのように確認していけばいいかを解説しました。
利用者側は内部がどのような実装になっているのか知る必要なく使えるのが望ましい状態ではありますが、 一切のバグがないというはあまり現実的ではありませんのでこの手の話は知っておくといいでしょう。 また、ここで挙げた方法は私が使うやり方ですが、他にも方法はあるかもしれませんので、ご自身でやりやすい方法を探ってみるのもいいでしょう。
明日18日目は兼本による機械学習の話を予定しています。 お楽しみに！
6
