WEB電子カルテインストール格闘記

背景

W先生から一式いただいたWEB電子カルテのインストール作業を始めてもう数週間が経過するというのにいまだに完成しない。しかし、何とかエラーメッセージが出ないところまで進んだ。記録を残しておかないとまた苦労することになる。そこで、このブログに作業記録を綴っていくことにする。

どこまでできたか

今のところ、ログイン後、診療受付一覧画面が表示されるところまでできている。しかし、何も表示されない。検索するつもりで診療科から「内科」を選択して患者名に「田中」と入力して「再表示」ボタンをクリックしたがやはり何も表示されない。おそらく該当するデータがないだけのことだろうが(そもそもデータベースにどのようなデータが入っているかは詳しく見ていない)、問題なのは入力した患者名が文字化けすること。

文字化け解決

WebContent/WEB-INF/web.xmlの文字エンコーディングフィルタの設定(34~42行目)を以下のようにwindows-31jからutf-8に修正したら文字化けが解消した。
<!-- 文字エンコーディングフィルタ -->
<filter>
 <filter-name>EncodeFilter</filter-name>
 <filter-class>web.karte.common.CommonSetCharacterEncodingFilter</filter-class>
 <init-param>
 <param-name>encoding</param-name>
 <!-- 
 <param-value>windows-31j</param-value>
  -->
 <param-value>utf-8</param-value>
 </init-param>
</filter>
ここで、encodingはweb.karte.common.CommonSetCharacterEncodingFilterがrequest.setCharacterEncoding(encoding)のようにしてパラメタの文字コードを指定している。 この修正には下記サイトが役立った。
http://www.javaroad.jp/servletjsp/sj_servlet13.htm
Servletの場合は、HttpServletRequestインタフェースのsetCharacterEncodingメソッドでパラメータの文字コードを指定するらしい。

開発マシンと実行マシン

開発マシンでは動いていたのに実行マシンではログイン時に次のエラーが出て動かない。
ERROR:  password is required
DETAIL:  Non-superuser cannot connect if the server does not request a password.
HINT:  Target server's authentication method must be changed.
検索してみると同じ現象を書いたサイトが見つかった。
http://d.hatena.ne.jp/toshifusa1423/20100623/1277279922
dblinkがらみらしい。dblinkとは簡単に言えばあるデータベースから別のデータベースのテーブルにアクセスするPostgreSQLの機能。上記のサイトでは
 pg_hba.confでローカル接続をtrustにしているせいで、パスワード無しで接続しようとしてはねられているようです。
と原因分析しているが、今回の設定(/etc/postgresql/9.3/main/pg_hba.conf)は次のようになっている。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# "local" is for Unix domain socket connections only
local   all             all                                     peer
local   all             postgres                                     md5
#local   all             orca                                    md5
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             172.16.0.0/16           md5
host    all             all             0.0.0.0/0            md5
ローカル接続はユーザがpostgresの場合はmd5で、それ以外はpeerになっている。peerというのはLinuxアカウントでの接続のみを許すということらしい。 一方、ホスト接続はすべてmd5になっている。 さて、では、WEB電子カルテはどのようにしてデータベースemrsdbに接続しているのだろう。 JDBCの設定は/usr/local/tomcat8/conf/Catalina/localhost/emrs.xmlに書かれている。
<Context path="/usr/local/tomcat8/webapps/emrs" reloadable="true" docBase="/usr/local/tomcat8/webapps/emrs/web" workDir="/usr/local/tomcat8/webapps/emrs/web/work">
        <Logger className="org.apache.catalina.logger.SystemOutLogger" verbosity="4" timestamp="true"/>
        <Resource name="jdbc/emrsdb" auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/emrsdb" username="postgres" password="postgres" maxActive="20" maxldle="10" maxWait="-1"/>
        <Resource name="jdbc/orca"   auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/orca"   username="orca" password="orca" maxActive="20" maxldle="10" maxWait="-1"/>
</Context>
はじめはjdbc/emrsdbに対するusernameもpasswordもorcaであったが上記のようにpostgresに変更するとエラーは出なくなった。

dblinkの問題

WEB電子カルテシステムが利用するデータベースemrsdbにはいくつかのビューがあり、それらはすべてORCAのデータベースであるorcaをdblinkして作ってある。一例をあげると、次のようなビューである。
 SELECT t1.knsbunrui,
    t1.srycd,
    t1.dspseq,
    t1.termid,
    t1.opid,
    t1.creymd,
    t1.upymd,
    t1.uphms
   FROM dblink('dbname=orca user=postgres password=postgres'::text, 'select * from tbl_kensasort'::text) t1(knsbunrui numeric(2,0), srycd character(9), dspseq numeric(4,0), termid character varying(32), opid character varying(16), creymd character(8), upymd character(8), uphms character(6));
これは、データベースorcaのテーブルtbl_kensasortをdblinkしてorca_tbl_kensasortというビューを定義している。こうしたビューのうち、orca_tbl_byomeiとorca_tbl_tensuの2つだけデータ表示がABORTした。原因を調べてみると、
  • orca_tbl_byomeiのビュー定義についてはdblinkの定義にあるselect * from tbl_byomeiの * を実際に必要とする列名だけにするとエラーは出なくなった
  • orca_tbl_tensuについては、上記に加え、orca側がsmallintになっていて、ビューの定義がnumeric(3,0)になっているフィールドのいくつか(kijunteigencd, sstkijuncd1~10)がオーバーフローしていたのでnumeric(4,0)(あるいはsmallint)とすることにより解決した。要するにデータ型の不整合である。
これらのエラーはWEB電子カルテが開発されたときからORCAのバージョンが上がりデータベースに変更が加えられたためと考えられ、ORCAをバージョンアップすると今後も起きる可能性がある。

0 件のコメント:

コメントを投稿