ユーザとは、AsJAVAシステムを使用する個人又はアプリケーションで、それぞれ一意なIDを持ちます。
ユーザにグループやロールを割当することができます。

UMEからAsABAPシステムをアクセスするためのABAPユーザを作成します。

• ユーザタイプ
  システムと指定する必要があります
• ロール
  以下の何れかを割り当てる必要があります。
  • SAP_BC_JSF_COMMUNICATION
    UMEからABAPユーザを修正、削除できます。
  • SAP_BC_JSF_COMMUNICATION_RO　
    UMEからABAPユーザデータを参照するのみです。

UME-ABAP 間の通信のためのシステムユーザ要件-SAP Help Portal

通信ユーザのアカウントとパスワードを登録します。

会社機能を利用することによって、一つのAsJAVAシステムの上に会社別の仮想システムを作成することができます。

• 記号なしリスト
• 会社別に管理ユーザを設定することができます。

会社機能は主に下記二つのパラメータの設定により制御されます。

• ume.tpd.imp.class　
  実装クラス名
  標準では以下の二つがデフォルトで用意されていますが、アドオン開発も可能です。
  • com.sap.security.core.tpd.abap.R3GroupTPD
  • com.sap.security.core. tpd.SimpleTPD
• ume.tpd.companies　
  指定可能な会社を指定します。このパラメータはume.tpd.imp.class=com.sap.security.core. tpd.SimpleTPDの場合のみ有効です。
  以下のように値を指定することができます。指定された会社のどちらにも所属していないユーザはゲスト会社を設けて纏めることができます。
  • 0:会社機能を利用しない
  • 1:1会社のみが設定されます。
  • 2:internal、externalの2会社が設定されます。
  • 会社リスト:カンマ区切りの会社名リストで複数会社を設定できます。

• Configuring Delegated User Administration Using Companies
  7.027.27.37.47.5

グループはユーザの集まりです。

ユーザをグルーピングする基準は要件しだいですが、運用では職務や部署などが利用されることが多いと考えられます。

コンセプトでは、UMEのグループはAsABAPシステムのユーザグループ(SUGRで管理)に相当するものです。

グループを使用することにより、各ユーザを所属しているグループ単位で纏めて権限を制御することができます。

グループは親子関係を持たせることにより、グループの階層を作成することができます。
このようにグループをネスト化することで、たとえば企業の階層を表すことができます。

デフォルトグループ(英：Built-in Group)は、システム実行時にUMEより自動的に生成されます。
3つのデフォルトグループがあります。

• すべてのユーザ
• 匿名ユーザ
• 認証済ユーザ

デフォルトグループは、UMEデータベースにも保存されることがなく、ユーザにより作成や削除、名前変更することができません。

AsABAPシステムがUMEのデータソースとして使用される場合、ABAPロールは自動的にUMEの同名のABAPロールグループとして読み込まれます。

ABAPロール割当はUMEでユーザからグループへの割当として処理されます。

会社グループ(英：Built-in Company Group)は、会社の設定時にUMEによって生成されます。

会社グループ、UMEデータベースにも保存されることがなく、ユーザにより作成や削除、名前変更することができません。

会社グループ機能を有効化するには、以下のUMEパラメータの値をTrueにする必要があります。
ume.company_groups.enabled = true

なお、どの会社にも所属しないユーザをゲスト会社グループに割り当てることができます。
ゲスト会社グループ機能を有効化するには、以下のUMEパラメータの値をTrueにする必要があります。
ume.guestcompany_groups.enabled = true

UMEグループは、UME管理機能からユーザにより明示的に作成されるグループです。
UMEグループはUMEのローカルデータベースに保存されます。

UMEのユーザ及び権限管理以下の要素から構成されます。

• ユーザ管理
• 権限制御
• 会社機能

AsJavaシステムを利用する個人や他のアプリケーションプログラムは、匿名ユーザを除く、すべてUMEで一意なIDをもって管理されます。
職位や部署など、同じ属性をもつユーザを纏めて権限などを管理できるような仕組みとして、ユーザの集まりを示すグループというコンセプトがサポートされています。

UMEの権限管理の仕組みは、アクションとロールから構成されます。
アクションはどんな処理ができるかという権限を示すものです。
アクションはABAPシステムの権限オブジェクトに相当します、ABAP権限オブジェクトと同じ、アクションもプログラム実装やシステムコンフィグにより定義されるものです。そのため、ユーザからできる作業は割り当てだけです。

アクションをロールに割り当てて、さらにロールをユーザやグループに割り当てることにより、ユーザ毎の権限制御が実現されます。
下記の図でそのイメージを示します。

(source : sap help portal)

会社機能を利用すれば、一つのAsJAVAシステムに会社毎の仮想システムを構築して、複数の会社を互いに影響せずに共存させることができます。

UMEのアーキテクチャは以下の階層図で示すことができます。

(source : sap help portal)

UMEのエンジンはライブラリとしてAsJavaのコアに組み込まれています。

• SC:SERVERCORE
• DC:com.sap.security.core.sda

UMEを利用するアプリケーションに統一したAPIはまた別に提供されています。

• SC:ENGINEAPI
• DC:com.sap.security.api.sda

ユーザ管理など、標準で用意された管理ツールは主に以下のSCで配布されています。

• SC:UMEADMIN
• DC:多数

標準で用意されたユーザ管理機能はWebUIから利用することができます。
以下はポータルからアクセスした画面のイメージです。

ポータル画面の利用を含めて、ユーザ管理機能のWebUIをアクセスするには、下記のような方法があります。

• ポータル画面利用から　
  ナビケーションパス：ユーザ管理(User Management)
• NWA画面から　
  ナビケーションパス：設定管理(Configuration Management)–セキュリティ(Security)–ID管理(Identity Management)
• スタートページから
  ナビケーションパス：User Management
• 直接URL指定
  URL：http://host-ip:host-port/useradmin

UMEはさまざまなパラメータが用意されています。パラメータの値を変更するには、ローカルツールによるオフライン変更とWebUIによるオンライン変更の二つの方式があります。
オンライン変更の場合、パラメータによって、変更後にAsJAVAを再起動する必要があるものとないものが存在します。

オフライン方式はConfigtoolを使用します。以下の図でイメージを示します。

オンライン方式はWebUIを使用します。ポータルからアクセスしたUME設定画面は以下のイメージです。

「Open Expert Mode」ボタンを押下すれば、パラメータ名を指定することによって、全パラメータの値を設定可能になります。

ポータル画面の利用を含めて、UME設定のWebUIをアクセスするには、下記のような方法があります。

• ポータル画面利用から　
  ナビケーションパス：システム管理(System Management)–システム設定(System Configuration)–UME設定(UME Configuration)
• NWA画面から　
  ナビケーションパス：設定管理(Configuration Management)–セキュリティ(Security)–ID管理(Identity Management) –設定(Configuration)ボタン

ポータル管理画面→システム管理タブ→移送→ナビゲーション(移送パッケージ→エクスポート) 
①移送パッケージを新規作成 
②移送パッケージに全オブジェクトを追加、エクスポート 
③エクスポートファイルをダウンロード

ポータル管理画面→システム管理タブ→移送→ナビゲーション(移送パッケージ→インスポート) 
①インポートファイルをアップロード 
②インポート

ポータルロールは、コンテンツをどのようにグループ化するか、コンテンツを SAP NetWeaver Portalにどのように表示するかが定義されます。 
ユーザ、またはグループをポータルロールに割り当てることによって、ユーザまたはグループがどのコンテンツをポータルに表示するかを定義します。割当時、ロール割当ユーザ権限のチェックが行われ、ロールを割り当てるための適切な権限を保有しているかどうかが確認されます。

ポータルロールのほかにユーザマネジメントエンジン (UME) ロールがあります。UMEロールによって、権限のセットが定義されます。但しUMEロールはポータルの表示を制御することができません。

ポータルロールの構成要素はおもに以下のようなものがあります。

• ページ: 
  レイアウトと割り当てられたiViewで構成されるiView のコンテナです。
• iView: 
  社内やインターネットのコンテンツソースからデータを取得し、ポータルのコンテンツエリアに表示するプログラムです。
• ワークセット: 
  特定の活動分野に属するタスク、サービス、情報のコレクションです。
• メニュー: 
  ワークセットとメニューの組み合わせを作成し、ロールに紐付けることでユーザーごとに異なる画面を表示することが可能です。

標準のgeneral/eu_role、super_admin/super_admin_roleとカスタマ作成のRoleT1を持っているユーザを例として取り上げて、ポータルの表示を示します。

• ユーザノポータル表示 
  
• general/eu_roleのコンテンツ定義 
  
• super_admin/super_admin_roleのコンテンツ定義 
  
• RoleT1のコンテンツ定義 
  

ポータルとは、以下の図で赤い枠線が示した通り、表示されているコンテンツおよびそのレイアウトを含むポータル画面全体のことです。

ポータル画面全体は以下の図で示されるように、大きく分けると、ヘッダエリア/ページタイトルバー/ナビゲーションパネル/コンテンツエリアの四つのエリアから構成されます。

トップヘッダエリアは、主にシステムの各ページに不変なヘッダ内容が表示されます。例えば、会社のロゴやシステムの名前、検索のツールボックスなどはよくこのエリアに含められます。 
概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

ツールエリアは、ポータルにナレッジマネジメント (KM) がインストールされている場合に限り表示されます。

トップレベルナビゲーションは、ユーザに割り当てられたロールのコンテンツをアクセスするためのタブを並べられるバーエリアです。 
設定により、2行目に選択中のロールの第1階層のサブフォルダを表示させることができます。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

表示されたページのパーソナライゼーション、ナビゲーション、およびアクションのオプションに関する情報などはこのエリアに表示されます。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

ページタイトルバーの直下にある左側のペインはナビゲーションiView 用に予約されており、これにはコンテンツツリー、インタフェースコントロール、各種コンテンツへのリンクが含まれています。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

この部分は本体のコンテンツが表示されます。コンテンツはiView が含まれるページまたは単独の iView です。ページ/iView 間のナビゲーションを行うと、内容が変化します。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

EP(Enterprise Portal)はSAP NetWeaver PlatformのWEBフロントエンドとして機能します。 ポータルのほか、以下の機能も統合されておます。

• ナレッジマネジメント 
  さまざまなデータソースの非構造化情報にロールベースでアクセスすることができます。
• コラボレーション 
  社内の同僚や他の従業員との通信/連絡および連携に役立つサービスを提供します。
• ガイドプロシージャ 
  複数のバックエンドシステムへのアクセスを伴うプロセスをモデリングし、管理するためのフレームワークです。

ポータル機能を利用するためにNetweaverから用意された利用タイプはEP(エンタープライズポータル)です。 
EPの一部基本機能を抜き出してEPC(EPコア)という利用タイプとしても提供されております。EPCはEP利用の前提条件になります。

以下の表でそれぞれの機能構成を示します。

EPCの管理ロール 
Super Admin ポータル管理環境のすべての管理ツールが含まれています。 
Content Admin ポータルでコンテンツを登録および更新するためのツールが提供されます。 
User Admin ポータルでのユーザ管理およびロール割り当てを行うためのツールが提供されています。 

主に下記の二つあります。

• 変更歴史の記録 
  バージョン間の変更点を確認したり、ふるいバージョンに戻したりすることができます。
• 統合時の判断 
  ソースファイルを統合する際に、バージョンを比較して統合できるかを判断できます。

DTRはファイルとワークスペースと二つのレベルでバージョン番号を管理しています。

ファイルはそれぞれ個別のRev No.(リビジョン番号)をもっています。 
Rev No.は、ワークスペース内で採番されます。1から始まり、ファイルが変更されるたびに一つずつあがっていきます。
ファイルのRev No.はNWDSで確認することができます。

• 対象ソースを指定、コンテキストメニューから「Revision History」を選択 
  
• Revision一覧を表示 
  ISNなども表示されますので、後ほどの説明に関わります。 
  

ワークスペースレベルのバージョン番号は、ISN (Integration Sequence Number、統合順序番号)と呼ばれます。 
ワークスペースにチェックインされた変更には、そのワークスペース内で適用される一意なISN番号が割り当てられます。

ワークスペースへの変更は、アクティビティによるものと、伝播(Propagation)によるものがあります。

• アクティビティ 
  ローカルワークスペースで行った修正
• 伝播
  トラックに跨ってインポートされる変更

ワークスペースが統合されるときに、ファイルのバージョンが統合されます。

バージョングラフから、ワークスペースに跨ったファイルのバージョン歴史を確認することができます。 
そこで、ワークスペース間でどうな統合が発生したのか、次の統合にコンフリクトも確認できます。

(このトピックは編集中です。)

アクティビティ(英：Activity)はDTRへ対する変更の開発及び移送の管理単位です。ABAPスタックにおける変更依頼に相当します。

アクティビティはOpenとClosedとの二つのステータスがあります。

• Open Activity 
  変更中のアクティビティです、ここで行う任意の変更を元に戻すことができます。
• Closed Activity 
  チェックインした後のアクティビティです。これらのアクティビティを変更することはできなくなります。

このセクションはアクティビティ のライフサイクルを順次説明します。

DTRはファイルバージョン管理を提供するリポジトリです。SAP のカスタマサイトやパートナサイト、および SAP 自社開発で使用されます。

DTRは以下のコンセプトがあります。

• ソースコード及びバージョンを一元管理 
  DTRでは、すべてのソースプログラム及びバージョンはセントラルデータベースで一元管理され、 標準DeltaVおよびWebDAVアクセスプロトコルによってDTR クライアントに階層ファイルシステムを公開されます。 
  そのため、DTRはCVS、SVNと同じ、集中型バージョン管理システムといえます。
• 変更を確実に管理 
  ソースコードに改修が発生する時に、まず変更依頼を作成しておかないといけない、改修はすべて変更依頼に記録されます。 
  これは本来プロジェクト管理システムの一部機能であり、よくチケットやチケット駆動開発と呼ばれています。DTRに統合されることにより、システムの変更がすべて確実に管理されることになります。
• ライフサイクルの各フェーズを統合的にサポート 
  開発やテストの各フェーズの間にソースの変更と移送が一元管理されます。

(source: sap help portal)

DTRリポジトリは、複数の論理開発ロケーション(仮想リポジトリ)から構成されます、その論理開発ロケーションはワークスペースと呼ばれます。

ワークスペースはDTR構造の基本要素であり、以下のような仕組みで機能しています。

• ソフトウェアコンポーネント単位でワークスペースが分けられます。
• 4システムランドスケープの中でDEVとCONSが異なるワークスペースを使用、TESTとPRODが持たないことが多い
• 各システム(DEV、CONS）を無効と有効との二つのDTRワークスペースで表現。全ての変更は無効なワークスペースで実行し、ビルドが完了したソースのみが有効なワークスペースに格納されます。有効なワークスペースはCBSで利用可能なアーカイブと常に同期します。
• 同じソースはワークスペースに跨ってDTR全体で一元管理されます。そういう意味で、ワークスペースはSVN、GITなどのような一般のバージョン管理システムにおけるブランチに相当するものと考えられます。

以下、DTRの構造のイメージです。 

 
system-tools 
-|administration 
-|reports 
--|Activity Search 
--|Conflict Search 
--|File/Folder Search 
--|Resource Lookup 
--|VersionSet Comparison 
--|Workspace Comparison 
--|Workspace Integrations 
ws 
-|track_1 
--|sc1 
---|cons 
----|active 
----|inactive
---|dev   

サポートツールでは、CMS管理用の幾つかのツールが提供されております。

URL:http://host:port/CmsSupportTool/

CMSシステムで発生していた各プロセス(インポート、ビルド、承認)の情報を照会できます。

CMSシステムで作成されていたアクティビティを検索することができます。

指定ソフトウェアコンポーネント(SC）が取り込まれたトラックを検索することができます。

指定トラックに取り込まれたソフトウェアコンポーネント(SC)の情報を照会できます

システムステートを削除できます。

以下の図でトラック内移送の概要を示します。 

開発者側の作業はすべてNWDSで実施されます。

開発者が作成又は変更したソースをチェックインしたら、該当ソースはDTRのinactiveワークスペースからactiveワークスペースに反映され、有効化されます。 
ソースが有効化すると、元開発者が保持したロックが解放されるため、同じ開発設定を使用するすべての開発者から再度修正をかけることができます。 
有効化されるソースは、CBSにより再ビルドされます。

有効化及び開発システムでのテストが正常に完了すると、開発者はアクティビティをリリースし、CMSに変更を転送します。 
これによって、開発者に選択された全てのアクティビティが一つのリリースに纏められ、コンソリデーションシステムのインポートキューに格納されます。

ABAPスタックの移送ディレクトリと異なり、インポートキューはファイルシステムではなくデータベースにされます。 
CMS_TQUEUE：インポートキュー 
CMS_THISTORY:インポート履歴 
CMS_RCHANGELIST: 変更依頼の割当

管理者側の作業は、WEB画面のTransport Studioで実施されます。

インポートは、インポートキューに入っている変更依頼を選択してコンソリデーションシステムに取り込みします。 
CMSによって、自動ビルドと関連する実行時システムへの自動デプロイが行われます。

ログファイルです。 
CMS/log：　エクスポート及びインポートのログ 
CMS/archives:　エクスポート時に生成されるscaファイルおよびpraファイル 
CMS/CBS`: デプロイのためにCBSによって生成されるsdaファイル

アセンブリは構築のことです。 
この間に変更依頼が収集され、それに基づいて、すべての変更依頼を含めたSCバージョンが作成されます。 
個々の変更依頼はこれ以降の転播に使用されません

承認とは、テストシステムで検証が完了したSCを本稼働システムへの移送を許可することです。 
承認によって、本稼働システムのインポートキューにSCが格納されます。

現場レベルのシステム開発環境は通常、連続する複数の開発トラックで構成されます。以下の理由がよくあげられます。

• 複数の検証環境が存在するため、複数のトラックを定義する必要
• 開発と保守を分けるため、複数のトラックを定義する必要
• ソフトウェアコンポーネントを別々開発するため、複数のトラックを定義する必要

(source:SAP Help Portal)

トラック間移送を行うには、トラック間の接続を設定しておく必要があります。

開発トラックとは、1つの開発の流れを定義します。

開発トラックには、開発されるSCのさまざまな開発ステータスの開発設定及び実行時システムが含まれます。

(source: SAP Help Portal)

セントラル開発システム(DEV)では、開発者のローカルPCで作成したソースを個々の開発者がさらにテストをします。

コンソリデーションシステム(CONS)は、特定の固定ステータスのSCの統合とそのSCの追加テストに使用されます。

その後、本稼働システム(PROD）へ適用する前に、テストシステム(TEST)でSCの新規バージョンを最終テストをします。

必要に応じて、これらの4つのシステムロールを実行時システムに割り当てることができます。実行時システムでは、インポート時に自動的にデプロイが実施されます。

• 開発トラックを使用した作業 - SAP Help Porta

CMSはソフトウェアの変更を一元で管理可能にするサービスです、JavaシステムのCMSはABAPシステムのCTSと同等します。

CMSのコンセプトは主に以下になります。

• ソースの改修を開発システムに限定します。
• 手作業ミスをなくし、システムにより改修内容を確実に開発システム→テストシステム→本番システムの間に移送します。
• ソフトウェアの構築とデプロイを自動化可能にします。

開発ドメインは、システムランドスケープ全体の構成を定義します。

開発ドメインには複数の開発トラックを含めることができます。

開発トラックは一つの開発の流れを定義します。 
一つの開発トラックには、一つ以上のソフトウェアコンポーネントの開発、テスト、本稼働に必要な開発設定と実行時環境がすべて組み込まれます。

CMSにおけるシステムは、厳密的にはシステムロールのことであり、開発設定と実行環境から構成され、各フェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。 

CBSはシステムの構築作業を集中管理可能にして、 NWDIにおいて中心的な役割を果たしています。

CBSは主に以下の機能を提供しています。

• オンデマンドのビルド 
  変更のセントラルビルドは依頼によりリアルタイムで発生します。変更がチェックインして有効化される際に自動的に依頼されることもあれば、管理者が明示的に指示することもあります。
• ビルド結果およびビルドツールの一元的な保管
• 有効化コンセプトの保証 
  開発オブジェクトの無効および有効ステータスが区別されます。無効ステータスのオブジェクトから有効ステータスのオブジェクトに変更を渡すには、これらを有効化しなければなりません。この前提条件は、変更された開発コンポーネントのセントラルビルドが正常に行われていることです。

NWDIの管理ツールを利用するフロントエンドは、おもにNWDSとWEB画面との2種類があります。

NWDSでは、NWDIをアクセスするためのフロントエンドツールとして、さまざまなパースペクティブとビューが組み込まれています。 

• Component Browserビュー 
  以下の作業を実施することができます。
  • SC/DCを照会
  • DCをローカルに取り込み、プロジェクトを作成
  • SCをscaファイルにExport
  • DCをビルド、デプロイ
• Component Propersビュー 
  以下の作業を実施することができます。
  • コンポーネントの構成や依存関係を照会

• Repository Browsesrビュー 
  以下の作業を実施することができます。
  • ソースファイルの内容及び履歴などを照会
• Open Acvitiesビュー 
  以下の作業を実施することができます。
  • 未チェックインのActivityを照会
  • 変更をチェックイン
  • 変更を廃棄
• Closed Acvitiesビュー 
  以下の作業を実施することができます。
  • チェックイン済のActivityを照会
• Integration Conflictビュー 
  以下の作業を実施することができます。
  • ワークスページ統合時に発生したConflictを照会、処理
• Version Graphyビュー 
  以下の作業を実施することができます。
  • ソースファイルのトラックに跨ったバージョン履歴を図で表示

• Transport Viewビュー 
  以下の作業を実施することができます。
  • 未リリースの変更依頼をリリース
  • 未リリースまたはリリース済の変更依頼を照会

• Activation Viewビュー 
  以下の作業を実施することができます。
  • チェックイン済のActivityを有効化
• Activation Requestビュー 
  以下の作業を実施することができます。
  • 有効化リクエストのステータスを確認

URL:http://domain:port/devinf/main 

URL:http://domain:port/dtr/

URL:http://domain:port/webdynpro/dispatcher/sap.com/tc~SL~CMS~WebUI/Cms 

URL:http://domain:port/webdynpro/dispatcher/sap.com/tc.CBS.WebUI/WebUI 

NWDIを使用した開発の流れは製品・リリース毎に設計、管理され、通常、開発準備→開発→移送及びテスト→本番稼働→運用保守などのフェーズに分けられます。
NWDIで開発流れは開発トラックで定義されます。
製品が本番稼働後、大きなアップグレードは別のリリースをとり、新しい開発流れを起こしますが、不具合修正やある程度の機能改善は、運用保守フェーズとして、同じ開発流れで対応するのが一般的です。

NWDIを使用した開発を始めるまえに、まず下記のようにNWDIの環境を整える必要があります。

• 構成要素(DTR、CBS、CMS、SLDなど)のインストール
• システムランドスケープに関する情報の更新

開発準備は以下のステップがあり、基本は管理者の作業となります。

1. ユーザ及びロールの登録　UMEAdmin
2. 製品及びソフトウェアコンポーネントの作成　SLD
3. 名称領域の予約　ネームサーバ
4. CMSドメインの作成　CMS
5. システム、トラック、開発設定の作成　CMS 
   トラックによって1つ以上のSCで構成されるリリースの開発フェーズが定義されます。 
   開発設定は、SCの特定のステータス(DEV、CONS）の開発に必要です。
6. 必要なソフトウェアコンポーネントの確認とインポート　CMS
7. ローカル開発環境の設定　NWDS

開発は、開発者の作業であり、ローカルのNWDSを使ってNWDI各サービスに接続して実施します。

開発作業は主に以下のステップになります。

1. チェックアウト
2. ソースの作成又は変更
3. ビルド
4. ローカルテスト
5. チェックイン
6. セントラルビルド、有効化
7. デプロイ
8. リリース

CMSを使用して、移送、テスト、アセンブリを行います。 
移送、アセンブリは管理者の作業であり、テストは開発者又はテスタが実施します。

CMSを使用してソフトウェアコンポーネントのバージョンを出荷します。

NWDIのコンポーネントモデルは、製品、ソフトウェアコンポーネント(SC)と開発コンポーネント(DC)の三つのレイヤから構成されます。 
開発コンポーネント(DC)にはさまざまな開発オブジェクトが含みます。

製品は、 価格設定と販売の単位であり、一つ以上のソフトウェアコンポーネントを集めたものです。1つのソフトウェアコンポーネントを複数の製品に含めることができます。
SAP社が販売した「製品+バージョン」は3000近くあり、その中に一番有名なのはSAP ERPに違いがないです。 
SLDの「製品とソフトウェアコンポーネントの照会」画面から、SAP社の製品を確認することができます。 

ソフトウェアコンポーネント (SC) は出荷およびインストールの単位であり、開発コンポーネントを重複せずにまとめたものです。 
通常のファイル形式はSCA形式です。

MDM(Master Data Management)という製品を例として、SLDの「製品とソフトウェアコンポーネントの照会」画面から製品の中身を確認してみます。

上記の図で示した通り、MDM製品には数多くのソフトウェアコンポーネントが含められております。 

開発コンポーネント (DC) は開発およびビルド、デプロイの単位です。 
開発コンポーネントは、明確な外部インタフェースとカプセルされた内部実装があり、他のコンポーネントのパブリックインタフェースを参照して相互使用することができます。そのため、基本的な再利用可能な単位になります。

通常のファイル形式はSDA形式です。

以下はNWDSから取得したDCのコンポーネントプロパティビューのイメージです。 

開発オブジェクトは、コンポーネントの構成要素で、機能部分を提供します。

ソフトウェアの保守は、パッチ、サポートパッケージ、アップグレードの3つのレイヤに分かれます。

パッチ(英：Patch)は開発コンポーネント(DC)レベルで配布されます。主に発見されたプログラムバグを修正するために開発、適用されます。

パッチにソースが含まれている場合、CMSのリソースを使用してインポートする必要があります。

サポートパッケージ(英:Support Package、略：SP)は、ソフトウェアコンポーネント(SC)レベルで配布されます。、幾つかのパッチを含みます。

サポートパッケージにソースが付属している場合は、CMSを使用して、トラックにサポートパッケージをチェックインして移送する必要があります。 
サポートパッケージにアーカイブのみが含まれる場合、SDMを使用して関連するシステムに直接インポートすることができます。

製品にどんなサポートパッケージが提供されているかは、SLDの「製品とソフトウェアコンポーネントの照会」画面から確認できます。

アップグレードは製品単位で実施されます、製品に大きな機能強化や新規機能の追加があった場合、新しいリリースが配布されます。 
アップグレードはCMSを使用しません。

開発の視点からは、開発モデルの基本構成となるものは、ソフトウェアコンポーネント(SC)と開発コンポーネント(DC)になります。

• SCは複数のDCを纏める大きい単位になり、SC情報とSC間の依存関係はSLD上に登録する必要があります。
• 開発設定はソフトウェアコンポーネント(SC)単位で管理されます。
• SC名はシステム全体としてユニークである必要があり、最初に設定した名称を変更することはできない。
• 移送はSC単位で分けられます。
• DTRのワークスペースはSC単位で分けられます

• DCは最小の開発単位（Web Dynpro JAVA, CAF等）でSCの配下に定義します。
• DC毎にNWDS環境でJAVA開発プロジェクトが作成されます
• DC間の再利用定義は利用される側からはPublicパーツを定義して利用する側は該当Publicパーツを参照するようになります。
• DC名はシステム全体としてユニークである必要があります。
• DCの参照設定はNWDSの「Development Infrastructure」パースペクティブウィンドウから行います。
• 参照対象のDCを「Component Properties」Viewの「Dependencies」タブから追加します。
• 「Dependency Details」は「Design Time」「Runtime」を設定して「Deploy Time」は外すようにします。

製品には、リリース番号がバージョンになります。 
例えば、NetWeaver AS Java は7.0、7.1、7.2、7.3、7.4などのバージョンがあります。

ソフトウェアコンポーネントのバージョン番号には、製品のバージョン、サポートパッケージのバージョンが含められます。 
システム情報画面からインストール済のソフトウェアコンポーネントのバージョンを確認することができます。

NWDIは、システムの開発作業を一つのプラットフォームに統合することにより、集中管理が可能になります。

NWDIでは以下の作業がすべて集中管理できるようになっております。

• ソースプログラムの集中管理化⇒DTR
• 構築配置作業の集中管理化⇒CBS
• 変更管理移送作業の集中管理化⇒CMS

(source: sap help portal)

上記のアーキテクチャ図で示したとおり、NWDIを構成する要素は、NWDS、DTR、CBS、CMSがあります。

• NWDS
  NWDSにおけるJavaアプリケーションの開発は、ソフトウェアコンポーネントモデルを基準としております。従ってソフトウェアプロジェクトが、開始時から管理しやすい再利用可能な単位に体系的に構造化されます。
• DTR
  DTRでは、バージョンニングソースコードを管理できるため、チームにおけるソフトウェアの分散開発、及びソースの移送と複製が可能です。
• CBS
  CBSは、ソースコードのセントラルビルドに使用されます。開発者の操作はNWDSに統合されます。CBSはビルドプロセスのために自動的にDTSと通信います。
• CMS
  CMSは、JAVA開発ランドスケープ、及びソフトウェアライフサイクル全体に渡る移送を集中管理するため、に使用します。CMSの機能は、DTR、CBS及びSLDに緊密に統合されています。

NWDIは開発者と管理者のためにそれぞれロールを用意しています。

• 管理者ロール 
  NWDI.Administrator
• 開発者ロール 
  NWDI.Developer