- 転職前は中身にあまり興味を示さない人達が多くて、きちんと実装しても「保守フェーズに入ってからじゃないと評価されないから無駄」とか言われる始末でした。感覚的にはクオリティー(ソースコードの健康!!?)を保つことがローコスト短納期に直結すると思うのですが。
- 転職しました。急に比較的新しい技術に触れるようになって戸惑いつつ楽しく働いています。実装とリファクタリングを同時並行で進めています。当初会社(というか上司)は、前職と同様に、実装(というか詳細設計)にあまり興味が無いのかと思って、オーバービューレヴェルで軽～く解説していました。しかしながら実際は、興味があるが故の質問や追加要望等たくさん出てきて、設計上の優位性を評価してくれて、とても気持ちが良いです。そんな状況なので何となくですが、手の内を明かすようなCode Pushdown手法のロジックを、今までのようにブログに書いて良いものか、戸惑っています。(止められました。喜んで従います)
- そんなわけで、ブログ記事としてはつまらないかもしれませんが、今回はコード無しです。
そろそろ本題ということで。既知の常識かも知れませんがユーザさんの本音が少し聞けました。
- 大前提として私は、SAP BW/4HANAが大好きです。
- SAP S/4HANAを導入するとSAP BW/4HANAが付属で付いてきます。そのため、情報系で別途プロダクトを準備する稟議はなかなか通らず、SAP BW/4HANAをなんとか使い倒そうということになるそうです。しかしながら、ユーザ様ご担当者レベルでは、使いにくいシステムが出来てしまい最悪は使い物にならないのではとの、懸念を抱くそうです。
- おそらくですが、世の中のSAP BWシステムは以下の問題点を抱えながら運用しているのだと思います。
- パフォーマンスが悪い。導入時に導入ベンダにパフォーマンス改善を要望し続けるのですが、様々な説明を受けて時間切れとなってしまう。
- BWの仕組みとして、BW変換、BWクエリ、OLAP変数(Customer Exit)が強調して動作するので、ロジック配置が分散してしまう傾向にあり、保守性を著しく低下させてしまう。
- SAP BW/4HANAの利点は私は詳しくないのですが(って言ったら会社に怒られるかな!!?)、定義済みのビジネスコンテンツを利用することで、インターフェイスアドオン開発が削減出来て、導入コストが抑えられると説明しているのだと思います。
- ビジネスコンテンツの実態って、例えば総勘定元帳(BKPF & ACDOCA)だとデルタで明細レベルデータを引っ張る動きをします。一方で、SAP BW/4HANAでは月単位のレポートが主で、明細データを参照するケースってあまり無いのではと思います。そのため、ほとんどのプロジェクトでは、SAP BW/4HANA内でSAP BWレガシーな手法であるレコードセットベース(つまりループ処理)のBW変換を使って、加工済みデータのコピーを多数作成することになります。
- 上記手法は以下の問題点があり、ほとんどの場合最後まで解決しないままユーザ様があきらめてカットオーバーを迎えると思います。
- BW変換はループ処理なのでパフォーマンスを確保するのが難しく、機能要件の一部を妥協して夜間バッチ処理がギリギリ終わるか、終わらないか。
- 伝言ゲームのように、加工済みデータのコピーを多数作るので、データリカバリ要件が複雑になり、運用の工数が増大し、難易度が高くなってしまう。
- BW変換を動かすには、DTPやBW変数等様々なオブジェクトが必要なため、ロジックが分散する傾向にあり、成果物の可読性が著しく低下し影響範囲の特定を難しくしてしまう。そのため保守性が悪く、変化に弱い仕組みとなってしまう。
- 上記(パフォーマンス確保、ロジックの分散)に付帯して、データ加工が中途半端(途中であきらめてしまう)になる傾向にあり、無理やり機能要件に合わせるために、BWクエリの実装が肥大化して、ますますパフォーマンス確保が難しくなり、ロジックが発散してしまう。
- ではどうしたら良いのか?、私の考える解決方法は、ビジネスコンテンツは最小限に、SAP S/4HANAにABAP CDS ViewやHANA Information View等で、加工集計済みデータをSAP BW/4HANAにデルタ連携する。(ここが私の強みなので、やれるものならやってみろとの思いもありますが(土井善治風に．．))。って、他社の分析系の仕組を導入するときも同じような設計をしているような気がします。(違うのかな!!?わかんないや)
- ハードルは以下2点。
若干話が飛びます。
- SAP Data Warehouse Cloudなんていう製品もあるようですが、私は中身について一切知りません。そのうえでいい加減なことを書きます。(勉強したら考えが変わるかもしれませんが、と言うか勉強したいです)
- SAP BW/4HANAは廃止して、SAP S/4HANA Include Enbeded BWに統合して、インターフェイスアドオン不要のシンプルな構成にするべきと思っています。(ドイツ人はどのように捉えているのは分かりませんが)
- そんなわけで、SAP S/4HANAのEnbeded BWネタです。
- SAP BW/4HANAのCode Pushdownといえば以下の印象です。
- HCPR(複合プロバイダ)ですよね？多分SAPJもそのように説明しているのではと思う。
- HCPRって、SAP BW on HANAのBW CUBEの時ように、へたっぴいにHANA Information Viewをラッピングしている。
- HCPRで本気にCode Pushdownに取り組もうとすると自由度が低すぎて破綻する。
- HANA Information Viewを習熟している身としては、歯がゆい。
- HCPRで試行錯誤するよりも、HANA Information View習得コストの方が少なく済むと思う。
- 上記歯がゆさ解消ということで、
- Open ODS Viewで、各項目にInfo Objectを割り当てるのですが、ここで大きな発見がありました。自分で作らなくて良いYo！！
- そんなわけで、Enbeded BWに、HANA Information View、SAP標準Info Object、AnalysisOfficeで、バタバタと会計情報のリアルタイムレポートを作成しました。もちろんクライアント制御も効いています。あとは、勘定グループを割り当てる程度で良い感じになりそうです。
またまた話が飛びます。
- 転職先は、SAP導入ベンダ以前にクラウドベンダを名乗っています。AWS、Azure、GCPがメインの事業領域だったりします。
- 今までは、Code Pushdownでパフォーマンス確保に奔走していました。パフォーマンスは正義だ！(草)
- 今でも、パフォーマンスは正義なのですが、クラウドといえば処理を軽くすると経費節減ですね。
- 自身の中で、パフォーマンスを確保する処理方法と同時に、処理量そのものを削減するにはどうするか？そんなことを考えるようになりました。場合によっては加工済みデータのコピーを持つのも悪くないかと。
最近の神様からの贈り物について
- 楽しんで働いていると、私に神様がたくさん語り掛けてくれるようです。いろいろ思考錯誤はありましたが、神様から贈り物、しっかり受け止めました。
- 過去月次の在庫を出力する要件を、Viewロジックのみで実現しました。もちろん在庫移動の無い月も正しく在庫を出力します。
最近の悩み事について
- SAP HANAって、組み込み関数群があるんですよね。3種類あって、一部は自作可能なんです。
- BFL：割引率計算とか組み込み関数で出来るようです。
- AFL：関数自作プラットフォーム：Cで記述するのかな？：私一応C書けます。基本情報もCで受けたし。
- Enbeded R(SAP HANAネイティブで動くそうです)：最近はPythonと一緒に組み合わせるとかで、流行っていますよね。
- 上記で何ができるのかよく分からないのと、エンタープライズ領域の要件で適用方法、アイデアの、具体的は手法が分からないのです。
- まずは何ができるのか把握しないと、始まらないんでしょう。
- 少しずつですが、RStudioで、Rを勉強中です。
最近、中田ヤスタカの2000年代を聴いてます。エッジが効いていて心地よいです。中田ヤスタカの動画や画像を見ていると、良い意味でオタクだなぁ〜って思います。例えば、スティーブジョブズが復帰する直前の、ピザボックスの頃のAppleとか。外付けMOドライブとか。我らがアラフィフのオタク心をくすぐられます。乱暴な話ですが、おじさん達は全員、中田ヤスタカが好きだからって思います。小室哲哉をリスペクトしているのが、楽曲のあらゆるところから滲み出ていると感じます。
