wtfbbq のブログ

2009年6月24日水曜日

CE7.1やPI7.1でいらないサービスを停止しておく方法

configtoolではなくnwaでやるようです。AdobeDocumentServiceとか使わないなら止めておきましょう。

http://help.sap.com/saphelp_nwesrce/helpdata/en/45/1e7eb303577524e10000000a114a6b/content.htm

SAP Note 1103864

2009年4月19日日曜日

JCo3.0 (第1回)

しばらく経ってしまいましたがJCo3.0に関して書いていきたいと思います。

JCo2.0との違いは色々あるのですが、まず大きなところは「コネクションプーリングがJCo Runtime 任せになった」ことでしょうか。

JCo3.0のpdfドキュメントでは以下のような感じでサンプルが書かれています。

1. まずは接続情報をプロパティファイルとして作成

2. Javaのコードからは、JCoDestinationManagerクラス(staticクラス)よりdestinationを取得する。このときプロパティファイル名をキーとする

JCoDestination destination = JCoDestinationManager.getDestination("プロパティファイル名")

3. 呼び出したいファンクションをリポジトリから探す

JCoFunction function = destination.getRepository().getFunction("ファンクション名");

4. ファンクション実行

function.execute(destination);

# もちろんファンクション引数ある場合は色々setValue()しておく

ここで、コネクションプーリングは1.のところの接続情報にてプールの情報を書いておくと、自動で実行時にJCo Runtimeがよきに計らってくれます*1。簡単になりましたね。

なお、接続情報にはサーバのIPアドレス、システム番号、SID、クライアント番号以外にも、ユーザクレデンシャルが含まれます。ユーザクレデンシャルがユーザID/パスワードの場合、これらをプロパティファイルとして作るのはイヤでしょう。そんなときは以下を参考にしてみてください。https://www.sdn.sap.com/irj/scn/thread?messageID=7303957

DestinationDataproviderを自分でインプリしてcom.sap.conn.jco.ext.Environmentに登録すると良いようです。

com.sap.conn.jco.ext.Environment.registerDestinationDataProvider( provider );

次回はもう少し突っ込んだファンクション実行、もしくはThreadを意識した利用方法です。その他SAPJCoIDocライブラリについても書いていきたいと思います。

*1：逆にJCoDestinationクラスはどう接続を生成するかの情報のみ保持し、実際の接続自体の生成や保持はしない。JCo Runtimeが生成/キャッシュをする

2009年4月14日火曜日

SolManでパッチ適用効率化

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12366

どうやらSolManにSP18適用して、かつそのSolManのNW7.0をEhP1にすると、メンテナンスオプティマイザによるパッチのダウンロードだけでなく、SolMan管理対象サーバへのパッチのデプロイと適用もできるようになるとのこと。NW7.0EhP1はちょうど先月正式リリースされましたので、是非とも試してみたいところですね。SolManで適用情報も一元管理されますし、特に頻繁にパッチ適用してサーバ状態管理するであろうベーシス担当者の作業負荷が軽減されるのではないでしょうか？

また今後はNW7.0EhP2でカーネルパッチやIGSへのパッチもあてられるようになるそうです。

>- Solution Manager (MOPZ) SP15-SP17 + Netweaver 700 SP14+ (SLM) = Download only

>- Solution Manager (MOPZ) SP18 + Netweaver 701 (SLM) = Download + Deployment of ABAP and Java

>- Solution Manager (MOPZ) ? + Netweaver 702 (SLM) = Download + Deployment of ABAP and Java + Kernel and IGS patch

2009年4月11日土曜日

AS Java の変化

以前sapjvmのtopicで以下のことを書きましたが、

>ねらいはAS Javaと組み合わせて、もし複数VMのうち1つがダウンしたとしても、他のVMに素早くsession failoverできるようにすることらしいです。

これを含む、CE7.1より変更されたAS JavaのアーキテクチャのことをSAPは "Solid Rock" と呼んでいるようです。

以前(NW7.0)は、AS JavaはHTTPリクエストを最初に取得する部分をJavaで実装していました(java dispatcher)。ただ、javaによるそもそものオーパヘッドを減らすために、Solid Rock(CE7.1~)ではこの部分がABAP Stackでも使われているICMに変更されました。で、J2EEエンジンにリクエストを渡すときには以前の通常のローカルTCP/IPポート経由ではなく、MPIという共有メモリ[*1]経由になり、sapjvmを通してJ2EEエンジンが取得することで、リクエスト受け渡しのオーバヘッドも減らすようにしたようです。

[*1] http://help.sap.com/saphelp_nw04s/helpdata/en/e7/2e25c472e04b63bf6139dd7071a858/content.htm