勝手に連載にしていますRustで業務アプリを検討するブログ、4回目にさせていただきました。
今回はシステム間連携に着目した話です。
業務アプリでシステム間連携は必須の機能です。
営業・見積・受注・製造・在庫・出荷・納品・請求・発注・支払などといったビジネスのライフサイクルにおけるデータ管理は、全部ひとつのシステムで完結していることはなかなか珍しいです。
かといって、一度あるシステムで人が入力した情報と同じことを別のシステムで入力しなければならないのは、ミス率が高まりますし、労働時間の無駄というものです。
ここでRPAでシステム間の連携をとる場合ももちろんありますが、どのシステムでどんな業務をやってるかを把握すべき企業の情報管理者であれば、なるべくそのような管理物は少なくしたく、容易にできるならより自動でシステム間連携をやりたいところです。
基本的に人手を介さないシステム間連携の技術的方法は、旧来はCSV形式のテキストファイルをFTPプロトコルで転送するのが常套でした。
ガリガリプログラミングしても、比較的容易にできます。
しかし、EDIなど企業間システムでデータ連携するにはセキュリティが弱いこともあり、FTPをSSLで暗号化するSFTPで対応するようにしたり、CSVでは表現しきれないデータで、かつ特別にファイアウォールの解放をしたくないからhttpで通信するSOAPで対応するようになったりしました。
ただ、XMLで記述するSOAPは、最初にデータ構造を定義するスキーマの作成が複雑で面倒だったり人の認識相違が生まれたりする上、タグをたくさん書かないといけないので転送するデータ量が多く、回線が狭いインターネットではリアルタイム性が損なわれるという問題があったりして、あまり流行りませんでした。
そこで、インターネットのような盗聴やなりすましの危険のあるネットワークでも安全に転送でき、プログラム上で最初から厳密にデータ定義する必要もなく、通信量も低減する方法として、アクセストークン発行方式によるSSLを使ったREST通信が出てきました。
SSLで盗聴を防ぎ、サーバから発行される期限付きのクライアント間ユニークな文字列（アクセストークン）をクライアントから通信の都度サーバーに返すことでなりすましを防ぎ、JSONという最小限のデータ量で構造化したデータを表現できるこの方式は、今の主流といってもいいのではないでしょうか。
しかし、このREST方式は、クライアント側からすると、欲しいデータや更新したいデータの要求方法がわかりづらいというデメリットがあります。
別のドキュメントでわかりやすく説明してあげないといけません。
SOAPの初期データ定義がつらいのでなくしたけど、全くないのも困る！という感じですかね。
そこでようやく今回の本題、Facebookが公開したGraphQLはいかが？という話です。
RESTで転送するJsonによる構造化のやり方に一定のルールを加えたものです。
構造化の方法はググればたくさん出てきます。日本の説明サイトも随分増えてきました。
SOAPほど難しくないですし、各種言語でGraphQLライブラリも備わっていて、だいぶ普及してきているようです。
Rustでも例外ではなく、Juniperというライブラリが主流です。
https://github.com/graphql-rust/juniper
2017年頃から公開されています。
RustでのWEBサービス開発を容易にするライブラリ、actix-webとも相性はよいようで、サンプルも公開されています。
私もサンプルをベースに実際にコーディングしてみましたが、プログラミング上は、やはりREST通信のAPIを作る方がシンプルだとは思いました。
クライアントがAPIを利用するにあたり、わかりやすい記述で要求できるようにするひと手間というところでしょう。
コミュニケーションロスを低減させることも踏まえると、総合的には時間削減になるかもしれませんね。
ということで、業務アプリに限らずですが、Rustで今どきシステム間連携をさせる方法として、GraphQLをJuniperライブラリで実現するのはいかがでしょうか。
（酒）
moniswitch
今お使いの離床センサーがそのまま使える！
離床センサーのスイッチ入れ忘れ事故を防止するスマートスイッチ
monipet
動物病院の犬猫の見守りをサポート
病院を離れる夜間でも安心
ASSE/CORPA
センサー、IoT、ビッグデータを活用して新たな価値を創造
「できたらいいな」を「できる」に
OSGi対応 ECHONET Lite ミドルウェア
短納期HEMS開発をサポート！
WhitePlug
手のひらサイズのLinuxサーバ
株式会社ジェイエスピー
横浜に拠点を置くソフトウェア開発・システム開発・
製品開発(monipet)、それに農業も手がけるIT企業
今回はシステム間連携に着目した話です。
業務アプリでシステム間連携は必須の機能です。
営業・見積・受注・製造・在庫・出荷・納品・請求・発注・支払などといったビジネスのライフサイクルにおけるデータ管理は、全部ひとつのシステムで完結していることはなかなか珍しいです。
かといって、一度あるシステムで人が入力した情報と同じことを別のシステムで入力しなければならないのは、ミス率が高まりますし、労働時間の無駄というものです。
ここでRPAでシステム間の連携をとる場合ももちろんありますが、どのシステムでどんな業務をやってるかを把握すべき企業の情報管理者であれば、なるべくそのような管理物は少なくしたく、容易にできるならより自動でシステム間連携をやりたいところです。
基本的に人手を介さないシステム間連携の技術的方法は、旧来はCSV形式のテキストファイルをFTPプロトコルで転送するのが常套でした。
ガリガリプログラミングしても、比較的容易にできます。
しかし、EDIなど企業間システムでデータ連携するにはセキュリティが弱いこともあり、FTPをSSLで暗号化するSFTPで対応するようにしたり、CSVでは表現しきれないデータで、かつ特別にファイアウォールの解放をしたくないからhttpで通信するSOAPで対応するようになったりしました。
ただ、XMLで記述するSOAPは、最初にデータ構造を定義するスキーマの作成が複雑で面倒だったり人の認識相違が生まれたりする上、タグをたくさん書かないといけないので転送するデータ量が多く、回線が狭いインターネットではリアルタイム性が損なわれるという問題があったりして、あまり流行りませんでした。
そこで、インターネットのような盗聴やなりすましの危険のあるネットワークでも安全に転送でき、プログラム上で最初から厳密にデータ定義する必要もなく、通信量も低減する方法として、アクセストークン発行方式によるSSLを使ったREST通信が出てきました。
SSLで盗聴を防ぎ、サーバから発行される期限付きのクライアント間ユニークな文字列（アクセストークン）をクライアントから通信の都度サーバーに返すことでなりすましを防ぎ、JSONという最小限のデータ量で構造化したデータを表現できるこの方式は、今の主流といってもいいのではないでしょうか。
しかし、このREST方式は、クライアント側からすると、欲しいデータや更新したいデータの要求方法がわかりづらいというデメリットがあります。
別のドキュメントでわかりやすく説明してあげないといけません。
SOAPの初期データ定義がつらいのでなくしたけど、全くないのも困る！という感じですかね。
そこでようやく今回の本題、Facebookが公開したGraphQLはいかが？という話です。
RESTで転送するJsonによる構造化のやり方に一定のルールを加えたものです。
構造化の方法はググればたくさん出てきます。日本の説明サイトも随分増えてきました。
SOAPほど難しくないですし、各種言語でGraphQLライブラリも備わっていて、だいぶ普及してきているようです。
Rustでも例外ではなく、Juniperというライブラリが主流です。
https://github.com/graphql-rust/juniper
2017年頃から公開されています。
RustでのWEBサービス開発を容易にするライブラリ、actix-webとも相性はよいようで、サンプルも公開されています。
私もサンプルをベースに実際にコーディングしてみましたが、プログラミング上は、やはりREST通信のAPIを作る方がシンプルだとは思いました。
クライアントがAPIを利用するにあたり、わかりやすい記述で要求できるようにするひと手間というところでしょう。
コミュニケーションロスを低減させることも踏まえると、総合的には時間削減になるかもしれませんね。
ということで、業務アプリに限らずですが、Rustで今どきシステム間連携をさせる方法として、GraphQLをJuniperライブラリで実現するのはいかがでしょうか。
（酒）
moniswitch
今お使いの離床センサーがそのまま使える！
離床センサーのスイッチ入れ忘れ事故を防止するスマートスイッチ
monipet
動物病院の犬猫の見守りをサポート
病院を離れる夜間でも安心
ASSE/CORPA
センサー、IoT、ビッグデータを活用して新たな価値を創造
「できたらいいな」を「できる」に
OSGi対応 ECHONET Lite ミドルウェア
短納期HEMS開発をサポート！
WhitePlug
手のひらサイズのLinuxサーバ
株式会社ジェイエスピー
横浜に拠点を置くソフトウェア開発・システム開発・
製品開発(monipet)、それに農業も手がけるIT企業
アクセス
トータル
ランキング
