UWLは、通常キャッシュを使用し、キャッシュで保存されているアイテムが表示されます。

キャッシュを使用したUWL表示のシステムイメージを下記の図で示します。

キャッシュされたアイテムは、UWL稼働サーバのローカルデータベースに保存されます。

• タイマによる自動更新
  以下の図で示されたように、いまの設定では、60秒単位でUWLキャッシュがバックアンドのBPMシステムと同期化を取っております。
• ログオン処理による更新
  ユーザがログオンしたときに、UWLキャッシュの更新がリクエストされます 画面リフレッシュによる更新
  ユーザが画面でリフレッシュリンクをクリックしたときに、UWLキャッシュの更新がリクエストされます

UWLキャッシュには有効期間があり、有効期間が切れましたら、更新されます。(デフォルトは5分)
またUWLキャッシュは下記の場合も更新されます。

• ユーザがポータルにログオンしたら、ログオンされたユーザはDeltaプールに追加され、バックグラウンドでUWL Cacheを更新します。(デフォルトは1分)
• UWLのWebDynpro　UIからアイテムを選択したり、ソートしたりした場合、Cacheの有効期間が切れましたら、更新されます。
• UWLのUIはデフォルトで10分間隔でRefreshされ、UWLのUIはCacheからアイテムを再度ロードし、Cacheの有効期間が切れましたら、更新されます。
• 手動的にUWLを更新する際

統合ワークリストは以下のタイミングで再表示処理が行われます。

• 一定間隔で自動的に再表示
  統合ワークリストのUIは一定間隔で自動的にRefreshされます。
  
• ユーザがリフレッシュリンクを押下した時
• ユーザがアイテムをソートしたり、フィルタリングしたりした時

• パラメータ:Wait duration before calling providers on loading of UWL
  デフォルトとは20(秒)と設定されます。ログオン直後になどUWLをロードする際に、キャッシュの内容が20秒以内に取得されたものであれば、キャッシュの内容をそのまま取得して表示し、キャッシュの内容が20秒前に取得されたものでれば、キャッシュを更新させてからキャッシュの内容を取得して表示するといういみです。
  0に設定しておけば、キャッシュを更新させて常に最新のものを取得して表示することになります。
• パラメータ:Wait duration before calling providers on loading preview
  アイテムの詳細画面の表示

1.ログオン直後のUWL表示
ログオン時に、UWLキャッシュ更新がリクエストされますが、UWLキャッシュ更新の完了を待たずに、当時のキャッシュ内容を画面に表示して、「更新を待っています」というメッセージを出力します。
(レスポンス性を向上するための措置)
下記の画面で設定された値(デフォルト値：20秒)が経過した後に、再度キャッシュの内容を取りなおして表示します。(その時点でもUWLキャッシュ更新が完了していない場合、画面上に処理中アニメを表示して画面操作不可にします。）
この設定値が0と変更されれば、ログオン直後のUWL表示は常にUWLキャッシュ更新が完了するまで待つようになります。
2.マニュアルでリフレッシュされた場合のUWL再表示

先にUWLキャッシュがに更新されます、その後、UWLキャッシュの内容が画面に表示されます

3.ィルタリング検索、代理ユーザが選択された場合のUWL再表示
UWLキャッシュの即時更新が発生しません、その時点のUWLキャッシュの内容が画面に表示されます。

4.画面自動リフレッシュ(10分間隔?)のUWL再表示
UWLキャッシュの即時更新が発生しません、その時点のUWLキャッシュの内容が画面に表示されます。

■代理指定者名前の表示
リストに該当するタスクがある場合のみ、代理指定者の名前が表示されます。

このセクションは準備中です。

統合ワークリストは、タスクを管理するための一元的なアクセスポイントを提供します。
この統合ワークリストは、各ユーザの作業スタイルに応じてパーソナライズすることができます。

UWLに表示される項目は、ワークアイテムまたはアイテムと呼ばれます。

以下のアイテムタイプがあります。

• タスク
• 警告
• 通知
• 追跡

以下のアイテムステータスがあります。

• 処理中
• 完了

アイテムは所有者をもちます、ﾜｰｸｱｲﾃﾑの転送や代理により所有者がかわることができます。

UWLは複数のプロバイダシステムからのタスクおよび通知が 1 つのリストにまとめられ、1 箇所でアクセスできるようになります。

(source:SAP Help Portal)

• UWLJWF

• 一覧表示
  
• 代理ルール管理
  

UWLの表示や動作をカスタマイズするには、以下の管理機能を利用することができます。
Portal Content管理画面

上記の画面はポータルのURLからアクセスできます。

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

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

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

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

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

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

• 統合コンフリクトの解決 - SAP Help Portal

JMS(Java Message Service)はメッセージングサービスを利用するためのJava標準APIであり、 J2EE 1.3 以降に標準で含まれています。
メッセージオブジェクトを作成して通信を行い、非同期に通信を行うことも出来ます。

Message Server

メッセージサーバ(英：Message Server)は、SAPシステムに一つのみ存在し、負荷分散や、アプリケーションサーバ間の通信を管理します。
メッセージサーバとは何かというと、セントラルインスタンスで稼働している親分的な存在のプロセス（サービス）で、インスタンス間の通信の仲介役をしたり、ユーザがログオンする際のログオン負荷分散のディスパッチャの役割を担ったりしています。

サーバと名が付いているので、アプリケーションサーバと同類のサーバなのかというと、そうではありません。あくまで1つのOSプロセスに過ぎません。

外部ポート番号は、ログオン時の負荷分散機能で使用。
内部ポート番号はデフォルトでは無効になっていますが、有効にすれば、インスタンス間の通信専用のポート番号になり、フロントエンドPCからの通信を受け付けません。

基本的には、メッセージサーバ内部ポートは無効にしておき、従来と同様に、外部ポート番号だけを有効にすれば良いと思います。

ABAPメッセージサーバポート番号
外部ポート　rdisp/msserv = 36 (例：3600)
内部ポート　rdisp/msserv_internal = 39 (例：3900、デフォルト値 = 0 （無効）)

JAVAインスタンスのメッセージサーバは、SCS（セントラルサービスインスタンス）で動作しますが、ABAPインスタンスと違って、内部ポート番号だけを有効にします。

JAVAメッセージサーバポート番号
外部ポート　rdisp/msserv = 0 (無効）
内部ポート　rdisp/msserv_internal = 39 (例：3902)

参考:http://help.sap.com/saphelp_nw70/helpdata/ja/4e/cffdb69d10424e97eb1d993b1e2cfd/content.htm

NWA

SAP NetWeaver Administrator は、SAP NetWeaver を管理およびモニタするためのWeb ベースツールです。

NWDI

NWDI(NetWeaver Development Infrastructure) は、 NetWeaverプラットフォームの上に動作するJavaベースのアプリケーションを開発するための基盤であり、アプリケーションのバージョン、構築、およびライフサイクルを管理する機能を備えています。
NWDI自体もNetWeaver Javaプラットフォームに稼働するものですので、NetWeaverインストール時に利用タイプDIを選択してインストールを行うことで、 NWDIに必要な機能がインストールされます。

Product

製品(英：Product)とは、 価格設定と販売の単位であり、一つ以上のソフトウェアコンポーネントを集めたものです。1つのソフトウェアコンポーネントを複数の製品に含めることができます。

Service Group

NWAの「アプリケーション通信: 設定」にて、サービスグループを単位として、アプリケーションが参照したサービスのプロバイダシステムを纏めて設定することができます。

Service Registry

サービスレジストリ(英:Service Registry、略：SR)

JavaEEアプリケーション(ear)を構成するモジュールは、Webモジュール(war)とEJBモジュール(jar)があります。

• Webモジュール
  Webモジュールとは、Web アプリケーションのことです。 Web モジュールは、サーブレット、JavaServer Pages (JSP) ファイル、 および Hypertext Markup Language (HTML) ページなどの静的コンテンツを、 デプロイ可能な単一の単位にアセンブルすることによって作成されます。
• EJBモジュール
  EJB モジュールは、1 つ以上の Enterprise Bean をデプロイ可能な単一の単位にアセンブルするために使用されます。 EJB モジュールは、標準の Java アーカイブ (JAR) ファイルに保管されます。

NWA画面で「設定管理」→「インフラストラクチャ」→「アプリケーションモジュール」で下記の画面をアクセスすることができます。

• Management Console
• Visual Administrator
• config tool
• Web画面
• NWDSクライアント

SAP Management Console はローカル版とJava版の二つがあります。

• ローカル版
  
• Java版
  

Visual Administrator は \usr\sap\(SID)\DVEBGS(システム番号)\j2ee\admin にある go.bat で起動します。

go.bat を起動すると、登録された接続先を選択する画面になるので Default を選び、Connect で Java System に接続します。

Java System 管理者ユーザ J2EE_ADMIN のパスワードを入力して Connect します。

Java SystemのDispatcherと一つ又は複数のServer があり、それぞれの設定を行う事が出来ます

Config tool は Java System が稼働していない時でも使用可能なツールです。
\usr\sap\(SID)\DVEBGS(システム番号)\j2ee\configtool にある configtool.bat で起動します。

JAVAの起動パラメータやメモリ割り当ての設定が出来ます。

http:<portal.domain>:<port>/startPage

http:<portal.domain>:<port>/nwa

http:<portal.domain>:<port>/nwa/sysinfo

http:<portal.domain>:<port>/wsnavigator

http:<portal.domain>:<port>/useradmin

http:<portal.domain>:<port>/sr_central

http:<portal.domain>:<port>/ejbexplorer

http:<portal.domain>:<port>/irj/portal

AsJavaの各バージョンは、下記のようにJavaEE仕様を準拠しております。

• 7.0
  J2EE 1.3
• 7.1-7.4
  JavaEE 5.0

下記のリンクをご参考ください。

http://codezine.jp/article/detail/5698

JavaEE5は以下の仕様から構成されます。

• Web Services Technologies
• Implementing Enterprise Web Services (JSR 109)
• Java API for XML-Based Web Services (JAX-WS) 2.0 (JSR 224)
• Java API for XML-Based RPC (JAX-RPC) 1.1 (JSR 101)
• Java Architecture for XML Binding (JAXB) 2.0 (JSR 222)
• SOAP with Attachments API for Java (SAAJ) (JSR 67)
• Streaming API for XML (JSR 173)
• Web Service Metadata for the Java Platform (JSR 181)
• Web Application Technologies
• Java Servlet 2.5 (JSR 154)
• JavaServer Faces 1.2 (JSR 252)
• JavaServer Pages 2.1 (JSR 245)
• JavaServer Pages Standard Tag Library (JSR 52)
• Enterprise Application Technologies
• Enterprise JavaBeans 3.0 (JSR 220)
• J2EE Connector Architecture 1.5 (JSR 112)
• Common Annotations for the Java Platform (JSR 250)
• Java Message Service API (JSR 914)
• Java Persistence API (JSR 220)
• Java Transaction API (JTA) (JSR 907)
• JavaBeans Activation Framework (JAF) 1.1 (JSR 925)
• JavaMail (JSR 919)
• Management and Security Technologies
• J2EE Application Deployment (JSR 88)
• J2EE Management (JSR 77)
• Java Authorization Contract for Containers (JSR 115)

J2EE 1.4は以下の仕様から構成されます。

• J2EE Connector Specification 1.5
• J2EE Deployment API Specification 1.1
• J2EE Management Specification 1.0
• Enterprise JavaBeans Specification 2.1
• Enterprise JavaBeans to CORBA Mapping 1.1
• Java API for XML Processing Specification 1.2
• Java API for XML Registries Specification 1.0
• Java API for XML-based RPC Specification 1.1
• Java Authorization Contract for Containers 1.0
• Java IDL API
• Java Naming and Directory Interface Specification 1.2.1
• Java Message Service Specification 1.1
• Java Servlet Specification 2.4
• Java Transaction API Specification 1.0.1B
• Java Transaction Service Specification 1.0
• JDBC Specifications, 3.0, 2.1, and Optional Package API (2.0)
• JavaBeans Activation Framework Specification 1.0.2
• JavaMail API Specification 1.3
• JavaServer Pages Specification 2.0
• RMI over IIOP
• SOAP with Attachments API for Java Specification 1.2

J2EE 1.3は以下の仕様から構成されます。

• JDBC Extension 2.0
• Java Naming and Directory Interface Specification (JNDI) 1.2
• Java API for XML Processing (JAXP) 1.1
• Java Servlet 2.3
• JavaServer Pages (JSP) 1.2
• JavaServer Pages Standard Tag Library (JSTL) 1.0
• Enterprise JavaBeans (EJB) 2.0
• J2EE Connector Architecture 1.0
• Java Message Service API (JMS) 1.0
• Java Transaction API (JTA) 1.0
• JavaMail API 1.2
• JavaBeans Activation Framework (JAF) 1.0
• Java Authentication and Authorization Service (JAAS) 1.0

(source: SAP Help Portal)

• アーキテクチャマニュアル - SAP Help Portal

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

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

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

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

・インタフェースビューとして公開された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上利用される。

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

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

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

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

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

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

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

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

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

• ume.tpd.imp.class　
  実装クラス名
  標準では以下の二つがデフォルトで用意されていますが、アドオン開発も可能です。
  • com.sap.security.core.tpd.abap.R3GroupTPD
  • com.sap.security.core. tpd.SimpleTPD
• ume.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のグループはAsABAPシステムのユーザグループ(SUGRで管理)に相当するものです。

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

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

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

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

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

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のユーザ及び権限管理以下の要素から構成されます。

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

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

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

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

(source : sap help portal)

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

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

(source : sap help portal)

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

• SC:SERVERCORE
• DC:com.sap.security.core.sda

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

• SC:ENGINEAPI
• DC:com.sap.security.api.sda

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

• SC:UMEADMIN
• DC:多数

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

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

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

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

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

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

ポータルロールは、コンテンツをどのようにグループ化するか、コンテンツを 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(Enterprise Portal)はSAP NetWeaver PlatformのWEBフロントエンドとして機能します。 ポータルのほか、以下の機能も統合されておます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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