ADempiereのJasperで使うImageのパス

■Jasper内で使うイメージのファイルパス
JasperReportで、静的イメージファイルを貼り付けたときに注意することとして
そのイメージのパスの問題がある。

通常、JasperReportをデザインするのは、iReportというツールを使う。
iReportで、静的イメージを貼り付けるには、パレットからImageオブジェクトを選択して
デザイン中のレポートへドラッグすることで貼り付けることができる。

このときに、ダイアログが出て、静的ファイルを選択することとなる。
しかし、この動作によって、設定されるファイルパスは、使用中のiReportがある環境でのファイルパスとなる。
つまり、このJasperReportとImageファイルをサーバなどへ配置した場合、ここで設定されたパスでは、Imageファイルが見つからないことになってしまうことも多く、最終的な実行環境を想定したパスをここで設定しておかなければならない。


■ADempiereでのJasperイメージパスの設定方法
ADempiereでは、AP辞書で登録したJasperファイルやイメージファイルをReportStarterというクラスが処理して、JasperReportのアウトプットを作成する。
このときに、使用されるパスは、以下のようになる。

System.getProperty("java.io.tmpdir") + System.getProperty("file.separator")+"ABCDEFG.png"

つまり、システムプロパティの「java.io.tmpdir」に、Jasper関連のファイルが一時保存されて使用されている。
（C:\Users\ユーザ名\AppData\Local\Temp）

なので、iReportでデザインするときに、ImageオブジェクトのImageExpressionプロパティにも、上記のパスを設定しておけば、ADempiereでうまく表示することができる。

ADempiereのIEブラウザ対応

ADempiereは、FireFoxやChromeには対応しており問題なく動作するが
IEとなると少し問題がある。
グリッド表示やテキストボックスの表示がおかしくなったり、画面が真っ白になってしまうことがある。

ただし、これは、コミュニティ版のADempiereの場合で、SMBアソシエイツ社では、IEでも問題なく正常動作するように修正を加えている。

ADempiereをIEで正常動作させるためには、以下の対応が必要となる。


■Compatible対応のヘッダー出力をしない
　WebUIプロジェクトのindex.zulで、IE8へのCompatible対応タグが記述されているので、これを削除する。
　具体的には、index.zulの７行目あたりの以下の部分を削除する。
　　<?meta http-equiv="X-UA-Compatible" content="IE=8" ?>

■拡大、縮小時のエラー対応
　上記の対応をすれば、IEでもほぼほぼ正常動作が可能になるが
　Ctrl＋マウスホイールを使った拡大縮小時にエラーが発生してしまう。
　
　これに対応するには、以下のソースの修正が必要である。
　zk.jarの中にある「MouseCommand.java」に以下の修正をおこなう。
　processメソッドの中で、NumberForamtExceptionが発生しないように対処をおこなっている。
　
        // SMBA_CHG IE対応（NumberFormatExceptionの回避）
        MouseEvent event = null;

        if( data == null || data.length == 0 )
        {
            event = new MouseEvent(getId(), comp);            //no area, no coord
        }
        else if( data.length == 1 )
        {
            event = new MouseEvent(getId(), comp, data[0]);    //by area
        }
        else
        {
            BigDecimal bdVal1 = new BigDecimal(data[0]);
            BigDecimal bdVal2 = new BigDecimal(data[1]);

            event = new MouseEvent(getId(), comp,            //by coord
                bdVal1.intValue(), bdVal2.intValue(),
                data.length < 3 ? 0: Commands.parseKeys(data[2]));
        }

//        final MouseEvent event =
//        data == null || data.length == 0 ?
//            new MouseEvent(getId(), comp):            //no area, no coord
//        data.length == 1 ?
//            new MouseEvent(getId(), comp, data[0]):    //by area
//            new MouseEvent(getId(), comp,            //by coord
//                Integer.parseInt(data[0]), Integer.parseInt(data[1]),
//                data.length < 3 ? 0: Commands.parseKeys(data[2]));
        // CHG_END
　

　　ちなみに、zk.jarは、通常はjarとして参照していることが多いが、ZK関連のjarもEclipseプロジェクト化しておくと、デバッグができるので便利である。

■メッセージの非表示
　最後に、ログインページで表示されるメッセージを非表示にする。
　IEでログインページにアクセスすると、「一部機能が正常に動作しない可能性がある」という旨のメッセージが表示されてしまう。

　これを表示しないようにしておくには、webuiプロジェクトのWLogin.javaを修正する。
　８１行目あたりでメッセージを表示している部分を削除しておく。
　
        /*
        if (!AEnv.isBrowserSupported())
        {
//            String msg = "You might experience slow performance and user interface anomalies using your current browser to access the application. We recommend the use of Firefox, Google Chrome or Apple Safari.";
            String msg = "You might experience slow performance and user interface anomalies using your current browser to access the application. We recommend the use of Firefox, Google Chrome or Apple Safari."
                + "<BR>現在のブラウザはADempiereの一部機能が正常に動作しない可能性があります。ADempiereのすべての機能を使用するにはFirefoxやGoogle ChromeまたはSafariなどのブラウザをお勧めします。";
            browserWarningWindow = new Window();
            Div div = new Div();
            div.setStyle("background-color:#FFFFCC; font-size: " + (AEnv.getFontSize() - 1) + "pt");
            div.appendChild(new Text(msg));
            browserWarningWindow.appendChild(div);
            browserWarningWindow.setPosition("top,right");
            browserWarningWindow.setWidth("550px");
            browserWarningWindow.setPage(page);
            browserWarningWindow.doOverlapped();
        }
        */

これらの対応をしておけば、ADempiereにInternet Explorerでアクセスしても、正常に動作させることが可能である。

ADempiereのヒープメモリの設定

ADempiereのヒープメモリの設定について、どのくらいが適切なのか

もちろん、潤沢なメモリ環境であれば、できるだけ多く設定しておいたほうが間違いないが
弊社で把握しているヒープメモリの設定状況について記述したい。

まず、ヒープ全体について、特にMRPなどの負荷の高い処理を行う場合は、最低４GB、できれば６GB以上あったほうがベターである。
Javaの起動オプションは以下で指定する。
 -Xms6144M -Xmx6144M

次にヒープメモリの内訳について、

■Permanent領域
まず指定しやすいのは、Permanentメモリサイズである。
これは、クラス定義のような一度メモリ登録すれば書き換わることのないであろうデータを登録する領域である。
ADempiereの場合、クラスが多いので通常のアプリケーションよりもこのサイズは、大きいほうがベターであるが、それでも２５６MBもあれば十分である。これでも、使用率が３０％を超えることはないと考えられる。
Javaの起動オプションは以下で指定する。
　-XX:PermSize=256M -XX:MaxPermSize=256M


■New領域
New領域とは、クラスをNewしたときに格納される領域である。クラスがNewされると、まずはEden領域というところに格納され、YoungGCまたはFullGCによって、Eden領域からSurvivor領域に移動されるか解放される。

このNew領域が小さければ、YoungGCが頻繁に走ってしまい、処理落ちを起こす原因となってしまう。
また、ADempiereの場合、Newされるオブジェクトが多いが、すぐに解放されることが多いので
New領域を多めにとって、Old領域を少なめにしても、よほど下手なプログラムを記述しない限り、FullGCが頻発することは考えにくい。

よって、７割から８割をNew領域に割り当てて問題ないといえる。
この設定でも、ある案件で実運用と同様のオーダー数のMRPを回した後でも、Old領域は１割程度の使用率である。

Javaの起動オプションは以下で指定する。
 -XX:NewSize=4096M -XX:MaxNewSize=4096M


＜Survivor領域＞
Survivor領域とは、Eden領域のうち、GCによって解放されなかったオブジェクトが格納される領域である。
このSurvivor領域とEden領域の割合を起動オプションで設定できるが、これを変えても大きな変化は見られなかった。
理由の推測としては、この割合を変えても、New領域全体が変わるわけではないので、YGCの頻度も変わらないから当然と思われる。
よって、これは、デフォルトでいいと考えられる。

もし、設定する場合、Javaの起動オプションは以下で指定する。
 -XX:SurvivorRatio=2


■Old領域
Old領域は、Survivor領域で、何度も解放されなかったオブジェクトおよび、Survivor領域がいっぱいになったときのオブジェクトが移動される領域である。
この領域がいっぱいになると、FullGCが発生し、何度もいっぱいになると、FullGCが頻発することになるのが、上記でも説明したとおり、ADempiereでは、Old領域に大きなサイズが必要ということにはなりにくいため、ヒープ全体の２割から３割でいいと考えられる。

Javaの起動オプションは特に指定しない。（NewRatioで設定もできるが、全体から、パーマネントとNew領域をひいたサイズとなるため。）


■ヒープ設定例（全体を６GBとしたとき）
 -Xms6144M -Xmx6144M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:NewSize=4096M -XX:MaxNewSize=4096M

　※もう少し、New領域を増やしてもよいが、ちまたのベストプラクティス（New:Old=1:2)と乖離しすぎるので・・・。
　※３２ビットOSでは、２GBまでなので注意。
　※起動オプションのgcInterval指定について不要という人もいるが、個人的にはあったほうがいいと思っている。１時間に１回ぐらいは、FullGCされてもいいかなと思うし、逆にこれをせずにメモリオーバーフローになるほうが怖いと思う。（gcInterval=3600000）

ヒープの状態とGCの実行回数を表示する（備忘録）

ヒープメモリの状態とGCの実行回数を表示するコマンド

jstat -gcutil -h3 <ProcessID> <表示頻度(ms)>


ex.
jstat -gcutil -h3 4716 5000


  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 92.74   0.00  76.22   9.29   7.27    188   23.448     0    0.000   23.448
 92.74   0.00  98.90   9.29   7.27    188   23.448     0    0.000   23.448
  0.00  92.31  23.16   9.29   7.27    189   23.630     0    0.000   23.630

＜各列の説明＞
S0：S0領域の使用率（Young領域）
S1：S1領域の使用率（Young領域）
E ：Eden領域の使用率（Young領域）
O ：Old領域の使用率（Old領域）
P ：Permanent領域の使用率（永続領域）

YGC：YoungGCの発生回数
YGCT：YoungGCの処理時間（秒）
FGC：FullGCの発生回数
FGCT：FullGCの処理時間（秒）
GCT：YoungGCとFullGCの処理時間（秒）


＜ヒープの世代＞
■Young領域
S0,S1,EdenがYoung領域（Newされてからまだ若いヒープ）
Eden: Newがおこなわれるとまずここにたまる。
S0: Edenから少し年をとったヒープ
S1: Edenから少し年をとったヒープ

■Old領域
　Young領域にある間に、解放されることがなかったヒープ。
　Young領域から、Old領域に移動するタイミングは、YoungGCの回数やS0,S1領域が満杯になったときなどGCアルゴリズムによる。

■Permanent領域
　基本的には永続的に保持するメモリ。主にクラス定義など


＜ヒープの容量を表示する＞
上記のオプションの「-gcutil」を「-gc」に変えるだけでよい。

jstat -gc -h3 <ProcessID> <表示頻度(ms)>


ex.
jstat -gc -h3 4716 5000


S0C     Survivor 領域 0 の現在の容量 (KB)
S1C     Survivor 領域 1 の現在の容量 (KB)
S0U     Survivor 領域 0 の使用量 (KB)
S1U     Survivor 領域 1 の使用量 (KB)
EC     Eden 領域の現在の容量 (KB)
EU     Eden 領域の使用量 (KB)
OC     Old 領域の現在の容量 (KB)
OU     Old 領域の使用量 (KB)
PC     Permanent 領域の現在の容量 (KB)
PU     Permanent 領域の使用量 (KB)
YGC     若い世代の GC イベント数
YGCT     若い世代のガベージコレクション時間
FGC     フル GC イベント数
FGCT     フルガベージコレクション時間
GCT     ガベージコレクション総時間

※S0CやS0U、ECやEUの「C」はCapacity、「U」はUsageと思われる。

http://docs.oracle.com/javase/jp/7/technotes/tools/share/jstat.html

ADempiereのMRPの処理速度改善メモ

MRPの処理速度改善のために、いろいろ実装したが、スレッド化がかなり効果的だった。
１スレッドごとに16％程度の処理改善がみられたようだ。
ただし、コア数以上のスレッドでは改善率が極端に下がる。

試験環境は、6コアで、1.16の6乗＝2.4363
実際には、6スレッド以上を起動しているので、2.4倍以上の速さになることを確認。

そこそこの部品構成と需要件数でも、30分で処理が終わるMRPになった。

技術的には、スレッドごとにレコードロックが競合しないように設計すること、こまめにコミットしてレコードロックを長時間保持しないこと、Wait、Notifyを巧みに使用すること、トランザクションのコミット漏れや長時間トランザクション、コネクション数のケア、Postgresのデッドタプル、オートバキューム実行ログのチェックなどがポイントだったように思う。

ADempiere 会計仕訳の勘定科目表（備忘録）

ADempiereでどのタイミングで、どの勘定科目が使われて仕訳が作成されるかが表にまとめられています。
データベースとの対比がよくわかります。

http://www.adempiere.com/ADempiere_Accounting

ZK FrameworkのJavascriptを修正してみる

ZKFrameworkを使えば、開発者はサーバプログラミングを記述するだけで
メンテナンス性の悪いJavaScriptを見る必要はない。
まるで、スタンドアローンアプリケーションを作っているような感覚で
イベント駆動処理をしながら、Webアプリケーションを開発できる。

っていうのが、ZKFrameworkの売り文句のひとつだろうけど
（ひと昔前のASP.Netと同じこと言ってるわけで）
やっぱり、顧客要件によっては、JavaScriptを見なきゃいけない場合も出てくる。

で、いざZKFrameworkのJavaScriptを見ようとすると、複雑怪奇で何のことかさっぱりなんてことになる。
そんなときに、役立つのがChromeの開発者ツール。

 

これがあれば、ZKFrameworkのJavaScriptのデバッグやカスタマイズもだいぶ楽になる。
難読化コードを整形したり、ステップ実行、ウォッチ、コールスタック表示なども普通にしてくれる。
JavaScriptのデバッグも、ついにここまでできるようになったようだ。

ちなみに、今回は顧客要望により、日付をスラッシュなしで入力しても、YYYY/MM/DDに自動変換するように、修正してみた。

ZKのアーキテクチャの基本シーケンス図

ZKのAPIをADempiereで触っているけど、どうもしっくりこない。
何のサーブレットがあって、実際どういう役割を担っているのかとか、
まずは、アーキテクチャのシーケンス図的なものがほしかった。

やっとそれを説明してくれているページを見つけた。
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0802/080101as01/080101as01.html

サーブレットは、zkLoaderとauEngineってのがあって、
zkLoaderがレイアウトを作成し、auEngineがAjaxのEventの入出力口になっているようだ。

Atmosphereって、なんだ？

iDempiereがZKバージョンアップ対応で使用しているAtmosphereというライブラリ。
これは、いったい何なのか？

少し調べてみると、どうやら非同期通信のためのライブラリのようで
特にAjaxでは実現できないサーバ側からのイベント発生、いわゆるサーバからのPUSHをサポートするようだ。

HTTPアーキテクチャの歴史を整理すると、その位置づけはわかりやすく、
現在の2015年は、Ajaxの問題点が顕在化し、新たなアーキテクチャが求められている時期にあるといえるようだ。
Atmosphereも、そんな中、必要とされるであろうライブラリのようだ。

＜HTTPアーキテクチャの歴史概略とAtomosphere＞

①Webウェブページは、かつてページを丸ごと更新するのが主流。
スタンドアローンアプリケーションのように、特定のラベルだけを書き換えるなどの処理が難しく
ボタンを押下すると、ページを丸ごと更新する必要があった。

②2006年ごろからAjaxの流行、ページ上の一部だけを更新することが可能になり
リッチなWebページが増えていった。
Ajaxの技術はもともとJavaScriptに存在したもので新しいものではなかったが、
この時期まで使われることはほとんどなかった。
しかし、ネットワークのスピードが速くなったなどの外部要因とのマッチもあり、この時期から急に使われるようになった。

同時にJavascriptの重要性が増したり、Javascriptコードが複雑化してきたことを機に、jQueryを筆頭にJavaScriptのライブラリが充実していくこととなる。

③Ajaxの問題点が顕在化。新たなアーキテクチャが求められる。
Ajaxを使ったウェブページへのバージョンアップが一段落し、その問題点が顕在化してくる。

中でも、HTTPのコネクションのアーキテクチャ上、サーバからイベント発生ができないため、
たとえば、他のユーザの更新情報などをサーバからクライアントへ直接PUSHすることができず、
その代替として、ブラウザ側からサーバの更新を定期的にチェックするなどのコーディングが必要というのは大きな問題として認識された。（ネットワーク負荷やサーバ負荷の増大）

この問題への解決策として以下のようなアーキテクチャが生まれてきた。

・Cometを利用したWebSocket
とにかく接続をひらきっぱなしのストリーミング状態にして、サーバはこの接続を使ってクライアントへのイベントを発生させる。
接続がひらっきぱなしのため、リソースを非常に使ってしまうという問題がある。
CometというアーキテクチャをWebSocketという標準仕様で定義しようとしたが、
このWebSocketのAPI自体が各WebServerのAPIに依存してしまい、ベンダーロックインを引き起こす可能性があるようだ。


・Atmosphere
上記のような問題を解決するべく、WebSocketなどをベンダーロックインにならないように抽象化したりして
非同期通信のライブラリをまとめている。
具体的なコーディング方法や詳細は、これからまた調べていきたいと思う。

ADempiere WorkFlowのシーケンス図

ADempiereWorkFlowのシーケンス図をまとめてみた。

MWFProcessとMWFActivitityの間で、次のノードをチェックしながら処理が繰り返されているようだ。

もっと大きいのは、以下。

ADempiereのJapserReportでIPAフォントを使う

ADempiereの帳票は、JasperReportを使うことで多様なデザインの帳票を作成することができる。

JasperReportとは、OSSの帳票作成プログラムのことである。
.NetやVBに精通している人であれば、GrapeCity社のActiveReportをご存知かと思うが、それと同じような機能を持っているJava用のしかもオープンソースの帳票処理プログラムである。

このJapserReportをADempiereで使うときに、問題となるのがフォントである。
特にLinuxサーバに実装するとき、マイクロソフト系のフォントが使えないという問題がある。
そこで、IPAフォントを使うというのが解決策となる。

また、ADempiereのEARにIPAフォントを含ませることで、OSにIPAフォントをインストールしたりする手間が省けたり、違うOSにEARを持っていったときにフォントなしエラーが出るなどの問題がなくなる。

ここでは、IPAフォントをEARに含める方法をご紹介する。


■IPAフォントを使う設定（EAR内にIPAフォントを含める）

①クラスパスを通したフォルダに、jasperreports_extension.propertiesを用意して、中身を以下にする

net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasperreports.engine.fonts.SimpleFontExtensionsRegistryFactory
net.sf.jasperreports.extension.simple.font.families.ireport=org/compiere/fonts/fonts_extend.xml

②fonts_extend.xmlを以下のフォルダに作成する。
org/compiere/fonts

中身を以下にして、UTF-8で保存する。

<?xml version="1.0" encoding="UTF-8"?>
<fontFamilies>
   <fontFamily name="IPA Pゴシック">
       <normal>org/compiere/fonts/ipagp.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
   <fontFamily name="IPAゴシック">
       <normal>org/compiere/fonts/ipag.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
   <fontFamily name="IPAexゴシック">
       <normal>org/compiere/fonts/ipaexg.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
   <fontFamily name="IPA P明朝">
       <normal>org/compiere/fonts/ipamp.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
   <fontFamily name="IPA明朝">
       <normal>org/compiere/fonts/ipam.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
   <fontFamily name="IPAex明朝">
       <normal>org/compiere/fonts/ipaexm.ttf</normal>
       <pdfEncoding>Identity-H</pdfEncoding>
       <pdfEmbedded>true</pdfEmbedded>
   </fontFamily>
</fontFamilies>

③②と同じフォルダに、②のxml内で指定したIPAのttfファイルを配置する。


■フォント変更作業（JasperReport内）
Jrxmlのソースを開いて、fontNameとpdfFontNameでIPAフォントを使用するように置換する。fontNameはフォント名、pdfFontNameはjarファイル名（パス不要）を指定。

<font fontName="ＭＳ 明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H"/>
↓↓
<font fontName="IPA明朝" size="16" pdfFontName="HeiseiMin-W3" pdfEncoding="UniJIS-UCS2-HW-H" isPdfEmbedded="true"/>