BASIS

5分で理解するSAPのシステム構成【移送とは?】

SAPの基本的なシステム構成(3システムランドスケープ・クライアント)について解説します。

ランドスケープやクライアントの基本理解は、Basisチーム(インフラチーム)だけではなく、SAPの開発・運用保守にかかわる人にとっての必須知識です。というのも、プログラム開発やカスタイマイズに伴う「移送」を行う上で、それらSAPの基本システム構成を知らないと思いがけないミスを招くためです。

このページで学べる内容

  • システムランドスケープとは?
  • クライアントとは何か?
  • クライアント依存/クライアント非依存の違い
  • 移送とは何か?

SAP関連の仕事に携わる方であれば、知らないと恥ずかしい内容ばかりですので是非最後までご覧ください。

それでは早速解説を始めます。

SAPのシステム構成

まずは本ページで解説する内容の前提です。

まず、SAPのシステム構成は、導入する企業ごとに異なります。(SAPだからといって完全に同じシステム構成をしているわけではありません。)会社Aと会社Bで、同じSAPを利用しているのに構成が全く違うということもあり得ます。

そのため、SAPのシステム構成は一概に「〇〇」である!というような説明ができないことを予めご了承ください。このページでは考え方の土台となるシステム知識について網羅的に整理していきます。

早速、SAPシステム構成の土台となる「3ランドスケープ」について解説します。

3システムランドスケープ【開発機・検証機・本番機】

【イメージ】3システムランドスケープ

SAPのシステム構成は、3システムランドスケープが基本形です。ここでのランドスケープは「システム構成」と言い換えていただいてOKです。

※3システムランドスケープは、省略して「3ランドスケープ」、単に「ランドスケープ」と呼ぶこともあります。

SAPでは、システム構成を「開発機」「検証機」「本番機」の3階層で構成することが基本となります。あえて「基本」というのは、例外も存在するためです。様々な事情により、例えば本番環境と全く同じような「本番同等環境」を作るような場合もあります。

「開発機」「検証機」「本番機」については、何となくその名前を聞いたことがある方もいるかもしれませんが、改めて各ランドスケープの役割について解説していきます。

開発機―システムランドスケープ①

開発機はその名の通り開発を行う環境です。もうちょっと詳しく説明すれば、「アドオン開発」「カスタマイズ」を行う環境といえるでしょう。

開発機では、一部サンドボックス(何をしてもOKな環境)的に利用することもあります。

全ての資源(プログラム・カスタマイズデータ)が、この開発機で作成され検証機・本番機へ移送(反映)される仕組みをとります。そのため、開発機を実際に触るのはABAPerやSAPコンサルが中心です。Vモデルでいう、開発~単体テストフェーズで用いられる環境です。

開発機のまとめ

  • 開発・カスタマイズが行われる環境である。
  • 開発資源はすべて開発機で作成・設定される。

検証機―システムランドスケープ②

検証機(もしくはテスト機)は、その名の通りあらゆるテストを実行するために用いられる環境です。

開発機から送られてきた資源は、この検証機上でテストされ問題がなければ本番機へと移送されます。

検証機はあくまでも検証・テストのための環境であるため、検証機上での開発(プログラム開発)やカスタマイズを行ってはいけないのが原則です。検証機上で資源をいじってしまった場合、本番機へ移送する資源とテストする資源に差異が出てしまうため、本番機上でバグが出てしまったりする可能性が高まります。

検証機のまとめ

  • 検証機はあらゆるテストを行う環境
  • 検証機で資源を修正するのは禁止。資源の修正は必ず開発機で行う。

本番機―システムランドスケープ③

本番機は、実際のユーザが利用する環境を指します。

通常、開発者・運用/保守メンバーがこの環境で何か作業をすることはありません。(単純なデータ抽出作業など、開発資源やトランザクションデータに影響を与えないことが保証されている作業については一部例外があります。)

本番機で障害が起こった場合でも、本番機を直接触るのではなく、本番機と同等の検証機上で調査を行えるように3ランドスケープが用いられます。

本番機のまとめ

  • 本番機は実際のエンドユーザが利用する環境。
  • 本番機上でのシステム作業は基本NG。

3システムランドスケープのメリット

3ランドスケープのメリットは、本番機上でのバグを未然に防ぎつつ効率的な開発が可能となることです。

例えば、もし仮に本番機しか存在しないシステム構成であればどうでしょうか?

プログラム開発も、カスタイマイズも、テストも本番機で実行するしかなくなります。本番機でテストを実行してしまえば、実際の業務データに影響を与えてしまいますし、バグも本番機上でしか検知することができません。システム運用にとっての大きなバリアとなります。

そのため、本番機以外に開発・検証用の環境を定義しておくことは非常に重要となります。

では、検証機の存在意義はなんでしょうか?開発機と、本番機さえあれば、上記のバリアは取り除けるのでは・・・?こんな疑問も出てくるのではないかと思います。

確かに、検証機については必ずしも必須というわけではないのではないかと考えることはできます。そのうえで、なぜSAPでは3システムランドスケープを採用しているのか?ここからは推測も含みますが、検証機があると以下のようなメリットを享受することができます。

  • 開発とテストを同時並行でできる
    ⇒ 検証機がないと、プログラミング中はテストができなくなる。
  • 移送のテストができる
    ⇒ 「開発機→検証機」の移送は本番機移送の検証となる。
  • 業務ユーザの練習環境ができる
    ⇒ 本番機で試してみる、という危険を防ぐことができる。

SAPを導入する企業は大企業であることが普通なため、特に上記の3点の絵=メリットはますます大きくなるといえるでしょう。

そのうえで、企業の規模が大きくなればなるほど、3ランドスケープでは耐え切れなくなる場合が出てきます。「検証機の他に、ユーザ練習環境が欲しい」「なんでもできるようなサンドボックス環境が欲しい」―。

こんな要件に応えることができるのが、「クライアント」という概念・仕組みです。

クライアント

SAPでは、1つのシステム上に複数の環境を定義することができます。この複数の環境をSAPでは「クライアント」と呼びます。

ランドスケープの中に複数のクライアントが存在する

複数のクライアントを持てることにはいくつかのメリットがあります。

例えば、目的別に「プログラム開発環境」「カスタマイズ環境」「単体テスト環境」・・・・等の環境を保持したい場合を考えます。仮に、SAPの「クライアント」という概念がないとすると、目的を達成するにはサーバを複数用意し、それぞれにSAPをインストールする必要が出てきてしまいます。

SAPでは、クライアントを定義することで1つの物理的なシステム上に、複数の環境を定義できるため、サーバを複数持つ必要がありません。したがって、システム運用に関するトータルコストを抑えることができるのです。クライアントは、プロジェクト開始時点で定義され、以後システムが廃棄されるまで同様に利用され続けるので、初期段階での設定方針は熟考して決定する必要があります。

さて、ここまででSAPのランドスケープ・クライアントの仕組みについてみてきました。

ここからは、最後「移送の仕組み」について解説を加えます。

移送とは?

移送とは、開発した資源(プログラムやカスタマイズなど)を各環境へ反映することです。通常は、開発機で作成したプログラムを検証機へ、そして検証機から本番機へと資源が反映されていきます。

移送のイメージ図

このページでは、実際に「移送」がどのような仕組みで成り立っているのかを少しだけ深堀してみたいと思います。

移送手順①―移送依頼番号の取得

移送は、「移送依頼番号」単位で行われます。

プログラムの修正や、カスタイマイズの修正を行うと自動で番号取得の画面が表示されるようになっています。この番号をキーに、インフラチームが検証機・本番機への移送を行います。

※基本は自動的に上記画面が表示されますが、たまに自動表示されない場合も存在します。

この移送依頼番号の取得は、「どの資源に修正が加えられたか」を特定する行為と同等です。すなわち、移送依頼番号を取得したタイミングのプログラムがそのまま移送資源となるわけではなく、移送依頼のリリースをしたタイミングのプログラムが移送資源となる点に注意です。

移送手順②―リリース

開発が完了したら(これ以上修正がないことを確認したら)を依頼をリリースします。

リリースは先ほど解説した通り、移送資源を確定する行為と同等です。もし、同じ資源に対して再度の修正が必要になれば、新しく移送依頼番号を取得する必要が出る点に注意しましょう。

移送手順③―エクスポート・インポート

移送資源の実態は「ファイル」です。資源を1つのファイルにまとめて、そのファイルを取り込むことで移送が完了します。

【イメージ図】移送

移送はファイルなので、そのファイルさえあればどの環境にも適用することが可能です。(あまりにトリッキーなことをするとエラーになりますが)

通常は、開発機・検証機がネットワークでつながっているため、リリース後に移送対象の環境で直後にインポートが可能です。が、これはあくまでも事前に移送ファイルの連携経路が設定されているために可能な仕組みです。

クライアント依存/非依存

移送管理における最大の注意点です。

移送を行うときは、対象の資源がクライアント依存なのか非依存なのか?を意識する必要があります。

クライアント非依存というのは、全てのクライアントに共通する資源のことです。

【イメージ図】全てのクライアントに共通

クライアントAで変更をすれば、クライアントBもクライアントCも変更されることになります。

  • プログラムは基本クライアント非依存

逆にクライアント依存というのは、そのクライアントでのみ変更が反映される資源です。

クライアントB/Cには変更が反映されない

上記の図を見ればわかるかと思いますが、クライアント依存の移送資源の場合「全てのクライアントで移送ファイルをインポートする必要」があります。

  • カスタマイズは基本クライアント依存

クライアント依存/非依存の区別方法

クライアント依存/非依存の区別をシステムから区別する方法があります。

トランザクションコードSE11:ABAPディクショナリからテーブルを確認する方法です。

もし、ここにクライアントを示す項目「 MANDT 」があれば、そのテーブルに格納されているデータはクライアント依存に、なければクライアント非依存になります。

  • MANDTがある ⇒ クライアント依存
  • MANDTがない ⇒ クライアント非依存

SAP開発においては、個々のプログラムやカスタマイズの知識に加えて、このページで解説したような全体像の理解が必要となります。特に、移送管理の観点から、システム構成については基本理解が必須です。

本記事が基礎理解の一助となれば幸いです。