12 9 JITパッケージ アップグレードのカスタマイズ

LANSA

12.9 JITパッケージ・アップグレードのカスタマイズ

JITパッケージ・アップグレードをカスタマイズしたい理由は何でしょうか。

  • コマンドライン・パラメータをMSIに提供し、例えばサイレント・インストールまたはパラメータのログといった動作を変更する。
  • ユーザーによってアップグレード・パスを変える。パッチを受け取るユーザーもいれば、受け取らないユーザーもいます。
  • 自分のしたいことにあわせて自分のSETUP.EXEを提供する。

SETUP.EXEは実行ディレクトリ内のLANSA 13.0とともに提供されます。このプログラムは、SETUP.EXEが実行されるディレクトリと同じディレクトリのSETUP.BATとよばれるファイルを実行します。

 

自動的に生成されるパッチのSETUP.BATには次のような例があります。

"TESTMSI2_v2.3.4.2_en-us.msp"  /passive start "" "C:\TestMSI2\X_Win95\X_Lansa\Execute\X_Run.exe"  UPCD=815F0A60-A9EC-41AB-A755-858C28F00C2B LANG=ENG PROC= FUNC= FORM=VL_DEM20 PART=DEX USER=QPGMR INDB=N INST=MSI UPSI=YES ASLU=*LOCAL ASUS= ASPW= ASTY=*OTHER ASCT= ASST= UPCF=PROMPT UPDF=PROMPT ASKC=NO ASTC=YES DBUT=MSSQLS DBII=TESTMSI2 DBUS= PSWD= INIT= PSTY= PSLU= PSUS=QPGMR PSPW= PSEA= PSCC= PSDB= PSDL= PSWM= PSEP= PSCT= PSST= PSTC=NO APPL=TESTMSI2 DBID= PSNM= UPGD=Y UPTP=P CMTH=T XENV=X_DOLLAR_SIGN_CHAR=$ XENV=X_HASH_SIGN_CHAR=# XENV=X_AT_SIGN_CHAR=@ XENV=X_GEN_AT_SIGN_CHAR=@

 1行目は実行されるMSIまたはMSPです - この場合は、TESTMSI2_v2.3.4.2_en-us.msp"  /passiveです。アプリケーション・サーバーがこの行を生成します。2行目はJITを実行しているクライアントのパラメータを含んでいます。この行はSETUP.EXEを呼び出す前にクライアントで追加されます。この行はパッチのインストールが終了するとアプリケーションを開始します。SETUP.EXEはAPI ShellExecute を使い、verb 'open'を使ってSETUP.BATを実行します。

パッチには答えるべき質問がないため、/passiveを使います。したがって、ユーザーは何か入力する必要があるでしょうか?/passiveオプションはプログレスバーを表示するので、ユーザーは何かが実行中であるというフィードバックを受け取ります。

これは自動操作です。

"SETUP.TXT"ファイルがアプリケーション・ディレクトリにある場合、内容は、次の例のようにMSI/MSPファイル名に添付されます。

 /L*V+ "C:\package.log"

ここでは有効なMSI/MSPパラメータが使えます。この特定の例では全てをログし、c:\package.logファイルに添付します。これは一次レベルのカスタマイズです - MSIコマンド・ラインにパラメータを追加します。以前のSETUP.BATは次のようになります。

"TESTMSI2_v2.3.4.2_en-us.msp"  /L*V+ "C:\package.log"
start "" "C:\TestMSI2\X_Win95\X_Lansa\Execute\X_Run.exe"  UPCD=815F0A60-A9EC-41AB-A755-858C28F00C2B LANG=ENG PROC= FUNC= FORM=VL_DEM20 PART=DEX USER=QPGMR INDB=N INST=MSI UPSI=YES ASLU=*LOCAL ASUS= ASPW= ASTY=*OTHER ASCT= ASST= UPCF=PROMPT UPDF=PROMPT ASKC=NO ASTC=YES DBUT=MSSQLS DBII=TESTMSI2 DBUS= PSWD= INIT= PSTY= PSLU= PSUS=QPGMR PSPW= PSEA= PSCC= PSDB= PSDL= PSWM= PSEP= PSCT= PSST= PSTC=NO APPL=TESTMSI2 DBID= PSNM= UPGD=Y UPTP=P CMTH=T XENV=X_DOLLAR_SIGN_CHAR=$ XENV=X_HASH_SIGN_CHAR=# XENV=X_AT_SIGN_CHAR=@ XENV=X_GEN_AT_SIGN_CHAR=@

 

JITアプリケーション・サーバーは要求されたアプリケーションのx_appsディレクトリがあるかどうかを確認します。ある場合はMSIがダウンロードされます。ない場合はx_pkgsディレクトリが使われます。これにより、バージョン13以前のクライアントが13.0サーバーにサポートされます。

サーバーは次にアプリケーション・ディレクトリにSETUP.EXEがあるかどうかを確認します。ない場合は、LANSA実行ディレクトリ内のコピーがクライアントに転送されます。これが別のレベルでの利用可能なカスタマイズです。開発者はどのようなSETUP.EXEファイルもアプリケーション・ディレクトリに入れることができます。ファイルはクライアントに転送され、実行されます。例えば、他のファイルをクライアントにダウンロードさせる手段として自己解凍される実行可能ファイルを入れることもできます。

もちろん、カスタムSETUP.EXEにはSETUP.BATの実行が必要ですが、MSI/MSPをインストールしてアプリケーションの起動もします。LANSAは、この構成について、カスタムSETUP.EXEのクライアントへの配布のみをサポートします。その後はユーザー自身でサポートしてください。

 クライアントに転送されるファイルは次のとおりです。

  • SETUP.EXE
  • SETUP.BAT
  • <クライアントにインストールされていない次のMSI/MSPファイル>

クライアントが13.0以前のバージョンの場合、x_apps\<アプリケーション名>\boot\cab2\build.datファイルサーバーのLANSA一時ディレクトリ(通常%TEMP%)に生成され、クライアントに転送されます。ファイルがクライアントに転送されると 13.0以前のクライアントがSETUP.EXEを実行します。内部のビルド番号(例:4051)がクライアントが使っている番号(例:4050)より新しいためです。

アプリケーション・サーバーは元のアプリケーション名と一致しないアプリケーション・ディレクトリを持つことができます。クライアントには新しい名前をMSIプロパティとして指定する最初のMSIをインストールする必要があります。インストールすると、APPL値が新しい値に設定され、新しいAPPLを使ってJITに添付されます。サーバーはMSIコマンド・ラインのAPPLを指定するSETUP.BATを生成します。

APPLはMSIコマンド・ラインでのみ設定できるランタイムのみの値です。APPLはJITサーバーがある場合にのみ必要です。アプリケーションの最初のインストールでは値の設定も必要です。JITがクライアントに提供し、クライアントがMSIではなくSETUP.EXEを実行させる(SETUP.EXE, SETUP.TXTおよび MSI)の3つのファイルを提供すると値が設定されます。APPL値との一貫性を持たせるためにはこのアプローチを推奨します。別の方法として、クライアントに命令を出し、msiexec.exeと引き渡すプロパティ値を使ってMSIを実行します。バッチ・ファイルを提供することもできます。

サーバーは、新しいAPPLディレクトリ名を作成してセットアップします。元のディレクトリからMSIファイルをコピーします。これでJITはクライアントにインストールするアップデートを検索しなくなります。必要に応じてMSPをコピーして入れると、次回アプリケーションが実行される時にJITがMSPをインストールします。ディレクトリには少なくとも1つのMSIまたはMSPが必要です。ない場合、エラー750がサーバーのX_ERR.LOGに出力されます(0750 - Application testmsi3 not found or no packages in applpkg.dat)。

利用可能なカスタマイズを要約すると次のようになります。

1  自分でSETUP.TXTを作成し、MSIプロパティとして公開されているすべてのX_RUN パラメータを含むMSIパラメータを指定します。

2  SETUP.EXEは開発者が実行したいどのようなインストールにも置換えられ実行されます。 

3  異なるパッケージレベルでの複数クライアントのサポートをするため、アプリケーションが生成された時の名前とは別のアプリケーション名を使います。例:LANSAInventoryControlとして生成されたアプリケーションをCustomer1InventoryControl と Customer2InventoryControlディレクトリに入れることができます。これらはまったく同じソフトウェアを実行していますが、異なるレベルでも保持されます。これらに異なるパッチを与えることもできます。