TRL:Terminal Request Library
ターミナルリクエストライブラリ

TRLとは

 TRLは、PCと端末間の情報のやり取りを簡単に実現するための通信ライブラリです。 サーバー版とクライアント版があります。 サーバーは、クライアント端末にあたるLAN上のPCからリクエスト情報を受け取り、レスポンス情報を返します。 これらの情報は文字列でやり取りされますが、そこでの受け渡しが困難な情報に関しては、ファイルを送受信することもできます。

 通常、LAN上で独自の通信を行うには、TCPソケットを用いて開発しますが、その開発には無視できない技術力と労力を要します。このTRLは、TCPソケット通信を組み込んだシステム開発の大変さを実感している私が、少しでも効率よく開発できないかと思い、ライブラリ化を考えました。

 社内やグループ内でLAN環境における通信を使ったシステム開発をご検討の方で、フリーウェアの使用に問題ない方のご利用を想定しています。

 倉庫の入出庫処理や、社員の勤怠打刻処理、作業の進捗報告処理、さまざまな用途にご利用いただけるかと考えております。

 最初の構想は以下のとおりです。
  • PCをサーバー、クライアントとして、複数クライアントからの接続に対応。
  • リクエストとレスポンスは任意の長さの文字列でやり取りしたい。
  • まとまったデータは文字列ではなく、ファイルでもやり取りしたい。
  • TCPソケット周りはラッピングして、単純化・簡略化したい。
  • サーバー側は、VB.NETから使えるライブラリにしたい。
 しばらく構想を練るうち、以下のような妄想をいだきました。
  • クライアントは、MicrosoftのExcelやAccessでも使いたい人がいるはず。VBA対応したらいい。
  • いや、どうせならサーバー側もVBA対応してしまえばいい。
  • これからは64ビットの時代?・・・32ビット/64ビットを問わずに使えたらいい。
こんなものできるのだろうか・・・
と、最初は思いましたが、構想から3ヶ月・・・なんとか動くところまではもっていけたので、公開したいと思います。



 TRLの使い方は単純です。クライアント側(TrlClientLib)は、リクエストしてレスポンスを受け取るだけで、そのほかは何もしません。クライアントからリクエストされた内容にしたがってすべての操作をサーバー側(TrlServerLib)で行います。
いくつか例をご紹介します。


使い方の例-その1:情報を文字列でやり取りする


例としてバーコードを使った棚卸作業をシステム化する場合を考えてみます。棚卸は通常、棚卸数(在庫数)をカウントするだけですが、今回は作業時に商品名と理論在庫数(帳簿在庫数)を確認できるようにしたいと思います。
必要な通信は以下の通りです。

(A)クライアントで読み取られたバーコードの値をサーバーへ送信して、商品名と理論在庫数を取得するための通信。

(B)クライアントで入力された棚卸数をサーバーへ送信して、その商品の棚卸数を登録するための通信。

ここでは、通信が二つありますので、どちらのリクエストなのかクライアントはサーバーに伝えなければなりません。それぞれ行頭のアルファベットの"A"と"B"で要求を区別したいと思います。

それでは、まず(A)の通信について、流れを記載します。

TrlServerLib 通信方向 TrlCilentLib
- - (1)バーコードの読み取り
(3)受け取ったリクエスト文字列をカンマ区切りで分割して解析。
リクエストが(A)であることを確認。バーコード値を取得。
(2)リクエストが(A)であることと、読み取られたバーコード値を送信。
リクエスト文字列:"A,4900000000001"
"4900000000001"はバーコードの値です。
(4)データベースなどで、商品情報を検索。
- -
(5)商品が見つかったら、検索結果を送信。
レスポンス文字列:"OK,えんぴつ,1200"
"OK"は検索が成功したことを表し、"えんぴつ"が商品名、"1200"が理論在庫数です。

商品が見つからなかった場合には、次のようなレスポンスを返します。
レスポンス文字列:"NG,商品が見つかりませんでした。"
"NG"は検索が失敗したことを表し、"商品が見つかりませんでした。"は処理結果です。
(6)受け取ったレスポンス文字列をカンマ区切りで分割して解析。
結果が"OK"か"NG"かを判断し、処理を継続する。

ここではリクエスト・レスポンス文字列をカンマ区切りの文字列としていますが、カンマ区切りにこだわる必要はありません。Tab区切りでも良いですし、各項目を固定長にしてもかまいません。項目の内容や順番も自由です。つまり、リクエスト内容とレスポンス内容がクライアントとサーバー間で伝わりさえすれば、これらの文字列フォーマットは開発者が自由に設計していただけます。
同じことの繰り返しとなりますが、一応、(B)の通信についても流れを記載しておきます。

TrlServerLib 通信方向 TrlCilentLib
- - (7)棚卸数の入力
(9)受け取ったリクエスト文字列をカンマ区切りで分割して解析。
リクエストが(B)であることを確認。バーコード値と棚卸数を取得。
(8)リクエストが(B)であることと、読み取られたバーコード値と棚卸数を送信。
リクエスト文字列:"B,4900000000001,1190"
"1190"が棚卸数です。
(10)データベースなどへ、棚卸数を登録。
- -
(11)登録結果を送信。
レスポンス文字列:"OK"

登録に失敗した場合には、次のようなレスポンスを返します。
レスポンス文字列:"NG,データベースがオープンできません。"
"NG"は検索が失敗したことを表し、"データベースがオープンできません。"は処理結果です。
(12)受け取ったエスポンス文字列をカンマ区切りで分割して解析。
結果が"OK"か"NG"かを判断し、処理を継続する。





使い方の例-その2:情報を文字列とファイルでやり取りする


TRLは文字列のやり取りに加え、サーバー側の制御によりファイルをクライアントから受信したり、ファイルをクライアントへ送信したりすることができます。
例としてピッキング作業をシステム化する場合を考えてみます。ピッキング作業は通常、出荷伝票番号に紐付いた商品一覧を元に、商品の種類と個数を照合していく作業になります。
必要な通信は以下のような感じになると思います。

(A)サーバーから出荷伝票番号一覧を取得するための通信。

(B)クライアントで選択された出荷伝票番号をサーバーへ送信して、商品一覧を取得するための通信。

(C)クライアントでのピッキング結果をサーバーへ送信して、ピッキング結果を登録するための通信。

ここでは、通信が三つありますので、どの要求なのかクライアントはサーバーに伝えなければなりません。その1の場合と同様に行頭のアルファベットでリクエストを区別したいと思います。

それでは、まず(A)の通信について、流れを記載します。

TrlServerLib 通信方向 TrlCilentLib
(2)受け取ったリクエスト文字列をカンマ区切りで分割して解析。
リクエストが(A)であることを確認。
(1)リクエストが(A)であることを送信。
リクエスト文字列:"A"
(3)データベースなどから、出荷伝票番号一覧ファイルを作成。
- -
(4)出荷伝票番号一覧ファイルが作成されていれば、ファイル送信。 作成されていなければ、この処理はスキップ。 -
(5)ファイル作成結果を送信。
レスポンス文字列:"OK"

ファイル作成に失敗した場合には、次のようなレスポンスを返します。
レスポンス文字列:"NG,出荷伝票は0件です。"
"NG"は作成が失敗したことを表し、"出荷伝票は0件です。"は処理結果です。
(6)受け取ったレスポンス文字列をカンマ区切りで分割して解析。
結果が"OK"か"NG"かを判断し、処理を継続する。

リクエスト・レスポンス文字列は、その1の場合と同じです。必要に応じてサーバー側はクライアント側にファイルを送信します。 ファイルを受信するのにクライアント側では何もしません。ただレスポンス文字列によってファイルが送られてきたのかどうか判断するだけです。ファイルはテキストファイルでもバイナリファイルでも送信できますので、ファイルフォーマットは開発者が自由に設計していただけます。受け渡すファイルのファイル名は事前に取り決めておくか、最後のレスポンス文字列でサーバーからクライアントへ報告することになります。
同じことの繰り返しとなりますが、一応、(B)の通信についても流れを記載しておきます。


TrlServerLib 通信方向 TrlCilentLib
- - (7)ピッキング作業を行う出荷伝票番号を選択。
(9)受け取ったリクエスト文字列をカンマ区切りで分割して解析。
リクエストが(B)であることを確認。出荷伝票番号を取得。
(8)リクエストが(B)であることを送信。
リクエスト文字列:"B,1000000001"
"1000000001"は出荷伝票番号です。
(10)データベースなどから、商品一覧ファイルを作成。
- -
(11)商品一覧ファイルが作成されていれば、ファイル送信。 作成されていなければ、この処理はスキップ。 -
(12)ファイル作成結果を送信。
レスポンス文字列:"OK"

ファイル作成に失敗した場合には、次のようなレスポンスを返します。
レスポンス文字列:"NG,この伝票はピッキング完了済みです。"
"NG"は作成が失敗したことを表し、"この伝票はピッキング完了済みです。"は処理結果です。
(13)受け取ったレスポンス文字列をカンマ区切りで分割して解析。
結果が"OK"か"NG"かを判断し、処理を継続する。

最後にピッキング結果をサーバーへ伝えるための、(C)の通信についても流れを記載します。

TrlServerLib 通信方向 TrlCilentLib
- - (14)ピッキング作業を行い、ピッキング結果ファイルを作成。
(16)受け取ったリクエスト文字列をカンマ区切りで分割して解析。
リクエストが(C)であることを確認。出荷伝票番号を取得。
(15)リクエストが(C)であることを送信。
リクエスト文字列:"C,1000000001"
"1000000001"は出荷伝票番号です。
(17)ピッキング結果ファイルを、ファイル受信。 -
(18)データベースなどへピッキング結果を登録。
- -
(19)登録結果を送信。
レスポンス文字列:"OK"

登録に失敗した場合には、次のようなレスポンスを返します。
レスポンス文字列:"NG,この伝票はピッキング完了済みです。"
"NG"は作成が失敗したことを表し、"この伝票はピッキング完了済みです。"は処理結果です。
(20)受け取ったレスポンス文字列をカンマ区切りで分割して解析。
結果が"OK"か"NG"かを判断し、処理を継続する。




使い方まとめ

 TRLは、上記で説明したように、基本的には「リクエスト文字列」と「レスポンス文字列」という情報のやり取りがあり、その間に必要に応じて「ファイル送信」と「ファイル受信」が行えるような仕組みになっています。
1回の「リクエスト文字列」と「レスポンス文字列」のやり取りの間に「ファイル送信」と「ファイル受信」はどのような順番でも、また、何回でも行えますので、さまざまな処理に対応することができると思います。







累積:
今日:
昨日:
Copyright (C) 2016 森山商店 All Rights Reserved.