コンセプト

WebdynproはSAPにおいて、ユーザインタフェースを作成するためのプログラミングモデルのこと。
Webdynproの具体的なコンセプトは以下のとおり

コーディングの最小化デザインの最大化コンポーネントの再利用のサポートWebサービスとデータバインドのサポート画面レイアウトとプログラムロジックの分離プラットフォーム非依存WebDynproアプリケーション

WebdynproアプリケーションはWebdynproコンポーネントへのエントリポイントであり、URLを介して呼び出せる唯一のWebdynproエンティティです 。以下はそのイメージ図です。

アプリケーションはインタフェースビューを持っているWDコンポーネントのアクセスポイントとして提供される。
各アプリケーションにはWDコンポーネント、インタフェースビュー及びStartupプラグを定義する。

WebDynproコンポーネントインタフェースビュー

・インタフェースビューとして公開されたWDコンポーネントのウィンドウをWDアプリケーションまたは別のWDコンポーネントから呼び出すことができる。
・複数のインタフェースビューを一つのウィンドウに割り当てることができる。
・インタフェースビューに定義するプラグは該当インタフェースビューを参照するウィンドウに定義されている必要がある。

インタフェースコントローラー

・各WDコンポーネント毎に一つのインタフェースコントローラーが自動定義されて、コンポーネントコントローラーとマッピングされる。
・インタフェースコントローラーに定義するコンテキスト、メソッド、イベントはコンポーネントコントローラーに定義されている必要がある。
・インタフェースコントローラーに定義したコンテキスト、メソッド、イベントのみが別のWDコンポーネントから利用できる。

コンポーネントコントローラー

・WDコンポーネント毎に一つのコンポーネントコントローラーが自動定義されて、WDコンポーネント全体の制御ロジックを実装する。
・UIエレメントのイベントとは違う独自のイベント処理が必要な場合、イベントを定義することができる。

カスタムコントローラー

・コンポーネントコントローラの付属コントローラーとして定義可能なコントローラーでコンポーネントコントローラーが大きくなる場合、
処理を分けることができる。

ウィンドウコントローラー

・主にインバウンドプラグの遷移に関するロジックを実装する。MVCモデル概念に基づき、詳細のロジックはできる限り、コンポーネントコントローラーまたは
カスタムコントローラーで実装する。

ウィンドウ

・ビューの配置とプラグによる画面遷移のモデリングを行う。

ビューコントローラー

・UIエレメントから発生するイベントのハンドリング、動的レイアウト変更、画面遷移等のロジックを実装する。MVCモデル概念に基づき、
詳細のロジックはできる限り、コンポーネントコントローラーまたはカスタムコントローラーで実装する。

ビュー

・画面のレイアウトをモデリングする。各UIエレメントに関する詳細は「X.X UIエレメント」を参照する。

プラグ

・主に、インバウンドプラグとアウトバウンドプラグが存在する。ウィンドウでアウトバウンドプラグをインバウンドにリンクさせることにより
画面遷移を定義し、ウィンドウコントローラーまたはビューコントローラーからアウトバウンドプラグのイベントを発生して実際の画面遷移を行う。
・インバウンドプラグは遷移先の画面で処理ロジックを追加することができる。
・プラグの種類としては下記の通り存在する。
Startupプラグ WDアプリケーションから呼び出す開始用のプラグ
Exitプラグ WDアプリケーションの処理を終了してログオフ等を行うプラグ
Inboundプラグ 通常の画面遷移で遷移先用プラグ
Outboundプラグ 通常の画面遷移で遷移元用プラグ

コンテキスト

・ノードとアトリビュートで構成されるWDJ特殊のデータ構造。

イベントとイベントハンドーラー

・イベントとしてはUIエレメントイベント、プラグイベント、そしてユーザ定義イベントが存在する。
・UIエレメントから発生するイベントは通常アクションという。

シンプルタイプとストラクチャー

・WDで使用されるデータの種類、桁数制限等をシンプルタイプとして定義し、複数の場所から再利用することができる。
・関連する複数のデータをストラクチャーとして定義してコンテキストで使用することができる。

モデル

WDJでは、一般的によく利用されるモデルの種類として、 EJB、WebService、RFCの三種類があります。

WDのモデルインポート機能によってES/CAF/BAPIを呼び出すモデルが自動生成され、WD上利用される。

RFCモデル

Webdynproでは、RFCの呼出はSAP Java Connector(JCo)通信レイヤ経由で行われます。
SapECCシステムから貰ったRFC I/F情報をもとに、Webdynpro FrameworkがRFCの呼出用メタデータクラスをJava ディクショナリに自動的に作成します。
RFC I/Fレイヤアーキテクチャのイメージを下図に示します。

このトピックでは、UMEのユーザを取り上げて説明します。

 ユーザとは

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

ABAPユーザとの統合UMEユーザプロファイルマッピングされるABAPユーザデータ属性値内容属性値内容company会社無country国無currency-無dateformat-無department追加情報：部門SU01/DEPARTMENT部署description---displayname一般情報：姓＋名SU01/NAME_LAST + NAME_FIRST姓＋名displayname_role---email電子メールアドレスSU01/SMTP_ADDRメールアドレスfaxコンタクト情報：FAXSU01/FAX_NUMBERファックスfirstname一般情報：姓SU01/NAME_LAST姓jobtitle追加情報：ポジションSU01/FUNCTION職務lastname一般情報：名SU01/NAME_FIRST名mobileコンタクト情報：携帯電話SU01/MOB_NUMBER携帯電話name一般情報：姓SU01/NAME_LAST姓pobox---position---room_desc---room_id---room_name---room_role_name---salutation一般情報：敬称SU01/TITLE_MEDIタイトル（敬称）sip---stateコンタクト情報：都道府県--streetaddressコンタクト情報：地名--telephoneコンタクト情報：電話番号SU01/TEL_NUMBER電話timezoneコンタクト情報：タイムゾーン--title-SU01/TITLE_ACA1学位称号uniquename一般情報：姓SU01/NAME_LAST姓zipコンタクト情報：郵便番号--ABAPデータソースの設定UME-ABAP通信ユーザ作成

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

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

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

宛先作成

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

ABAPデータソース指定外部リンク

UME データソース-SAP Help Portal(Netweaver 7.02)

このトピックでは、UMEの会社機能を取り上げて説明します。

 目的

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

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

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

ume.tpd.imp.class　
実装クラス名
標準では以下の二つがデフォルトで用意されていますが、アドオン開発も可能です。com.sap.security.core.tpd.abap.R3GroupTPDcom.sap.security.core. tpd.SimpleTPDume.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のグループ機能を取り上げて説明します。

 概要

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

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

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

利用目的

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

階層化

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

種類デフォルトグループ

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

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

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

ABAPロールグループ

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のローカルデータベースに保存されます。

 

UMEは、すべての Java アプリケーションに集中的なユーザ及び権限管理機能を提供し、複数のデータソースからユーザ管理データに対して作業することができます。

コンセプト

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

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

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

権限管理

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

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

(source : sap help portal)

会社機能

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

実現アーキテクチャ

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

(source : sap help portal)

エンジン

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

SC:SERVERCOREDC:com.sap.security.core.sda

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

SC:ENGINEAPIDC:com.sap.security.api.sda

ツール

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

SC:UMEADMINDC:多数

ユーザ管理機能

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

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

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

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)ボタン

このトピックでは、ポータルコンテンツの移送を取り上げて説明します。
ポータルコンテンツの移送は、移送元からEXPORT⇒Exportファイルを移送先にインポートの順に行います。

移送元からEXPORT概述

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

手順の詳細

移送先へIMPORT概述

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

手順の詳細

このトピックでは、ポータルロールを取り上げて、その構成要素などを説明します。

概述

ポータルロールは、コンテンツをどのようにグループ化するか、コンテンツを 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を利用することにより、すべての操作が単一のユーザエクスペリエンスに統合されます。

コンセプト

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

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

利用タイプ

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

機能構成

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

機能EPCEPポータル○○ガイドプロシージャ○○統合ワークリスト○○ナレッジマネジメント×○コラボレーション×○ビジュアルコンポーザ×○管理ロール

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

System Admin ポータル、ポータルのサービス、およびシステムランドスケープの設定、更新およびサポートを行うためのツールが提供されます。

このトピックでは、DTRのバージョン管理の仕組みを取り上げて説明します。

目的

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

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

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

ファイル

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

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

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

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

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

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

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

外部リンク

セントラルソースファイル管理 - SAP Help Portal

このトピックでは、DTRのアクティビティを取り上げて説明します。 

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

概述

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

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

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

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

作成変更の記録チェックイン有効化リリース照会

NWDSやWEB-UIからアクティビティ一覧を照会することができます。アクティビティ一覧からワークスペース全体の変更経緯を確認することができます。

デザインタイムリポジトリ (DTR) はファイルバージョン管理を提供するリポジトリ及びそのシステムです。
同じバージョン管理システムとして、オープンシステム開発系の世界では、以下のオープンソースソリューションがよく利用されています。

CVSSVNGit

歴史的には、最初はCVSがはやっていて、次はSVN、いまはGitが一番流行っているに間違いないです。

コンセプト

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の構造

以下、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照会

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

システムステート削除

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

間違って追い越しして後のリリースが先に移送されてしまった場合、対象システムのシステムステートをクリアしておけば、古いリリースが再び移送可能になります。

このトピックでは、トラック内移送とトラック間移送に分けてNWDIにおける移送プロセスを説明します。

 トラック内移送

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

開発者側作業

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

1.有効化

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

2.リリース

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

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

管理者側作業

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

3.インポート

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

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

4.アセンブリ

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

5.承認

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

6.出荷トラック間移送

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

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

(source:SAP Help Portal)

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

このトピックでは、開発トラックを取り上げて説明します。

概述

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

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

構成

(source: SAP Help Portal)

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

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

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

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

外部リンク開発トラックを使用した作業 - SAP Help Porta

変更管理サービス(CMS)は、ソフトウェア変更のシステム間の移送管理を行います。システムは開発設定と実行システムのどちらかまたは両方で構成することができます。
システムはシステム開発のフェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。CMSはABAPシステムのCTSに相当します。

コンセプト

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

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

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

構成要素開発ドメイン

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

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

開発トラック

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

システム

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

システムロールは、開発設定のみ、または実行環境のみのものとしても定義することができます。

CBSはDTRと密接に連携しています。DTRからソースコードを取得して、ビルドします。アプリケーションサーバの設定があれば、ビルドできたアカイブ(ear,sdaファイルなど)をサーバへデプロイします。

コンセプト

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

実現アーキテクチャ画面機能

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

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

 

このトピックでは、NWDIの管理ツールを纏めて説明します。 

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

NWDS

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

DIComponent Browserビュー 
以下の作業を実施することができます。SC/DCを照会DCをローカルに取り込み、プロジェクトを作成SCをscaファイルにExportDCをビルド、デプロイComponent Propersビュー 
以下の作業を実施することができます。コンポーネントの構成や依存関係を照会DTRRepository Browsesrビュー 
以下の作業を実施することができます。ソースファイルの内容及び履歴などを照会Open Acvitiesビュー 
以下の作業を実施することができます。未チェックインのActivityを照会変更をチェックイン変更を廃棄Closed Acvitiesビュー 
以下の作業を実施することができます。チェックイン済のActivityを照会Integration Conflictビュー 
以下の作業を実施することができます。ワークスページ統合時に発生したConflictを照会、処理Version Graphyビュー 
以下の作業を実施することができます。ソースファイルのトラックに跨ったバージョン履歴を図で表示CMSTransport Viewビュー 
以下の作業を実施することができます。未リリースの変更依頼をリリース未リリースまたはリリース済の変更依頼を照会CBSActivation Viewビュー 
以下の作業を実施することができます。チェックイン済のActivityを有効化Activation Requestビュー 
以下の作業を実施することができます。有効化リクエストのステータスを確認WEB画面メイン画面

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

DTR

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

CMS

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

CBS

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

このトピックでは、 NWDI を使用した開発の流れを抜粋して説明します。

概述

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

前提条件

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

構成要素(DTR、CBS、CMS、SLDなど)のインストールシステムランドスケープに関する情報の更新各フェーズ開発準備

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

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

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

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

チェックアウトソースの作成又は変更ビルドローカルテストチェックインセントラルビルド、有効化デプロイリリース移送及びテスト

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

本番稼働

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

運用保守

運用保守フェーズで変更が発生するたびに、アクティビティ作成⇒修正⇒ローカルテスト⇒リリース⇒品証機移送⇒品質テスト⇒本番機移送という作業を繰り返します。

このトピックでは、NWDIを使用して開発、運用されるソフトウェアのコンポーネントモデルを取り上げて説明します。

モデルの構成

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などのバージョンがあります。

ソフトウェアコンポーネント

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

パーツ値意味11000固定27.20製品のバージョン35.2サービスパッケージ(SP)のバージョン420110906181900リリースのタイムスタンプ