参加
最後オンライン
最近の投稿
WDJに投稿されました 続きを読む

コンセプト

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上利用される。

RFCモデル

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

UMEに投稿されました 続きを読む

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

 

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

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コンタクト情報:郵便番号--

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に投稿されました 続きを読む

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

 

会社機能を利用することによって、一つの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会社が設定されます。
    • 会社リスト:カンマ区切りの会社名リストで複数会社を設定できます。

UMEに投稿されました 続きを読む

このトピックでは、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に投稿されました 続きを読む


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

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

EPに投稿されました 続きを読む

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

概述

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

手順の詳細










概述

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

手順の詳細




EPに投稿されました 続きを読む

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

ポータルロールは、コンテンツをどのようにグループ化するか、コンテンツを 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のコンテンツ定義 
EPに投稿されました 続きを読む

このトピックでは、ポータルの画面構成を取り上げて説明します。

 

ポータルとは、以下の図で赤い枠線が示した通り、表示されているコンテンツおよびそのレイアウトを含むポータル画面全体のことです。


ポータル画面全体は以下の図で示されるように、大きく分けると、ヘッダエリア/ページタイトルバー/ナビゲーションパネル/コンテンツエリアの四つのエリアから構成されます。

トップヘッダ

トップヘッダエリアは、主にシステムの各ページに不変なヘッダ内容が表示されます。例えば、会社のロゴやシステムの名前、検索のツールボックスなどはよくこのエリアに含められます。 
概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

ツール

ツールエリアは、ポータルにナレッジマネジメント (KM) がインストールされている場合に限り表示されます。

トップレベルナビゲーション

トップレベルナビゲーションは、ユーザに割り当てられたロールのコンテンツをアクセスするためのタブを並べられるバーエリアです。 
設定により、2行目に選択中のロールの第1階層のサブフォルダを表示させることができます。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

ページタイトルバー

表示されたページのパーソナライゼーション、ナビゲーション、およびアクションのオプションに関する情報などはこのエリアに表示されます。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

ナビゲーションパネル

ページタイトルバーの直下にある左側のペインはナビゲーションiView 用に予約されており、これにはコンテンツツリー、インタフェースコントロール、各種コンテンツへのリンクが含まれています。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

コンテンツエリア

この部分は本体のコンテンツが表示されます。コンテンツはiView が含まれるページまたは単独の iView です。ページ/iView 間のナビゲーションを行うと、内容が変化します。

概要で取り上げられたデスクトップサンプルの下記部分はこのエリアに該当します。 

EPに投稿されました 続きを読む


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 ポータル、ポータルのサービス、およびシステムランドスケープの設定、更新およびサポートを行うためのツールが提供されます。

NWDIに投稿されました 続きを読む

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

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

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

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

ファイル

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

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

ワークスペース

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

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

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

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

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

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