高度なカスタマイズ > サービスおよびインフラストラクチャのカスタマイズ > システム生成 > ビジネスオブジェクトのモデル化 > モデル化されたカスタマイズの公開
  
モデル化されたカスタマイズの公開
このセクションでは、モデル化されたカスタマイズを公開する際のガイドランについて説明します。ここでの "公開" とは、あるシステムから別のシステム (ソースからターゲットなど) にカスタマイズをコピーすることを指します。使用するプロセスは、カスタマイズの実際のソースとターゲットによって異なります。
モデル化されたカスタマイズが構築されると、以下の 3 つの領域でインストールに影響が及びます。
1. 1. <loadpoint>/codebase にある次のファイル内のモデル化された (アノテーション付き) クラスの登録:
modelRegistry.properties
associationRegistry.properties
descendentRegistry.properties
2. コンパイル済みファイルと生成されたファイルの追加:
Java クラス (*.class)
イントロスペクション成果物ファイル (*.ClassInfo.ser)
シリアライズされたバンドルファイル (*.RB.ser)
3. <loadpoint>/db 内のデータベーススクリプトの更新による追加のスキーマ (インデックスを含む) の組み込み
データベースファイル (*.sql)
さらに、たとえばサービスを登録するために site.xconf にエントリが追加されている可能性があります。
どちらのアプローチでも、以下の操作を行う必要があります。
1. カスタマイズによって加えられた変更 (上記のファイル) を送信先システムにコピーします。
2. テーブルとインデックスを作成するために必要な SQL スクリプトを呼び出すことによって、スキーマをインストールします。
3. 送信先システムの site.xconf を補足して、カスタマイズの変更を組み込みます (および xconfmanager を実行します)。
4. 送信先システムを再起動します。
開発システムから本番システムへのモデル化されたカスタマイズの公開
一般的なシナリオの 1 つとして、ソースが開発システムでターゲットが本番システムである環境があります。このシナリオでは、公開プロセスを簡略化する前提を設けることができます。最も重要な点として、開発システムと本番システムは基本的にクローンであることを前提としています。
このセクションでは、カスタマイズが開発されるソースを "開発システム" と呼びます。"本番システム" とは、顧客が現在その生産業務に使用している送信先システムか、新規の公開、マイグレーション、アップグレードの一環として開発されている新しい本番システムを指します。環境によっては、テストシステムやステージング (運用前) システムなど、保守が必要なその他のシステムも含まれることがあります。以下で説明する、カスタマイズを本番システムに公開するためのステップはすべて、同じ前提に当てはまるかぎり、その他のシステムにも適用されます。
このシナリオでは、開発システムと本番システムはクローンであり、開発システムに対して変更を加える際に、これらの変更を本番システムにコピーできることを前提としています。このため、本番システムと開発システムが同じ基本状態を共有している (同じ製品がインストールされ、同じパッチであり、同じリリースレベルである) ことが重要です。そうでなければ、クラスに互換性がなかったり、レジストリファイルに不要なエントリが含まれていたり (または重要なエントリがなかったり)、データベーススキーマが不適切であったりします。
これらの前提に当てはまる場合、以降のステップのガイドラインに従うことができます。
1. カスタマイズによって加えられた変更 (上記のファイル) を本番システムにコピーします。
2. カスタマイズによって加えられた変更を本番システムにコピーします。
a. C:\temp\original_registry_files のカスタマイズを開始する前に、次のレジストリファイルをコピーします。
associationRegistry.properties
descendentRegistry.properties
modelRegistry.properties
moduleRegistry.properties
b. モデリングされた新しいオブジェクトを作成します。詳細については、新しいドキュメントサブクラスのモデル化を参照してください。
c. d:\Windchill\temp\_model_registry の内部に追加または削除する結合ファイルを作成するには、Windchill シェルで次のコマンドを実行します。
ant -f bin/tools.xml registry_diff -Dregistry_diff.basedir=C:\temp\original_registry_files -Dregistry_diff.modsdir=D:\windchill\codebase -Dregistry_diff.diffdir=d:\Windchill\temp\_model_registry
d. _model_registry フォルダを新しい Windchill ターゲットシステムにコピーして d:\Windchill\temp に貼り付けます。
e. 新しいターゲットシステムの Windchill シェルで次のコマンドを実行します。
ant -f bin/tools.xml registry_merge -Dregistry_merge.adds=D:\Windchill\temp\_model_registry\reg_adds -Dregistry_merge.removes=D:\Windchill\temp\_model_registry\reg_removes
3. テーブルとインデックスを作成するために必要な SQL スクリプトを呼び出すことによって、スキーマをインストールします。
4. 本番システムの site.xconf を補足して、カスタマイズの変更を組み込みます (および xconfmanager を実行します)。
5. 本番システムを再起動します。
別のアプローチによるモデル化されたカスタマイズの公開
ソースからターゲットにカスタマイズを公開するには、ソース環境で行った操作を送信先システムでも実行する必要があります。1 つのアプローチとして、単純にソースをコピーし、送信先システムで再構築する方法があります。ただし、このアプローチでは送信先システムでのコンパイルが必要となりますが、送信先システムが本番システムである場合、コンパイルはおそらく許可されません。
もう 1 つのアプローチとして、Git や Subversion などのバージョン制御システムを使用する方法があります。このアプローチでは、ロードポイント全体をバージョン制御の対象にして、バージョン制御システムによってカスタマイズによるインストールへの影響をユーザーに通知し、変更内容をマージします。
モデル化されたカスタマイズのマージ
送信先システムに、公開するソースシステムにないカスタマイズが含まれている場合、送信先システム内のレジストリファイルにマージ可能な差分レジストリファイルを作成する必要があります。registry_diff ターゲットをソースシステムファイルに対して実行することで、registry_merge ターゲットを使用して送信先システムにマージする差分ファイルを生成できます。
registry_diff ターゲットは、以下で説明する必要なフォルダへのアクセス権があるかぎり、いずれかのシステムの Windchill シェルから実行できます。
ant -f <loadpoint>/bin/tools.xml registry_diff -Dregistry_diff.basedir=/wt_dev/base
-Dregistry_diff.modsdir=/wt_dev/codebase -Dregistry_diff.diffdir=/wt_dev/diff
registry_diff.basedir - カスタマイズを開発する前の、オリジナルのレジストリファイルが含まれているフォルダ。
カスタマイズを行う前のレジストリファイルの元の状態を維持しておくのが理想的です。そうでない場合、オリジナルのレジストリファイルにアクセスするためには、カスタマイズしたクラスを登録解除し、レジストリファイルをベースとして残してから、カスタマイズを再構築する必要があります。たとえば、プレフィックス "ext." で始まるカスタマイズしたクラスを登録解除するには、次の操作を行います。
"ext." で始まるか "=ext." を含む行を除去します。
ant -f <loadpoint>/bin/tools.xml model_uninstall
-Dmodel_uninstall.filter="\Aext\.|=ext\."
注記: "ext." で始まるすべてのキーと値がこれに合致します。
その他の使用例を表示するには、ant -f <loadpoint>/bin/tools.xml model_uninstall.help を実行します。
registry_diff.modsdir は開発レジストリファイル (開発コードベース) が含まれているフォルダです。これはカスタマイズが登録されているバージョンのレジストリファイルです。
registry_diff.diffdirbasedirmodsdir の間の差分が出力されるフォルダです。このディレクトリ内に reg_addsreg_removes の 2 つのフォルダが作成されます。この 2 つのフォルダは、以下で説明するように、送信先システムに対する registry_merge コマンドによって使用されます。
registry_merge ターゲットは送信先システムの Windchill シェルから実行する必要があり、registry_diff ターゲットによって生成されたファイルにアクセス可能である必要があります。
ant -f <loadpoint>/bin/tools.xml registry_merge
-Dregistry_merge.adds=/wt_dev/diff/reg_adds
-Dregistry_merge.removes=/wt_dev/diff/reg_removes
registry_merge.adds は、送信先システムに追加されるカスタマイズエントリを含むフォルダです。
registry_merge.removes は、送信先システムから除去されるカスタマイズエントリを含む (オプションの) フォルダです。