ポスト
目次
via pixabay.com
はじめに
こんにちは、新卒2年目エンジニアのUです。
本記事は、mitocoX Ver2.0を初めて触る方や、これからデータ連携作業を行う方を対象としています。
実際にmitocoX Ver2.0を利用する中で、未経験・初心者の立場でつまずいたポイントがいくつかありました。
本記事では、それらのつまずきポイントを実体験ベースで整理し、同様の作業を行う際の参考になればと思い執筆しました。
技術的な詳細な解説というよりは、作業を進める中で「分かりづらかった点」「戸惑った点」を中心にまとめていますので、これからmitocoX Ver2.0を扱う方の助けになれば幸いです。
本記事は、mitocoX Ver2.0を初めて触る方や、これからデータ連携作業を行う方を対象としています。
実際にmitocoX Ver2.0を利用する中で、未経験・初心者の立場でつまずいたポイントがいくつかありました。
本記事では、それらのつまずきポイントを実体験ベースで整理し、同様の作業を行う際の参考になればと思い執筆しました。
技術的な詳細な解説というよりは、作業を進める中で「分かりづらかった点」「戸惑った点」を中心にまとめていますので、これからmitocoX Ver2.0を扱う方の助けになれば幸いです。
mitocoX Ver2.0を触り始めた背景
私がmitocoX Ver2.0を触り始めたきっかけは、案件において連携チームとしてアサインされたことでした。
連携業務自体が初めてであり、あわせてmitocoX Ver2.0も今回が初めての利用となります。
なお、mitocoXについてはこれまで触った経験はありません。
そのため、事前知識がほとんどない状態から作業を進めることになり、実際に作業を行う中で戸惑う場面やつまずく点がいくつかありました。
次章では、連携未経験・mitocoX未経験の立場で、実際につまずいたポイントを中心にまとめていきます。
連携業務自体が初めてであり、あわせてmitocoX Ver2.0も今回が初めての利用となります。
なお、mitocoXについてはこれまで触った経験はありません。
そのため、事前知識がほとんどない状態から作業を進めることになり、実際に作業を行う中で戸惑う場面やつまずく点がいくつかありました。
次章では、連携未経験・mitocoX未経験の立場で、実際につまずいたポイントを中心にまとめていきます。
つまずいたポイント①：デバック時の「成功」、「失敗」の見分け方
「成功」と表示されていてもデータが取得できなかった
実際に処理を実装してデバッグを行ったところ、処理が成功している場合でも失敗している場合でも、システムログ上は「正常に終了しました」と表示されることが分かりました。
では、どのように成功と失敗を見分ければよいのでしょうか。
システムが正常終了した場合と異常終了した場合では、デバッグ画面の表示内容に違いがあります。
正常終了した場合は「［フロー名］の実行を正常に終了しました」と表示されます。
一方、異常終了した場合は上記は表示されません。
では、どのように成功と失敗を見分ければよいのでしょうか。
システムが正常終了した場合と異常終了した場合では、デバッグ画面の表示内容に違いがあります。
正常終了した場合は「［フロー名］の実行を正常に終了しました」と表示されます。
一方、異常終了した場合は上記は表示されません。
正常終了の表示
異常終了の表示
どちらの場合も「正常に終了しました」と表示されるため、当初は「成功したのかな？」と勘違いしてしまっていました。
しかし、このように表示内容に違いがあるため、デバッグ時には注意が必要だと感じました。
しかし、このように表示内容に違いがあるため、デバッグ時には注意が必要だと感じました。
エラーメッセージの表示場所はどこなのか？
システムログでは、処理が正常に終了したかどうかまでしか確認できません。
処理内容の詳細については、別途詳細ログを確認する必要があります。
ホームで「ステージ」を選択し、ステージ一覧から使用しているステージを選択します。
※ステージとは、連携処理における実行環境のことです
処理内容の詳細については、別途詳細ログを確認する必要があります。
ホームで「ステージ」を選択し、ステージ一覧から使用しているステージを選択します。
※ステージとは、連携処理における実行環境のことです
次に、ステージ詳細画面から「実行履歴」を選択します。
こちらで、処理全体の詳細ログを確認することができます。
こちらで、処理全体の詳細ログを確認することができます。
システムログには詳細なログが表示されないため、どこでエラーが発生しているのか分からず戸惑いました。
しかし、別の場所で詳細ログを確認できることが分かりました。
しかし、別の場所で詳細ログを確認できることが分かりました。
つまずいたポイント②：データ登録時のずれ
「データ登録」で謎のエラーが発生
マッピング自体は問題なく設定できていることを確認できていたにもかかわらず、なぜかデータ登録の段階で原因不明のエラーが発生していました。
実装内容を見直してみても、エラーにつながりそうな箇所が見当たらず、対応に苦慮しました
実装内容を見直してみても、エラーにつながりそうな箇所が見当たらず、対応に苦慮しました
マッピングの余分な項目が原因
原因は、マッピング先に不要な項目を残したままにしていたことでした。
マッピングせずに置いているだけの項目だったため、「後で削除すれば問題ないだろう」と考えていましたが、実際にはこの不要な項目が影響し、マッピング自体は正しく行われているにもかかわらずデータの位置がずれてしまっていました。
その結果、最後の項目にデータが格納されず、エラーが発生していたようです。
マッピングせずに置いているだけの項目だったため、「後で削除すれば問題ないだろう」と考えていましたが、実際にはこの不要な項目が影響し、マッピング自体は正しく行われているにもかかわらずデータの位置がずれてしまっていました。
その結果、最後の項目にデータが格納されず、エラーが発生していたようです。
マッピング自体に問題がないように見えても、不要な項目が残っているだけでエラーが発生することがあるということが分かりました。
初心者のうちは「後で消せばいい」と思いがちですが、作業前に項目を整理しておくことがトラブル回避につながると学びました。
初心者のうちは「後で消せばいい」と思いがちですが、作業前に項目を整理しておくことがトラブル回避につながると学びました。
つまずいたポイント③：SOQLにローカル変数を含める際のルール
テンプレートリテラルを用いることで実現可能
mitocoX上のSOQLでローカル変数を使用しようとしたところ、通常の書き方ではエラーが発生してしまいました。
SOQLにローカル変数を含めたい場合は、テンプレートリテラルを用いて記載することで実現できます。
記載する際の注意点は、以下の2点です。
① SOQL全体を「バッククォーテーション」で囲む
② フロー変数を指定する際は、プレースホルダーを使用する
SOQLにローカル変数を含めたい場合は、テンプレートリテラルを用いて記載することで実現できます。
記載する際の注意点は、以下の2点です。
① SOQL全体を「バッククォーテーション」で囲む
② フロー変数を指定する際は、プレースホルダーを使用する
このように記載することで、SOQL内でローカル変数を使用することが可能になります。
エラーを確認する際の注意点
フローアイテム上にはSOQLをテスト実行できる機能がありますが、上記のようにテンプレートリテラルを用いて記載したSOQLをテスト実行すると、「SOQLクエリが未入力です。」というエラーが表示されてしまいます。
そのため、現時点ではフローのテスト実行（通常のデバッグ）を用いて動作確認を行う必要があります。
テスト実行ではエラーが表示されても、実行履歴上では正常終了しているケースもあるため、テスト実行だけで判断せず、実行履歴の詳細ログで結果を確認することが大切です。
テスト実行ではエラーが表示されても、実行履歴上では正常終了しているケースもあるため、テスト実行だけで判断せず、実行履歴の詳細ログで結果を確認することが大切です。
まとめ
本記事では、mitocoX Ver2.0を初めて触る中で、実際につまずいたポイントをいくつかご紹介しました。
SOQLでのローカル変数の扱いや、デバッグ時の成功・失敗の見分け方、マッピング時のデータのずれなど、いずれも基本的な内容ではありますが、事前に知っていれば防げたケースばかりだと感じています。
本記事が、これからmitocoX Ver2.0を触る方や、連携業務に初めて携わる方の参考になれば幸いです。
SOQLでのローカル変数の扱いや、デバッグ時の成功・失敗の見分け方、マッピング時のデータのずれなど、いずれも基本的な内容ではありますが、事前に知っていれば防げたケースばかりだと感じています。
本記事が、これからmitocoX Ver2.0を触る方や、連携業務に初めて携わる方の参考になれば幸いです。
37 件
