BW の変更点
Top/BW
ビジネスインフォメーションウエアハウスの略で、レポーティング専用の[[インスタンス>SAPの構成/インスタンス]]。 昨今では[[BO>Business Objects]]がメジャーらしいが、その金額は多くのユーザ企業を仰け反らせるに充分であることも多く、引き続き利用されている。 ---- #contents ---- * 概要 [#ke3b18f9] 要は外付けのレポーティングパッケージであり、筆者は''データの集中管理''と''データの一元管理''はERPの大きなメリットであると考えているため、必ずしもWelcomeではないと考えるが、導入がもたらすものは決して小さくない。 SAP社がどう謳っているかは置いておいて、下記がBWのメリットでありコンセプトであると考える。 +SAPとの高い親和性を背景とした、情報の集中管理 データベースとしてハイレベルな信頼性を持つSAPとの高い親和性を背景に、情報を集中管理することで、一般的に発生するインタフェース時のデータの欠落や集計の誤りなどが発生しづらい基盤を構築することができる。 また、その連携部分についてSAP社がその品質を担保し、発生する不具合に対応するということは、その他のBIソリューションと比較して非常に大きなアドバンテージであると言うことができる。 +レポーティング基盤の統一 対象システムを使い分けることは、エンドユーザにとって殊のほかストレスを感じさせるものだが、上述の情報の集中管理を実現することで「目的によって、あちこち見なくてよい」こととなる。 また、技術基盤の統一という観点では、Excelをユーザインタフェースとしたことで、「個別のレポートごとに使用方法を習得しなくともよい」、「トレーニングを実施しなくともよい」という点も、大きなメリット。 +ビジネスに軸足を置いた技術基盤 [[得意先>得意先マスタ]]や[[品目>品目マスタ]]などの主要な切り口に加え、それらの対外的な分類や内部的な色付けをまとめた[[次元>BW/次元]]という考え方や階層化など、単にレポートの切り口として用意することに留まらず、これらをデータベース自身の技術基盤としてデザインに取り込んでいる。 ** BWのメリット [#p06f6281] *** 利用者側から見たメリット [#x8c16f5c] ,ユーザビリティ,ユーザが慣れ親しんでいるWebブラウザやMicrosoft Excelによる照会を基本としており、既存システムからも抵抗感なく切り替えることができる。, ,レイアウト変更の容易性,従来は新たな切り口での照会を望むたびに仕様変更コストが発生することが常であったが、利用者自らが表示項目の追加や表示軸の切り替え、位置の入れ替えなどを行うことができ、既定のレイアウトに縛られないダイナミックなレポーティングが可能, ,汎用的な操作方法,Excelやブラウザというインタフェースであることに加え、ドリルダウンやフィルタリング、項目の追加や入れ替え等の操作方法は全てのレポートで共通しており、レポートごとの特殊性が原則的に排除されている。個別に操作方法を習得する必要がないため、トレーニングやマニュアル作成といった副次的要素も軽減されることは大きい。, ,配布と最新化,出力したレポートはExcel形式等で保存可能なため、ユーザライセンスを持たないメンバとの情報共有をはじめ、データのシェアが容易。また、保存後にファイルを開きリフレッシュすれば、保存したファイルそのままのレイアウトでデータの最新化が可能, ,データの二次加工性,出力したレポートは、そのままの照会だけでなく加工することもでき、マクロや計算式を設定するなどして、ユーザの望む形に加工できる, *** 管理者側から見たメリット [#j091faf7] ,SAPとの高い親和性,一貫したデザインを背景とした高い信頼性がある。データ連携に使用する各種オブジェクトは予め用意されているものも多く、他のBIソリューションと比較すると構築が容易で開発工数の低減を狙うことができる。また、手数を減らせることは不具合発生の抑制に繋がると言っていい, ,SAP社からの一貫したサポート,一般的に、データ連携部分のトラブルはfromとtoの双方のシステム販売元から面倒を見てもらえないか或いは「弊社の領分ではない」とたらいまわしにされるケースが多くある。しかし、BWはそもそもSAPを中核としたデータ連携を前提としているため、ベンダにとっての逃げ道を塞ぐことができる, ,高い再利用性,SAPからの連携部分、一次加工部分、二次的に加工したデータを格納するオブジェクト、各種データを統合したオブジェクト、それらを更に統合したオブジェクトなどで構成されており、新たなレポートが必要になった場合にも、既存資産が活用しやすい構成, ,アプリケーション保守の一元化,BWを採用した場合、SAPとの親和性の高さから、殆どのSAPベンダはBWをセットでアプリケーション保守の対象とするが、BW以外を採用した場合は多くのSAPベンダにナレッジがないために引き受けないことが多く別途保守運用先を選定し契約しなければならない。これは窓口業務の煩雑化と保守コストの重複を招くため、これを避けることができることは大きい, ** SAPレポートとの比較 [#ie36fb77] *** ユーザ要件実現の観点 [#ef069f0f] |実現手段|ユーザビリティ|特殊レイアウトへの対応|汎用性|二次加工の可用性|h |BW|操作方法が共通で、Excel やブラウザ出力を基本としているため、利便性は非常に高い|テーブル状ないしクロス集計のようなレイアウト以外の表現は苦手|項目の追加、表示順の変更、マスタの階層表示に容易に対応可能で、非常に高い|直接、Excelファイルとして出力するため、マクロや計算式を組込むなどの加工は容易| |[[ALVレポート>ABAP/ALVレポート]]|操作方法が共通で、ExcelへのExportもできるため、相対的には高いと言え、レイアウトの保存や適用が可能|テーブル状のレイアウト以外は表現できない|表示項目やソート基準を含めたレイアウトの保存や、それらの適用が可能|Excel形式に加えPivotでもExportすることができるため、再利用性は高い| |[[ABAPレポート>ABAP/ABAPレポート]]|対話形式での表示も可能ではあるが、個別の要件ごとに作成されることが多く、操作方法は個別に学習しなければならないことが多い|他のレポートに比べ、印刷後も考慮した特殊帳票出力にも柔軟に対応しやすい|レポートプログラムごとに、個別にロジックを構築する必要があるなど、汎用性は他のレポートに比べ著しく低い|そもそも、個別要件の実現や、印刷を前提として作成されることも多く、相対的に低いと言える| |[[SAP Query>SAPの拡張手段/SAP Query]]|操作方法が共通で、出力形式の自由度が高く、ExcelへのExportもできるため、相対的には高いと言える|テーブル状のレイアウト以外は表現できない|表示項目やソート基準を含めたレイアウトの保存や、それらの適用が可能|Excel形式に加えPivotでもExportすることができるため、再利用性は高い| |[[レポートペインタ>SAPの拡張手段/レポートペインタ]]|操作方法は共通で、Excel出力も可能だが、ALVレポートやSAP Queryと比較すると一枚落ちる|テーブル状のレイアウト以外も表現できるものの、そもそも一定の範疇でしか作成できない|Excel形式での出力は可能だが、汎用性という意味では高くはない|Excel形式での出力は可能だが、コードとテキストが結合していたりと加工はしづらい| *** システム運営側の観点 [#q113126b] |実現手段|新規開発コスト|変更要件への対応|パフォーマンス|システムへの負荷|h |BW|SAP側とBW側双方での開発や設定が必要であり、またBW技術者の数がSAP開発者より格段に少ないこともあり、相対的に費用は高め|要件にもよるが、再利用性が高い作りであるため、既存のオブジェクトへの追加変更工数は低くなることが多い|一般的には遅いといわれることが多く、クライアントPCに多めのメモリを積むなどの対策が必要|BWを使用することでSAPにのみかかる負荷を分散することが可能だが、ディスク容量は圧迫する| |[[ALVレポート>ABAP/ALVレポート]]|BWよりは安いが、個別に開発を実施する必要があるため、相対的には中規模程度|帳票ごとに固有のロジックやレイアウトが設定されている場合が多々あり、変更のためのコストは相対的に高め|そのレポートに特化したロジックやSQL文を書くために最適化可能な範囲が広く、相対的には速いと言える|SQLに最適化の余地があるためDBサーバへの負荷は相対的に低いが、メモリを多く消費する| |[[ABAPレポート>ABAP/ABAPレポート]]|BWよりは安いが、個別に開発を実施する必要があるため、相対的には中規模程度|帳票ごとに固有のロジックやレイアウトが設定されている場合が多々あり、変更のためのコストは相対的に高め|そのレポートに特化したロジックやSQL文を書くために最適化可能な範囲が広く、相対的には速いと言える|SQLに最適化の余地があるためDBサーバへの負荷は相対的に低く、ABAPレポートの表示はメモリを食わない| |[[SAP Query>SAPの拡張手段/SAP Query]]|凝ったコーディングさえしなければ、格安で開発が可能|凝ったコーディングさえしなければ、格安で開発が可能|SQL文は自動生成されたもので、個別に最適化されていないため、速くはない|効率的なSQLを実行するわけではないこと、またALV表示されることが多くメモリを食うため、相対的には高い| |[[レポートペインタ>SAPの拡張手段/レポートペインタ]]|レポートのみの作成であれば格安で実現可能で、集計の仕組みを新規開発する場合も標準のカスタマイズの範疇|できることが限られているため、変更でなく新規作成するにしても、相対的には安い|そもそも抽出対象が集計テーブルであり個々の伝票ではないため、相対的には速い|対象データがサマリテーブルであることが多いこと、またExcelまたはABAPレポート形式で表示され打事が多く、相対的には低い| ** 制約と注意事項 [#sc887f50] +動作環境は、クライアント PCに依存する部分が大きい クライアントPCに搭載されたExcel のバージョン、行列の表示制限、マクロのセキュリティ設定、GUIのバージョン、通信状況などの影響を受け、意図通りに動作するか否かが左右される。ヘルプデスクを悩ませる点。 +基本的に、軽くはない そもそも遅いと評されることも多く、充分なパフォーマンスを発揮するためには、並行して行う処理をある程度絞り込む、メモリを多めに搭載するなどの対応が必要となる場合も少なくない。 +テーブル結合やクロス集計以外のレポート形式が苦手 ExcelのPivotをはじめテーブル形式で出力するレポートはBWの得意とするところだが、こういったレイアウト以外での表示、例えば年初〜当月のような形式での表示は苦手。 +リアルタイム性が損なわれる SAPではリアルタイムにデータの取り扱いレポートを出力するなどが可能だが、SAP→BW間のデータ連携は、システム負荷を考慮してバッチ処理で行われるケースが多く、多くの場合はデータのリアルタイム性が日次レベルまで低下する。 +SAPとはライセンスは別扱い BWのライセンスはSAPとは別に購入しなければならず、金食い虫と呼ばれる所以。 中にはセットで契約するパターンもあるだが、多くの場合はSAとBWで利用者が異なるため、損か得かは微妙なところ。 * 主要な構成 [#g1931eae] まず、バージョンが3.xであるか7.0移行かで大きく全体像が異なる。 具体的には、下記が挙げられる。 -3.xまでは[[更新ルール>BW/更新ルール]]や[[転送ルール>BW/転送ルール]]だったものが、7.0からは[[変換>BW/変換]]という考え方に置き換えられた -また、[[インフォソース>BW/インフォソース]]の扱いが変更され、2つの[[変換>BW/変換]]を結合するための複数のオブジェクトで構成される構造となった -今迄は[[更新ルール>BW/更新ルール]]を経由しなければデータの変換ができず、データをConvertするには何度か格納しなおさなければならなかったが、今後は[[変換>BW/変換]]を行うことでデータの更新が容易になり、新しい[[インフォソース>BW/インフォソース]]を使用すると、データフローで2つ或いはそれ以上の連続変換が実行できるようになった。 -3.xでは[[ODS>BW/ODS]]と呼ばれていたオブジェクトは、7.0以降では[[DSO>BW/DSO]]と呼ばれるようになった なお、7.0においても3.xのインフォソースを使用することは可能だが、当然ながらSAP社は7.0より使用可能になった新しいタイプの[[インフォソース>BW/インフォソース]]を使用することを推奨している。 ** 主要オブジェクトとその役割 [#m5a82a37] -[[データソース>BW/データソース]] -[[インフォソース>BW/インフォソース]] --[[PSA>BW/PSA]] --[[転送構造>BW/転送構造]]（3.x） --[[転送ルール>BW/転送ルール]]（3.x） --[[通信構造>BW/通信構造]]（3.x） -[[インフォプロバイダ>BW/インフォプロバイダ]] --[[キューブ>BW/キューブ]] --[[DSO>BW/DSO]] --[[ODS>BW/ODS]]（3.x） --[[マルチインフォプロバイダ>BW/マルチインフォプロバイダ]] --[[更新ルール>BW/更新ルール]]（3.x） ** SAPとのつながり [#pafff069] *** データ連携 [#c480bb61] -[[データソース>BW/データソース]]からの連携 標準的な手法である[[データソース>BW/データソース]]からの連携は、BWからのPullで行なわれることが多く、イベント起動やRFCなどによるSAPからのPush方式は、あまり採用されない。 BW側より、転送するデータの抽出条件やアップロード先を設定した[[インフォパッケージ>BW/インフォパッケージ]]を実行することで転送が開始される。 ここでは、即時実行のほかJOB実行も可能であり、[[プロセスチェーン>BW/プロセスチェーン]]で表現しなければならないような複雑な条件でなければ、JOBのスケジューリングも可能。 7.0では、[[インフォパッケージ>BW/インフォパッケージ]]の代わりに[[DTP（データ転送プロセス）>BW/データ転送プロセス]]が用意されており、これを使用すると特定の[[変換>BW/変換]]に従ってデータを転送することができる。 -ファイルからのデータ転送 リカバリ・テスト・データ移行など、主にシステムに元データが存在しない場合に利用され、データを[[キューブ>BW/キューブ]]にアップロードするためにファイルインターフェースが用意されている。 このファイルインターフェースは、[[キューブ>BW/キューブ]]および[[ODS>BW/ODS]]毎に個別に設定する必要がある。 -セキュリティ間隔 一般的に、デルタデータ抽出中に出現し、例えば、保存されていなかったために 抽出できなかったレコードが次回の抽出中に考慮されるようにすることを目的として、セキュリティ間隔（通称：''安全デルタ時間''）を設定する。 例えばセキュリティ間隔を30分と設定しておくと、前回のデルタアップロード以降、且つアップロード開始時点から30分より前に登録されたデータがアップロード対象となる。 *** データ更新 [#x37a4cef] -完全更新 抽出条件に基づき、現在の[[キューブ>BW/キューブ]]へ登録状況を問わず、データの転送を行なう。 [[データソース>BW/データソース]]からの抽出において、タイムスタンプなど更新の条件として識別可能な項目を持たない場合、後述のデルタ更新に対応していないため、更新モードの設定画面でこちらしか選べない。 なお、同一条件でアップロードされた依頼を削除する機能があるため、それを利用した疑似的なデルタ更新を実現することは可能。 -デルタ更新 いわゆる差分更新で、初回更新時の設定条件に基づき、前回からの差分を抽出してデータ転送を行なう。 これには、タイムスタンプなどの前回実行分との識別が可能であることが条件であり、[[CO-PA>管理会計/収益性分析]]などのSAP標準においてはデルタ更新に対応したデータソースとなっているものも多くある。 そのため[[アドオン]]においてはデルタ更新が必要な場合はテーブル設計に加味する必要がある・・・と言うこともできるが、デルタ更新が必要となる対象はトランザクションデータあるいは履歴管理が必要なマスタであるため、アドオンでそういったものを管理することを、そもそも是とするか？という議論もある。 -フェイクデルタ 月単位とかでデータを洗い替えする方法とのこと。7.0から？ * misc [#z45da270] ** データの洗い替え [#y0cc39dc] -基本的な考え方 [[キューブ>BW/キューブ]]からダウンロード→Fileのデータを修正→アップロードという方法、或いは[[キューブ>BW/キューブ]]から[[PSA>BW/PSA]]へ転送→[[PSA>BW/PSA]]に格納されたデータを修正のうえ[[キューブ>BW/キューブ]]へアップロードという方法なども考えられるが、いずれも開発は必要であり、手作業によるミスが懸念される。 そのため、既に充分な試験を行い、品質が保証されている仕組みを用いるという意味において、[[データソース>BW/データソース]]からの再アップロードを行うことが基本。 なお、年度などの明確なデータ切り分けの基準がある場合に限られるが、元の[[キューブ>BW/キューブ]]はそのままとして、差分用の[[キューブ>BW/キューブ]]を新たに作成し、マルチで出力するという方法もある。 -差分情報の初期化 [[キューブ>BW/キューブ]]などBW側に項目を追加し、その項目に値を設定したいケースにおいてはデータの再生成を行う必要がある、その場合、更新方法がデルタの場合は差分情報を初期化しなければならない。 これにあたり、改めて全データを取り込みなおす場合はその限りではないが、最終アップロードの後に発生したデータの差分を取り込まずに初期化すると、取りこぼしが発生するため、差分情報に関してはSAP側のデルタキューを確認しつつ実施すること。 -データソースの確認 データを流し直しする場合は、SAP側あるいはファイルからの再アップロードが主となるが、これらの元データに全ての洗替対象のデータが残っていることを確認しなければならない。 ハウスキーピング、アーカイブ、ファイルの消失などを原因に必要なデータが失われてしまった場合、現在の状態を復元することができなくなってしまう。 ** 移送について [#zb3e1f78] -移送取得の流れ トランザクションコードRSA1より「移送接続」画面を開き、移送対象のオブジェクトを選択するという流れとなるが、そもそもBWのオブジェクト修正は、まずGUI側から[[BEx依頼>BW/BEx依頼]]という[[移送依頼>ベーシス/移送依頼]]を割り当てる必要がある。 これは「とりあえず、何らかの変更を加える場合に割り当てる[[移送依頼>ベーシス/移送依頼]]」と考えて差支えないが、クエリの修正時に関連オブジェクトが登録されている場合が多くあり、古いものを誤って移送してしまうことを防ぐため、一旦[[BEx依頼>BW/BEx依頼]]をリリースしてから改めて依頼を取得し直すのが一般的な流れ。 その後、また新たに[[BEx依頼>BW/BEx依頼]]を登録する。 -移送ログ クエリ関連オブジェクトは、英数字が羅列された内部IDで管理されており、SAPと違い、[[移送依頼>ベーシス/移送依頼]]」やログをトレースしてもオブジェクトを特定するのが困難。 その為、[[移送依頼>ベーシス/移送依頼]]」の取得時に、しっかり漏れや誤りがないように注意すること。 -移送の順番 SAP側で必要な[[データソース>BW/データソース]]やEXITの移送が正常終了していることの確認後に、BW側の移送を行うこと。 当然ながら、必要な移送がSAP側で行なわれていない場合あるいは失敗している場合はBW側でエラーとなる。 ** まとめ前のメモ [#m158ef16] -データの連携またはアップロードタイミング BWへのデータ連携やアップロードは、多くの場合、大量のデータが処理対象となり、レポートの表示速度に影響を与えるため、リアルタイムキューブを除いて営業時間中の更新は避けることが無難。 定期処理以外にアップロードする場合、特に使用率の高いキューブは、定時後や休日などにアップロードが行われるようにJOBを設定すること。 -旧バージョンで作成したクエリ 3.x以前の旧バージョンで作成したクエリを7.0以降の新バージョンで修正すると、旧バージョンで修正不可能になるなどのトラブルに見舞われるケースがあるため、修正するツール（GUI）のバージョンは統一すること。 -その他レイアウト関係 論理式に関連する[[キー数値>BW/キー数値]]や要素を追加した場合、その項目を論理式に忘れずに組み込むこと。 また、ワークブックやブックマーク（Web版）はレイアウトを記憶するため、あわせて注意。 -照会ログの扱い 触れられないことも結構ありますが、クエリのドリルダウン一回ごとにログが標準DBにたまるようになっている場合がある。 あるクライアントでは、稼働から一回も削除されておらず、稼働後4〜5年で30GBも溜まっていた事例もあるとのこと。 -セル定義 [[クエリ>BW/クエリ]]において、セルを指定して計算式を埋め込むことも可能。 ただし、ドリルダウンの仕方によっては、狙った通りに表示されなかったり、動作が重くなることもあるため、ある程度自由に切り口を定めるフリーレイアウトではなく、固定帳票向きの設定。 -並列読み出し [[キューブ>BW/キューブ]]からデータを読み出す際に、複数のプロセスを使用し並列で読み出すか否かを定めるConfigで、環境レベルで設定する。 裏を返すとプロセスを必要以上に使ってしまう可能性もあるため、単一プロセスの使用を推奨。 -権限設定について 権限設定は[[キューブ>BW/キューブ]]単位に施されることが多く、クエリ単位での設定はあまり行われない。 これは、単にクエリ単位での設定が煩雑であること、照会可能なデータの多くは[[キューブ>BW/キューブ]]単位で切り分けられるためにクエリレベルで制御する意義が薄いことなどが背景。 なお、一部のパワーユーザのみに限定してクエリの作成権限を開放する場合は少なくない。 -ビジネスコンテンツ 一般的に使用する[[インフォオブジェクト>BW/インフォオブジェクト]]、[[データソース>BW/データソース]]などのオブジェクトについては、ビジネスコンテンツと呼ばれるSAP標準のオブジェクトが用意されている。 * 関連 [#v6abd598] * BWのまとめページ [#v6abd598] [[BW/トランザクションコード]] [[BW/関連テーブル]] [[BW/分野メニュー]] #ls2(BW/,link,BWの関連ページ) * 関連ページ [#f017cb53] #ls() ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)