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





Blue Ruby



http://www.atmarkit.co.jp/news/200904/01/blueruby.html


https://www.sdn.sap.com/irj/scn/wiki?path=/display/Research/BlueRuby


ABAP VM上でRubyが動くようになるようですね。


・Ruby1.8.6ベース(1.9ベースにswitchすることも計画中)


・RubyのコードからABAPのFMやESを呼び出せる(RFC[*1]経由/WebService経由)


・ABAPコードから作成したRubyコードを呼び出せる


・HTTP Bridgeにより、作成したRubyコードをICM経由でブラウザから呼び出せる(Webアプリ作れる)


・HTTP Client用のライブラリも用意されている[*2]


・BAdI Bridgeにより、RubyでBAdIインプリできる


・(制限)ProcessとかKernel、Threadクラスは使えない。NetworkはNet::HTTPのみ


[*1] Remote-enabledなFMしか呼び出せないのは技術的理由ではなくセキュリティの理由からだそう。。


[*2] Rubyのnet/httpライブラリとはちょっと違うらしい


まだリリースはされていないものの、なかなか面白そうです。


ABAP Stack でWebアプリとか作るときの新たな候補としてBlue Ruby使えるかもしれませんね。