NETSUITE / DEBUG

NetSuiteのデバッグ機能、
使い方が分かるとかなり便利だった。

NetSuiteの開発を始めた頃は、 「このコード、どこで動かして確認するんだろう」 というところからでした。

でも実際には、 NetSuiteの画面からコードを動かして確認したり、 アップロードしたスクリプトを呼び出したりできます。

RESTletやMap/Reduceを触る中では、 このデバッグ機能をかなり使いました。

FIRST QUESTION

NetSuiteって、
どこでコードを動かして確認するんだろう。

Javaの開発なら、 IDEから実行したり、 ブレークポイントを置いたりする感覚があります。

でもNetSuiteでは、 最初その感覚がそのまま使えませんでした。

SuiteScriptを書いていても、 「これを今すぐちょっと動かして、 値だけ確認したい」 という場面があります。

そこで使っていたのが、 NetSuite上からコードを実行して 結果を確認できるデバッグ機能でした。

QUICK CHECK

まずは画面から、
小さく動かしてみる。

例えば、 レコードがちゃんと取得できるか確認したい。

検索結果が何件返ってくるか見たい。

スクリプトパラメータに どんな値が入っているか確認したい。

そういうときは、 大きな処理を全部動かすより、 確認したいところだけコードを書いて 実行した方が早いことがあります。

CODE Quick Check
var customer = record.load({
    type: record.Type.CUSTOMER,
    id: 123
});

log.debug({
    title: 'customerName',
    details: customer.getValue({
        fieldId: 'companyname'
    })
});

「この処理全部を確認したい」ではなく、 「今知りたいのはこの値だけ」 という形で小さく試せるのは便利でした。

DEPLOYED SCRIPT

上げたコードを、
実際に呼んで確認する。

小さなコードだけではなく、 NetSuiteへアップロードして デプロイしたスクリプトも実際に動かして確認していました。

コードだけ見て 「たぶんこう動くだろう」 で終わらせるのではなく、

実際に呼び出して、 ログが出るか。

想定した値が渡っているか。

最後まで処理が通っているか。

そこまで見て、 ようやく動きを確認できたという感覚でした。

RESTLET

RESTletは、
まず入口まで来ているかを見る。

RESTletでは、 外部からリクエストが来るところから処理が始まります。

なので、 何かうまくいかないときは、 まずRESTletまでリクエストが来ているのかを確認します。

CODE RESTlet Debug
function post(requestBody) {

    log.debug({
        title: 'requestBody',
        details: requestBody
    });

    // 処理

}

ログが出ていれば、 少なくともRESTletまでは来ている。

次に、 必要な項目が入っているかを見る。

そのあと検索やレコード更新を見る。

こうやって順番に追うと、 問題の場所をかなり絞りやすくなります。

RESTletの処理を追った話 →

MAP / REDUCE

Map/Reduceは、
どこまで進んだかを見る。

Map/Reduceでは、 処理がいくつかの段階に分かれています。

そのため、 「動かなかった」 だけでは原因が分かりません。

入力データの取得まではできたのか。

mapまで進んだのか。

reduceで止まったのか。

最後のsummarizeまで来ているのか。

CODE Map/Reduce Debug
function map(context) {

    log.debug({
        title: 'map start',
        details: context.value
    });

    // map処理

}

function reduce(context) {

    log.debug({
        title: 'reduce start',
        details: context.key
    });

    // reduce処理

}

function summarize(summary) {

    log.debug({
        title: 'summarize',
        details: 'Map/Reduce finished'
    });

}

各段階でログを出しておけば、 どこまでは処理が進んでいるのか かなり見やすくなります。

Map/Reduceを触っていたときは、 この確認をかなり使いました。

LOG

エラーだけじゃなく、
途中の値も見る。

デバッグというと、 エラーが出たところを見るイメージもあります。

でも実際には、 エラーになる前の値を見る方が 原因を見つけやすいことも多いです。

IDは取れているか。

検索結果は0件なのか、 それとも複数件なのか。

外部から来た値は 想定した形式になっているか。

そういう途中経過を log.debug() で確認していくと、 「どこからおかしくなったのか」 が分かりやすくなります。

SUMMARY

使い方が分かると、
NetSuiteのデバッグはかなり便利だった。

最初は、 NetSuite上でコードを動かして確認するやり方に 少し慣れが必要でした。

でも、 画面から小さくコードを試す。

デプロイしたスクリプトを実際に呼ぶ。

RESTletやMap/Reduceのログを追う。

そこまで使うようになると、 むしろ確認しやすい場面も多くなりました。

分からないときは、
実際に動かして、 どこまで通っているかを見る。

NetSuiteでも、 結局このやり方が 一番分かりやすかったです。