ラベル PostgreSQL の投稿を表示しています。 すべての投稿を表示
ラベル PostgreSQL の投稿を表示しています。 すべての投稿を表示

2015年2月16日月曜日

iDempiere 2.1 ダウンロード& 新DB作成

まず iDempiere 2.1をダウンロードします。

クライアント側でダウンロードしてからサーバーにアップロードするのは面倒なので、サーバーで直接インターネットからダウンロードしてしまいます。(本番環境では??ですが、検証なので楽してしまいます)

一応簡単に私のやり方を残しておきます。
1:AWS上 の CentOSを起動
2:クライアント(Windows)から PuTTY をトンネルして VCNでサーバーに接続
3:サーバーで Firefox から インターネットで SourceForge を開く
4:SourceForgeからidempiereServer.gtk.linux.x86_64.zipをダウンロード




次はサーバー内の所定の位置へ展開ですが、その前に前回(2.0)インストール時の後始末から、、、
以前/usr/local/bin/idempiere 直下に zipファイルを置き、ここで展開するという変なことをしていたので、旧zipファイルは 2.0 にしまっといて、、、

# cd /usr/local/bin/idempiere
# ls
2.0
idempiereServer.gtk.linux.x86_64.zip
# mv idempiereServer.gtk.linux.x86_64 2.0
今回は 2.1ディレクトリを作成してからここに格納することにします。

# pwd
# /usr/local/bin/idempiere
# mkdir 2.1
# cd 2.1
# mv /home/maginger/Downloads/idempiereServer.gtk.linux.x86_64 .
# unzip idempiereServer.gtk.linux.x86_64
展開ログ省略
# ls
idempiereServer.gtk.linux.x86_64       <---展開されたディレクトリ
idempiereServer.gtk.linux.x86_64.zip

このまま 2.0のデータスキーマに接続できるか試したい衝動に駆られますが、何が起きるかわからないので、ここはグッとこらえてPostgreSQLのスキーマー作りに移ります。

iDempiere2.0 のデータベース(DB名 idempiere) を残したまま 新たなデータベースを追加します。(DB名 idempiere2.0)


# su - postgres
-bash-4.1$ createdb --template=template0 -E UNICODE -O adempiere -U adempiere idempiere2.1
-bash-4.1$ psql
psql (9.3.5)
Type "help" for help.
postgres=# \l
                                    List of databases
     Name     |   Owner   | Encoding |   Collate   |    Ctype    |   Access priv
ileges   
--------------+-----------+----------+-------------+-------------+--------------
---------
 idempiere    | adempiere | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 idempiere2.0 | adempiere | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 postgres     | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 template0    | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres  
 template1    | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres  
(5 rows)

新しいDBは作成できましたが、現時点当然中身は何もありません。最近入れたpgadminで見てみます。




これまで使っていた DB idempiere (赤枠)にはテーブル始め様々なオブジェクトが存在しています。
これに今回追加した DB idempiere2.1 (青枠)はすかすかであることがわかります。


次はDB idempiere2.1(青枠に idempiere2.1 のスキーマをロードしてみます。)
とおもったら、ちょっと失敗発見。

さきほど/usr/local/bin/idempiere/2.1 で dempiereServer.gtk.linux.x86_64.zip を展開したものだから idempiere-server ディレクトリ構成が想定とずれていました。

誤り:/usr/local/bin/idempiere/2.1/dempiereServer.gtk.linux.x86_64/idempiere-server
というわけで余計なディレクトリは省きます。
想定:/usr/local/bin/idempiere/2.1/idempiere-server
修正しておきます。

修正後、idempiere のダンプファイルを生成します。



# pwd
/usr/local/bin/idempiere/2.1/idempiere-server
# jar xvf data/seed/Adempiere_pg.jar
ここから処理にちと時間がかかり、処理の途中でターミナル接続しているとセッションが切れてしまうため、VNCで接続している環境で処理を流します。

# psql -d idempiere -U adempiere -f Adempiere_pg.dmp


と前回の経験を活かして工夫したつもりでしたが、あっという間に終わりました。
これはAWS インスタンスを拡張したからだと思われます。

で、ダンプファイル展開後のスキーマを再度確認してみます。


pdadmin で見てみると、 idempiere2.1 にもテーブル等生成されていることがわかります。
ちなみにテーブル数は idempiere2.0 は 816、 idempiere2.1 は840 と増えていることがわかります。

ここまではだいたい予想通り、次はidempiere2.1の初期設定&起動をやってみます。
何がおこることやら。。


2015年2月4日水曜日

iDempiere:遅ればせながら pgAdmin 設定してみた


これまで iDempiereのデータベースを見るのに直接SQLを叩いていたわけですが、、やはり決して効率が良いとは言えませんでした。

ちょいと内部コードを調べるくらいは苦になりませんでしたが、まずテーブル名確認してから、コラム名調べて、ものによってクライアントや諸条件を WHERE したりするとそれなりに時間を消費するわけで、、

むか〜し、 ORACLE使った時シェアウェアで GUIのDB操作ツールを利用したので、その良さは知っておりました。(もっともっと昔はそんな良い物もなくSQLを打つしかなかったので、驚きました。。)
最近iDempiereの内部コードを確認する機会も増えたこともあり、とうとう PostgreSQLの Adminツールインストールしてみました。

MAC版のもあるのですが、今回 Windows の Putty の SSL を利用するため、王道の WIndows版です。

pgAdmin でググります。(http://www.pgadmin.org   とか)
いろいろなバージョンがありますが、このブログでは PostgreSQL は 9.3 を使っているので pgAdmin v1.18.0 released を選択することにします。
Windows 版を選択し、、、、
------------------
ウィンドゥ右の広告エリアに 050plus の広告が出ていますが、この作業の直前奥さんから「050 plus」ってなに?と質問されてググったので表示されています。どうでもいいことですが、、、
------------------

 と、ここまできて、また選択する バージョンを聞いてきます。。
が、 v1.18.0がありません。。。
ま、 v.1.18.1 でいいか。。。(今のところ不具合ありませんが、ちと気持ち悪いです)
 ダウンロード画面になりますので、 pgadmin3-1.18.1.zip を選択します。
あとはお約束のインストーラー
指示に従い進みます。










 インストールが完了すると起動できます。(当たり前ですが、、)
当然この時点ではまだ接続出来ないので、接続設定を開始します。


ここから pgAdmin ではなく、Putty の設定画面です。
「AWS EC2 CentOS に SSH経由で VNC 接続してみる」にて設定した TuTTY の VNC用トンネルに pgAdmin 用トンネルを追加します。

Source Port はなんでもいいので 9002としました。
Destination は pgAdmin 用の 5432を指定します。指定後 Addボタンを押します。

以前も書きましたが、ここであわてて Openボタンを押してはいけません。
一度戻って Save します。その後 Openを押します。(そうしないと設定が記憶されず何度も作業をし直すことになります。)



で、 PuTTYでAWSに接続します。(ターミナルでパスワードも入力し、接続を完了します。)

接続後pgAdmin 側の設定に戻ります。
ファイル -> 新しいサーバーの追加
にて接続するDBを指定します。

ホストは localhost、
Port は先ほど指定したポート番号です。



接続するといきなり サーバー上の postgreSQLのインスタンスが見えます。

あまりにあっけなくて、ちょっと拍子抜けしましたが、、、気を取り直して、、

ためしに サーバー -> iDempiere -> データベース -> iDempiere -> スキーマ -> adempiere -> テーブル
を見てみましょう。

見たいテーブルを選択します。
選択後、表の様に見えるアイコンをクリックすると、そのテーブルの内容がポップアップで表示されます。

ちなみに一度開いてから特定の値で絞り込みたい場合(特定クライアントのデータのみ表示したい時など)、そのデータをクリックしたあと、右クリックをするとメニューダイアログが表示されます。ここで選択フィルターを指定すると、その値が含まれる行のみ抽出してくれます。( MS-Access などの  GUI DBツールを使ったことのある方にはおなじみの機能)



細かい使い方はこれから見てみますが、結構直感的に活用できると思います。

しかし、こんなものまでフリーで使えるなんて、すごい世の中ですね。

2015年1月5日月曜日

iDempiere アプリケーション辞書 画面のカスタマイズ(Default Logic)

Windows, Tab & Field の画面エディタの機能をいじってみようと思っていたのですが、気になることがあったので、もちっとフィールド設定いじります。

前回は iDempiere Application Dictionary (アプリケーション辞書)から必須項目の設定をしてみました。

Requisition / Requisition Line の Product を必須項目に変えたのですが、も1つ気になっていたことが、、、

Requisition の Document Type です。
必須項目であることは良いのですが、選択肢が Purchase Requisition の一択。それならデフォルトとしてセットしてくれていればいいのに。。

もしかしたら条件によって別の選択肢が「出現」するかもしれないので、これが正解かは断言できないのですが、デフォルト値のセット方法のお勉強としてやってみようと思います。

まず初期状態の確認。
営業の西島さんでログオンし、
Requisition 画面を開き、新規作成します。



Document Type と Data Required が赤字で必須となっているのがわかります。
この Document Type は Purchase Requisition しか選択肢がありません。

選択すれば良いだけなので、あえて設定を埋め込むほど重要な箇所とは思えませんが、、、、、、(ユーザーの中にはこういうわかりやすいところに異常に固執する人もいますしね。)

設定は System ユーザーで行いますので、ログオンし直します。

前回の Window, Tab & Field 画面で

Requisition / Requisition /Document Type と進みます。

下はWindow, Tab & Fieldで Requisition を選択したところ
 子タブの Requisition に移動したところ
子タブの Document Type フィールドの属性を表示させたところ
 下の方にスクロールしていくと、 Default Logic というフィールドがあります。
(はじめは空白)
 ここに次の文を埋め込みます。

@SQL=SELECT c_doctype_id FROM c_doctype WHERE ad_client_id = @#AD_Client_ID@ AND name = 'Purchase Requisition';

一度ログアウトして、営業ユーザーでログオン、 Requisition画面を表示して新規作成すると今度ははじめから Document Type に Purchase Requisition が設定されているのが確認出来ました。




ここから先は苦労話(&たどり着くまでの道のり)なので、興味の無い方は読み飛ばしてください。

はじめ、超安直に Document Type の Default Logic には リテラルとして 'Purchase Order' という文字列を入力して試してみました。
Requisition 画面で確認しても Document Type は空白のまま。

あたりまえですが、Requisition 画面の Document Type は表示上  Purchase Requisition と見えているだけで、内部的には Document コードを持っていることが予想されます。

Column  フィールドを見てもC_DocType_ID_Document Type と設定されています。

DBをのぞいてみると、テーブル名にそれっぽいものが、

テーブル:C_DocType
項目名を確認指定見ると、ありました、C_DocType_ID、きっとこれに違いない。
(本当はきちんとマニュアルなり定義書を調べるべきですが、、、)

SQLでC_DocType_IDを表示してみると、なんと複数のC_DocType_IDが表示されます。
よくよくC_DocTypeを見てみると、 Client ごとに異なるC_DocType_IDを持っていました。
ま、そりゃそうか。。

私の環境ではC_DocType_IDは4レコード(クライアントが4つ)存在したので、ためしに1つ試したところ、思い通りの結果となりました。(他のID はNG)

これで最終的に Default Logicにセットすべきものは、実行しているクライアントのC_DocType_IDであることは確認できました。

次はどうやって動的にC_DocType_IDを取り出すかです。

iDempiere画面横に Tool Tip があり、ここにガイドがあります。

文字列は '(シングルクオート)で囲む
変数は @ (アットマーク)で囲む
ログイン情報は # (シャープ)で始まる
SQLコードは @SQL= から始まる

今必要なのはこの程度でしょうか?

これらの情報から必要な式を作ります。

@SQL=SELECT c_doctype_id FROM c_doctype WHERE ad_client_id = @#AD_Client_ID@ AND name = 'Purchase Requisition';

これで Purchase Requisition の Document Type フィールドの Default Logic に c_doctype_id の中身が渡されます。
(繰り返しになりますが、何かしらの他の条件が存在する可能性があります。ここでは「こうすればうまくいった」程度の示唆であることご理解ください。)

ちなみに私は #AD_Client_ID を取り出すのに苦労をしました。@で囲むんですね。
わかってしまえば簡単なのですけど、、


次こそ WYSIWYGかな?

2014年12月8日月曜日

ちょっと脱線して iDempiere のDB(PostgreSQL) を直接変更してみました

今日はちょっと脱線。

以前営業の西島さんが作成した Requisiton (購買依頼)から Purchase Order を作成したとき、ワークフロー的な機能はなんだろう?と思い、思いつきで "Request" を作成してみました。

いろいろ入力してみたものの、よく分からず今回は断念しました(というわけでワークフロー的には「声をかける」という原始的なプロセスを設定)。

まぁ、そまでは良いのですが、 Request を中途半端な状態のまま残してしまって消せなくなってしまいました。

 メッセージを見ると、消そうとしてテーブル  "r_request" のレコードは他のテーブル "r_requestaction" から参照されているので、消せないとか。。

r_requestaction のテーブルをどうやって消すのかわからないし、、、ぢゃテーブル直接いじっちゃいますか。。。。(やっていいかは解らないので人様には勧めませんが、今後DBを直接いじることも出てくると思いますので予行演習ということで、、)

まずssh でサーバーへ接続。
PC から Putty 使っても、VNCでデスクトップ開いてもいいのですが、私はMAC のターミナル使ってサーバーにアクセスしました。
(必要であればそれぞれ以前の記事のリンクを参照ください。)

MacのターミナルでAWSのサーバーにログインします。

# su - postgres
[root@ip ~]# su - postgres
-bash-4.1$ 
-bash-4.1$ psql -d idempiere -U adempiere
psql (9.3.5)
Type "help" for help.


---------------------------------------------
テーブル群を見てみます。
テーブル:r_request と r_requestaction がありました。
---------------------------------------------

idempiere=# \d
                       List of relations
  Schema   |             Name              | Type  |   Owner   
-----------+-------------------------------+-------+-----------
 adempiere | a_asset                       | table | adempiere
 adempiere | a_asset_acct                  | table | adempiere
-----省略------
adempiere | r_request                     | table | adempiere
adempiere | r_request_v                   | view  | adempiere

adempiere | r_requestaction               | table | adempiere
----省略------

idempiere=#           

---------------------------------------------
テーブル:r_request のrequest IDを見てみます。
エラーメッセージの中に示されていた 1000004があります。
これの参照元をさがします。
---------------------------------------------
                            
select r_request_id from r_request;
r_request_id 
--------------
             100
      1000001
      1000002
      1000003
      1000004
(5 rows)

---------------------------------------------
テーブル:r_requestaction の request_IDを見てみます。
エラーメッセージの中に示されていた 1000004があります。
---------------------------------------------

idempiere=#  
select r_request_id from r_requestaction;
 r_request_id 
--------------
            100
            100
     1000004
(3 rows)

---------------------------------------------
(良いか悪いか不明ですが、、)消しちゃいましょう。
---------------------------------------------

idempiere=# delete from r_requestaction where r_request_id = '1000004';

DELETE 1

iDempiere の画面に戻って、 Request を削除してみます。

今度はすんなりと消すことができました。

ちなみに Postgresql にてテーブルを探すときは
¥d ですが、
¥d の後ろにテーブル名を付けると、そのテーブルが持つ項目名が出力されます。
(あれば)マニュアルを読むのが理想ですが、解らなければ項目名を確認したりデータそのものを出力させるなどすればデータに対する理解が進みます。
(DBの世界では「今見えているもの」だけで項目の定義を判断するのはとっても危険なのですが、それを理解した上で手っ取り早く外観を知るには結構使う手です。)

今までの流れからは脱線しましたが、DBを直接見たりいじったりする必要は出てくると思いますので、予行演習がてら試してみました。
(外部からSQLなどでデータに手を付けると iDempiereが担保している整合性を壊す可能性があるため、本来は十分な理解の上行うべきです。)


脱線ついでに以前ログインパスワードの暗号化のところで気になったテーブルを見てみました。
現時点はパスワードが平文であることがわかります。
今度暗号化を指定してもう一度テーブルを確認してみたいと思います。

idempiere=# select ad_user_id, name, password from ad_user;
 ad_user_id |            name            |   password    
------------+----------------------------+---------------
        102 | GardenUser                 | GardenUser
        103 | Joe Sales                  | 
        104 | Carl Boss                  | 
        101 | GardenAdmin                | GardenAdmin
      50001 | WebService                 | WebService
        100 | SuperUser                  | System
    1000006 | clientUser                 | clientUser
    1000005 | clientAdmin                | clientAdmin
          0 | System                     | System
    1000020 | TaroSasaki                 | taro
    1000030 | hamadaj                    | hamadaj
    1000027 | NishijimaO                 | nishijimao
    1000028 | UedaE                      | uedae
    1000029 | takadas                    | takadas





2014年9月22日月曜日

iDempiere 日本語化してみた

1:AWS にて CentOS上に iDempiereの環境を構築、ブラウザからiDempiereを使えるようにした。
2:英語が表示だと読まなくちゃいけないので、直感的にわからないので日本語表示に設定変更してみた

---------------------------------------------
後日記:いろいろググってみるとどうやら私のやりかたでは中途半端な日本語化のようでした。スミマセン
こちらの情報では画面項目も日本語化されています。
http://www.compiere-distribution-lab.net/2013/11/10/idempiere-lab-日本語の翻訳ファイルの適用方法/

私自身は極力英語項目に慣れるため英語環境で検証をしていますが、日本語化の方法をもう一度見直そうと考えています。

後日記2
ようやく日本語化再チャレンジしました。
「iDempiere 日本語化ふたたび (iDempiere Lab版)」
リンク貼ってあるだけなので、参照いただく必要はないと思いますが、、一応。
---------------------------------------------



実は今後を考えると英語表示のままの方が都合が良いと思うのですが、いまはまだ試行段階なので、直感的にいじれるように日本語表示にしたいと思います。

まずはログオンします。
 User: Superuser
Password: System

当然ですが、この段階ではLanguage で日本語を選択できません。(表示されない)


次にClient: System を選択します。




iDempiere画面より Menu -> System Admin -> General Rules -> System Rules -> Language を選択



標準では言語が Arabic (Algeria) となっていますので、虫眼鏡アイコンで言語検索アログを出します。


Language が ja_JPであることを確認して OK(チェック)ボタンを押します。



基本的な設定が表示されます。追加で "System Language"、"Login Locale" にチェックを入れ、Data Pattern は "yyyy/MM/dd" にします。
(このあたりは会社内での標準的な記述に合わせるのが吉です。混在していると結構混乱します。ちなみに yyyy と dd は小文字、 MM は大文字です。小文字の mm は時間:分:秒の分を表します。だった気が。。。)

設定したらセーブアイコン(フロッピーの形)を押して保存します。




続いて Translationファイルのインポートです。

iDempiere画面より Menu -> System Admin -> General Rules -> System Rules -> Translation Import/Export を選択します。



Client : System・Language: Japanese(japan)を選択して、 Importボタンを押します。





Translationファイルの格納場所を指定します。すでにインストールフォルダが選択されているので、 dataフォルダを選択します。



言語は ja_JPを選択



あとはOKボタンを押します。



しばし処理に時間かかりますが終了後はログアウトし、ログインしなおします。
このときLanguageで日本語を選択ができる様になっているはずです。



これはユーザーが 側の画面ですが、日本語で表示されます。







お疲れ様でした。

これでちっと画面わかりやすくなったかな?




参考:http://e076.dgblog.dreamgate.gr.jp/e105389.html

AWS CentOS iDempiere Webui iptables なんとかすべての問題をクリアして接続成功!

これまでの流れ:
1:急にiDempiere に興味を持った。
2:iDmpiere を使うためにAWS(Amazon Web Services) アカウントを作成することにした。
3:AWS にEC2 インスタンスを作成し、 CentOS をセットアップすることにした。
4: SSHの設定をして外部からアクセスできる様にしてみた。
5:コマンドラインでは使いにくいのでデスクトップ環境を作ってみた。
6-1:iDempiere に必要なDB (PostgreSQL8.4)をインストールしてみた。が失敗した。
6-2:PostgreSQL9.3をインストールしてみたがまた失敗した。
6-3:EC2でCentOS6.5のインスタンス作成からPostgreSQL9.3のインストールまで完了した。
7:JDKをインストールする。
8:iDempiere で使用するデータスキーマを PostgreSQL へロードした。
9:iDempiere をセットアップした。
10:iDempiere へ Web クライアントからの接続してみた。が、失敗。。。
11:AWS のインスタンスをアップグレードしたら VNC上から http://localhost:8080/webui で接続できた。


もう設定のゴール寸前。あとはすんなりと外部のクライアントPCからWebuiで接続できるはずだ。。。。はずなんだけど。。

WindowsやMacのブラウザから http://<Public DNA>:8080/webui で接続しようとしてもまったく受け付けない。
VNC上からhttp://<Public DNA>:8080/webui としてももちろん駄目、http://localhost:8080/webui では接続出来るのに。。。

AWS の Security group では all trafficを anywhere 接続可能にしても駄目。
Ping は通る。なぜ?

ちなみに AWS Security Group にて Custom ICMP rule にてEcho reply を anywhere にしても何故か外部からの Ping を受け付けない。 All traffic を anywhere にすると通る。
今ひとつ納得できない。
それはともかくAll traffic を anywhere スルーにしているのに iDempiere の Webuiが外部から接続できないのは困った。
動作としてはどう見ても Firewall ではじかれている様に見えるのだが、、

これはかなり悩んだ。
あちこちググると、 AWS の CentOS AMI のFirewall はデフォルトで活きているとのこと。
つまり AWS の Security Group とかぶっているようだ。

Firewallの機能は AWS の Security Groupに集中させた方が良いと思い、CentOS側の iptables は停止する。



# /etc/rc.d/init.d/iptables stop

これでクライアントからブラウザで接続してみる。



接続成功!

余談ですが、 SELinux もデフォルトで動作しています。設定で何か問題が起きたらSELinuxのセキュリティ設定も確認しましょう。

しかし、 AWS の Security Group と CentOS の iptables が2重になっているとは。。。とんだ罠だ。

あと、再起動時に iptables が立ち上がらないようおまじない。

# chkconfig iptables off

いや、ながかった。

お疲れ様でした。

2014年9月17日水曜日

iDempiere のデータスキーマを PostgreSQL へロードする

これまでの流れ:
1:急にiDempiere に興味を持った。
2:iDmpiere を使うためにAWS(Amazon Web Services) アカウントを作成することにした。
3:AWS にEC2 インスタンスを作成し、 CentOS をセットアップすることにした。
4: SSHの設定をして外部からアクセスできる様にしてみた。
5:コマンドラインでは使いにくいのでデスクトップ環境を作ってみた。
6-1:iDempiere に必要なDB (PostgreSQL8.4)をインストールしてみた。が失敗した。
6-2:PostgreSQL9.3をインストールしてみたがまた失敗した。
6-3:EC2でCentOS6.5のインスタンス作成からPostgreSQL9.3のインストールまで完了した。
7:JDKをインストールする。

いよいよiDempiere のインストールに近づいてきました。
その前にiDempiere で使用するデータスキーマを PostgreSQL へロードします。

先ずは本体のダウンロード
VNC でデスクトップを起動し、Firefox(インターネットブラウザ)で idempiere download 等で検索するとページが出てきます。
iDempiere server を選ぶのですが、2014年9月時点ではバージョンが、Daily V2.0 (Stable) と V2.0 (alpha) とあります。
ここではDaily V2.0 (Stable)を選択しました。





ファイルをセーブして良いかの確認がでますので、もちろん Save File。
ダウンロードされる場所は、ホームディレクトリのダウンロードフォルダです。

私の場合は
/home/maginger/Downloads 以下にzipファイルが作成されます。



ちなみに Open with Archive Manager (default) を選択した場合、解凍の上 /tmp にフォルダが作成されます。
お好きな方で、

zipファイルを展開するために unzip するのですが、CentOS に標準で入っていなかったため、yum でインストールします。
# yum -y install unizp
iDempiere をインストールするフォルダは /usr/local/bin 以下にしました。

最終的には次のフォルダになります。
/usr/local/bin/idempiere/2.0/idenpiere-server

以下よりもスマートなやり方はあると思いますが、ステップバイステップで、、

# cd /usr/local/bin
# mkdir idempiere
# cd idempiere
# pwd /usr/local/bin/idempiere
# mv /home/maginger/Downloads/idempiereServer.gtk.linux.x86_64.zip ./
# ls idempiereServer.gtk.linux.x86_64.zip
# unzip idempiereServer.gtk.linux.x86_64.zip
展開ログ省略
# ls 
idempiereServer.gtk.linux.x86_64 idempiereServer.gtk.linux.x86_64.zip
# mv idempiereServer.gtk.linux.x86_64 2.0
# ls
2.0 idempiereServer.gtk.linux.x86_64.zip
# cd 2.0
# ls
idenpiere-server
# cd idenpiere-server
次にiDempiere に必要なテーブル定義を PostgreSQL に展開するために ダンプファイルを生成します。



# pwd
/usr/local/bin/idempiere/2.0/idempiere-server
# jar xvf data/seed/Adempiere_pg.jar
 inflated: Adempiere_pg.dmp
ここで生成したダンプファイルをPostgreSQLにロードするのですが、なぜか私の環境ではWindows の SSH(PuTTY)が一定時間毎に接続が切れるため、時間のかかるダンプは途中で停止してしまいました。
このため、次の作業は VNC のデスクトップ上の端末で実行しました。

# psql -d idempiere -U adempiere -f Adempiere_pg.dmp
SSHは接続が切れると子プロセスまで停止してしまいますが、VNC は接続が切れても子プロセスは生き続けるため、不安定な環境では利用できます。

次こそ iDempiere 本体か?

2014年9月16日火曜日

Open JDK1.7.0 をインストールする。 EC2インスタンスを削除してみる。

これまでの流れ:
1:急にiDempiere に興味を持った。
2:iDmpiere を使うためにAWS(Amazon Web Services) アカウントを作成することにした。
3:AWS にEC2 インスタンスを作成し、 CentOS をセットアップすることにした。
4: SSHの設定をして外部からアクセスできる様にしてみた。
5:コマンドラインでは使いにくいのでデスクトップ環境を作ってみた。
6-1:iDempiere に必要なDB (PostgreSQL8.4)をインストールしてみた。が失敗した。
6-2:PostgreSQL9.3をインストールしてみたがまた失敗した。
6-3:EC2でCentOS6.5のインスタンス作成からPostgreSQL9.3のインストールまで完了した。

iDempiereは JDK を必要とする。ここはCentOS6.5にプリセット(?)されている JDK1.7.0で行けそうなので、そのままyum する。


# yum -y install java-1.7.0-openjdk*

ちょっと時間が半端になったので、iDempiere のインストールはお預け。いらなくなった EC2インスタンスを削除してお茶を濁しておく



EC2 -> Instance -> インスタンス選択して -> Action -> Terminate
で、ステータスが terminated となる。

このままほっとくと1,2日で消えるらしい。
あ、消えた。
terminateしてから1時間ほどで消えました。