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

このトピックでは、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 • 718
みんなのツイート (0)

関連サマリー


  • NWDI • 峯 0 Votes 81 閲覧数


     

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

    メイン画面

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

    プロセス照会

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

    アクティビティ検索

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

    トラック検索

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

    SC照会

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

    システムステート削除

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

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


  • NWDI • 峯 0 Votes 177 閲覧数


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


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

    コンセプト

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

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

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

    構成要素開発ドメイン

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

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

    開発トラック

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

    システム

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

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


  • NWDI • 峯 0 Votes 198 閲覧数



    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 94 閲覧数


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


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

    概述

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

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

    構成

    (source: SAP Help Portal)

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

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

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

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

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


  • NWDI • 峯 0 Votes 95 閲覧数



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

    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

人気