NWDI | iサマリー

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you may not be able to execute some actions.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

投稿するにはログインしてください

NWDI

NWDI：全体：概述
• 峯 0 Votes 1 投稿 221 閲覧数

NWDI(NetWeaver Development Infrastructure) は、 NetWeaverプラットフォームの上に動作するJavaベースのアプリケーションを開発するための基盤であり、アプリケーションのバージョン、構築、およびライフサイクルを管理する機能を備えています。
NWDI自体もNetWeaver Javaプラットフォームに稼働するものですので、NetWeaverインストール時に利用タイプDIを選択してインストールを行うことで、 NWDIに必要な機能がインストールされます。
コンセプト
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
NWDI：全体：コンポーネントモデル
• 峯 0 Votes 1 投稿 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リリースのタイムスタンプ
NWDI：全体：開発の流れ
• 峯 0 Votes 1 投稿 285 閲覧数

このトピックでは、 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：全体：管理ツール
• 峯 0 Votes 1 投稿 161 閲覧数

このトピックでは、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：CBS：概述
• 峯 0 Votes 1 投稿 200 閲覧数

CBSはDTRと密接に連携しています。DTRからソースコードを取得して、ビルドします。アプリケーションサーバの設定があれば、ビルドできたアカイブ(ear,sdaファイルなど)をサーバへデプロイします。
コンセプト
CBSはシステムの構築作業を集中管理可能にして、 NWDIにおいて中心的な役割を果たしています。
実現アーキテクチャ画面機能
CBSは主に以下の機能を提供しています。
オンデマンドのビルド
変更のセントラルビルドは依頼によりリアルタイムで発生します。変更がチェックインして有効化される際に自動的に依頼されることもあれば、管理者が明示的に指示することもあります。ビルド結果およびビルドツールの一元的な保管有効化コンセプトの保証
開発オブジェクトの無効および有効ステータスが区別されます。無効ステータスのオブジェクトから有効ステータスのオブジェクトに変更を渡すには、これらを有効化しなければなりません。この前提条件は、変更された開発コンポーネントのセントラルビルドが正常に行われていることです。
NWDI：CMS：概述
• 峯 0 Votes 1 投稿 125 閲覧数

変更管理サービス(CMS)は、ソフトウェア変更のシステム間の移送管理を行います。システムは開発設定と実行システムのどちらかまたは両方で構成することができます。
システムはシステム開発のフェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。CMSはABAPシステムのCTSに相当します。
コンセプト
CMSはソフトウェアの変更を一元で管理可能にするサービスです、JavaシステムのCMSはABAPシステムのCTSと同等します。
CMSのコンセプトは主に以下になります。
ソースの改修を開発システムに限定します。手作業ミスをなくし、システムにより改修内容を確実に開発システム→テストシステム→本番システムの間に移送します。ソフトウェアの構築とデプロイを自動化可能にします。実現アーキテクチャ
構成要素開発ドメイン
開発ドメインは、システムランドスケープ全体の構成を定義します。
開発ドメインには複数の開発トラックを含めることができます。
開発トラック
開発トラックは一つの開発の流れを定義します。
一つの開発トラックには、一つ以上のソフトウェアコンポーネントの開発、テスト、本稼働に必要な開発設定と実行時環境がすべて組み込まれます。
システム
CMSにおけるシステムは、厳密的にはシステムロールのことであり、開発設定と実行環境から構成され、各フェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。
システムロールは、開発設定のみ、または実行環境のみのものとしても定義することができます。
NWDI：CMS：開発トラック
• 峯 0 Votes 1 投稿 105 閲覧数

このトピックでは、開発トラックを取り上げて説明します。
概述
開発トラックとは、1つの開発の流れを定義します。
開発トラックには、開発されるSCのさまざまな開発ステータスの開発設定及び実行時システムが含まれます。
構成
(source: SAP Help Portal)
セントラル開発システム(DEV)では、開発者のローカルPCで作成したソースを個々の開発者がさらにテストをします。
コンソリデーションシステム(CONS)は、特定の固定ステータスのSCの統合とそのSCの追加テストに使用されます。
その後、本稼働システム(PROD）へ適用する前に、テストシステム(TEST)でSCの新規バージョンを最終テストをします。
必要に応じて、これらの4つのシステムロールを実行時システムに割り当てることができます。実行時システムでは、インポート時に自動的にデプロイが実施されます。
外部リンク開発トラックを使用した作業 - SAP Help Porta
NWDI：CMS：移送プロセス
• 峯 0 Votes 1 投稿 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：CMS：サポートツール
• 峯 0 Votes 1 投稿 81 閲覧数

サポートツールでは、CMS管理用の幾つかのツールが提供されております。
メイン画面
URL:http://host:port/CmsSupportTool/
プロセス照会
CMSシステムで発生していた各プロセス(インポート、ビルド、承認)の情報を照会できます。
アクティビティ検索
CMSシステムで作成されていたアクティビティを検索することができます。
トラック検索
指定ソフトウェアコンポーネント(SC）が取り込まれたトラックを検索することができます。
SC照会
指定トラックに取り込まれたソフトウェアコンポーネント(SC)の情報を照会できます
システムステート削除
システムステートを削除できます。
間違って追い越しして後のリリースが先に移送されてしまった場合、対象システムのシステムステートをクリアしておけば、古いリリースが再び移送可能になります。
NWDI：DTR：概述
• 峯 0 Votes 1 投稿 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：DTR：アクティビティ
• 峯 0 Votes 1 投稿 100 閲覧数

このトピックでは、DTRのアクティビティを取り上げて説明します。
(このトピックは編集中です。)
概述
アクティビティ(英：Activity)はDTRへ対する変更の開発及び移送の管理単位です。ABAPスタックにおける変更依頼に相当します。
アクティビティはOpenとClosedとの二つのステータスがあります。
Open Activity
変更中のアクティビティです、ここで行う任意の変更を元に戻すことができます。Closed Activity
チェックインした後のアクティビティです。これらのアクティビティを変更することはできなくなります。ライフサイクル
このセクションはアクティビティのライフサイクルを順次説明します。
作成変更の記録チェックイン有効化リリース照会
NWDSやWEB-UIからアクティビティ一覧を照会することができます。アクティビティ一覧からワークスペース全体の変更経緯を確認することができます。
NWDI：DTR：バージョン管理
• 峯 0 Votes 1 投稿 89 閲覧数

このトピックでは、DTRのバージョン管理の仕組みを取り上げて説明します。
目的
主に下記の二つあります。
変更歴史の記録
バージョン間の変更点を確認したり、ふるいバージョンに戻したりすることができます。統合時の判断
ソースファイルを統合する際に、バージョンを比較して統合できるかを判断できます。管理レベル
DTRはファイルとワークスペースと二つのレベルでバージョン番号を管理しています。
ファイル
ファイルはそれぞれ個別のRev No.(リビジョン番号)をもっています。
Rev No.は、ワークスペース内で採番されます。1から始まり、ファイルが変更されるたびに一つずつあがっていきます。
ファイルのRev No.はNWDSで確認することができます。
対象ソースを指定、コンテキストメニューから「Revision History」を選択
Revision一覧を表示
ISNなども表示されますので、後ほどの説明に関わります。
ワークスペース
ワークスペースレベルのバージョン番号は、ISN (Integration Sequence Number、統合順序番号)と呼ばれます。
ワークスペースにチェックインされた変更には、そのワークスペース内で適用される一意なISN番号が割り当てられます。
ワークスペースへの変更は、アクティビティによるものと、伝播(Propagation)によるものがあります。
アクティビティ
ローカルワークスペースで行った修正伝播
トラックに跨ってインポートされる変更統合
ワークスペースが統合されるときに、ファイルのバージョンが統合されます。
バージョングラフから、ワークスペースに跨ったファイルのバージョン歴史を確認することができます。
そこで、ワークスペース間でどうな統合が発生したのか、次の統合にコンフリクトも確認できます。
外部リンク
セントラルソースファイル管理 - SAP Help Portal
NWDI：DTR：ツール
• 峯 0 Votes 1 投稿 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
NWDI：DTR：統合Conflict
• 峯 0 Votes 1 投稿 127 閲覧数

このトピックでは、統合Conflictを取り上げて、その発生原因と解決策を説明します。
原因
ワークスペースを統合する際に、同じソースで、前回統合された後に、別々修正が発せしていれば、システムが判断できないため、
統合Conflictが発生します。
以下の図でそのイメージを示します。
(source:SAP Help Portal)
解決
統合Conflictが発生したときに、統合元のソースはActiveバージョン、統合先のソースはCollidingバージョンとして格納されます。同時にConflictフラグをワークスペースに立てられます。
解決方法は下記のようになります。
統合元のソースが正であれば、Activeバージョンを採用します。統合先のソースが正であれば、Collidingバージョンを採用します。各自の修正内容をマージする必要があれば、マージを取ります。
いずれにしても新たにアクティビティを起こして対応する必要があります。
対応の手順を簡単に示します。
統合Conflictビューを表示
差異を確認1)
対象DCを選択して、コンテキストメニューから対応方法を選択
ここでは統合元ノースを採用する
新たなアクティビティに記録
アクティビティをチェックイン
対応後のバージョングラフを確認(必須ではない)
外部リンク統合コンフリクトの解決 - SAP Help Portal