トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS

BW

Last-modified: 2015-08-07 (金) 16:26:00
Top/BW

ビジネスインフォメーションウエアハウスの略で、レポーティング専用のインスタンス

昨今ではBOがメジャーらしいが、その金額は多くのユーザ企業を仰け反らせるに充分であることも多く、引き続き利用されている。



概要

要は外付けのレポーティングパッケージであり、筆者はデータの集中管理データの一元管理はERPの大きなメリットであると考えているため、必ずしもWelcomeではないと考えるが、導入がもたらすものは決して小さくない。

SAP社がどう謳っているかは置いておいて、下記がBWのメリットでありコンセプトであると考える。

  1. SAPとの高い親和性を背景とした、情報の集中管理 データベースとしてハイレベルな信頼性を持つSAPとの高い親和性を背景に、情報を集中管理することで、一般的に発生するインタフェース時のデータの欠落や集計の誤りなどが発生しづらい基盤を構築することができる。 また、その連携部分についてSAP社がその品質を担保し、発生する不具合に対応するということは、その他のBIソリューションと比較して非常に大きなアドバンテージであると言うことができる。
  2. レポーティング基盤の統一 対象システムを使い分けることは、エンドユーザにとって殊のほかストレスを感じさせるものだが、上述の情報の集中管理を実現することで「目的によって、あちこち見なくてよい」こととなる。 また、技術基盤の統一という観点では、Excelをユーザインタフェースとしたことで、「個別のレポートごとに使用方法を習得しなくともよい」、「トレーニングを実施しなくともよい」という点も、大きなメリット。
  3. ビジネスに軸足を置いた技術基盤 得意先品目などの主要な切り口に加え、それらの対外的な分類や内部的な色付けをまとめた次元という考え方や階層化など、単にレポートの切り口として用意することに留まらず、これらをデータベース自身の技術基盤としてデザインに取り込んでいる。

BWのメリット

利用者側から見たメリット

ユーザビリティユーザが慣れ親しんでいるWebブラウザやMicrosoft Excelによる照会を基本としており、既存システムからも抵抗感なく切り替えることができる。
レイアウト変更の容易性従来は新たな切り口での照会を望むたびに仕様変更コストが発生することが常であったが、利用者自らが表示項目の追加や表示軸の切り替え、位置の入れ替えなどを行うことができ、既定のレイアウトに縛られないダイナミックなレポーティングが可能
汎用的な操作方法Excelやブラウザというインタフェースであることに加え、ドリルダウンやフィルタリング、項目の追加や入れ替え等の操作方法は全てのレポートで共通しており、レポートごとの特殊性が原則的に排除されている。個別に操作方法を習得する必要がないため、トレーニングやマニュアル作成といった副次的要素も軽減されることは大きい。
配布と最新化出力したレポートはExcel形式等で保存可能なため、ユーザライセンスを持たないメンバとの情報共有をはじめ、データのシェアが容易。また、保存後にファイルを開きリフレッシュすれば、保存したファイルそのままのレイアウトでデータの最新化が可能
データの二次加工性出力したレポートは、そのままの照会だけでなく加工することもでき、マクロや計算式を設定するなどして、ユーザの望む形に加工できる

管理者側から見たメリット

SAPとの高い親和性一貫したデザインを背景とした高い信頼性がある。データ連携に使用する各種オブジェクトは予め用意されているものも多く、他のBIソリューションと比較すると構築が容易で開発工数の低減を狙うことができる。また、手数を減らせることは不具合発生の抑制に繋がると言っていい
SAP社からの一貫したサポート一般的に、データ連携部分のトラブルはfromとtoの双方のシステム販売元から面倒を見てもらえないか或いは「弊社の領分ではない」とたらいまわしにされるケースが多くある。しかし、BWはそもそもSAPを中核としたデータ連携を前提としているため、ベンダにとっての逃げ道を塞ぐことができる
高い再利用性SAPからの連携部分、一次加工部分、二次的に加工したデータを格納するオブジェクト、各種データを統合したオブジェクト、それらを更に統合したオブジェクトなどで構成されており、新たなレポートが必要になった場合にも、既存資産が活用しやすい構成
アプリケーション保守の一元化BWを採用した場合、SAPとの親和性の高さから、殆どのSAPベンダはBWをセットでアプリケーション保守の対象とするが、BW以外を採用した場合は多くのSAPベンダにナレッジがないために引き受けないことが多く別途保守運用先を選定し契約しなければならない。これは窓口業務の煩雑化と保守コストの重複を招くため、これを避けることができることは大きい

SAPレポートとの比較

ユーザ要件実現の観点

実現手段ユーザビリティ特殊レイアウトへの対応汎用性二次加工の可用性
BW操作方法が共通で、Excel やブラウザ出力を基本としているため、利便性は非常に高いテーブル状ないしクロス集計のようなレイアウト以外の表現は苦手項目の追加、表示順の変更、マスタの階層表示に容易に対応可能で、非常に高い直接、Excelファイルとして出力するため、マクロや計算式を組込むなどの加工は容易
ALVレポート操作方法が共通で、ExcelへのExportもできるため、相対的には高いと言え、レイアウトの保存や適用が可能テーブル状のレイアウト以外は表現できない表示項目やソート基準を含めたレイアウトの保存や、それらの適用が可能Excel形式に加えPivotでもExportすることができるため、再利用性は高い
ABAPレポート対話形式での表示も可能ではあるが、個別の要件ごとに作成されることが多く、操作方法は個別に学習しなければならないことが多い他のレポートに比べ、印刷後も考慮した特殊帳票出力にも柔軟に対応しやすいレポートプログラムごとに、個別にロジックを構築する必要があるなど、汎用性は他のレポートに比べ著しく低いそもそも、個別要件の実現や、印刷を前提として作成されることも多く、相対的に低いと言える
SAP Query操作方法が共通で、出力形式の自由度が高く、ExcelへのExportもできるため、相対的には高いと言えるテーブル状のレイアウト以外は表現できない表示項目やソート基準を含めたレイアウトの保存や、それらの適用が可能Excel形式に加えPivotでもExportすることができるため、再利用性は高い
レポートペインタ操作方法は共通で、Excel出力も可能だが、ALVレポートやSAP Queryと比較すると一枚落ちるテーブル状のレイアウト以外も表現できるものの、そもそも一定の範疇でしか作成できないExcel形式での出力は可能だが、汎用性という意味では高くはないExcel形式での出力は可能だが、コードとテキストが結合していたりと加工はしづらい

システム運営側の観点

実現手段新規開発コスト変更要件への対応パフォーマンスシステムへの負荷
BWSAP側とBW側双方での開発や設定が必要であり、またBW技術者の数がSAP開発者より格段に少ないこともあり、相対的に費用は高め要件にもよるが、再利用性が高い作りであるため、既存のオブジェクトへの追加変更工数は低くなることが多い一般的には遅いといわれることが多く、クライアントPCに多めのメモリを積むなどの対策が必要BWを使用することでSAPにのみかかる負荷を分散することが可能だが、ディスク容量は圧迫する
ALVレポートBWよりは安いが、個別に開発を実施する必要があるため、相対的には中規模程度帳票ごとに固有のロジックやレイアウトが設定されている場合が多々あり、変更のためのコストは相対的に高めそのレポートに特化したロジックやSQL文を書くために最適化可能な範囲が広く、相対的には速いと言えるSQLに最適化の余地があるためDBサーバへの負荷は相対的に低いが、メモリを多く消費する
ABAPレポートBWよりは安いが、個別に開発を実施する必要があるため、相対的には中規模程度帳票ごとに固有のロジックやレイアウトが設定されている場合が多々あり、変更のためのコストは相対的に高めそのレポートに特化したロジックやSQL文を書くために最適化可能な範囲が広く、相対的には速いと言えるSQLに最適化の余地があるためDBサーバへの負荷は相対的に低く、ABAPレポートの表示はメモリを食わない
SAP Query凝ったコーディングさえしなければ、格安で開発が可能凝ったコーディングさえしなければ、格安で開発が可能SQL文は自動生成されたもので、個別に最適化されていないため、速くはない効率的なSQLを実行するわけではないこと、またALV表示されることが多くメモリを食うため、相対的には高い
レポートペインタレポートのみの作成であれば格安で実現可能で、集計の仕組みを新規開発する場合も標準のカスタマイズの範疇できることが限られているため、変更でなく新規作成するにしても、相対的には安いそもそも抽出対象が集計テーブルであり個々の伝票ではないため、相対的には速い対象データがサマリテーブルであることが多いこと、またExcelまたはABAPレポート形式で表示され打事が多く、相対的には低い

制約と注意事項

  1. 動作環境は、クライアント PCに依存する部分が大きい クライアントPCに搭載されたExcel のバージョン、行列の表示制限、マクロのセキュリティ設定、GUIのバージョン、通信状況などの影響を受け、意図通りに動作するか否かが左右される。ヘルプデスクを悩ませる点。
  2. 基本的に、軽くはない そもそも遅いと評されることも多く、充分なパフォーマンスを発揮するためには、並行して行う処理をある程度絞り込む、メモリを多めに搭載するなどの対応が必要となる場合も少なくない。
  3. テーブル結合やクロス集計以外のレポート形式が苦手 ExcelのPivotをはじめテーブル形式で出力するレポートはBWの得意とするところだが、こういったレイアウト以外での表示、例えば年初〜当月のような形式での表示は苦手。
  4. リアルタイム性が損なわれる SAPではリアルタイムにデータの取り扱いレポートを出力するなどが可能だが、SAP→BW間のデータ連携は、システム負荷を考慮してバッチ処理で行われるケースが多く、多くの場合はデータのリアルタイム性が日次レベルまで低下する。
  5. SAPとはライセンスは別扱い BWのライセンスはSAPとは別に購入しなければならず、金食い虫と呼ばれる所以。 中にはセットで契約するパターンもあるだが、多くの場合はSAとBWで利用者が異なるため、損か得かは微妙なところ。

主要な構成

まず、バージョンが3.xであるか7.0移行かで大きく全体像が異なる。 具体的には、下記が挙げられる。

  • 3.xまでは更新ルール転送ルールだったものが、7.0からは変換という考え方に置き換えられた
  • また、インフォソースの扱いが変更され、2つの変換を結合するための複数のオブジェクトで構成される構造となった
  • 今迄は更新ルールを経由しなければデータの変換ができず、データをConvertするには何度か格納しなおさなければならなかったが、今後は変換を行うことでデータの更新が容易になり、新しいインフォソースを使用すると、データフローで2つ或いはそれ以上の連続変換が実行できるようになった。
  • 3.xではODSと呼ばれていたオブジェクトは、7.0以降ではDSOと呼ばれるようになった

なお、7.0においても3.xのインフォソースを使用することは可能だが、当然ながらSAP社は7.0より使用可能になった新しいタイプのインフォソースを使用することを推奨している。

主要オブジェクトとその役割

SAPとのつながり

データ連携

  • データソースからの連携 標準的な手法であるデータソースからの連携は、BWからのPullで行なわれることが多く、イベント起動やRFCなどによるSAPからのPush方式は、あまり採用されない。 BW側より、転送するデータの抽出条件やアップロード先を設定したインフォパッケージを実行することで転送が開始される。 ここでは、即時実行のほかJOB実行も可能であり、プロセスチェーンで表現しなければならないような複雑な条件でなければ、JOBのスケジューリングも可能。 7.0では、インフォパッケージの代わりにDTP(データ転送プロセス)が用意されており、これを使用すると特定の変換に従ってデータを転送することができる。
  • ファイルからのデータ転送 リカバリ・テスト・データ移行など、主にシステムに元データが存在しない場合に利用され、データをキューブにアップロードするためにファイルインターフェースが用意されている。 このファイルインターフェースは、キューブおよびODS毎に個別に設定する必要がある。
  • セキュリティ間隔 一般的に、デルタデータ抽出中に出現し、例えば、保存されていなかったために 抽出できなかったレコードが次回の抽出中に考慮されるようにすることを目的として、セキュリティ間隔(通称:安全デルタ時間)を設定する。 例えばセキュリティ間隔を30分と設定しておくと、前回のデルタアップロード以降、且つアップロード開始時点から30分より前に登録されたデータがアップロード対象となる。

データ更新

  • 完全更新 抽出条件に基づき、現在のキューブへ登録状況を問わず、データの転送を行なう。 データソースからの抽出において、タイムスタンプなど更新の条件として識別可能な項目を持たない場合、後述のデルタ更新に対応していないため、更新モードの設定画面でこちらしか選べない。 なお、同一条件でアップロードされた依頼を削除する機能があるため、それを利用した疑似的なデルタ更新を実現することは可能。
  • デルタ更新 いわゆる差分更新で、初回更新時の設定条件に基づき、前回からの差分を抽出してデータ転送を行なう。 これには、タイムスタンプなどの前回実行分との識別が可能であることが条件であり、CO-PAなどのSAP標準においてはデルタ更新に対応したデータソースとなっているものも多くある。 そのためアドオンにおいてはデルタ更新が必要な場合はテーブル設計に加味する必要がある・・・と言うこともできるが、デルタ更新が必要となる対象はトランザクションデータあるいは履歴管理が必要なマスタであるため、アドオンでそういったものを管理することを、そもそも是とするか?という議論もある。
  • フェイクデルタ 月単位とかでデータを洗い替えする方法とのこと。7.0から?

misc

データの洗い替え

  • 基本的な考え方 キューブからダウンロード→Fileのデータを修正→アップロードという方法、或いはキューブからPSAへ転送→PSAに格納されたデータを修正のうえキューブへアップロードという方法なども考えられるが、いずれも開発は必要であり、手作業によるミスが懸念される。 そのため、既に充分な試験を行い、品質が保証されている仕組みを用いるという意味において、データソースからの再アップロードを行うことが基本。 なお、年度などの明確なデータ切り分けの基準がある場合に限られるが、元のキューブはそのままとして、差分用のキューブを新たに作成し、マルチで出力するという方法もある。
  • 差分情報の初期化 キューブなどBW側に項目を追加し、その項目に値を設定したいケースにおいてはデータの再生成を行う必要がある、その場合、更新方法がデルタの場合は差分情報を初期化しなければならない。 これにあたり、改めて全データを取り込みなおす場合はその限りではないが、最終アップロードの後に発生したデータの差分を取り込まずに初期化すると、取りこぼしが発生するため、差分情報に関してはSAP側のデルタキューを確認しつつ実施すること。
  • データソースの確認 データを流し直しする場合は、SAP側あるいはファイルからの再アップロードが主となるが、これらの元データに全ての洗替対象のデータが残っていることを確認しなければならない。 ハウスキーピング、アーカイブ、ファイルの消失などを原因に必要なデータが失われてしまった場合、現在の状態を復元することができなくなってしまう。

移送について

  • 移送取得の流れ トランザクションコードRSA1より「移送接続」画面を開き、移送対象のオブジェクトを選択するという流れとなるが、そもそもBWのオブジェクト修正は、まずGUI側からBEx依頼という移送依頼を割り当てる必要がある。 これは「とりあえず、何らかの変更を加える場合に割り当てる移送依頼」と考えて差支えないが、クエリの修正時に関連オブジェクトが登録されている場合が多くあり、古いものを誤って移送してしまうことを防ぐため、一旦BEx依頼をリリースしてから改めて依頼を取得し直すのが一般的な流れ。 その後、また新たにBEx依頼を登録する。
  • 移送ログ クエリ関連オブジェクトは、英数字が羅列された内部IDで管理されており、SAPと違い、移送依頼」やログをトレースしてもオブジェクトを特定するのが困難。 その為、移送依頼」の取得時に、しっかり漏れや誤りがないように注意すること。
  • 移送の順番 SAP側で必要なデータソースやEXITの移送が正常終了していることの確認後に、BW側の移送を行うこと。 当然ながら、必要な移送がSAP側で行なわれていない場合あるいは失敗している場合はBW側でエラーとなる。

まとめ前のメモ

  • データの連携またはアップロードタイミング BWへのデータ連携やアップロードは、多くの場合、大量のデータが処理対象となり、レポートの表示速度に影響を与えるため、リアルタイムキューブを除いて営業時間中の更新は避けることが無難。 定期処理以外にアップロードする場合、特に使用率の高いキューブは、定時後や休日などにアップロードが行われるようにJOBを設定すること。
  • 旧バージョンで作成したクエリ 3.x以前の旧バージョンで作成したクエリを7.0以降の新バージョンで修正すると、旧バージョンで修正不可能になるなどのトラブルに見舞われるケースがあるため、修正するツール(GUI)のバージョンは統一すること。
  • その他レイアウト関係 論理式に関連するキー数値や要素を追加した場合、その項目を論理式に忘れずに組み込むこと。 また、ワークブックやブックマーク(Web版)はレイアウトを記憶するため、あわせて注意。
  • 照会ログの扱い 触れられないことも結構ありますが、クエリのドリルダウン一回ごとにログが標準DBにたまるようになっている場合がある。 あるクライアントでは、稼働から一回も削除されておらず、稼働後4〜5年で30GBも溜まっていた事例もあるとのこと。
  • セル定義 クエリにおいて、セルを指定して計算式を埋め込むことも可能。 ただし、ドリルダウンの仕方によっては、狙った通りに表示されなかったり、動作が重くなることもあるため、ある程度自由に切り口を定めるフリーレイアウトではなく、固定帳票向きの設定。
  • 並列読み出し キューブからデータを読み出す際に、複数のプロセスを使用し並列で読み出すか否かを定めるConfigで、環境レベルで設定する。 裏を返すとプロセスを必要以上に使ってしまう可能性もあるため、単一プロセスの使用を推奨。
  • 権限設定について 権限設定はキューブ単位に施されることが多く、クエリ単位での設定はあまり行われない。 これは、単にクエリ単位での設定が煩雑であること、照会可能なデータの多くはキューブ単位で切り分けられるためにクエリレベルで制御する意義が薄いことなどが背景。 なお、一部のパワーユーザのみに限定してクエリの作成権限を開放する場合は少なくない。
  • ビジネスコンテンツ 一般的に使用するインフォオブジェクトデータソースなどのオブジェクトについては、ビジネスコンテンツと呼ばれるSAP標準のオブジェクトが用意されている。

BWのまとめページ

BW/トランザクションコード BW/関連テーブル BW/分野メニュー

関連ページ



【スポンサードリンク】
  




コメントはありません。 Comments/BW

お名前: