「JSON」の記事 - Crieit

ConMas Gateway スクリプトのデバッグ (2)

2022-08-11T09:30:57+09:00

ConMas Gateway スクリプトのテスト、デバッグをどうする、というテーマの続編です。

結論は「スクリプト単体でテストをしましょう」です。
端末（i-Reporter）や ConMas Gateway を使うと何かと不便なので、テスト、デバッグの9割をスクリプト単体でテストをし、最後に端末と ConMas Gateway を使ったテストをしましょう、ということです。

このような、スクリプトを例として解説を進めます。

準備

テストに必要となるデータの雛形を取得します。

Gateway が稼働するサーバ上のディレクトリ action 下のファイルを以下のようにしておきます。

Gateway は端末からのリクエストを受けると最初にこのファイルを探し出し参照します。次に Gateway は、"script"に記述されたスクリプトを起動します。

ConMas/gateway/action/hogehoge.json

{
 "datasource": "script",
 "script": "scripts/requestlog.py"
}

"script"に記述するスクリプトは以下のようなスクリプトにしておきます。

ConMas/gateway/scripts/requestlog.py

import sys
import json
import traceback

jsonData = json.loads(sys.stdin.readline())
# querydata = jsonData['query']
# postdata = jsonData['post']['clusters']

f = open('./logs/request.log', 'w')
dp = json.dumps(jsonData)
f.write(dp + '\n')
f.close()

mappings_data = []
mappings = dict(error="", mappings=mappings_data)
print(json.dumps(mappings))

この状態で、端末からGateway連携を起動させます。当然ですが、このスクリプトが実行されます。
このスクリプトは、端末からのリクエストをファイルに書き込む以外に何の仕事もしません。端末は期待するデータを受け取ることができませんが、準備作業としては問題はありません。

前述のスクリプトが出力したファイルは、サーバ上のディレクトリ ConMas/gateway/logs にあります。
テスト対象となる（前述の、リクエストをファイルに書く以外に何もしないスクリプトを偽物とした場合の）本物のスクリプトの入力には、端末からのリクエストの代わりに、このファイルを使用します。
これでスクリプト単体でのテストが可能となります。ここからのテストには、Gateway も端末も不要です。つまり、スクリプト・エンジンがPythonであれば、Pythonスクリプトの通常のテストとまったく同様のテストが可能です。当然ですが、便利なテスト・ツールを使うことが出来ます。

trace-Python文の実行をトレースまたは追跡する。
Pythonのデバッグを完全理解
 Pythonプログラムを追跡する
 pythonの例外でstack traceを表示する

忘れないうちにディレクトリ action 下のファイルを書き変えて本物にしておきましょう。
ConMas/gateway/action/hogehoge.json

{
 "datasource": "script",
 "script": "scripts/hogehoge.py"
}

テスト用に取得した入力ファイルにはJSONが書かれています。ただし、見にくいのでツール等を使ってキレイにしてから使用することをおすすめします。

JSONきれい～JSON整形ツール～

例えば、こうやってスクリプトを実行させます。

c:\ConMas\gateway\scripts>type ..\logs\request.log | python hogehoge.py

参考までに、本物のスクリプトの姿はこんな感じです。
ConMas/gateway/script/hogehoge.py

import sys
import json
import traceback

try:
    #-----------------------------------------------------
    #   帳票から送信されたデータ
    #-----------------------------------------------------
    jsonData = json.loads(sys.stdin.readline())

    mappings_data = []

    #-----------------------------------------------------
    #   帳票にレスポンスするデータを作成する処理がこの辺に書かれているはず
    #-----------------------------------------------------

    mappings = dict(error="", mappings=mappings_data)
    print(json.dumps(mappings))

except Exception as e:
    logging.debug(traceback.format_exc())
    mappings = {"error": "Error: " + str(e)}
    print(json.dumps(mappings))

テストにおいて入力データを変更したければ、入力ファイルの内容を書き換えれば良いのです。

ここで紹介したテストでは、端末（帳票）とのコンビネーションをテストすることは出来ませんが、それは後ですれば良い、という考え方に基づいています。それじゃダメ、という考えの場合は始めからコンビネーションでテストしてください。

ConMas Gateway スクリプトのデバッグ (1)

2022-08-06T19:02:04+09:00

製造現場の紙帳票のデジタル化を担うi-Reporter。現段階ではまだベストなソリューションとは言えませんが、今後の機能アップが期待出来るとすればそのポテンシャルは大きく、紙帳票のデジタル化に留まらず、旧態依然な現場のパネルまでも、i-ReporterをのせたWindowsのタッチパネルに入れ替わるかもしれません。日本の製造業をチャンピオンに返り咲かせるDXの誘因として重要なソリューションのひとつであることに間違いはありません。。
このi-Reporterシステムに必須といってもよいのが"ConMas Gateway"です。まだ機能面での不足がある ConMas Gateway ですが、i-Reporter の jQuery.ajax とも言える ConMas Gateway を使わずして i-Reporter の存在意義は語れません。

この記事では、ConMas Gateway スクリプトの効率的なデバッグ手法について複数回に分けて解説します。

この記事の内容は、IT系開発に不慣れなFA系システム開発者向けです。WEBシステムのサーバ・サイド開発等に長けたITエンジニアにとっては、当たり前のことが書かれています。

この記事の内容を理解するために、i-Reporterに関する細かな知識を事前に得ている必要はありません。ただし、この知識がない方は、ある程度の想像力を働かせながら読み進める必要があります。

システム・モデル

ConMas Gateway から起動されたスクリプトは、i-Reporter からPOST（あるいはGET）されたデータを、標準入力を介して ConMas Gateway から受け取ります。
スクリプトは i-Reporter へのレスポンスを標準出力を介して ConMas Gateway へ渡し、ConMas Gateway はこれを i-Reporter にレスポンスします。

つまり、ConMas Gateway のスクリプトは、WEBシステムにおける CGIを使うスクリプトと何ら変わりがありません。

面白いのは、ConMas Gateway と ConMas Server の間にインタフェースが全く存在せず、両者は何のやりとりもしないことです。
もちろん、ConMas Server のデータベースは公開されているため、ConMas Gateway が直接あるいはスクリプトを介して、このデータベースをアクセスすることは可能です。

なお、ConMas Gateway はスクリプトがなくても、自らの機能でデータベースをアクセスし結果を i-Reporter にレスポンスすることが出来ます。ただし、このデータベースのアクセスはシンプルなものに限定され、複雑な処理、あるいはデータベース・アクセス以外の処理を行うにはスクリプトが必要となります。
この記事では、このスクリプトのデバッグについて述べており、ConMas Gateway 自身が持つデータベース・アクセスについては述べていません。

データ

i-Reporter とスクリプトの間でやりとりされるデータはJSONです。これは、データを処理する手続きをシンプルに記述できるという点で歓迎できます。

POSTされるデータは、クラスタ（i-Reporterで処理される帳票上のデータの最小単位）の属性と（当該クラスタに入力された）データが key: value のタプルとなったJSONです。複数のタプルが配列で並びます。どのクラスタをPOSTするかは、事前に ConMas Designer 上で選択します。
GETされるデータは任意です。ConMas Designer による設定でURLに続くデータを任意に記載することが出来ます。
レスポンスは、帳票上のクラスタのIDと当該クラスタに表示されるデータをタプルにしたJSONです。もちろん、このタプルは配列で複数にすることができます。

この記事では、データのフォーマットに関する細かな解説をしません。データのフォーマットに関する細かなルールや、ConMas Designer での設定については、シムトップス社から提供されるマニュアルを参照してください。これらの情報がなくても、この記事を読み進める上での支障にはなりません。
マニュアルにアクセスするには、シムトップス社のサイトにアクセスするためのIDが必要になります。

標準と思われるデバッグ手法

標準と思われるデバッグの手法は、i-Reporterで（必要であれば帳票にデータを入力し）帳票上のアクション・クラスタを発動させ、当該クラスタに設定されたスクリプトを動作させながらテストと不具合の解消を進めるという（何の工夫もない）いたって普通の方法です。
小さく単純でテストが簡単なスクリプトのデバッグでは、この方法でも良いかもしれません。ただし、大きく複雑で、複雑、高度なテストとデバッグを要するスクリプトの場合には問題が生じます。

問題

この方法ではスクリプトの動作を簡単にはトレースすることができない
この方法でのスクリプトのトレースは、デバッグのための古典的なプリント、あるいはカバレージをファイル等に出力するなどが必要となる。一方で、Python で提供される Pdb や Trace 等のコマンドラインで容易に使えるツールが使用できない。

次回

続きは次回とさせていただきます。
初心者の方々のために、ゆっくりとマッタリと進めさせていただきます。
次回は「ではどうすれば良いか」です。

ConMas Gateway スクリプトのデバッグ (2)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

2022-07-23T23:14:58+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
前回は、PLCから取得したデータをデータベースに保存しました。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)

タイトルに書かれたテーマは前回で完了しています。完了していますが、これでは何か物足りないと感じ、今回はデータベースに次々と書かれるPLCからのデータをブラウザに表示してみます。

WEBアプリケーション

データベースのデータをWEBブラウザに表示するために、WEBアプリケーションをサーバ上に作成します。このサンプルでは、WEBアプリケーションはPHPスクリプトで実装します。

いよいよ図が窮屈になってきました。これ以上に窮屈な図は、もはや理解容易性の面で逆効果です。正確さと理解容易性は、ある時点以後、反比例します。

PHPである必要はありません。では、このサンプルを何故にPHPスクリプトで実装するのか？それは、そこ（私の開発環境）にPHPが稼働していたから。

PHPの準備についてはここでは解説しません。PHPの準備についての解説は、他の記事にお任せします。PHPスクリプトでのMySQLアクセスについても、他の記事にお任せします。

HTMLとPHPスクリプト、そしてJavaScript

結果的には、サーバ・サイドはPHPスクリプトのみではなく、以下の3つのファイルで構成してみました。

HTML
PHPスクリプト
JavaScript

3つめの JavaScript は jQuery です。jQuery は一般に配布されているとても便利なライブラリです。jQuery を利用することにより、とても高機能なWEBアプリケーションを短期間で実装することができます。jQuery の解説も他の記事にお任せします。

以下がサンプルです。

index.htm



  
  
  Sample
  
  


  count: count

index.php

getMessage() . "\n";
    exit();
  }

  $sql = "SELECT JSON_EXTRACT(body, '$.value') AS count FROM from_plc ORDER BY time_insert DESC";
  $res= $dbh->query($sql);
  foreach($res as $value) {
    echo $value['count'];
    break;
  }
?>

jQuery は、HTML中で参照されている、jquery-3.6.0.min.js です。
HTML中には、jQueryを呼び出すオリジナルのJavaScriptスクリプトを書いています。
いずれもコードの解説はいたしません。

WEBブラウザでアクセスしてみる

WEBブラウザで上記の index.htm を参照すると以下ようになります。

数字は、データベース上のテーブルが更新される都度変化してます。（正確には、JSONの要素"value"の値が変化してから1秒以内に、ブラウザの表示も変化します）

最後に

ここまでサンプルとして実装したシステムを応用すると、工場の機器により製造される製品の生産数を、ほぼリアルタイムに画面表示する、といったシステムを構築することができます。
勘違いしていただきたくないのは、この記事で示したサンプルはあくまでもサンプルであって、基盤となるミドルウェアやプロトコル、プログラム言語は、この記事のサンプルで使用したものである必要はありません。もし、この記事で取り上げたような、PLCからデータを取得し、これを処理するようなシステムを設計・構築する場合は、この記事の内容にとらわれず、それぞれの環境、条件、実現したい機能などに応じて、最適なハードウェア、ミドルウェア、プロトコル、プログラム言語、そしてアーキテクチャを想像し選択してください。

実はこのアーキテクチャを想像する、というのが設計者にとって最も楽しく重要な工程なのです。実装のテクニックなどは、アーキテクチャの上に成立する技術であって、アーキテクチャがイマイチなシステムは、おそらく実装もへんてこりんになってしまったり、どこかアンバランスなものになってしまうものです。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)

2022-07-22T18:43:07+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
前回は、データを保存するデータベースとテーブルを準備しました。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)

今回は、MQTTブローカーからデータを受信するサブスクライバーを実装します。少々駆け足になりますが、サブスクライバーには、データを受信しつつデータベースに書き込むまでを実装します。

プログラミング

Pythonを使用して実装します。Pythonでなければならない合理的な理由はありませんが、私の環境では、Pythonではだめだという理由もありません。

PythonでMQTTをハンドリングには、paho-mqttというライブラリを使うと、新規コーディング量を減らすことができます。paho-mqttの導入については、このサイトをおすすめします。
Python で MQTT (Paho)

同様に、PythonからMySQLをアクセスするには、mysql-connector-python-rfというライブラリを使うと、新規コーディング量を減らすことができます。mysql-connector-python-rfの導入については、このサイトをおすすめします。
Python 3 から MySQL を触る

最低限の機能を実装してみました。

import paho.mqtt.client as mqtt
import json
import mysql.connector

#-----------------------------
#    mqtt
host = '127.0.0.1'
port = 1883
topic = 'sample'

def on_connect(client, userdata, flags, respons_code):
    print('status {0}'.format(respons_code))
    client.subscribe(topic)

def on_message(client, userdata, msg):
    json_text = json.dumps(json.loads(msg.payload))
    print(json_text)
    try:
        #-----------------------------
        #    database
        conn = mysql.connector.connect(
            host='127.0.0.1',
            port=3306,
            user='hoge',
            password='hoge001',
            database='hoge'
        )
        cur = conn.cursor()
        sql = "insert into from_plc (body) values (%s);"
        cur.execute(sql, (json_text,))
        conn.commit()
        cur.close()
        conn.close()
    except Exception as e:
        print(e)
        print("Debug: Error at Database access.")
        return

if __name__ == '__main__':
    client = mqtt.Client(protocol=mqtt.MQTTv311)
    client.on_connect = on_connect
    client.on_message = on_message
    client.connect(host, port=port, keepalive=60)
    client.loop_forever()

サンプル・プログラムは、MQTTブローカー（=mosquitto）に届く、Topic = sample のメッセージを待ち受けます。メッセージが届くと、メッセージ中のデータをJSON文字列に変換し、これをMySQLのテーブル"from_plc"に追加します。この動作をひたすら繰り返します。

テスト

Pythonスクリプトを起動しておきます。

c:\Users\hoge>py sample.py
status 0

これまでと同様に、PLCには、本物の代わりにModbus/TCPシミュレーターを使用します。
Modbus/TCPシミュレーター"mod_RSsim.exe"を起動します。

ゲートウェイのシミュレーターを起動するために、EasyBuilderのメニュー[プロジェクト]-[オンラインシミュレーション]をクリックします。

シミュレーターの起動を確認します。

Modbus/TCPシミュレータの、アドレス40001（注意: +0です）をクリックし、Valueに任意の数値を入力し値を変更します。[OK]ボタンで閉じます。

Modbus/TCPシミュレータの、アドレス40001の値を変更する都度、Pythonスクリプトがこの情報をJSONで受け取り、コンソールに表示します。
Pythonスクリプトを止めるには、キーボードからCtrl+Cを押してください。

c:\Users\hoge>py sample.py
status 0
{"value": 0, "ts": "2022-07-21T15:27:43.676079"}
{"value": 1, "ts": "2022-07-21T15:27:49.704662"}
{"value": 2, "ts": "2022-07-21T15:27:57.641088"}
{"value": 3, "ts": "2022-07-21T15:28:07.644020"}
{"value": 4, "ts": "2022-07-21T15:28:11.627588"}
{"value": 5, "ts": "2022-07-21T15:28:14.659965"}
Traceback (most recent call last):
  File "c:\Users\hoge\sample.py", line 44, in 
    client.loop_forever()
  File "C:\Users\hoge\AppData\Local\Programs\Python\Python310\lib\site-packages\paho\mqtt\client.py", line 1756, in loop_forever
    rc = self._loop(timeout)
  File "C:\Users\hoge\AppData\Local\Programs\Python\Python310\lib\site-packages\paho\mqtt\client.py", line 1150, in _loop
    socklist = select.select(rlist, wlist, [], timeout)
KeyboardInterrupt
^C
c:\Users\hoge>py sample.py

MySQLのテーブル"from_plc"を確認すると、ゲートウェイからのJSONデータが保存されているのはわかります。

c:\Users\hoge>mysql -u hoge -p
Enter password: *******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 8.0.29 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use hoge
Database changed
mysql> select * from from_plc;
+--------------------------------------------------+---------------------+
| body                                             | time_insert         |
+--------------------------------------------------+---------------------+
| {"ts": "2022-07-21T15:27:43.676079", "value": 0} | 2022-07-21 23:27:43 |
| {"ts": "2022-07-21T15:27:49.704662", "value": 1} | 2022-07-21 23:27:49 |
| {"ts": "2022-07-21T15:27:57.641088", "value": 2} | 2022-07-21 23:27:57 |
| {"ts": "2022-07-21T15:28:07.644020", "value": 3} | 2022-07-21 23:28:07 |
| {"ts": "2022-07-21T15:28:11.627588", "value": 4} | 2022-07-21 23:28:11 |
| {"ts": "2022-07-21T15:28:14.659965", "value": 5} | 2022-07-21 23:28:14 |
+--------------------------------------------------+---------------------+
6 rows in set (0.00 sec)

mysql>

次回

PLCのデータをデータベースにJSONで書きました。もう次回は不要かもしれませんが、せっかくデータベースに書いたので、次回はこれをブラウザに表示させます。くどいなあ。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)

2022-07-21T09:17:30+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
初回から前回にかけては、ゲートウェイを使って、PLCから取得したデータをMQTTでブローカーに送信するまでを実装しました。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)

今回はデータベースを準備します。

データベース

このサンプルではMySQLを使用します。MySQLでなければいけない理由はまったくありません。MySQLを選択した理由は、そこ（私の開発環境、作業場ですね）で動いていたからです。
テーマを「JSONで保存」とした以上は、JSON型をサポートしているDBMSである必要はあるのですが、MySQL以外にもJSON型をサポートしているDBMSはあります。

ユーザとデータベースは事前に作成されていたものを使います。これらの作成については解説はいたしません。

MySQLにおける、データベースとユーザの作成については、こちらを参照ください。
データベースの作成
 ユーザーの作成

テーブルを作成する

任意のユーザとデータベースでテーブルを作成します。

hoge@localhost C:\Users\hoge>mysql -u hoge -p
Enter password: *******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 8.0.29 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use hoge
Database changed
mysql>

データを保存するためのテーブルをひとつだけ作成します。

mysql> create table from_plc (
    -> body json,
    -> time_insert timestamp default current_timestamp
    -> );
Query OK, 0 rows affected (0.17 sec)

mysql> show full columns from from_plc;
+-------------+-----------+-----------+------+-----+-------------------+-------------------+---------------------------------+---------+
| Field       | Type      | Collation | Null | Key | Default           | Extra             | Privileges                      | Comment |
+-------------+-----------+-----------+------+-----+-------------------+-------------------+---------------------------------+---------+
| body        | json      | NULL      | YES  |     | NULL              |                   | select,insert,update,references |         |
| time_insert | timestamp | NULL      | YES  |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED | select,insert,update,references |         |
+-------------+-----------+-----------+------+-----+-------------------+-------------------+---------------------------------+---------+
2 rows in set (0.07 sec)

mysql>

次回

続きは次回とさせていただきます。
MySQLのセットアップを行われた方がいるとすれば、その方にとっては、この記事の中で最も時間を要した回であったはずです。そういった方に配慮し、今回は短めとし続きは次回とさせていただきます。
私の記事は先を急ぎませんので。
次回は、いよいよデータをデータベースに書き込みます。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)

2022-07-20T08:40:18+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
前回は、ゲートウェイを用いてPLCからデータを取得し、ゲートウェイのメモリに保存しました。
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)

今回はこのデータをサーバに送信します。

サンプルで使用するゲートウェイは、引き続きWEINTEK製ゲートウェイの開発環境であるEasyBuilderのシミュレーターです。WEINTEK製ゲートウェイはサーバへのデータ送信に2種類のインタフェースを持っており、そのひとつがMQTTです。サンプルではMQTTを使用してサーバにデータを送信します。

IT技術より生産現場の技術に強い方は、"MQTT"とか登場した時点で「もういやだな」となるかもしれません。そういった方はロガーの類が欲しくなりますよね。わかります。この記事ではロガーの類はまったく登場しません。この先を読み進めるかどうか、ご自由にご判断ください。

サーバ側にはMQTTのブローカーが必要となります。サンプルでは、MQTTブローカーとしてMosquittoを使用します。

Mosquittoはテストの場面で必要となります。サンプルの実装に加えて、テストをしてみたいという方は、自己責任でMosquitto、あるいは他のMQTTブローカーを準備してください。Mosquittoの準備については以下を参照してください。
【MQTT】MQTTの導入 mosquittoのインストール/動作確認まで

ゲートウェイのMQTT送信設定

データをサーバに送信するために、前回まで作成したプロジェクトに設定を加えます。

EasyBuilderのメニュー[IIoT/エネルギー]-[MQTT]をクリックすます。

[有効にする]をクリックします。

[一般的な属性]はデフォルトのままです。サンプルでは、ゲートウェイのシミュレーターと同じWindowsでMosquittoを動作させるので、IPアドレスは127.0.0.1のままです。[OK]ボタンをクリックします。

[トピック発行者]タブで[新規作成]ボタンをクリックします。

[一般的な属性]タブで以下のように設定します。
中ほどの設定、[アドレス]のLBと0は、LB0がONになったらMQTTでサーバにデータを送信する、という意図です。

[アドレス]タブに移り、[新規作成]ボタンをクリックします。

ダイアログに以下のように設定し、[OK]ボタンをクリックします。
[アドレス]の設定LWと0は、LW0にあるデータを送信する、という意図です。LW0には、PLCから取得したデータが置かれています。

[MQTTトピック発行者オブジェクト属性]ウィンドウの[OK]ボタンをクリックします。

[MQTT]ウィンドウの[終了]ボタンをクリックします。

以上で、ゲートウェイのMQTT設定は完了です。

ゲートウェイのプログラミング

前回作成したゲートウェイのプログラムに、若干のステップを追加します。

EasyBuilderのメニュー[プロジェクト]-[マクロ]をクリックします。

[ID : 001]をダブル・クリックします。

以下のように、ステップを追加します。

6〜10行目では、今回取得したデータと前回取得したデータを比較して、同じデータであったら何もしない、と書いています。業務上、連続する同じデータは不要という場合に、サーバに無駄なデータを送信しません。
13〜14行目は、MQTT送信をキックするために、ゲートウェイのLB0をオンにします。LB0はMQTT送信後に自動でオフになります（そのようにMQTTを設定しました）。

コピーしたい方はこちらからどうぞ。

macro_command main()
        unsigned short        x40001 = 0
        GetData(x40001, "MODBUS TCP/IP (32-Bit)", 4x, 1, 1)
        
        unsigned short        LW0 = 0
        GetData(LW0, "Local HMI", LW, 0, 1)
        if x40001 == LW0 then
                return
        end if

        SetData(x40001, "Local HMI", LW, 0, 1)
        bool        LB0 = 1        
        SetData(LB0, "Local HMI", LB, 0, 1)

end macro_command

エディタの[閉じる]ボタンをクリックします。

[コンパイルが成功]に[ID : 000]があることを確認します。

連続する同じデータは不要

連続する同じデータは不要という仕様は、よくある仕様です。例えば、工場の生産マシンで生産される製品の数をPLCで数えている場合、そのカウンタがこれに該当します。変化のないカウント値は不要なはずです。この不要なデータをネットワークやサーバに垂れ流すと、ネットワークやサーバにとって無駄な負荷となります。データベースのサイズも無駄に膨れ上がります。「IoTのデータは無駄なデータばかりだけど、そういうものだ」という誤った悟りを持った設計者を多く見かけますが、実は、設計次第でエレガントなシステムになります。想像が足りないだけなのです。
時系列データベースが提供する重複排除機能などは、あったほうが便利、という程度です。排除する前に発生させなければ良いのです。ただし、ロガーなどを使って無秩序に記録したデータをデータベースにロードする、というような場合は、不要なデータの排除に苦労します。
連続する同じデータをサーバ側で捨てるテクニックもあります。これについては機会があれば、別途解説をさせていただきます。

テスト

テストには、MQTTブローカーと、一時的にテストで使用するMQTTの汎用サブスクライバーが必要となります。
これらは、Mosquittoが提供してくれます。Mosquittoの準備については以下を参照してください。
【MQTT】MQTTの導入 mosquittoのインストール/動作確認まで

私の開発・テスト環境では、MosquittoブローカーはWindowsの設定で自動起動にしてあり、常に実行中です。

注意: 他のサーバ上のMosquittoへ送信する場合には注意が必要です。Mosquittoは、標準の設定では外部からのメッセージを受け付けません。この場合は、外部からのメッセージを受け付けるよう、Mosquittoの設定を変更する必要があります。

受信側となるMQTTサブスクライバーを起動しておきます。
Mosquittoにはコマンド起動可能な簡単なサブスクライバーが付属しています。Windowsでは、このコマンドはMosquittoのインストール・フォルダにあります。
以下のように起動しておきます。

c:\Program Files\mosquitto>mosquitto_sub -h localhost -t sample

オプション -h localhost は、localhost上のブローカーから受信することを示しています。-t sample はトピック名を示しており、ゲートウェイのMQTT設定で設定したトピック名と同じである必要があります。mosquitto_sub はトピックsampleのメッセージをひたすら待ち続けます。

前回のテストと同様に、Modbus/TCPシミュレーター"mod_RSsim.exe"を起動します。

注意: "mod_RSsim.exe"は連続起動に時間制限がある点に注意してください。制限を超えた場合は再起動させます。

EasyBuilderのメニュー[プロジェクト]-[オンラインシミュレーション]をクリックします。

シミュレーターが起動したことを確認します。

前回のテストと同様に、Mdobus/TCPシミュレーターのアドレス40001のデータを任意の数値に書き換えます。

Mosquittoのサブスクライバーが、受信したデータをコンソールに出力します。

ゲートウェイのプログラムで、データに変化があった場合にのみ送信、としているため同じデータが次々と送られてくることはありません。ゲートウェイを単なるプロトコル変換器だと考えているなら、それは誤りです。

ゲートウェイのMQTT設定にて、タイムスタンプを付与するよう設定したため、tsという名前でゲートウェイの時刻が送られてきます。

このゲートウェイの時刻はサーバの時刻と必ずしも一致しない、という点を設計上留意してください。時刻の取扱いについては別途、解説をさせていただきます。

以上でテストは終了です。

次回

続きは次回とさせていただきます。
次回は、データベースを準備します。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)

2022-07-19T16:02:44+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。
今回はその2回目、ゲートウェイによるPLCからのデータ取得です。

サンプルの環境については第一回で解説しています。必ず第一回を参照し、前提となる環境を理解した上で以下の解説を参照してください。
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)

想定: PLC上のデータ

サンプルでは、取得するPLC上のデータを以下のように想定しています。

Modbus/TCP

Modbus/TCPについては、このドキュメントが理解しやすいドキュメントです。M・SYSTEM技研さまに感謝です。
M・SYSTEM技研さま Modbusプロトコル概説書

間違っていただきたくないのは、"Modbus/TCP"とは、PLCが自身のメモリを後悔するためのインタフェースのひとつにすぎない、ということです。"Modbus/TCP"が貴重なプロトコルである理由を述べます。PLCが自身のメモリを公開するためのプロトコルは他にもたくさんあります。そして、それらの多くは各PLCメーカー固有のものです。Modbus/TCPの特徴は、複数のPLCメーカー間で横断で採用されているプロトコルという点です。複数のメーカーのPLCは、標準ではModbus/TCPが使用できずオプションとして提供され、標準では当該メーカー固有のプロトコルがサポートされます。

Holding Registers

"Holding Registers"とは、Modbus/TCPが定める複数のメモリ領域のうちのひとつです。主に、数値や文字を記憶するために用いられます。アドレスは40001〜です。サンプルでは、40001上のデータをターゲットにします。
今回、PLCの代わりに活躍してくれる"mod_RSsim.exe"では、このような画面で眺めることが出来ます。

ゲートウェイの設定とプログラミング

前回は、ゲートウェイを設定し、PLCに見立てたModbus/TCPシミュレーターに接続しました。
今回は、ゲートウェイを使って、PLCに見立てたModbus/TCPシミュレーターからデータを取得します。サンプルでは前回と同様に、ゲートウェイの代わりにWEINTEK製ゲートウェイのソフトウェア開発ツールであるEasyBuilderのシミュレーターを使用します。

前回作成したEasyBuilderのプロジェクトを開き、メニュー[プロジェクト]-[マクロ]をクリックします。

[マクロ]ウィンドウから[新規作成]をクリックします。

[マクロエディター]に以下のようにコードを記述します。
[周期的に実行する]オプションをオンにし、時間間隔を10にします。

コピーしたい方はこちらからどうぞ。

macro_command main()
        unsigned short        x40001 = 0
        GetData(x40001, "MODBUS TCP/IP (32-Bit)", 4x, 1, 1)
        SetData(x40001, "Local HMI", LW, 0, 1)

end macro_command

[マクロエディター]の下にある[閉じる]をクリックします。

[マクロ]ウィンドウの[コンパイルが成功]に新たなマクロが追加されたら、ひとまずプログラミングは終了です。

マクロ=プログラムの意図

Modbus/TCPが定める"Holding Register"（アドレス: 40001〜）は、EasyBuilderでは"4x"で解釈されます。
EasyBuilderでは、対象装置（今回はModbus/TCPシミュレーター）のメモリ・マップを参照することができます。EasyBuilderの[アドレス]ペイン（ウィンドウ）にて、装置名、ステーション番号、アドレスタイプを以下のように設定すると、ひとつめのアドレスが赤になっているはずです。これは、作成したマクロがこのアドレスを参照している、という証です。

今回作成したコードでは、行4で、対象装置の"4x"のひとつめのアドレスから1ワードだけデータを取得しています。対象装置は”MODBUS TCP/IP (32-Bit)”です。これは、前回、システムパラメータで設定した対象装置の「装置名」です。
行4で取得したデータを、行5で自らのメモリ"LW"のひとつめのアドレスにコピーしています。EasyBuilder（=WEINTEK製ゲートウェイ）も複数のメモリ領域をもっており、LWはそのうちのひとつです。LWは16bitワードであり、Modbus/TCPのHolding Registerと同じワード・サイズです。

[周期的に実行する]オプションのオンはこのプログラムを周期的に実行することを意味します。そしてその周期を今回は1000m秒（=１秒）としています。
このプログラムで、PLCからデータを取得する、という今回の目的は達成されるはずです。

周期的に実行する

とても残念なことに、PLCからデータを取得するゲートウェイは、PLC側のデータ変更等のイベントをもって振る舞いを起こすということが出来ません。これは、完全にPLC側の都合によるものです。このため、ゲートウェイがPLC上のデータを参照するとき、ゲートウェイは空振りすることを承知でPLCのメモリを周期的に参照します。いまどきのシステムとしては実に残念です。"Factory Automation"の技術者は、ITの世界ではとっくに古典となった"Message Passing"や"Data Driven"といった考え方すら学んでいないのです。こういった問題は当面は放置され続けるでしょう。

テスト

前回と同様に、PLCには、本物の代わりにModbus/TCPシミュレーターを使用します。

Modbus/TCPシミュレーター"mod_RSsim.exe"を起動しておきます。

EasyBuilderのメニュー[プロジェクト]-[オンラインシミュレーション]をクリックします。

シミュレーターが起動したら、メニュー[Object]を選択し、右側にある[＋]をクリックします。

ダイアログにて以下のように入力し[OK]ボタンをクリックします。

Modbus/TCPシミュレータの、アドレス40001（注意: +0です）をクリックし、Valueに任意の数値を入力、[OK]ボタンで閉じます。

アドレス40001の表示が変わります。

EasyBuilderのシミュレータ上で、LW-0も変更されることを確認します。

これでテストは終わりです。数行のプログラムのテストとしては十分でしょう。

次回

続きは次回とさせていただきます。
今回は、初心者には少しだけ難解であったかもしれません。慌てずじっくり、しっかり理解して進んでください。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (1)

2022-07-18T11:42:52+09:00

PLCからゲートウェイでデータを取得し、データベースにJSONで保存します。複数回に分けて、サンプルを用いて解説します。

初回は、ゲートウェイでPLCのデータを取得します。

サンプルは、Windowsがあれば環境の準備と動作が可能です。よろしければ、自己責任のもとで環境を準備し、サンプルを動作させてみてください。

PLC

この解説でのサンプルでは、PLCの代わりにModbus/TCPシミュレーターを使用します。これにより、PLCの本物がなくても、実装の学習とテストが可能となります。
今回使用したModbus/TCPシミュレーターは、貴重なmod_RSsim.exeです。もちろん、他のシミュレータでも構いません。

Modbus/TCPシミュレーター: MOD-RSsim Version 8.20

ゲートウェイ

この解説のサンプルでは、WEINTEK製ゲートウェイを想定します。WEINTEK製ゲートウェイのソフトウェア開発ツールは、Windows上でソフトウェアを書くことができることに加え、ゲートウェイの動きをシミュレートすることが出来ます。これにより、ゲートウェイの本物がなくても、実装の学習とテストが可能となります。

WEINTEK製ゲートウェイのソフトウェア開発環境: EasyBuilder Pro

EasyBuilderはWEINTEKのサイトからダウンロードすることが出来ます。
https://www.weintek.com/globalw/Download/Download.aspx

ゲートウェイの設定とプログラミング

ゲートウェイは各社、各モデルで実装のスタイルが大きく異なります。しかし、この解説では、多くのゲートウェイでの機能実装が可能となるよう勘案し、よりシンプルな手順になるよう考慮しています。
前述のとおり、この解説では、ゲートウェイの本物を使用しません。代わりにEasyBuilderという、WEINTEK製ゲートウェイの開発環境を使用します。

EasyBuilder Pro を起動します。

プロジェクトを新たに作成します。
これから行う設定が、どのゲートウェイの設定であるかをゲートウェイのモデルの一覧から選択します。このサンプルでは、最もシンプルなモデル"cMT-G01"を選択します。

"cMT-G01"とはこのようなハードウェアです。
cMT-G01

このゲートウェイが対象にするPLCを設定します。メニュー[ホーム]-[システムパラメータ]を選択します。

[装置]タブを選択します。

[装置/サーバを新規追加]をクリックします。

以下のように設定します。

PLCに相当するModbus/TCPシミュレータは、EasyBuilderと同じWindowsマシン上で稼働させる予定です。このため装置（=PLC=Modbus/TCPシミュレータ）のIPアドレスを127.0.0.1にしています。
装置のポートはModbus/TCPの標準である502を選択しています。

上記設定は、この解説におけるサンプルのための設定です。現実は、対象とするPLCやリモートIOなどに応じた設定が必要となります。
例えば、対象の装置が三菱電機のMELSECであれば、該当のモデルを選択します。下は、Mitsubishi QJ71E71の例です。

テスト

ここまでで、PLC（=Modbus/TCPシミュレータ）に接続する設定が終わりました。接続のテストをします。

mod_RSsim.exeを起動しておきます。

次はEasyBuilderです。
もちろん、これまでの設定をゲートウェイ（cTM-G01）にロードしてゲートウェイを動かすことも可能ですが、今回はシミュレーターを使います。
メニュー[プロジェクト]-[オンラインシミュレーション]をクリックします。

シミュレーターが起動します。"MODBUS TCP/IP (32-Bit)"に接続済みであるように見えますが、これはあてにはなりません。

Modbus/TCPシミュレーターのウィンドウの左上にある"Connected"の表示を確認します。ゲートウェイからの接続が行われていれば、[1/10]となります。

次回へ

続きは次回とさせていただきます。
初心者の方々のために、ゆっくりとマッタリと進めさせていただきます。
次回は、ゲートウェイによるPLCからのデータ取得です。

PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (2)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (3)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (4)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (5)
PLCからゲートウェイでデータを取得しデータベースにJSONで保存 (6)

(PowerShell) PSCustomObject をループさせつつキーと値の両方にアクセスする

2021-01-12T23:48:54+09:00

引き続き PowerShell のお話。今度は PSCustomObject をループさせつつキーと値の両方にアクセスする方法が分からず躓きました。

現象

{
    "common": {
        "config":  {
            "user.name":  "testuser",
            "user.id": 12345,
            "user.email":  "[email protected]"
        }
    }
}

例えばこんな config.json があるとします。

この JSONファイルを読み込んでループさせつつ、キーと値の双方にアクセスしたい。

そこで foreach($confgi in $configData.GetEnumerator()){} としたり、 foreach($confgi in $configData.Keys){} としたりしましたが一向に中身が取得できず四苦八苦。

対処

# JSONファイル 読み込み
[String]$configPath = Join-Path ( Convert-Path . ) 'config.json'
$configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON

# ループ
foreach( $key in $configData.common.config.psobject.properties.name )
{
    Write-Host $key ' = ' $configData.common.config.$key
}

最終的に、 $Object.psobject.properties.name という全然異なるアクセス方法だったことが分かりました。今回の場合はキーが階層で入り組んでいるのでさらに . (ピリオド(ドット)) の個数が増えています。

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1
user.name  =  testuser
user.id  =  12345
user.email  =  [email protected]

やっとキーと値の両方が取得できました……。

参考

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

(PowerShell) PSCustomObject のピリオド(ドット)入りのキー名にアクセスする

2021-01-11T22:59:05+09:00

Powershell で JSON から読み込んだオブジェクトにピリオド(ドット)入りのキー名があり、これにどうやってアクセスしようか悩みました。

現象

{
    "user": {
        "user.name": "testuser",
        "user.email": "[email protected]"
    }
}

例えばこんな config.json があるとします。

この JSONファイルを読み込み、ユーザの入力を受け付けて設定を上書きするスクリプトを書きました。

# JSONファイル 読み込み
[String]$configPath = Join-Path ( Convert-Path . ) 'config.json'
$configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON

# 一度出力
Write-Host $configData.user['user.name']

# 入力受付
[String]$username = Read-Host 'ユーザー名 を入力してください (半角英数字と一部記号 (-, _) )。'
if (-not ($username -match "^[a-zA-z0-9\-_]+$") ) {
    Write-Host 'ERROR: ユーザ名 に使用できない文字が含まれています。' -BackgroundColor DarkRed
    Write-Host `r`n

    exit
}
$configData.user['user.name'] = $username

# 再度出力
Write-Host $configData.user['user.name']

ここで問題となったのが user.name という . (ピリオド(ドット))入りのキー名。オブジェクトで . でキー名を連結できるのが JavaScript に似ていたので、つい JavaScript のように $configData.user['user.name'] と書いてしましました。

すると

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1

ユーザー名 を入力してください (半角英数字と一部記号 (-, _) )。: aaa
型 System.Management.Automation.PSObject のオブジェクトにインデックスを付けることはできません。
発生場所 PATH\TO\PROJECT\test.ps1:16 文字:1
+ $configData.user['user.name'] = $username
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) []、RuntimeException
    + FullyQualifiedErrorId : CannotIndex

怒られました。しかも、初出の位置ではなく変数で上書きする部分で。初出の Write-Host による標準出力はブランクを出力してスルーされたようです。

以上より、

変数の値を読み込む場合(出力など): 存在しないキーとしてブランク出力してそのままスルー
変数の値を書き込む場合: エラー

となるようです。困った。

対処

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

プロパティ名に文字列を使用しても、やはり機能します。

$myObject.'Name'

なん……だと……。

ということで上記スクリプトを書き換えます。

# JSONファイル 読み込み
[String]$configPath = Join-Path ( Convert-Path . ) 'config.json'
$configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON

# 一度出力
Write-Host $configData.user.'user.name'

# 入力受付
[String]$username = Read-Host 'ユーザー名 を入力してください (半角英数字と一部記号 (-, _) )。'
if (-not ($username -match "^[a-zA-z0-9\-_]+$") ) {
    Write-Host 'ERROR: ユーザ名 に使用できない文字が含まれています。' -BackgroundColor DarkRed
    Write-Host `r`n

    exit
}
$configData.user.'user.name' = $username

# 再度出力
Write-Host $configData.user.'user.name'

肝は $configData.user.'user.name' 。 $configData.user['user.name'] の角括弧 ([])を外してキー名の文字列をそのまま . (ピリオド(ドット)) で繋げました。

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1
testuser
ユーザー名 を入力してください (半角英数字と一部記号 (-, _) )。: abc
abc

上手く行きました。

参考

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

【Java】JSON-libを使ってJSON配列を生成する際に日付型（Date）を好きなフォーマットで変換する方法

2020-03-09T10:04:51+09:00

最近はWEBのサービス開発などでSPA（Single Page Applicatoin）が流行って？るので、
サーバーとクライアントとのデータのやり取りをJSONで行うのはよくあるケースかと思います。

サーバー側をJavaで開発している場合に、Javaオブジェクトや Bean を JSONに変換するのに、
JSON-lib というのも結構主流なやり方かと思いますが、ちょっと日付型のところでハマったので備忘的な記事を。

※JSON-lib 自体の詳しい説明（利用方法）などは省略します。

JSON-libとは

OSDNサイトより転載 Json-libは、beans, map, collection, Java配列、XML to JSON, DynaBeansを変革するJavaライブラリです。 Douglas Crockfordによる作業をベースにしています。

Javaオブジェクトを簡単に JSON文字列に変換したり、逆に JSON文字列からオブジェクトを生成したりといったことが可能です。

昔、XMLへの相互変換ロジックを自作したことがありますが、こういう処理って実際に作ってみると結構大変だったりします。
便利な世の中ですね。

サンプル

変換するサンプルクラスを作成。

Person.java

package jp.co.doraxdora.sample;

import java.io.Serializable;
import java.util.Date;

/**
 * パーソンクラス
 *
 * @author doraxdora
 *
 */
public class Person implements Serializable {

    /** ID */
    private int id;
    /** 氏名 */
    private String name;
    /** 年齢 */
    private int age;
    /** 更新日時 */
    private Date updateDate;

    public Person() {
    }

    /**
     * パーソンの生成
     *
     * @param id
     * @param name
     * @param age
     */
    public Person(int id, String name, int age, Date updateDate) {
        this.id = id;
        this.name = name;
        this.age = age;
        this.updateDate = updateDate;
    }

    /**
     * @return id
     */
    public int getId() {
        return id;
    }

    /**
     * @param id セットする id
     */
    public void setId(int id) {
        this.id = id;
    }

    /**
     * @return name
     */
    public String getName() {
        return name;
    }

    /**
     * @param name セットする name
     */
    public void setName(String name) {
        this.name = name;
    }

    /**
     * @return age
     */
    public int getAge() {
        return age;
    }

    /**
     * @param age セットする age
     */
    public void setAge(int age) {
        this.age = age;
    }

    /**
     * @return updateDate
     */
    public Date getUpdateDate() {
        return updateDate;
    }

    /**
     * @param updateDate セットする updateDate
     */
    public void setUpdateDate(Date updateDate) {
        this.updateDate = updateDate;
    }

}

何故か更新日時を持つパーソンクラスです。

JavaオブジェクトからJSON文字列に変換

import net.sf.json.JSONObject;

public class HelloWorld {
    public static void main(String[] args) {

        Person person = new Person(1, "サンプル　一郎", 20, new Date());

        JSONObject jsonObject = JSONObject.fromObject(person);
        System.out.println(String.valueOf(jsonObject));
    }
}

こんな感じで、Dateを持つクラスをJSONに変換すると次のような文字列が生成されます。

{
    "age": 20,
    "id": 1,
    "name": "サンプル　一郎",
    "updateDate": {
        "date": 23,
        "day": 2,
        "hours": 10,
        "minutes": 22,
        "month": 3,
        "seconds": 44,
        "time": 1555982564167,
        "timezoneOffset": -540,
        "year": 119
    }
}

これはこれで正しいのですが、クライアント側で日時の部分が扱いづらい。。

対応

JSON-lib には、「JsonValueProcessor」という、変換時に対象となる値に対して処理できるインターフェースが定義されているので、
実装したクラスを作成して日付型オブジェクトに対して別途変換する処理を組み込みます。

DateJsonValueProcessor.java

package jp.co.doraxdora.sample;

import java.util.Date;

import net.sf.json.JsonConfig;
import net.sf.json.processors.JsonValueProcessor;
import java.text.SimpleDateFormat;

/**
 * 日付型をJSON変換する際にフォーマットする
 *
 * @author doraxdora
 *
 */
public class DateJsonValueProcessor implements JsonValueProcessor {

    /* (非 Javadoc)
     * @see net.sf.json.processors.JsonValueProcessor#processArrayValue(java.lang.Object, net.sf.json.JsonConfig)
     */
    @Override
    public Object processArrayValue(Object value, JsonConfig jsonConfig) {
        return process((Date) value, jsonConfig);
    }

    /* (非 Javadoc)
     * @see net.sf.json.processors.JsonValueProcessor#processObjectValue(java.lang.String, java.lang.Object, net.sf.json.JsonConfig)
     */
    @Override
    public Object processObjectValue(String key, Object value, JsonConfig jsonConfig) {
        return process((Date) value, jsonConfig);
    }

    /**
     * 日付型を文字列に変換.
     *
     * @param date
     * @param config
     * @return
     */
    private Object process(Date date, JsonConfig config) {
        if (date == null) {
            return null;
        }

        SimpleDateFormat formatter = new SimpleDateFormat("yyyy/MM/dd（E）");

        return formatter.format(date);
    }

}

JsonConfig に DateValueProcessor を設定して変換

import net.sf.json.JSONObject;
import net.sf.json.JsonConfig;

public class HelloWorld {
    public static void main(String[] args) {

        Person person = new Person(1, "サンプル　一郎", 20, new Date());

        JsonConfig config = new JsonConfig();
        config.registerJsonValueProcessor(java.util.Date.class, new DateJsonValueProcessor());

        JSONObject jsonObject = JSONObject.fromObject(person, config);
        System.out.println(String.valueOf(jsonObject));
    }
}

という感じで、日付型だった場合の処理を設定して変換してあげると次のような文字列が生成されます。

{
    "age": 20,
    "id": 1,
    "name": "サンプル　一郎",
    "updateDate": "2019/04/23（火）"
}

大分シンプルになりました。

まとめ

ちょっとした単発のプログラムネタでした。

実は以前 Python でも同様の問題にぶち当たったことがあって、
だったら Java でも同じようになんとかできるだろうと調べてみたという感じです。

何かのお役に立てれば。

ではでは。

Data.Aesonの使い方

2019-09-29T19:46:32+09:00

自分のブログ記事からのクロス投稿です。

HaskellのJSONライブラリとしておそらくメジャーなData.Aesonですが、使い方が難しいので色々試行錯誤しています。

以降のコードはghci上で実行することを想定しています。
適当にstackでプロジェクトを作って、aesonをcabalファイルのbuild-dependsに追加してビルドし、stack ghciとするのが良いと思います。あと、Data.TextやData.HashMapなども必要です。

# ここはターミナルで
stack new sandbox-prj simple
cd sandbox-prj
# cabalファイルのbuild-dependsにaeson, text, unordered-containers, vectorを追記
stack build
stack ghci

はじめに、以下をghci上でコピペしておいてください。以降のコードが全部動くはずです。

-- ghci上で
-- 最初にこれらをコピペしておくと、以降のコードが全部動くはず

-- 後でGHC拡張を使う
:set -XDeriveGeneric
:set -XExistentialQuantification
:set -XFlexibleContexts
:set -XFlexibleInstances
:set -XGADTs
:set -XInstanceSigs
:set -XOverloadedStrings
:set -XTypeFamilies
:set +m

-- 後で色々使う
import Control.Applicative (empty, pure)
import Data.Aeson
import qualified Data.Aeson.Encoding.Internal as DAE
import Data.Aeson.Types
import Data.Char (toLower, toUpper)
import qualified Data.HashMap.Lazy as HML
import qualified Data.HashMap.Strict as HMS
import qualified Data.Text as T
import qualified Data.Text.Lazy as TL
import qualified Data.Vector as V
import GHC.Generics

基本的な使い方

基本的な型については特にパーサーを定義しなくて良いので、いきなりエンコード・デコードできます。

エンコード

encode 1
-- --> "1"
encode "hello"
-- --> "\"hello\""
encode [1,2,3]
-- --> "[1,2,3]"
encode (1,2)
-- --> "[1,2]"
encode (Just 1)
-- --> "1"
encode True
-- --> "true"
encode Null
-- --> "null"
encode (1234, "hello", True, False, [1,2,3], Just 10)
-- --> "[1234,\"hello\",true,false,[1,2,3],10]"

デコードは、Haskellの型を指定する必要があります。

-- 型を指定しないとデコードできない
decode "1"
-- --> Nothing

decode "1" :: Maybe Int
-- --> Just 1
decode "\"hello\"" :: Maybe String
-- --> Just "hello"
decode "[1234,\"hello\",true,false,[1,2,3],10]" :: Maybe (Int,String,Bool,Bool,[Int],Maybe Int)
-- --> Just (1234,"hello",True,False,[1,2,3],Just 10)

ToJSON, FromJSON

エンコード・デコードするためには、そのデータ型がToJSON・FromJSONのインスタンスになっている必要があります。
このように定義します。DeriveGeneric拡張（はじめにセットしたやつ）とGHC.Genericsが必要です。

data MyData = MyData { field :: String } deriving (Show, Generic)
instance FromJSON MyData
instance ToJSON MyData

myData = MyData "my data!!"
encode myData
-- --> "{\"field\":\"my data!!\"}"
decode "{\"field\":\"my data!!\"}" :: Maybe MyData
-- --> Just (MyData {field = "my data!!"})

簡単ですね。基本的には、エンコード・デコードの実装を自分で定義しなくても自動的に導出してくれます。

-- :{ :} はghciで複数行定義をするときに使う記号
:{
data Person = Person
  { name :: String
  , age :: Int
  , group :: [String]
  } deriving (Show, Generic)
:}
instance FromJSON Person
instance ToJSON Person

p1 = Person "Neo" 30 ["groupA", "groupB"]
p2 = Person "Morpheus" 40 ["groupA"]
p3 = Person "Trinity" 30 []

encode p1
-- --> "{\"group\":[\"groupA\",\"groupB\"],\"age\":30,\"name\":\"Neo\"}"

decode "{\"group\":[\"groupA\",\"groupB\"],\"age\":30,\"name\":\"Neo\"}" :: Maybe Person
-- --> Just (Person {name = "Neo", age = 30, group = ["groupA","groupB"]})

-- リストはもともとToJSONとFromJSONのインスタンスなので、
encode [p1, p2, p3]
-- --> "[{\"group\":[\"groupA\",\"groupB\"],\"age\":30,\"name\":\"Neo\"},{\"group\":[\"groupA\"],\"age\":40,\"name\":\"Morpheus\"},{\"group\":[],\"age\":30,\"name\":\"Trinity\"}]"

decode "[{\"group\":[\"groupA\",\"groupB\"],\"age\":30,\"name\":\"Neo\"},{\"group\":[\"groupA\"],\"age\":40,\"name\":\"Morpheus\"},{\"group\":[],\"age\":30,\"name\":\"Trinity\"}]" :: Maybe [Person]
-- --> Just [Person {name = "Neo", age = 30, group = ["groupA","groupB"]},Person {name = "Morpheus", age = 40, group = ["groupA"]},Person {name = "Trinity", age = 30, group = []}]

※ 彼らの年齢は間違っているかもしれません。

Haskellのレコードを使うときは、以下のように型名のプレフィックスをフィールド名につけて定義することが多いかもしれません（あるいはlensなどを使うのかもしれませんが）。それでも、JSONのフィールド名はシンプルに"title", "created"としておきたいですよね。
こういう場合、defaultOptionsというのを使います。fieldLabelModifierに、フィールド名の変換関数を定義しておけば、エンコード時に適用してくれます。ここでは、プレフィックス（"movie"の5文字）を取り除き、かつ小文字にするというルールにしました。

:{
data Movie = Movie
  { movieTitle :: String
  , movieCreated :: Int
  } deriving (Show, Generic)
:}
movieOptions = defaultOptions {fieldLabelModifier = map toLower . drop 5}
instance ToJSON Movie where
  toEncoding = genericToEncoding movieOptions
instance FromJSON Movie where
  parseJSON = genericParseJSON movieOptions


movie = Movie "The Matrix" 1999

encode movie
-- --> "{\"title\":\"The Matrix\",\"created\":1999}"

decode "{\"title\":\"The Matrix\",\"created\":1999}" :: Maybe Movie
-- --> Just (Movie {movieTitle = "The Matrix", movieCreated = 1999})

エンコーダー・デコーダーを自前で定義

では、代数データ型の場合はどうでしょうか。基本的には以下のように自動導出できます。

data Size = Small|Medium|Large deriving (Show, Generic)
instance ToJSON Size
instance FromJSON Size

encode [Small, Medium, Large]
-- --> "[\"Small\",\"Medium\",\"Large\"]"

decode "[\"Small\",\"Medium\",\"Large\"]" :: Maybe [Size]
-- --> Just [Small,Medium,Large]

ただ、JSONデータではキャメルケースでなくsmall, medium, largeのように小文字で表現したいかもしれません。その場合は、以下のように自分で定義する必要があります。ToJSONのインスタンスにするには、toJSONか、toEncodingを自分で定義します。以下のような型です。

toJSON :: a -> Value
toEncoding :: a -> Encoding

toJSONは任意の型をData.AesonのValue型にします。したがって、toJSONのみを定義した場合は、toEncodingが自動導出されます。JSONにエンコードするときは、一旦Valueに変換され、その後JSONの文字列に変換されます。
一方、toEncodingを直接定義することもできて、その場合は、Valueを経由せず直接エンコードされることになります。ここには歴史的経緯があるようです。

-- toJSONを定義する場合
data Size = Small|Medium|Large deriving (Show, Generic)
instance ToJSON Size where
  toJSON Small = String "small"
  toJSON Medium = String "medium"
  toJSON Large = String "large"

encode [Small, Medium, Large]
-- --> "[\"small\",\"medium\",\"large\"]"

-- toEncodingを定義する場合
data Size = Small|Medium|Large deriving (Show, Generic)
instance ToJSON Size where
  toEncoding Small = DAE.string "small"
  toEncoding Medium = DAE.string "medium"
  toEncoding Large = DAE.string "large"

encode [Small, Medium, Large]
-- --> "[\"small\",\"medium\",\"large\"]"

FromJSONのインスタンスについては、parseJSONを定義します。こちらは少し面倒です。以下のような型をしています。

parseJSON :: Value -> Parser a

-- withTextの第一引数（"Size"）は、どんな文字列でも良いみたい。
-- なんのための引数なのかまだわかっていない。
instance FromJSON Size where
  parseJSON = withText "Size" $ \t ->
    fromString (TL.unpack (TL.fromStrict t))
    where fromString :: String -> Parser Size
          fromString "small" = pure Small
          fromString "medium" = pure Medium
          fromString "large" = pure Large
          fromString _ = empty

decode "[\"small\",\"medium\",\"large\"]" :: Maybe [Size]
-- --> Just [Small,Medium,Large]

これで、Sizeデータを使ったレコードもエンコード・デコードすることができます。

:{
data Tomato = Tomato
  { size :: Size
  , brand :: String
  } deriving (Show, Generic)
:}
instance ToJSON Tomato
instance FromJSON Tomato

mini = Tomato Small "famous brand name"

encode mini
-- --> "{\"size\":\"small\",\"brand\":\"famous brand name\"}"

decode "{\"size\":\"small\",\"brand\":\"famous brand name\"}"
-- --> Just (Tomato {size = Small, brand = "famous brand name"})

多相型

このようなデータ型でもこれまでと同じようにToJSON・FromJSONのインスタンスにすることができます。自動導出の場合は、以下の例のようにエンコード時にWrapが外れます。

data Wrap a = Wrap a deriving (Show, Generic)
instance ToJSON a => ToJSON (Wrap a)
instance FromJSON a => FromJSON (Wrap a)

encode $ Wrap 1
-- --> "1"
encode $ Wrap "wrapped"
-- --> "\"wrapped\""

decode "1" :: Maybe (Wrap Int)
-- --> Just (Wrap 1)
decode "\"wrapped\"" :: Maybe (Wrap String)
-- --> Just (Wrap "wrapped")

今度はPoint a型で考えます。自動導出で問題ない場合は良いのですが、自分で定義しようとした時に、少し悩みました。toJSONもparseJSONも、aの部分の値をエンコード・デコードする処理を自分で定義してしまうと型を決めなくてはなりません。そうするとaのままではできず、Point Intなどの具体的な型で定義せざるを得ません。そこで、aの部分については、自分で定義せず、toJSONやparseJSONをそのまま使います。もともとaはそれらのインスタンスであることを仮定しているので、自分で定義する必要がありません。以下のように書くと、型引数をとる型についても定義できます。

data Point a = Point a a deriving (Show, Generic)
instance ToJSON a => ToJSON (Point a) where
  toJSON (Point x y) = Object $ HMS.fromList [("point", toJSON [x,y])]

:{
instance FromJSON a => FromJSON (Point a) where
  parseJSON (Object o) = case HML.lookup "point" o of
    Just arr -> let
                    pts = parseJSON arr :: FromJSON b => Parser (b, b)
                in
                    Point <$> (fst <$> pts) <*> (snd <$> pts)
    Nothing -> empty
:}

pi = Point 1 2
ps = Point "one" "two"

encode pi
-- --> "{\"point\":[1,2]}"

encode ps
-- --> "{\"point\":[\"one\",\"two\"]}"

decode "{\"point\":[1,2]}" :: Maybe (Point Int)
-- --> Just (Point 1 2)

decode "{\"point\":[\"one\",\"two\"]}" :: Maybe (Point String)
-- --> Just (Point "one" "two")

少し複雑な代数データ型

data Gender = Female|Male deriving (Show, Generic)
data Property = Name String|Age Int|Gender Gender deriving (Show, Generic)
instance ToJSON Gender
instance FromJSON Gender
instance ToJSON Property
instance FromJSON Property

props = [Name "Neo", Age 30, Gender Male]

encode props
-- --> "[{\"tag\":\"Name\",\"contents\":\"Neo\"},{\"tag\":\"Age\",\"contents\":30},{\"tag\":\"Gender\",\"contents\":\"Male\"}]"

decode "[{\"tag\":\"Name\",\"contents\":\"Neo\"},{\"tag\":\"Age\",\"contents\":30},{\"tag\":\"Gender\",\"contents\":\"Male\"}]" :: Maybe [Property]
-- --> Just [Name "Neo",Age 30,Gender Male]

このような型でもすべて自動導出できました。しかし、JSONのフォーマットは微妙ですね。以下のようになって欲しいです。（レコード型で定義すれば良いだけの話なのですが、今は例ということで。。）

{ "name": "Neo", "age": 30, "gender": "male" }

自前で定義しましょう。名前を変えるため別の例にしますが、データ構造はほぼ一緒です。

data CarType = Coupe|SUV deriving (Show, Generic)
data Car = Model String|Release Int|CarType CarType deriving (Show, Generic)

instance ToJSON CarType where
  toJSON Coupe = String "coupe"
  toJSON SUV = String "suv"

instance FromJSON CarType where
  parseJSON = withText "CarType" $ \t ->
    fromString (T.unpack t)
    where fromString :: String -> Parser CarType
          fromString "coupe" = pure Coupe
          fromString "suv" = pure SUV
          fromString _ = empty

instance ToJSON Car where
  toJSON (Model s) = object [("model", toJSON s)]
  toJSON (Release i) = object [("release", toJSON i)]
  toJSON (CarType c) = object [("car_type", toJSON c)]

instance FromJSON Car where
  parseJSON (Object o) = case HML.lookup "model" o of
    Just (String s) -> pure (Model $ T.unpack s)
    _ -> case HML.lookup "release" o of
      Just i -> Release <$> (parseJSON i :: Parser Int)
      _ -> case HML.lookup "car_type" o of
        Just t -> CarType <$> (parseJSON t :: Parser CarType)

myCar = [Model "Land Cruiser", Release 1954, CarType SUV]

encode myCar
-- --> "[{\"model\":\"Land Cruiser\"},{\"release\":1954},{\"car_type\":\"suv\"}]"

decode "[{\"model\":\"Land Cruiser\"},{\"release\":1954},{\"car_type\":\"suv\"}]" :: Maybe [Car]
-- --> Just [Model "Land Cruiser",Release 1954,CarType SUV]

これで、望みのJSON形式でエンコード・デコードできるようになりました。

Either型

Either型の場合はどうなるでしょうか。わからないのでまずは自動導出して見ましょう。

:{
data Filter = Filter
  { value :: Either String [String] } deriving (Show, Generic)
:}
instance ToJSON Filter
instance FromJSON Filter

filterL = Filter (Left "eq")
filterR = Filter (Right ["eq", "gt"])

encode filterL
-- --> "{\"value\":{\"Left\":\"eq\"}}"

encode filterR
-- --> "{\"value\":{\"Right\":[\"eq\",\"gt\"]}}"

decode "{\"value\":{\"Left\":\"eq\"}}" :: Maybe (Filter)
-- --> Just (Filter {value = Left "eq"})

decode "{\"value\":{\"Right\":[\"eq\",\"gt\"]}}" :: Maybe (Filter)
-- --> Just (Filter {value = Right ["eq","gt"]})

一応できました。しかし、JSONデータの中に"Left"や"Right"が入ってしまって冗長です。この場合は、以下のようになって欲しいですね。

# Leftの場合
{"value": "eq"}

# Rightの場合
{"value": ["eq", "gt"]}

以下のように定義しましょう。別の例にするのが面倒なので、同じデータを再定義します。

:{
data Filter = Filter
  { value :: Either String [String] } deriving (Show, Generic)
:}
instance ToJSON Filter where
  toJSON (Filter (Left s)) = object [("value", toJSON s)]
  toJSON (Filter (Right ss)) = object [("value", toJSON ss)]

-- Arrayの時に、判定できていないのが難点
-- でも、失敗した時はちゃんとNothingを返してくれるのでとりあえず良いか
instance FromJSON Filter where
  parseJSON (Object o) = case HML.lookup "value" o of
    Just (String s) -> pure (Filter (Left $ T.unpack s))
    Just arr -> (Filter . Right) <$> (parseJSON arr :: Parser [String])
    _ -> empty

filterL = Filter (Left "eq")
filterR = Filter (Right ["eq", "gt"])

encode filterL
-- --> "{\"value\":\"eq\"}"

encode filterR
-- --> "{\"value\":[\"eq\",\"gt\"]}"

decode "{\"value\":\"eq\"}" :: Maybe Filter
-- --> Just (Filter {value = Left "eq"})

decode "{\"value\":[\"eq\",\"gt\"]}" :: Maybe Filter
-- --> Just (Filter {value = Right ["eq","gt"]})

Either型の場合もこのように定義することで自由にJSONとの変換ができます。ちなみに上記の例のようにではなく、Either String aとしてエラーメッセージ付きのMaybeのような扱いをしたい場合は、専用の関数がすでに用意されているようです。

GADT

この場合は、Field StringとField Boolの場合でそれぞれ定義するしかなさそうです。もしまとめて定義する方法があれば誰か教えてください。

data Field typ = (typ ~ String) => Title | (typ ~ Bool) => Done

instance Show (Field typ) where
  show Title = "Title"
  show Done = "Done"

instance ToJSON (Field typ) where
  toJSON Title = String "title"
  toJSON Done = String "done"

:{
instance FromJSON (Field String) where
  parseJSON = withText "Field" $ \v -> case v of
    "title" -> pure Title
    _ -> empty
instance FromJSON (Field Bool) where
  parseJSON = withText "Field" $ \v -> case v of
    "done" -> pure Done
    _ -> empty
:}
encode Title
-- --> "\"title\""
encode Done
-- --> "\"done\""
decode "\"title\"" :: Maybe (Field String)
-- --> Just Title
decode "\"done\"" :: Maybe (Field Bool)
-- --> Just Done

で、このFieldを使って、以下のようなレコードを定義します。

:{
data Filter = forall typ. Show typ => Filter
            { field :: Field typ
            , value :: typ
            }
:}

なぜこんなデータ型を考えているかというと、実はpersistentのクラスに、Filterっていうのがあって、これをFromJSONのインスタンスにしたかったのです。このデータをもう少し簡易にしたものが、上で定義したFilterです。ここでの肝は、型引数のtypが型としては明示的に現れていない点です。つまりFilter Title "some title"も、Filter Done Trueも型としては単にFilter型ですが、前者のtypはStringで後者はBoolです。

-- どちらも単にFilter型
:t Filter Title "some title"
-- --> Filter Title "some title" :: Filter

:t Filter Done True
-- --> Filter Done True :: Filter

このようなデータ型の場合、先ほどFieldのFromJSONをField StringとField Boolでそれぞれ定義した時のようなことができません。fieldの値がTitleならtypはString、DoneならBoolというような場合分けをする必要があります。色々試行錯誤してようやくできた定義が以下です。mayTitleとmayDoneの場合分けのところは、この2つデータの型が違うので、それぞれ別の変数にせざるを得ませんでした。そのためmayFieldを必ず2回評価することになり、無駄の多い実装になってしまいました。

instance FromJSON Filter where
        parseJSON (Object o) = do
            let mayField = HMS.lookup "field" o
            let mayValue = HMS.lookup "value" o
            let mayTitle = case mayField of
                               Just (String "title") -> Just Title
                               _ -> Nothing
            let mayDone = case mayField of
                              Just (String "done") -> Just Done
                              _ -> Nothing
            case mayValue of
                Just value -> do
                    case mayTitle of
                        Just title -> Filter title <$> (parseJSON value :: Parser String)
                        Nothing -> case mayDone of
                                       Just done -> Filter done <$> (parseJSON value :: Parser Bool)
                                       Nothing -> empty
                Nothing -> empty

-- Filter Title "some title"
case decode "{\"field\":\"title\", \"value\":\"some title\"}" :: Maybe Filter of
    Just (Filter field value) -> print value
    Nothing -> print Nothing

-- Filter Done True
case decode "{\"field\":\"done\", \"value\":true}" :: Maybe Filter of
    Just (Filter field value) -> print value
    Nothing -> print Nothing

Laravel5.8現在FormRequestのバリデーション結果をJSON APIで返す

2019-05-21T16:05:34+09:00

LaravelはFormRequestという仕組みでバリデーションを分離できる。APIの場合はコードを変えずにバリデーション結果のJSONを取得することができるのでその方法。

ちなみにAPIでない通常のWebページの場合は$errorsオブジェクトを使ってページ上にバリデーション結果を表示することができる。これのために作ったFormRequestをそのままAPIでも利用することができる。

やりかた

リクエストする際にAccept: application/jsonヘッダーを送るだけ。これでJSONで取得できる。

以前のやりかた

ちなみに以前はこんな感じでFormRequestのメソッドをオーバーライドして対応していたっぽい。

【Laravel5】FormRequestのバリデーション結果をJSON APIで返す

もしかしたらこの時もAcceptヘッダーを送ればできたのかもしれないが。何にしろ、リクエスト側の仕様の問題でAcceptヘッダーを正しく送ることができないのであればこの方法でやるしかなさそう。