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

アクティビティ(英：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などのバージョンがあります。

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