NETSUITE / EXTERNAL SYSTEM
Concur・Workday連携、
NetSuiteだけ見ても分からなかった。
NetSuiteとConcur、
Workdayなどの外部システムを
つなぐ処理を触りました。
最初は、
NetSuite側のコードを追えば
処理全体が分かると思っていました。
でも、
「このデータはどこから来た？」
「途中で何が変わった？」
「直接つながっているのか？」
「SFTPを経由しているのか？」
外部連携では、
一つのシステムだけを見るより、
データが通ってきた道を見る方が
分かりやすかったです。
FIRST QUESTION
このデータ、
そもそもどこから来てる？
NetSuite側の処理を見ると、 すでに値が渡されているところから 始まっていることがあります。
でも、 その値だけを見ても 元の意味や経路は分かりません。
Concurから来たデータなのか。
Workdayから来たデータなのか。
APIで直接来たのか。
SFTPへ置かれたファイルを NetSuiteが取りに行っているのか。
途中で別の処理を通って 形式が変わっているのか。
まずは、 「このデータの入口はどこか」 を確認するところから始まりました。
FLOW
システム名より、
データの流れを見る。
外部連携を追うときは、 Concur、Workday、NetSuiteという システム名だけで考えるより、 データがどう動くかで見る方が 分かりやすかったです。
大きく見ると、 やっていることは こんな流れでした。
Concur / Workday
↓
データを受け取る
↓
項目・形式を確認する
↓
必要な形へ変換する
↓
NetSuite側で検索・照合する
↓
レコードへ登録・更新する
↓
処理結果を確認するこの流れが見えると、 エラーが起きたときに どこを見るべきかも 分かりやすくなります。
入口まで来ていないなら、 NetSuiteの登録処理を 見続けても原因にはたどり着けません。
入口までは来ているなら、 次は渡された値や 変換処理を見る。
INTEGRATION DESIGN
直接つなぐだけが、
外部連携じゃなかった。
外部システムとNetSuiteを連携するとき、 最初は 「システム同士を直接つなぐ」 ようなイメージを持っていました。
でも実際には、 相手側の仕様や接続方法、 データの受け渡し方によって、 直接つなぐのが難しいこともあります。
そういう場合には、 中間にSFTPサーバーを置いて、 ファイルを受け渡す構成を取ることもありました。
Concur / Workday
↓
SFTP Server
↓
NetSuite外部システム側が ファイルをSFTPへ置く。
NetSuite側が そのファイルを取得して処理する。
逆方向なら、 NetSuiteがSFTPへファイルを置いて、 相手側が取得する。
中間にSFTPを置くことで、 システム同士を直接つながなくても データを受け渡せます。
ただ、 中継点が増えるということは、 確認する場所も増えます。
外部システムから データは出ているのか。
SFTPまで届いているのか。
NetSuiteは そのファイルを取得できているのか。
取得したあと、 正しく処理できているのか。
連携の構成が分かると、
問題が起きたときに
次にどこを見るべきかも分かる。
コードだけではなく、 システム同士を どうつないでいるのかまで 見るようになりました。
MAPPING
同じ意味のデータでも、
システムが変われば持ち方が違う。
外部システムから データが届けば終わり、 というわけではありません。
次に必要になるのが、 外部システム側の項目と NetSuite側の項目を どう対応させるかでした。
例えば、 外部システム側では社員コードを持っていても、 NetSuite側では 別のIDや内部IDを使うことがあります。
外部システム
employeeCode
departmentCode
amount
↓
検索・変換
↓
NetSuite
employee
department
amountどの項目が NetSuite側のどこに対応するのか。
値をそのまま使うのか。
一度NetSuite側を検索して、 内部IDへ変換するのか。
コードだけではなく、 項目の意味まで確認しないと 正しく連携できません。
外部連携では、 データを運ぶだけではなく、 データの意味を合わせる必要がある。
TRACE
エラーが出た場所より、
その前から追う。
外部連携でエラーが出ると、 どうしても エラーになった処理を最初に見ます。
でも、 原因がその場所にあるとは限りません。
外部から来た値が 想定と違っていた。
SFTP上のファイルが 想定した形式ではなかった。
マッピングした値が 正しくなかった。
NetSuite側の検索で 対象が見つかっていなかった。
そういう状態のまま処理が進み、 最後の登録処理で エラーとして表に出ることもあります。
だから、 エラー箇所だけを見るのではなく、 「その値はどこから来た？」 と前へ戻って確認するようにしていました。
TROUBLESHOOTING
データが通った場所を、
一つずつ確認する。
外部連携がうまくいかないときは、 実際のデータの流れに沿って 確認していきました。
- 外部システムからデータやファイルが出ているか
- SFTPを使う構成なら、SFTPまで届いているか
- ファイル名や形式は想定どおりか
- NetSuiteがファイルやデータを取得できているか
- 必要な項目が入っているか
- NetSuite側の値へ正しく変換できているか
- 検索・照合で対象が見つかっているか
- 登録・更新まで進んでいるか
RESTletなら、 まずリクエストが届いているかを見る。
SFTPなら、 ファイルが届いているかを見る。
Map/Reduceなら、 どのフェーズまで進んでいるかを見る。
入口や仕組みは違っても、 「どこまでは正常なのか」 を一つずつ確認する という考え方は同じでした。
BIGGER PICTURE
連携を追っていたら、
業務のつながりまで見えてきた。
ConcurやWorkdayとの連携を触るまでは、 NetSuiteの中の処理を見ることが 中心でした。
でも実際には、 NetSuiteの外にも 業務システムがあります。
そこからデータが入り、 必要ならSFTPを経由し、 NetSuite側の情報と照らし合わせて 次の処理へつながっていく。
そういう流れを追っていると、 システム同士だけではなく、 その後ろにある業務のつながりも 少しずつ見えるようになりました。
システム間のデータを見ると、
その裏にある業務の流れも見えてくる。
NetSuiteを触っていて 面白かったところの一つです。
SUMMARY
NetSuiteだけを見るより、
データが通ってきた道を見る。
ConcurやWorkdayとの連携では、 NetSuite側のコードだけを追っていても 処理全体は分かりませんでした。
どこから来たデータなのか。
直接来たのか。
SFTPを経由したのか。
途中でどう変換されたのか。
NetSuiteのどの情報と 照らし合わせるのか。
最後にどこへ登録されるのか。
一つのシステムだけではなく、
データが通ってきた道を見る。
外部連携を触ったことで、 コードだけではなく、 システム構成や業務のつながりまで 意識するようになりました。