- 5月にSAPJ主催のウェビナーをいくつか受講しました。SAPはBTPと呼ばれているCloudサービスにユーザを誘導したいようで、SAP BW/4HANAのマイグレーション先をDWC内で動作するBW Bridgeに移行するのがメインストリートになるようです。
- 私は以前ブログに書いた内容の通り、従来型のBW設計は、製品のネガティブな部分が表面化してしまうと考えています。
- 根本にはデータをどこで処理するべきか？という問題になると思っています。
- 一旦話が変わります。(無理やりですが、ちゃんと戻ってきます。)
- 40年前8ビットCPUのZ80の頃(爆)、パソコン：NEC：PC-8801の画面に画像ファイルを表示するのに、BMP形式、MAG(MKI)形式、JPEG形式などがありました。画像ファイルは、300bpsのモデムをアナログ電話回線に接続して、主にNiftyや東京BBSで取ってきました。以上3つの画像形式で使い勝手が最もよかったのは、MAG(MKI)形式でした。MAG(MKI)形式は、確か早稲田大学のサークルの「まきちゃんネット」(正式名称は不明です。誰か教えて下さい)が開発した画像形式で、当時のパソコンの、CPUのデータ解凍処理速度とファイル読出速度を加味したベストバランスで設計されていたのではないかと思います。
- 時代は大幅に進んで15年前MS Office 2007と共に「Microsoft Office Open XML Formats(OpenXML)」が登場しました。いわゆるxlsx形式ですね。このxlsxですが、複数のXMLファイルをZIP圧縮して、拡張子をxlsx、docx等としているので、Officeドキュメントにファイルアクセスするときに、ZIP圧縮解凍を逐次行っています。ファイル読出速度よりもCPUのデータ解凍処理速度のほうが大幅に進化したので、ZIP圧縮解凍を逐次処理する仕組みになったのだと思います。
- ファイルI/Oの進化は緩やかで、CPUの進化は急激ということが言いたかったのです。そのため、CPUの恩恵を十分に受けると処理は軽量となりパフォーマンスが劇的に改善する可能性があるのです。
- さて、話戻って、SAP S/4HANAのデータをどのように扱うと効率が良いのか？
- 私の考える結論は、明細データをCPUで加工集計して、加工集計結果を直接参照またはデータマートとしてコピーを作成するべきです。(もちろん要件によっては明細情報が必要な場合もありますが．．)
- 特に会計データに限っては月次集計する要件が大半を占めるので、総勘定元帳(BKPF、ACDOCA)は、明細情報のコピーを持たずに加工集計済みデータのコピーを持つべきと思います。
- データ加工をCPUで行うということは、データベースで処理することと、ほぼ同義なのではと思います。つまり、Code Pushdown設計により各種ビュー(HANA Information View、ABAP CDS View、Composite Provider(BW)、ABAP SQL)で処理するのが理想的と思います。そしてI/Oが無視できるSAP S/4HANAで処理するべきと思います。つまり、SAP S/4HANA Include embedded BWで処理することになると思います。
- 上記を実現すると、BWのBusiness Contentは不要になります。(全て不要にはなりませんが．．)
- 私の主張は上記の通りですが、、、
- SAPJのマーケティング戦略により、少なくとも数年、もしかしたら10年以上BW Bridgeが、SAP BW/4HANAの受け皿として流行ると思います。売り文句としては、「BWで培った資産を継承することで有効活用できる」としているようです。
- せめて「BWで培った資産」はごみ箱に捨てて、データ加工集計処理の中心をSAP S/4HANA上に各種ビューとして実装して、加工集計結果をデータコピー(連携)することで、「SAP情報系は遅い」というイメージを払拭できると思います。
- 私事ですが、今回題材にしたコンセプトを、細々とではありますが「SAP Sapphire Tokyo 2022」で展示する機会を頂きました。今後も継続して少しずつ露出していこうと思います。
