9. NWDI：全体：コンポーネントモデル
NWDI：全体：コンポーネントモデル
峯
0 • 717

このトピックでは、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リリースのタイムスタンプ

 

0 • 717
みんなのツイート (0)

関連サマリー


  • NWDI • 峯 0 Votes 197 閲覧数



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

    コンセプト

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

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

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

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

     


  • NWDI • 峯 0 Votes 100 閲覧数


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

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

    概述

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

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

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

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

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

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


  • NWDI • 峯 0 Votes 93 閲覧数


    デザインタイムリポジトリ (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  


  • NWDI • 峯 0 Votes 88 閲覧数


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

    目的

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

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

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

    ファイル

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

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

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

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

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

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

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

    外部リンク

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


  • NWDI • 峯 0 Votes 94 閲覧数



    このトピックでは、それらのツールを取り上げてそれぞれ説明します。

    DTR Client概述

    DTR Clientは、Eclipse Perspectiveとして、NWDS環境に統合されています。
    そこで、各DTRクライアントツールはeclipse viewとして多数用意されています。

    各ツールClosed ActivitiesIntegration ConflictsOpen Activities

    オープン中のActivity

    ビューのツールバーメニューから全ユーザのActivityを照会することができます。

    checkin(チェックイン)
    Activityがチェックインされたら、ローカルの変更がすべてDTRのinactiveワークスペースに反映され、別の開発者も見えるようになります。
    revert(変更を元に戻す)
    PermissionsRepository Browser

    ツリー構造で、Repositoryのリソースを照会することができます。

    Version GraphyWEBを利用メイン画面

    DTRのWEBツールのメイン画面は以下のようなURLからアクセスすることができます。

    http://<host>:<port>/dtr/

    ツールのアクセス

    ツールバーにツールへアクセスするためのアイコンが並べられていますので、そちらを利用することができます。

    また、リポジトリツリーの「system-tools」ノードよりも各ツールをアクセスすることも可能です。

    各ツール

    ファイルブラウザワークスペース比較

    外部リンク DTRのブラウザベース設定とクエリツール - SAP Help Portal


  • NWDI • 峯 0 Votes 127 閲覧数


    このトピックでは、統合Conflictを取り上げて、その発生原因と解決策を説明します。

    原因

    ワークスペースを統合する際に、同じソースで、前回統合された後に、別々修正が発せしていれば、システムが判断できないため、
    統合Conflictが発生します。
    以下の図でそのイメージを示します。
    (source:SAP Help Portal)

    解決

    統合Conflictが発生したときに、統合元のソースはActiveバージョン、統合先のソースはCollidingバージョンとして格納されます。同時にConflictフラグをワークスペースに立てられます。
    解決方法は下記のようになります。

    統合元のソースが正であれば、Activeバージョンを採用します。統合先のソースが正であれば、Collidingバージョンを採用します。各自の修正内容をマージする必要があれば、マージを取ります。

    いずれにしても新たにアクティビティを起こして対応する必要があります。

    対応の手順を簡単に示します。

    統合Conflictビューを表示
    差異を確認1)
    対象DCを選択して、コンテキストメニューから対応方法を選択
    ここでは統合元ノースを採用する
    新たなアクティビティに記録
    アクティビティをチェックイン
    対応後のバージョングラフを確認(必須ではない)
    外部リンク統合コンフリクトの解決 - SAP Help Portal


  • NWDI • 峯 0 Votes 176 閲覧数


    このトピックでは、トラック内移送とトラック間移送に分けて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)

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


  • NWDI • 峯 0 Votes 104 閲覧数


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

    概述

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

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

    構成

    (source: SAP Help Portal)

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

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

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

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

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

人気