ダウンロード
Magazine
開発
アカウント
ダウンロード
Magazine
開発
ログイン
アカウント/パスワードを忘れた
アカウント作成
言語
ヘルプ
言語
ヘルプ
×
ログイン
ログイン名
パスワード
×
アカウント/パスワードを忘れた
日本語の翻訳状況
カテゴリ:
ソフトウェア
人物
PersonalForge
Magazine
Wiki
検索
OSDN
>
ソフトウェアを探す
>
オフィス/ビジネス
>
エンタープライズ
>
ビジネスパフォーマンスマネージメント
>
ADempiere ERP Business Suite
>
フォーラム
>
全般
>
データ移行の手法
ADempiere ERP Business Suite
概要
プロジェクト概要
開発ダッシュボード
Webページ
開発メンバー
画像ギャラリー
公開フィード一覧
活動
統計情報
活動履歴
ダウンロード
リリース一覧
統計
ソースコード
コードリポジトリリスト
Subversion
リポジトリ閲覧
チケット
チケット一覧
マイルストーン一覧
チケットの種類一覧
コンポーネント一覧
よく使われるチケット一覧のリスト/RSS
新規チケット登録
文書
コミュニケーション
フォーラム
フォーラム一覧
イベント (229)
Adempiereの使い方 (48)
JasperReports & iReport (18)
Pentaho (8)
全般 (419)
文書管理 (69)
コミュニティ運営 (16)
開発 (47)
雑談、つぶやき (97)
メーリングリスト
MLの一覧
ニュース
フォーラム:
全般
(スレッド #29225)
話題(スレッド)一覧に戻る
RSS
データ移行の手法 (2011-05-03 09:36 by
kpuichi
#57183)
返信
チケットに引用
高橋です。
Adempiereを導入するにあたって、マスターとかレガシーシステムからコンバートすることになるかと思うのですが
コンバートの手順について書いてあるページをご存知ないですか?
Adempiereの機能には`「システム管理」→「データ」→「データインポート」以下のアプリケーションで出来そうなのですが
「インポートフォーマット」にあらかじめ登録されているフォーーマットは会計系のいくつかだけで、GardenWorldが登録
したものが」取引先」「製品」「請求」「受注」などありますがどれも項目が限定されています。
これらのフォーマットに項目を増やすことは可能でしょうか?
あるいはインポートデータフォーマット自体を増やして設定することは可能でしょうか?
ご存知のかた
よろしくお願いします。
メッセージ #57183 への返信
×
題名
本文
メッセージ #57183 への返信 > 高橋です。 > > Adempiereを導入するにあたって、マスターとかレガシーシステムからコンバートすることになるかと思うのですが > コンバートの手順について書いてあるページをご存知ないですか? > Adempiereの機能には`「システム管理」→「データ」→「データインポート」以下のアプリケーションで出来そうなのですが > 「インポートフォーマット」にあらかじめ登録されているフォーーマットは会計系のいくつかだけで、GardenWorldが登録 > したものが」取引先」「製品」「請求」「受注」などありますがどれも項目が限定されています。 > これらのフォーマットに項目を増やすことは可能でしょうか? > あるいはインポートデータフォーマット自体を増やして設定することは可能でしょうか? > > ご存知のかた > よろしくお願いします。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-03 10:51 by
cozy56
#57184)
返信
チケットに引用
データのインポート方法については下記本の11章に示されています。
http://www.amazon.co.jp/Adempiere-Solutions-Bayu-Cahya-Pamungkas/dp/1847197264/ref=sr_1_1?ie=UTF8&qid=1304387498&sr=8-1
#57183
への返信
メッセージ #57184 への返信
×
題名
本文
メッセージ #57184 への返信 > データのインポート方法については下記本の11章に示されています。 > http://www.amazon.co.jp/Adempiere-Solutions-Bayu-Cahya-Pamungkas/dp/1847197264/ref=sr_1_1?ie=UTF8&qid=1304387498&sr=8-1
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-03 10:53 by
cozy56
#57185)
返信
チケットに引用
soap連携によるデータ挿入については下記本の4章に示されています。
http://www.amazon.co.jp/Adempiere-3-6-Cookbook-Ajit-Kumar/dp/1849513384/ref=sr_1_2?ie=UTF8&qid=1304387498&sr=8-2
#57183
への返信
メッセージ #57185 への返信
×
題名
本文
メッセージ #57185 への返信 > soap連携によるデータ挿入については下記本の4章に示されています。 > http://www.amazon.co.jp/Adempiere-3-6-Cookbook-Ajit-Kumar/dp/1849513384/ref=sr_1_2?ie=UTF8&qid=1304387498&sr=8-2
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-06 16:03 by
syatsuzuka
#57235)
返信
チケットに引用
DBがOracle XEであれば、APサーバを介さず、SQL*Loaderを使って直接投入するのが、現実的かもしれませんね。
データ移行ということになると、それなりのデータ容量となることもあるので、パフォーマンス的にもその方がいいと思います。
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19211-01/ldr_concepts.html
SQL*Loaderの制御ファイルには、ある程度コード変換を行うことができますし、場合によっては一度テンポラリテーブルに投入した後、PL/SQLでロジック変換をかける、なんてことが、世の中のOracle系アプリの移行では行われているかと思います。
Oracle E-Businessなんかですと、csvから直接テーブルに取り込む機能があったりしますが。
PostgreSQLにも似た機能があるようですね。
http://lets.postgresql.jp/documents/technical/bulkload
#57183
への返信
メッセージ #57235 への返信
×
題名
本文
メッセージ #57235 への返信 > DBがOracle XEであれば、APサーバを介さず、SQL*Loaderを使って直接投入するのが、現実的かもしれませんね。 > データ移行ということになると、それなりのデータ容量となることもあるので、パフォーマンス的にもその方がいいと思います。 > > http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19211-01/ldr_concepts.html > > SQL*Loaderの制御ファイルには、ある程度コード変換を行うことができますし、場合によっては一度テンポラリテーブルに投入した後、PL/SQLでロジック変換をかける、なんてことが、世の中のOracle系アプリの移行では行われているかと思います。 > Oracle E-Businessなんかですと、csvから直接テーブルに取り込む機能があったりしますが。 > > PostgreSQLにも似た機能があるようですね。 > > http://lets.postgresql.jp/documents/technical/bulkload
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-06 16:33 by
kpuichi
#57237)
返信
チケットに引用
resありがとうございます。
高橋です。
英語の文書はちょっと...
なので自分なりに調べてみました。
現行バージョンのAdempiereが用意しているインポートの口はメニューにあり、これらは「インポートフォーマット」のウィンドウで全て定義できるようです。
とりあえず取引先だけ作ってみました。投入はまだしていません。定義を作るのに結構時間とられます。
SOAPインターフェースはこれらの定義に向かってSOAPメッセージを投げる機能だと推測されます。
SOAPインターフェースを使うとWEBアプリケーションから直接メッセージを投げられますから受注とかの取り込みに便利かもしれませんがなぜかSOAPは日本の技術者に人気がないらしいっぽいですね。
移行の目的というわけではなかったのですがPostgresqlのデータベースを直接ハンドルする方法を調べて見ました。
OOpenoffice.orgのデータベースでJDBC経由でアクセスできそうだったんですが何故か接続できなかったです。
代わりにEclipseのDBViewerプラグインで接続してみました。
こちらは問題なく接続できてテーブルにも直接さわれます。(JDBCだから当たり前っちゃ当たり前か...)
移行作業のようなワンタイムタスクならばこれを利用する手はあると思います。
ただ、ADempiereのテーブル、結構構造が複雑っぽいので直接テーブルをいじると動かなくなる可能性大きそうです。
(openoffice.orgにつなぎたかったのは帳票とかをoffice側に任せたいと思ったのですが...何故接続できないんだろう?)
#57235
への返信
メッセージ #57237 への返信
×
題名
本文
メッセージ #57237 への返信 > resありがとうございます。 > 高橋です。 > > 英語の文書はちょっと... > > なので自分なりに調べてみました。 > 現行バージョンのAdempiereが用意しているインポートの口はメニューにあり、これらは「インポートフォーマット」のウィンドウで全て定義できるようです。 > とりあえず取引先だけ作ってみました。投入はまだしていません。定義を作るのに結構時間とられます。 > SOAPインターフェースはこれらの定義に向かってSOAPメッセージを投げる機能だと推測されます。 > SOAPインターフェースを使うとWEBアプリケーションから直接メッセージを投げられますから受注とかの取り込みに便利かもしれませんがなぜかSOAPは日本の技術者に人気がないらしいっぽいですね。 > > 移行の目的というわけではなかったのですがPostgresqlのデータベースを直接ハンドルする方法を調べて見ました。 > OOpenoffice.orgのデータベースでJDBC経由でアクセスできそうだったんですが何故か接続できなかったです。 > 代わりにEclipseのDBViewerプラグインで接続してみました。 > こちらは問題なく接続できてテーブルにも直接さわれます。(JDBCだから当たり前っちゃ当たり前か...) > 移行作業のようなワンタイムタスクならばこれを利用する手はあると思います。 > ただ、ADempiereのテーブル、結構構造が複雑っぽいので直接テーブルをいじると動かなくなる可能性大きそうです。 > (openoffice.orgにつなぎたかったのは帳票とかをoffice側に任せたいと思ったのですが...何故接続できないんだろう?)
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-08 02:13 by
syatsuzuka
#57257)
返信
チケットに引用
確かに現状の業務システムは、FTPによるファイル転送だったり、といった枯れた技術がいまだに利用されていたりしますよね。
ただ、SOAPも連携データがXML形式ということで、転送データ量の見積もりが難しく、ネットワーク上のデータ転送パフォーマンスを定量的に担保しようと思うと、結構面倒というのも事実だと思います。これからのSOAの時代ではそんなこと言ってられないのかもしれませんが(^_^;。
以前、某ベンダーのWebコンテナ(EnterpriseServiceBus)でSOAP連携にタッチしたことがあるのですが、そのときは、同時に大容量のSOAPメッセージを送信すると、Java VMのヒープメモリがたらなくなってがハングアップする、なんてことがありました。
そこで私が個人的に得た教訓は、「SOAPは、在庫管理だったりとリアルタイム性が要求され、かつ少量のトランザクションデータ連携には向いているが、マスターの洗い替えをするような大量データ連携では、テーブル連携やファイル連携といった、枯れた技術が無難」、ということでした。ということから、大容量データ連携はコンテナ(AP)を経由させず、DB上でやるのがいいのかなー、なんて感じています。少量であればまったく問題ないですが。
OpenOfficeからJDBC接続できると、確かに何かと便利そうですね。
#57237
への返信
メッセージ #57257 への返信
×
題名
本文
メッセージ #57257 への返信 > 確かに現状の業務システムは、FTPによるファイル転送だったり、といった枯れた技術がいまだに利用されていたりしますよね。 > > ただ、SOAPも連携データがXML形式ということで、転送データ量の見積もりが難しく、ネットワーク上のデータ転送パフォーマンスを定量的に担保しようと思うと、結構面倒というのも事実だと思います。これからのSOAの時代ではそんなこと言ってられないのかもしれませんが(^_^;。 > > 以前、某ベンダーのWebコンテナ(EnterpriseServiceBus)でSOAP連携にタッチしたことがあるのですが、そのときは、同時に大容量のSOAPメッセージを送信すると、Java VMのヒープメモリがたらなくなってがハングアップする、なんてことがありました。 > > そこで私が個人的に得た教訓は、「SOAPは、在庫管理だったりとリアルタイム性が要求され、かつ少量のトランザクションデータ連携には向いているが、マスターの洗い替えをするような大量データ連携では、テーブル連携やファイル連携といった、枯れた技術が無難」、ということでした。ということから、大容量データ連携はコンテナ(AP)を経由させず、DB上でやるのがいいのかなー、なんて感じています。少量であればまったく問題ないですが。 > > OpenOfficeからJDBC接続できると、確かに何かと便利そうですね。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: データ移行の手法 (2011-05-07 11:35 by
kpuichi
#57251)
返信
チケットに引用
Postgresqlデータベースへopenoffice.org database から接続できました。
JDBCドライバ経由です。
単純にデータソースURLの記述に誤りがあったようです。
詳しくは
http://nstage.ddo.jp/pukiwiki/index.php?OpenOffice.org%2FBase%2FDB#x06667cc
これでopenoffice.orgと連携できるので簡単な帳票とか作成するのに便利かもしれません。
ただ、openofficeから直接テーブルをメンテナンスするとえらい目にあうかもしれません。
#57183
への返信
メッセージ #57251 への返信
×
題名
本文
メッセージ #57251 への返信 > Postgresqlデータベースへopenoffice.org database から接続できました。 > JDBCドライバ経由です。 > 単純にデータソースURLの記述に誤りがあったようです。 > 詳しくは > http://nstage.ddo.jp/pukiwiki/index.php?OpenOffice.org%2FBase%2FDB#x06667cc > > これでopenoffice.orgと連携できるので簡単な帳票とか作成するのに便利かもしれません。 > ただ、openofficeから直接テーブルをメンテナンスするとえらい目にあうかもしれません。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル