警告のトリガ 

目的

特定のカテゴリに属する警告は、実行時にアプリケーションによってトリガされる必要があります。警告のトリガにはさまざまな方法があります。汎用モジュールを直接呼び出したり、警告をトリガする以下のようなミドルウェアコンポーネントを使用したりすることができます。

●     BOR オブジェクトで特定の変更が発生した場合にイベントをトリガするビジネスオブジェクトリポジトリ (イベントリンク)。たとえば、購買発注が変更された場合に警告がトリガされます。

●     特定の条件をチェックし、条件が一致した場合に警告をトリガする後処理フレームワーク(PPF)。

●     SAP ワークフロー。

●     警告をトリガするCCMS (対応する自動応答がCCMS で割り当てられている場合)。

 

前提条件

警告をトリガするには、以下の前提条件が満たされている必要があります。

●     セントラルアラートサーバは、ローカルシステムのトランザクションSM59 で RFC 宛先として更新されている必要があります。また、トランザクションSALRT1、または設定 → アラートサーバのRFC 宛先で、このセントラルアラートサーバがRFC 宛先として選択されていることも必要です。(これにより、テーブル TALRTDST に一意のエントリが構成されます。)

セントラルアラートサーバが同じクライアントのローカルシステムで実行されている場合は、RFC 宛先を更新する必要はありません。この場合は、トランザクション SALRT1 で NONE と入力するだけです。

●     警告が、外部の通信方法を使用してセントラルアラートシステムから追加的に送信される場合は、選択した外部の通信方法 (電子メール、SMS、FAX) が SAPconnect で正しく設定されている必要があります。

SAPconnect の設定を行う際に、トランザクションSU01 の受信者のユーザ設定において、電子メールアドレスなどの通信データがカスタマイズされている必要があります。

 

 

プロセスフロー

警告をトリガするためのさまざまなオプションを以下に説明します。

汎用モジュールの直接呼出によるトリガ

ローカルシステムのアプリケーションにより、汎用モジュールSALRT_CREATE_API が直接呼び出され、RFC でセントラルアラートサーバにデータが渡されます。

警告カテゴリ (IP_CATEGORY) は唯一の必須インポートパラメータです。

パラメータIP_EXPIRATION_TIME およびIP_EXPIRATION_DATE は、有効期限時間および日付に関するオプションのインポートパラメータです。

オプションのインポートパラメータIP_WAIT_ON_COMMIT は、警告のトリガを即座に行うか次のコミットで行うかを制御するために使用されます。デフォルト設定では、アプリケーションのコミットを待機します。

汎用モジュールを使用してトリガする場合は、動的な後続アクティビティを定義することもできます。この方法は、たとえば、実行時まで警告に追加されない文書を後続アクティビティが参照するような状況で使用されます。これらのアクティビティは、構造 SALRTSACT の内部テーブルに値を入力するか、このテーブルをテーブルパラメータ IT_ACTIVITIES としてモジュールに渡すことにより、汎用モジュールに渡されます。構造 SALRTSACT の項目 ACTTEXT にはアクティビティの名称が入力され、項目 ACTURL には後続アクティビティを参照する URL が入力されます。

パラメータテーブル IT_EXT_RECIPIENTS、IT_EXT_ADDR、およびIT_ROLES を使用すると、非SAP ユーザアドレス、SAP ユーザ (セントラルアドレス管理でのエントリ)、およびSAP ロールを追加のアラート受信者として追加することが可能になります。

ワークプレイス Plug-In での汎用モジュールの直接呼出しによるトリガ

SAP ワークプレイスPlug-In を使用すると、SAP Web Application Server 6.10 または以前の SAP ベーシスリリースで警告管理を使用することができるようになります。警告をトリガする汎用モジュールは、SALERT_CREATE_API です。この汎用モジュールは、前述したSALRT_CREATE_API と同様のインタフェースを備えています。

 

セントラル警告管理サーバには、SAP Web Application Server 6.20 以降が必要です。警告機能は、ローカルアラートシステムのみを拡張します。たとえば、SAP Web Application Server 6.10 または以前の SAP ベーシスリリースにもとづくアプリケーションは、上述の汎用モジュールを使用してカスタマ Exit で警告を発生させることができます。

イベントリンクを使用するトリガ

警告は、ビジネスオブジェクトリポジトリ (BOR) で定義したイベントの発生によってもトリガすることができます。ローカルシステムのトランザクション SWE2 で、レシーバタイプとして警告カテゴリを入力し、イベントのレシーバ汎用モジュールとして汎用モジュールSALRT_CREATE_VIA_EVENT を入力します。アラートフレームワークでは、警告カテゴリをイベントリンクテーブルのエントリから受信します。

アプリケーション固有の属性が必要な場合は、BOR のオブジェクトに対して適切な属性を定義する必要があります。属性が、警告カテゴリの定義においてアラートコンテナのエレメントとしても定義される場合は、レシーバ汎用モジュールにより、BOR のトリガオブジェクトに対して定義された非テーブル属性がすべて決定され、その属性がアラートコンテナに書き込まれます。

また、チェック汎用モジュールまたはレシーバ汎用モジュールを実装することもできます。これらのモジュールを使用すると、それぞれの要件に従ってコンテナへの書込を行うことができます。

アプリケーションに BOR オブジェクトを実装した場合、警告はイベントリンクによるトリガのみを行うようにしてください。

 

後処理フレームワーク (PPF) または出力管理 (MC) を使用するトリガ

警告のトリガに PPF/MC を使用すると、一般条件の定義や出力の開始 (印刷、電子メールの送信、またはワークフローの開始など) が可能になります。警告のトリガは、メソッドコール (PPF) として、あるいは媒体の "特殊機能" (MC) に関する処理プログラムを記述することによってモデル化することができます。

アプリケーションですでに PPF/MC を使用している場合は、PPF/MC を使用してのみ警告をトリガするようにしてください。

 

ワークフローからのトリガ

警告のトリガは、ワークフロー定義における 1 つのステップとして定義することもできます。ただしこのような定義は通常、既存のワークフローの拡張としてのみ行います。ワークフローコンテナ内のエレメントを属性として使用することができます。ワークフローの詳細については、SAP ビジネスワークフロー (BC-BMT-WFM) を参照してください。

 

自動応答を使用する CCMS からのトリガ

CCMS では、自動応答メソッドCCMS_Send_Alert_to_ALM を使用することができます。このメソッドが監視ノードに割り当てられている場合は、監視アーキテクチャにより、このノードの警告が ALM に送信されます。この自動応答の使用方法の詳細については、警告管理 (ALM) への警告の転送を参照してください。

 

 

例

以下のレポート例 RSALERTDEMO1 は、警告が汎用モジュールによってどのように直接呼び出され、パッケージSALERT_LOCAL でどのように利用することができるのかを示しています。

詳細については、パッケージ SALERT_DEMO のレポート例を参照してください。

 

*&---------------------------------------------------------------------*

*& Report  RSALRTDEMO1                                                 *

*&                                                                     *

*&---------------------------------------------------------------------*

*&                                                                     *

*&                                                                     *

*&---------------------------------------------------------------------*

 

REPORT  rsalrtdemo1                                                 .

 

* Here, you find almost all constants, which are relevant for

* the Alert Framework.

TYPE-POOLS:

salrt.

 

CONSTANTS:

*   Name of your alert category

c_category TYPE salrtdcat VALUE 'ALRTFRMWRKTST',

*   Name of application specific attribute / container element

c_docnumber TYPE swfdname  VALUE 'DOCNUMBER'.

 

* Declaration of the alert-container including application data

DATA: li_container  TYPE REF TO if_swf_cnt_container.

 

TRY.

li_container = cl_swf_cnt_factory=>create( ).

CATCH cx_swf_utl_no_instance_found

cx_swf_utl_obj_create_failed .

ENDTRY.

 

* Fill in the document number as an element of the container

TRY.

li_container->element_set(

name             = c_docnumber

value            = '0815').

CATCH cx_swf_cnt_cont_access_denied

cx_swf_cnt_elem_not_found

cx_swf_cnt_elem_access_denied

cx_swf_cnt_elem_type_conflict

cx_swf_cnt_unit_type_conflict

cx_swf_cnt_elem_def_invalid

cx_swf_cnt_invalid_qname

cx_swf_cnt_container .

ENDTRY.

 

* Create an alert of category 'ALRTFRMWRKTEST'.

* Recipient, texts and other attributes are added from

* the definition of the alert category, i.e. the document

* number is the only dynamic element of this API call.

CALL FUNCTION 'SALRT_CREATE_API'

エクスポート

ip_category       = c_category

ii_container      = li_container

ip_wait_on_commit = salrt_true  "An explicite COMMIT WORK statement

"within the application is mandatory for

"the alert delivery.

EXCEPTIONS

OTHERS                  = 1.

 

IF sy-subrc NE 0.

*   message                         "error when creating alert

ENDIF.

 

* Here is our COMMIT WORK

COMMIT WORK.

 

 警告管理