データの外部アプリケーションへの統合 - IBM · v Open Services for Lifecycle Collaboration (OSLC) 統合仕様をサポートするアプリ...

IBM Maximo Asset Managementバージョン 7 リリース 6

データの外部アプリケーションへの統合

��

お願い本書および本書で紹介する製品をご使用になる前に、 431ページの『特記事項』に記載されている情報をお読みください。

本書は、IBM Maximo Integration Framework バージョン 7、リリース 6、モディフィケーション 0、および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： IBM Maximo Asset Management

Version 7 Release 6

Integrating Data With External Applications

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

© Copyright IBM Corporation 2008, 2014.

目次データの外部アプリケーションへの統合 . . 1統合フレームワークの概要 . . . . . . . . . . 1アーキテクチャー . . . . . . . . . . . . 2データ交換用のフレームワーク . . . . . . 2運用管理製品統合用のフレームワーク . . . . 4ユーザー・インターフェース統合用のフレームワーク . . . . . . . . . . . . . . 5

データのエクスポートおよびインポートの有効化 . . 5システムの準備 . . . . . . . . . . . . 5

JMS キューの構成 . . . . . . . . . . 5統合プロパティーの構成 . . . . . . . . 6JMS キューのクーロン・タスクのアクティブ化 6テスト・ファイルへのデータのエクスポート . . 6テスト・ファイルからのデータのインポート . . 7

統合コンポーネント . . . . . . . . . . . . 8オブジェクト構造 . . . . . . . . . . . . 8オブジェクトの識別 . . . . . . . . . . 8代替キー . . . . . . . . . . . . . . 9オブジェクト・フィールド . . . . . . . 10インターフェース・テーブルおよびフラット・ファイルに関する考慮事項 . . . . . . . 10定義済みオブジェクト構造の変更 . . . . . 11オブジェクト構造の構成 . . . . . . . . 11

チャネルおよびサービス . . . . . . . . . 16パブリッシュ・チャネル . . . . . . . . 16呼び出しチャネル . . . . . . . . . . 18オブジェクト構造サービス . . . . . . . 21エンタープライズ・サービス . . . . . . 22標準サービス . . . . . . . . . . . . 25

エンドポイントおよびハンドラー . . . . . . 26エンドポイントの構成 . . . . . . . . . 27定義済みのエンドポイント・ハンドラー . . . 29

統合 Web サービス. . . . . . . . . . . 44Web サービス・ソース . . . . . . . . 45Web サービスのデプロイメント・オプション 46Web サービス導入アクション . . . . . . 46スキーマの生成 . . . . . . . . . . . 47Web サービス記述言語ファイルの生成 . . . 48UDDI への登録 . . . . . . . . . . . 48Web サービスの作成およびデプロイ . . . . 49Web サービス相互作用の概説 . . . . . . 51

外部システム . . . . . . . . . . . . . 53外部システムの構成 . . . . . . . . . 53

事前定義統合コンテンツ . . . . . . . . . 69マスター・データ・オブジェクト . . . . . 69部品オブジェクトおよび在庫オブジェクト . . 78ドキュメント・オブジェクト . . . . . . 84トランザクション・インターフェース・オブジェクト . . . . . . . . . . . . . . 94システム・オブジェクト . . . . . . . . 105データのロード順序 . . . . . . . . . 118

統合データ処理 . . . . . . . . . . . . . 119統合のためのデータ処理の計画 . . . . . . 119インバウンド・データ処理 . . . . . . . . 120インバウンド・メッセージの非同期処理 . . 120インバウンド・メッセージの同期処理 . . . 121インバウンド・データの非同期処理の開始 122インバウンド・データの同期処理の開始 . . 124処理シーケンス . . . . . . . . . . . 126

アウトバウンド・データ処理 . . . . . . . 128パブリッシュ・チャネルとの非同期統合 . . 128呼び出しチャネルとの同期統合 . . . . . 131

統合処理の構成 . . . . . . . . . . . . 132エンタープライズ・サービスを使用したインバウンド・メッセージの非同期処理の構成 . . 132パブリッシュ・チャネルを使用したアウトバウンド・メッセージの非同期処理の構成 . . 134

ルール・ベースのカスタマイズ . . . . . . 135オブジェクトおよびレコードのルール定義 135処理ルールの定義 . . . . . . . . . . 136条件および評価 . . . . . . . . . . . 140統合コントロール . . . . . . . . . . 145処理ルールの構成 . . . . . . . . . . 148

コード・ベースのカスタマイズ . . . . . . 164カスタマイズ Java クラスおよびメソッド 164自動化スクリプトを使用したカスタマイズ 171XSL マッピング . . . . . . . . . . 190インターフェース・テーブルのユーザー出口クラス . . . . . . . . . . . . . . 190

統合フレームワークの構成 . . . . . . . . . 191統合システム・プロパティー . . . . . . . 191JMS キュー構成 . . . . . . . . . . . 199キューの作成および構成 . . . . . . . . 199連続キュー . . . . . . . . . . . . 201継続中のキュー . . . . . . . . . . . 202キュー・メッセージのフォーマット . . . . 206キューのセレクター . . . . . . . . . 208JMS キュー内のメッセージの表示および削除 209WebSphere MQ によるキューの構成 . . . . 210

エラー管理 . . . . . . . . . . . . . 211非キュー・エラー管理 . . . . . . . . 212キュー・ベースのエラー管理 . . . . . . 212エラー管理の構成 . . . . . . . . . . 213エラー通知 . . . . . . . . . . . . 213メッセージ再処理 . . . . . . . . . . 214ファイル・ベースのデータ・インポート機能によるエラーの管理 . . . . . . . . . 217インターフェース・テーブルのエラー管理 221エラーの一般的な原因 . . . . . . . . 222エラーの調査 . . . . . . . . . . . 223メッセージ・トラッキング . . . . . . . 224

クラスターの構成 . . . . . . . . . . . 229

© Copyright IBM Corp. 2008, 2014 iii

サーバー・クラスターの JMS キュー . . . 229クーロン・タスクの構成 . . . . . . . . 232メッセージ処理サーバーの構成 . . . . . 232グローバル・ディレクトリーの構成 . . . . 233インバウンド・メッセージによるサービスへのアクセス . . . . . . . . . . . . 233

統合セキュリティー . . . . . . . . . . 234認証セキュリティー . . . . . . . . . 234許可セキュリティー . . . . . . . . . 242

言語サポート . . . . . . . . . . . . 243複数言語のデフォルトの処理 . . . . . . 243複数言語属性 . . . . . . . . . . . 244双方向言語サポート . . . . . . . . . 244双方向言語の形式 . . . . . . . . . . 245外部システムの双方向言語サポートの構成 245

ファイル・ベースのデータのエクスポートとインポート . . . . . . . . . . . . . . . . 246外部システム・アプリケーションでのデータのエクスポートおよびインポート . . . . . . . 246ファイル・ベースのデータのエクスポート 246ファイル・ベースのデータのインポート . . 247

インバウンド・データ処理用のクーロン・タスク 249XMLFILECONSUMER クーロン・タスク . . 249FLATFILECONSUMER クーロン・タスク . . 250

データのエクスポートおよびインポート用のアプリケーションの構成 . . . . . . . . . . 252オブジェクト構造の内容の定義 . . . . . 252アプリケーションでのデータのインポートおよびエクスポートの有効化 . . . . . . . 253アプリケーションでのデータのエクスポートおよびインポートの開始 . . . . . . . . 254

REST API . . . . . . . . . . . . . . 256REST API フレームワーク . . . . . . . . 256サポートされる表現 . . . . . . . . . . 257リソース・ハンドラーおよび URI . . . . . 258GET メソッド . . . . . . . . . . . . 258クエリーのパラメーターおよび演算子 . . . 261_opmodeor パラメーター. . . . . . . . 263_rsStart パラメーターおよび _maxItems パラメーター . . . . . . . . . . . . . 264_orderbyasc パラメーター . . . . . . . 265_includecols パラメーターおよび _excludecolsパラメーター . . . . . . . . . . . 266_dropnulls パラメーター . . . . . . . . 267_format パラメーターおよび _compact パラメーター . . . . . . . . . . . . . . 267表現のコンテンツ・ネゴシエーション . . . 269セッション内スクロール . . . . . . . . 270GET 要求のキャッシング . . . . . . . 271

PUT、POST、および DELETE の各メソッド 272PUT メソッド . . . . . . . . . . . 273POST メソッド . . . . . . . . . . . 274DELETE メソッド . . . . . . . . . . 275リソースの並行更新 . . . . . . . . . 275

サービス・メソッドのクエリーおよび更新 . . . 276

HTTP POST を使用してリソースを更新するサービス・メソッド . . . . . . . . . 276HTTP GET を使用してリソースをクエリーするサービス・メソッド . . . . . . . . 277HTTP GET を使用してシステム・データをクエリーするサービス・メソッド . . . . . 279

HTTP ヘッダー・プロパティー . . . . . . 280応答コード . . . . . . . . . . . . . 281REST API のセキュリティー . . . . . . . 281REST API のカスタマイズ . . . . . . . . 283REST クエリー・パラメーター . . . . . . 285REST システム・プロパティー . . . . . . 289外部サービス呼び出し . . . . . . . . . 292

OSLC 統合 . . . . . . . . . . . . . . 293Maximo Asset Management での OSLC の実装 294OSLC の構成 . . . . . . . . . . . . 295

OSLC のリソースの仕様. . . . . . . . 295ドメインのサービス・プロバイダー . . . . 297保存されたクエリー . . . . . . . . . 299OSLC セキュリティー . . . . . . . . 300OSLC ロギング. . . . . . . . . . . 302

HTTP トランザクション . . . . . . . . . 302OSLC のリソース・クエリー . . . . . . 302リソース・インスタンスの作成 . . . . . 307リソースの修正 . . . . . . . . . . . 308HTTP ヘッダー . . . . . . . . . . . 311HTTP 応答コード . . . . . . . . . . 313

OSLC コンシューマーとしての統合 . . . . . 314OSLC プロバイダー・レコードの作成 . . . 315OSLC 相互作用の設計 . . . . . . . . 320相互作用グループの作成 . . . . . . . . 329例: OSLC 相互作用の実行 . . . . . . . 330パブリック URI の変更 . . . . . . . . 332OSLC 統合のマイグレーション . . . . . 332手動による UI 変更 . . . . . . . . . 333OSLCのプロパティー . . . . . . . . . 335

統合クエリー . . . . . . . . . . . . . 335クエリー・サービス . . . . . . . . . . 336エンタープライズ・サービス・クエリーの作成 336Web サービスのクエリー . . . . . . . . 336XML 構造のクエリー. . . . . . . . . . 337クエリーの選択基準 . . . . . . . . . . 340フィールドの選択 . . . . . . . . . . 340フィールド評価 . . . . . . . . . . . 342範囲選択 . . . . . . . . . . . . . 343Where 文節の選択 . . . . . . . . . . 343

インターフェース・テーブル . . . . . . . . 345インターフェース・テーブルの作成 . . . . . 347インターフェース・テーブルの再生成 . . . . 348インターフェース・テーブルおよびレコードの削除 . . . . . . . . . . . . . . . . 348インターフェース・テーブルの形式 . . . . . 348インターフェース・テーブルのポーリング . . . 352インターフェース・テーブルのポーリング・クーロン・タスク . . . . . . . . . . 352

iv データの外部アプリケーションへの統合

インターフェース・テーブルのポーリングの拡張 . . . . . . . . . . . . . . 354

外部システムでのインターフェース・テーブルの処理 . . . . . . . . . . . . . . . 355インバウンド処理の有効化 . . . . . . . 355アウトバウンド処理の有効化 . . . . . . 355

統合モジュール . . . . . . . . . . . . . 356統合モジュールのコンポーネント . . . . . . 357統合モジュールの定義 . . . . . . . . 357運用管理製品 . . . . . . . . . . . 357論理管理操作 . . . . . . . . . . . 357

実装の前提条件 . . . . . . . . . . . . 358実装プロパティー . . . . . . . . . . . 359統合モジュールのパラメーター . . . . . 359統合モジュールのプロセス・フロー . . . . 360エンドポイント . . . . . . . . . . . 361

呼び出しチャネルまたは Java クラスの実装 . . 361呼び出しチャネルと Java クラスの比較 . . 362呼び出しチャネルの実装 . . . . . . . . 363Java クラスの実装 . . . . . . . . . . 364

統合モジュールの処理 . . . . . . . . . 365統合コンポーネントの識別 . . . . . . . 365統合モジュールの呼び出し . . . . . . . 366統合モジュールの応答処理 . . . . . . . 369

統合モジュールの構成 . . . . . . . . . 369統合モジュールの作成 . . . . . . . . 370統合モジュールの論理管理操作の選択 . . . 371論理管理操作の統合モジュールとの関連付け 372

論理管理操作の構成 . . . . . . . . . . 374論理管理操作の作成 . . . . . . . . . 374属性の論理管理操作への追加 . . . . . . 374

「コンテキストでの起動」機能 . . . . . . . 375外部アプリケーションの準備 . . . . . . . 375外部アプリケーションへの起動エントリー URL 376製品アプリケーションへの起動エントリー URL 376コンテキストでの起動の有効化 . . . . . . 377起動エントリーの作成 . . . . . . . . 377起動ポイントの署名オプションの構成 . . . 379アプリケーション・メニューへの起動ポイントの追加 . . . . . . . . . . . . . 379起動ポイントとしてのボタンの追加 . . . . 380起動ポイントへの条件の追加 . . . . . . 380

統合の参照情報 . . . . . . . . . . . . . 381統合システム・プロパティー . . . . . . . 381統合 XML . . . . . . . . . . . . . 389概要 . . . . . . . . . . . . . . 389XML 構造 . . . . . . . . . . . . 390統合 XML スキーマ . . . . . . . . . 402

コラボレーション・スイッチ . . . . . . . 415コラボレーション・スイッチの形式 . . . . 415コラボレーション・スイッチの取得 . . . . 416コラボレーション・スイッチの構成 . . . . 417定義済みのコラボレーション・スイッチ . . 420

特記事項. . . . . . . . . . . . . . 431商標 . . . . . . . . . . . . . . . . 432

目次 v

vi データの外部アプリケーションへの統合

データの外部アプリケーションへの統合

統合フレームワークを使用すると、エンタープライズ内部で、または外部システムを使用して、アプリケーション・データを他のアプリケーションと統合することができます。フレームワークには、多数のビジネス・オブジェクトとの統合を可能にする事前定義コンテンツ、および事前定義統合コンテンツの拡張や新規統合ポイントの開発に使用できるツールキットが含まれています。

統合フレームワークの概要統合フレームワークを使用すると、エンタープライズ内部で、または外部システムを使用して、アプリケーション・データを他のアプリケーションと統合することができます。フレームワークには、多数のビジネス・オブジェクトとの統合を可能にする事前定義コンテンツ、および事前定義統合コンテンツの拡張や新規統合ポイントの開発に使用できるツールキットが含まれています。

統合フレームワークには、以下のコンポーネントおよび機能が含まれています。

v 事前定義統合コンテンツ

v 統合コンポーネントを作成および構成するアプリケーション

v Web サービス、HTTP、および Java Message Service (JMS) メッセージングを含む複数の通信モードのサポート

v データベース・インターフェース・テーブル、XML メッセージ、JSON

(JavaScript Object Notation) メッセージ、およびフラット・ファイル (コンマ区切りのテキスト・ファイルなど) などの各種データ形式のサポート

v イベント・ベース処理、バッチ処理、プログラムにより開始された処理、ユーザーにより開始された処理、およびコンテキスト・ベースの外部アプリケーション起動

v 運用管理製品 (OMP) への統合のサポート

v クラスター環境のサポート

v Open Services for Lifecycle Collaboration (OSLC) 統合仕様をサポートするアプリケーションとの相互作用のサポート。統合フレームワークによって、アプリケーションを、OSLC プロバイダー機能を実装した外部アプリケーションと統合できる OSLC コンシューマー・アプリケーションにすることができます。

統合フレームワークには、データの送受信のための複数のオプションが用意されています。統合を計画する際は、要件にとってどのアプローチが最も効率的かを評価してください。代表的な統合シナリオには、以下のものがあります。

v 実装時にレガシー・データを持つファイルをロードする。

v 製品アプリケーションと外部 ERP アプリケーションの間でマスター・データを同期する。

v Web サービスを使用して、外部アプリケーションからの製品アプリケーション・データのリアルタイム・クエリーができるようにする。

© Copyright IBM Corp. 2008, 2014 1

v 製品アプリケーションに入力されるデータを検証するための外部アプリケーションを呼び出す。

大量のレコードを外部システムからインポートする場合は、データをバッチ・ファイルでインポートするか、インターフェース・テーブルを使用します。この方法では、データを分離して、複数のメッセージが別個のトランザクションとして処理されるようにします。処理を同期的に実行する単一トランザクション (Web サービス呼び出しなど) を使用して、トランザクションが妥当な時間内に確実に処理を実行するように、単一トランザクション内のメッセージの数を制限します。統合を計画する際は、どの統合オプションが要件に最も適しているかを評価してください。

事前定義統合コンテンツには多数のビジネス・オブジェクトのサポートが含まれ、それらのビジネス・オブジェクトに対する挿入、更新、および削除機能が使用可能になっています。事前定義コンテンツを使用する場合、実装に影響を及ぼし得るある種の制約があります。ビジネス・オブジェクト内に、機能 (例えば削除機能）を許可しないビジネス・ルールがある場合、その機能を統合に使用することはできません。製品アプリケーションは、挿入、更新、および削除操作のサポートのほか、アクションとして使用可能なその他の機能もサポートしています。事前定義統合コンテンツは、使用可能なアクションをすべてサポートしているわけではありません。ほとんどの場合、「ステータスの変更」アクションは統合全体を通じてサポートされています。

関連概念:

69ページの『事前定義統合コンテンツ』統合フレームワークには、事前定義統合コンテンツがあります。これには、外部システムからのデータのインポートまたは外部システムへのデータのエクスポートをサポートするオブジェクト構造、パブリッシュ・チャネル、およびエンタープライズ・サービスが含まれます。

アーキテクチャー統合フレームワークのアーキテクチャーには、別個のアプリケーションとシステムの間で情報を交換するために必要なデータ、トランスポート、通信、およびセキュリティーの各種コンポーネントが含まれています。

データ交換用のフレームワークデータ交換用のフレームワークには、さまざまなタイプの統合シナリオを実装するために使用できるコンポーネントおよびツールが含まれています。

コンポーネント

フレームワークには、コンポーネントの構成に使用できる事前定義の統合コンポーネントおよびアプリケーションが含まれています。以下の表に、主要コンポーネントについて説明します。

2 データの外部アプリケーションへの統合

表 1. 統合フレームワークのデータ交換コンポーネント

コンポーネント説明

オブジェクト構造オブジェクト構造は、統合フレームワーク・コンポーネントが、アウトバウンドおよびインバウンドのアプリケーション・メッセージ処理に使用する、共通のデータ・レイヤーです。オブジェクト構造は、XML メッセージ (スキーマ) の内容を定義する 1 つ以上の関連ビジネス・オブジェクトで構成されます。

ビジネス・オブジェクト

アプリケーション・ビジネス・オブジェクトは、統合フレームワークの REST (Representational State Transfer) API コンポーネントを使用することで、クエリーおよび更新で REST リソースとして使用可能です。

パブリッシュ・チャネル

パブリッシュ・チャネルは、非同期メッセージを JMS キューを介して外部システムに送信するために使用されます。パブリッシュ・チャネル・メッセージは、イベントまたはデータのエクスポート機能を介して開始できます。

呼び出しチャネル呼び出しチャネルは、同期メッセージを外部システムに送信するため、および応答の内容を処理するために使用されます。このチャネルは、処理ロジックの実装および要求と応答のマッピングをサポートします。呼び出しチャネルでは、応答データを使用してビジネス・オブジェクトを更新し、アプリケーション・ユーザーに表示することができます。

エンタープライズ・サービス

エンタープライズ・サービスは、外部システムのデータのクエリーおよび外部システムからのデータのインポートを行うためのパイプラインです。エンタープライズ・サービスは、データの同期処理(キューを使用しない)、または非同期処理 (キューを使用する) を実行することができます。エンタープライズ・サービスは、Web サービスや HTTP などの複数のプロトコルを使用することができます。

外部システム外部システムは、統合しようとする外部アプリケーションに対して定義されます。外部システムは、使用する通信プロトコルを識別し、その外部システム用に実装するエンタープライズ・サービス、パブリッシュ・チャネル、および JMS キューを識別します。

エンドポイントおよびハンドラー

エンドポイントとその関連ハンドラーは、アウトバウンド・メッセージを外部システムにルーティングします。エンドポイントとハンドラーの組み合わせによって、トランスポート・プロトコル (HTTP

や Web サービスなど)を指定し、宛先に到達するために必要な通信データ (URL など) を提供します。

Web サービス統合フレームワーク・サービス (エンタープライズ・サービスやオブジェクト構造サービスなど) を、外部システムが呼び出すことのできる Web サービスとしてデプロイすることができます。

データのインポートおよびエクスポート

XML ファイルからでもフラット・ファイル (コンマ区切りのテキスト・ファイルなど) からでも、データをロードできます。製品アプリケーションからデータのインポートおよびエクスポートを開始でき、バッチ処理をスケジュールに入れてインポートをバックグラウンド・プロセスとして実行することができます。パブリッシュ・チャネルを使用して、1 つ以上のレコードをファイルにエクスポートでき、その際にフィルター条件を適用してエクスポートするデータの内容を制御することができます。

データの外部アプリケーションへの統合 3

表 1. 統合フレームワークのデータ交換コンポーネント (続き)

コンポーネント説明

内容統合フレームワークには、オブジェクト構造、対応するエンタープライズ・サービスとパブリッシュ・チャネル、外部システム、および各種の通信プロトコルをサポートする定義済みのハンドラーが組み込まれた事前定義コンテンツが用意されています。

処理

フレームワークは、統合メッセージ・フローが出入りするときに、オプション (Java

クラス、XSL マッピング、処理ルールなど) を提供し、統合要件に合わせてメッセージ変換ロジックおよびビジネス・ルールを使用できるようにします。

通信

統合フレームワークによって、非同期または同期データ交換が実行しやすくなります。非同期メッセージは Java Message Service (JMS) キューを介して処理されます。JMS キューでは、優先度の順序 (連続) またはマルチスレッド方式 (継続中) でメッセージを処理できます。送信側への応答を必要とする同期メッセージは、JMS

キューを介して処理されないため、統合フレームワークと外部アプリケーションの間の直接接続が必要です。

HTTP、Web サービス、JMS メッセージングなど、複数の通信プロトコルを構成することができます。

複数の外部アプリケーションと統合する場合、異なるチャネルおよびサービスを構成して、個々の外部アプリケーションの機能に基づき異なる通信プロトコル(HTTP、Web サービス、 JMS メッセージングなど）を使用することができます。

セキュリティー

統合フレームワークは、J2EE 認証セキュリティー用の製品サポートを使用して、Enterprise Java Beans (EJB)、HTTP、および Web サービスのための構成を可能にしています。アプリケーション、オブジェクト、および標準的なサービス・メソッドのための許可セキュリティーを構成することができます。

関連概念:

256ページの『REST API』Representational State Transfer (REST) アプリケーション・プログラミング・インターフェース (API) は、外部アプリケーションが共通基盤のアプリケーション・データをクエリーおよび更新できるようにします。

運用管理製品統合用のフレームワーク統合モジュールを使用すると、工程管理製品を自動化モードで運用管理製品と統合することができます。工程管理製品では、「コンテキストでの起動」機能を使用して支援モードで運用管理製品を統合することができます。

工程管理製品にはアクション Java クラスがあり、それによって統合モジュールへの呼び出しが開始され、続いて運用管理製品への呼び出しが開始されます。工程管理製品はこの後に運用管理製品からの応答を処理します。


論理管理操作は、工程管理製品が運用管理製品に対して実行するアクションを定義します。論理管理操作は、以下のプロパティーを識別します。

v サポートするアクションの名前と説明

v 処理が同期的か非同期的か

v トランザクションの入力 (ソース) および出力 (ターゲット) オブジェクトとフィールド

統合モジュールは、工程管理製品が外部運用管理製品を呼び出すためのメカニズムを提供します。統合モジュールは、工程管理製品によって開始されると、工程管理製品から提供されたデータを使用して運用管理製品サービスの呼び出しを支援します。統合モジュールは、工程管理製品に応答データを返すこともできます。

運用管理製品には、統合モジュールが運用管理製品アクションを開始するために呼び出すことができるサービスが用意されています。

ユーザー・インターフェース統合用のフレームワーク外部アプリケーションでウィンドウを開くように統合フレームワークを構成し、そこに組み込むデータを、そのウィンドウのコンテキストに合わせて提供することができます。

コンソール URL は、Web ベースのコンソールを使用する任意のアプリケーションに対して構成でき、URL は Java Web Start を使用するコンソールに対して構成することができます。起動エントリーは、Web に対応していないアプリケーションを開く場合には使用できません。任意の製品アプリケーションからの起動ポイントを構成できます。アクション、ハイパーリンク、およびアプリケーション・ボタンを使用して、起動ポイントへのアクセスを提供することができます。

同じアプローチを使用して、外部アプリケーションから製品アプリケーション・ウィンドウを開くことができます。

データのエクスポートおよびインポートの有効化統合フレームワークを使用して外部アプリケーションとデータを交換する前に、インバウンドおよびアウトバウンドの通信に必要なコンポーネントを構成する必要があります。以下の手順では、ファイルへのデータのエクスポートおよびファイルからのデータのインポートが実行できることを確認するために、最小限必要な構成ステップを説明します。

システムの準備統合を可能にするために、システムのプロパティー、JMS キュー、およびクーロン・タスクに関連するいくつかの構成タスクを実行する必要があります。

JMS キューの構成JMS キューの構成は、アプリケーション・サーバーで行います。JMS キューの構成は、WebSphere® Application Server では自動的に、または手作業で行われます。WebLogic Server では、JMS キューの構成は常に手動で行う必要があります。


手順1. JMS キューが構成済みであることを確認します。

2. 継続中のキューでメッセージ駆動型 Bean が有効になっていることを確認します。

統合プロパティーの構成統合フレームワークを有効にする前に、統合プロパティーのデフォルト設定を、ご使用の環境に適した設定に変更します。

手順1. 「システムのプロパティー」アプリケーションでフィルター処理を実行し、構成するプロパティーを検出します。「プロパティー」フィールドで mxe.int についてフィルター処理を実行した場合、すべての統合プロパティーがリストされます。

2. mxe.int.dfltuser プロパティーを選択して、指定されているユーザー・アカウントが有効なシステム・ユーザー・アカウントであることを確認します。必要に応じて、プロパティーの値を変更します。このプロパティーは、インバウンドJMS キューで処理されるすべての統合トランザクションに使用する、デフォルトのログイン ID を指定します。

3. オプション: 単一のファイル・ロケーションによってファイル・システム上の統合関連ファイルを保持できる、グローバル・ディレクトリーを構成することができます。Maximo® Asset Management サーバーは、ファイル・システム上のグローバル・ディレクトリーにアクセスできる必要があります。例えば、ファイル・ロケーションが構成されていないファイル・ベースのエンドポイントを使用する場合、エンドポイントによって生成されるファイルは、グローバル・ディレクトリー内のデフォルト・ディレクトリーに配置されます。グローバル・ディレクトリーの名前を mxe.int.globaldir システム・プロパティーで構成することができます。

JMS キューのクーロン・タスクのアクティブ化非同期処理の場合、統合メッセージは JMS キューに入れられます。クーロン・タスクが短い間隔で頻繁に JMS キューをポーリングし、キューで見つかったメッセージを処理します。

手順1. 「クーロン・タスクのセットアップ」アプリケーションで、

JMSQSEQCONSUMER クーロン・タスクを検索します。

2. そのクーロン・タスクが SEQQIN キューと SEQQOUT キューの両方をポーリングするように構成されていることを確認します。

3. 各キューの「アクティブ」チェック・ボックスを設定します。

4. 「保存」をクリックします。

5. 「要求の再ロード」アクションをクリックします。

テスト・ファイルへのデータのエクスポートアウトバウンド処理が正しく構成され、有効になっていることを確認するには、テスト・エクスポートを実行します。


このタスクについて

アウトバウンド処理をテストするために、このタスクではデータのエクスポート機能を使用して担当者レコードをファイルにエクスポートします。このタスクでは、以下の定義済み統合コンポーネントが使用されます。

v 外部システム: EXTSYS1

v パブリッシュ・チャネル: MXPERSON オブジェクト構造を使用するMXPERSONInterface

v エンドポイント: MXXMLFILE

手順1. 「システム」タブで、EXTSYS1 外部システムに対して「有効」チェック・ボックスが選択されていることを確認します。

2. 「パブリッシュ・チャネル」タブで、MXPERSONInterface パブリッシュ・チャネルをフィルターに掛けます。

3. MXPERSONInterface パブリッシュ・チャネルの「詳細」セクションで、「エンドポイント」フィールドに MXXMLFILE を指定します。

4. 「データのエクスポート」をクリックします。

5. 「データのエクスポート」ウィンドウの「カウント」フィールドに 1 を指定して、エクスポートを 1 つのレコードのみに制限します。

タスクの結果

FILEDIR プロパティー内にロケーションが指定されていない場合、XML ファイルはmxe.int.globaldir プロパティー内に指定したロケーションにエクスポートされます。

テスト・ファイルからのデータのインポートインバウンド処理が正しく構成され、有効になっていることを確認するには、テスト・インポートを実行します。

手順1. エクスポートしたテスト・ファイルをテキスト・エディターで開き、以下の変更を実行します。

a. <PublishMXPERSON> タグを <SyncMXPERSON> に変更して、インバウンド処理用に操作を変更します。

b. LASTNAME 値に接尾部を追加して LASTNAME_TEST などのようにし、テスト・ファイルをインポートしたときに変更を確認しやすくします。

c. ファイルを保存します。

2. 外部システム・アプリケーションの「システム」タブで、EXTSYS1 外部システムに対して「有効」チェック・ボックスが選択されていることを確認します。

3. 「エンタープライズ・サービス」タブで、MXPERSONInterface エンタープライズ・サービスをフィルターに掛けます。

4. MXPERSONInterface 行を選択し、「継続中のキューの使用」をクリアします。


6. MXPERSONInterface 行を選択し、「データのインポート」をクリックします。


7. 「データのインポート」ウィンドウで、以下の値を指定します。

a. 「XML ファイル」オプションを選択します。

b. 「インポート・ファイルの指定」フィールドで、変更したテスト・ファイルにナビゲートして選択します。

8. 「OK」をクリックします。

9. 担当者アプリケーションで、テスト・レコードをフィルターに掛け、追加した接尾部が「姓」フィールドの値に含まれていることを確認します。

10. 接尾部を削除してレコードを元の値に復元し、「保存」をクリックします。

統合コンポーネント実装の対象範囲および要件に応じて、新規コンポーネントを作成するか、または定義済みコンポーネントをコピー、変更、または拡張することができます。

統合コンポーネントを複製して、コピーを変更することには、いくつかの利点があります。統合コンポーネントのコピーはユーザー定義のエンティティーとなり、定義済みコンポーネントに適用される変更の制限はそのコピーに適用されません。コンポーネントの元のバージョンは変更されません。コンポーネントをトランザクション処理のために使用している間に変更してしまうことを防ぐには、すべての変更を管理者モードで行ってください。

オブジェクト構造オブジェクト構造は、統合フレームワーク・コンポーネントが Maximo Asset

Management でのデータの送受信に使用する共通のデータ・レイヤーです。オブジェクト構造は、統合メッセージの内容を定義する 1 つ以上の関連ビジネス・オブジェクトで構成されます。

オブジェクト構造は、チャネルおよびサービスのメッセージ内容を提供し、アプリケーション・ベースのインポートおよびエクスポートを可能にします。さらに、オブジェクト構造はそれ自体をサービスとして呼び出すことができ、作成、更新、削除、同期、およびクエリーの操作をサポートします。

オブジェクトの識別オブジェクト構造に組み込むデータを識別するには、アプリケーションとその関連オブジェクトに関する知識がある程度必要です。アプリケーションのデータ・モデルを調べて、どのオブジェクト、データベース表、およびビューに外部システムとの間で転送しなければならないデータが含まれるかを判別します。

どのオブジェクトがデータベース表にデータを追加するかを判断することが必要です。一般に、オブジェクトとデータベース表の間には 1 対 1 の関係が存在します。ただし、複数のオブジェクトがデータを 1 つの表に書き込む場合もあります。

担当者オブジェクト内のデータを外部システムと交換するために、定義済みのオブジェクト構造が用意されています。定義済みのオブジェクト構造がない場合、それを作成するには、必要なデータが PERSON、PHONE、EMAIL、および SMS の各表に入っていることを確認します。これらのデータベース表には、対応するオブジ


ェクトと同じ名前が付いています。これらのオブジェクトを、作成するオブジェクト構造に組み込んでください。オブジェクト構造の名前は、英字で始める必要があります。

オブジェクト構造に複数のオブジェクトが含まれている場合、そのオブジェクト構造は、ルート・オブジェクト (最上位オブジェクトつまりメイン・オブジェクト) と下位階層のオブジェクトを持つ階層として配置されます。オブジェクト構造は、階層内で任意の数のオブジェクト・レベルをサポートすることができます。階層の最上位より下にあるすべてのオブジェクトには上位階層と下位階層の有効な関係を指定する必要があります。また、階層の同じ分岐内で同じオブジェクトを複数回参照することはできません。オブジェクト構造を作成する際は、最初にメイン (最上位)

オブジェクトを追加してください。その後、その上位階層オブジェクトの下位階層のオブジェクトとして、さらにオブジェクトを追加することができます。

代替キーインバウンド・メッセージ処理は、更新および削除をサポートするために、オブジェクトのキー・フィールドを手掛かりにしてシステム内の既存のレコードを検出します。デフォルトの処理は、プライマリー・キーによって既存のレコードを取得します。場合によっては、プライマリー・キーが外部アプリケーションに認識されておらず、外部システムによるレコードの更新および削除をサポートするために代替キーが定義され、外部システムが代替キーを認識していることがあります。

インバウンド・メッセージは、通常、オブジェクトのプライマリー・キーを使用して既にシステムに存在するレコードを検索し、処理します。ただし、プライマリー・キーが内部で生成された値であり、外部システムでは使用できない場合があります。そのような場合は、オブジェクトの代替のキーを定義して、外部システムが(1 次キー・フィールドではなく) 統合フレームワークが使用する代替キー・フィールドを渡すことでそのオブジェクトのデータを取得することができます。

オブジェクトの代替キーは、オブジェクト・レベルまたはオブジェクト構造レベルのいずれかで指定できます。オブジェクト・レベルで代替キーを指定した場合は、そのオブジェクトを含むすべてのオブジェクト構造が同じ代替キーを使用します。オブジェクト構造レベルで代替キーを指定する場合は、複数のオブジェクト構造を使用して、オブジェクトが使用する外部データ・ソースごとに異なる代替キーを指定することができます。オブジェクトの代替キーを構成するインデックスは、データベース構成アプリケーションで定義します。インデックスを作成すると、そのインデックスをオブジェクトの代替キーとして選択できます。

インバウンド処理中に、統合フレームワークは、以下の順序で代替キーおよびプライマリー・キーを処理します。

v オブジェクト構造の代替キーが構成されている場合は、そのキーを処理します。

v オブジェクトの代替キーが構成されているが、オブジェクト構造の代替キーが構成されていない場合は、前者を処理します。

v オブジェクト構造とオブジェクトのいずれの代替キーも構成されていない場合は、オブジェクトのプライマリー・キーを使用します。

代替キーを指定した後に代替キーのインデックスを変更またはドロップすると、インバウンド・メッセージが失敗する場合があります。


オブジェクト・フィールド統合フレームワークおよび外部システムは、オブジェクト構造にあるオブジェクトのデータ・カラムのサブセットを交換します。一定の制限に従って、個々のオブジェクトの永続カラムおよび非永続カラムを組み込んでメッセージ内のオブジェクト・フィールドの内容を制御することができます。

ビジネス・オブジェクトには多数のフィールドを入れることができますが、そのほとんどは統合シナリオには不要な場合があります。オブジェクト構造を構成する際は、どのフィールドを統合メッセージに組み込むかを選択して、アプリケーション間のメッセージ転送のパフォーマンスを改善することができます。デフォルトでは、オブジェクト構造内のオブジェクトにはオブジェクトの永続カラムがすべて含まれています。永続カラムは、オブジェクトが処理の一部としてデータベース表にデータを書き込むために使用するデータ・フィールドです。内容のサイズを制御するために、外部アプリケーションと交換しない永続カラムを除外することができます。組み込まれた永続カラムのみがアウトバウンド・メッセージの XML メッセージの一部になります。インバウンド・メッセージの場合は、オブジェクト構造に組み込まれたオブジェクト・カラムのみが更新されます。プライマリー・キーまたは代替キーに含まれているカラムは除外しないでください。

デフォルトでは、オブジェクト構造はコンポーネント・オブジェクト内のほとんどの非永続カラムを除外します。非永続カラムは、オブジェクトが計算用または一時保管用に使用する一時データ・フィールドです。オブジェクト構造には追加の非永続カラムを組み込むことができます。例えば、永続カラム DESCRIPTION を含むオブジェクトには非永続カラム DESCRIPTION_LONGDESCRIPTION も含まれます。多くの統合シナリオでは詳細説明フィールドが必要なため、この非永続カラムはほとんどの定義済みオブジェクト構造に組み込まれます。このフィールドは、組み込まなければ統合メッセージの一部にはなりません。

インターフェース・テーブルに使用中のオブジェクト構造のメッセージ内容を変更した場合は、インターフェース・テーブルを再生成してオブジェクト構造の更新済みの内容を反映する必要があります。

インターフェース・テーブルおよびフラット・ファイルに関する考慮事項オブジェクト構造を使用してインターフェース・テーブルまたはフラット・ファイルとデータ交換を行う場合は、オブジェクト構造に重複カラム名が絶対に存在しないようにしなければなりません。

インターフェース・テーブルまたはフラット・ファイルの統合シナリオに使用するオブジェクト構造の場合、「フラット構造をサポート」チェック・ボックスを選択する必要があります。このオプションを設定すると、オブジェクト構造内の各オブジェクトの各カラムが必ず固有の名前になるように、メッセージが検査されます。重複するカラム名がある場合は、重複名のいずれかについて別名フィールド名を作成できます。エイリアスを変更すると、すべてのカラム名が一意になり、システムはエラーを起こさずにインターフェース・テーブルまたはフラット・ファイルを生成することができます。インターフェース・テーブルでは、対応するオブジェクトに含まれるすべてのカラムに 18 文字以下のエイリアス名が付けられていることが必要です。


定義済みオブジェクト構造の変更定義済みオブジェクト構造を変更する場合には、一定の制限があります。

オブジェクトを定義済みオブジェクト構造に追加することはできますが、定義済みオブジェクトをオブジェクト構造から削除することはできません。この制限を回避するには、定義済みオブジェクト構造を複製してユーザー定義のオブジェクト構造を作成し、複製したバージョンからオブジェクトを削除します。

統合処理中に適用される標準の検証に従って、永続カラムおよび非永続カラムを組み込んだり、除外したりすることができます。アウトバウンド・メッセージには、オブジェクト構造に追加するオブジェクトのカラムが組み込まれます。インバウンド・メッセージをテストして、追加したカラムが正常に処理されることを確認してください。追加のオブジェクト・カラムが正常に処理されない場合は、インバウンド処理を取り扱うためのオブジェクト構造処理クラスを追加します。

オブジェクト構造をインターフェース・テーブルまたはフラット・ファイルで使用する場合は、別名が競合していないか検査してください。別名の競合は、フラット・ファイルをサポートするオブジェクト構造にある 2 つのオブジェクトが同じ名前の列を持つ場合に発生することがあります。別名の競合を検査すると、重複する名前が特定され、代替として使用する別名を割り当てて競合を解消することができます。インターフェース・テーブルを使用する場合、変更されたオブジェクト構造を使用するエンタープライズ・サービスまたはパブリッシュ・チャネルのテーブルを再生成してください。

オブジェクト構造の構成新規オブジェクト構造を作成でき、そのプロセス中に、スキーマ・ファイルの生成、フィールドの除外または組み込み、および別名競合の解決を行うことができます。また、インバウンド設定の制限を指定したり、詳細構成プロパティーを設定したり、アプリケーションの権限を構成したりすることもできます。

オブジェクト構造の作成:

オブジェクト構造を作成するとき、関連するオブジェクトのグループを、外部アプリケーションと交換する統合メッセージの部品として定義します。統合メッセージの内容を決定する各ビジネス・オブジェクトのデータ・フィールドを指定できます。


構成作業中に、インバウンド・メッセージおよびアウトバウンド・メッセージを処理する Java クラスを必要に応じて定義できます。また、オブジェクト構造を使用して処理される統合メッセージの許可規則を提供するアプリケーションも定義できます。オブジェクト構造がクエリーのみを目的とし、更新に使用しない場合、「照会のみ」オプションを選択します。オブジェクト構造内のメイン・オブジェクトが、下位階層のオブジェクトとしてそれ自身との関係を持つ場合、「自己参照」オプションを設定します。

手順

1. オブジェクト構造アプリケーションで、「新規オブジェクト構造」をクリックします。


2. 「オブジェクト構造」フィールドに、オブジェクト構造 ID を指定します。

3. オプション: クエリー操作のためにオブジェクト構造を使用する場合は、「クエリーのみ」チェック・ボックスをオンにします。

4. オプション: 統合フレームワークと外部システムの間でデータ交換をするためにインターフェース・テーブルまたはフラット・ファイルを使用する場合は、「フラット・ファイル構造のサポート (Support Flat File Structure)」チェック・ボックスをクリックします。

5. 「適用先」フィールドに、オブジェクト構造を使用するモジュールを指定します。

オプション説明

INTEGRATION 統合フレームワーク

MIGRATIONMGR マイグレーション・マネージャー

REPORTING レポート

OSLC OSLC

6. 「ソース・オブジェクト」テーブル・ウィンドウで、「新規行」をクリックします。

7. 次のフィールドに値を入力して、ビジネス・オブジェクト階層を作成します。

v オブジェクト

v 上位階層オブジェクト

v レポート作成の説明

v 関係

v オブジェクト順序

8. 「オブジェクト構造の保存」をクリックします。

次のタスク

オブジェクト構造レコードで「別名の競合」チェック・ボックスが選択されている場合は、ソース・オブジェクト内の重複フィールド名を訂正するために別名を追加または変更できます。オブジェクト構造から除外またはオブジェクト構造に組み込む永続フィールドおよび非永続フィールドも指定できます。

代替キーの構成:

代替キーを構成するには、データベース構成アプリケーションで固有インデックスを作成し、オブジェクト構造または特定オブジェクトの代替キーとしてそのインデックスを参照します。


オブジェクト・レベルで代替キーを設定すると、任意のオブジェクト構造内のオブジェクトのすべての使用に対してそのキーが適用されます。オブジェクト構造内で代替キーを設定すると、選択されたオブジェクト構造を通じてオブジェクトにアクセスする場合にのみ、オブジェクトに対して代替キーが適用されます。


手順

1. 代替キーとして使用するオブジェクトのフィールド (複数可) を指定します。

2. データベースの構成アプリケーションでオブジェクトを選択します。

3. 「インデックス」タブでそれらのフィールドの固有インデックスを作成します。

4. 以下のいずれかのタブで、「代替キー」フィールドにこのインデックスを指定します。

a. すべての外部データ・ソースのオブジェクトに代替キーを適用する場合、データベースの構成アプリケーションの「オブジェクト」タブ。

b. オブジェクトのこの特定の使用に対して代替キーを適用する場合、データベースの構成アプリケーションの「オブジェクト構造」タブ。

オブジェクト構造への非永続フィールドの組み込み:

ビジネス・オブジェクトでは、計算またはデータの一時的な保管のために非永続フィールドが使用されます。デフォルトでは、ビジネス・オブジェクトの非永続フィールドがオブジェクト構造定義から除外されます。統合メッセージに非永続フィールドのデータを含めることができます。

始める前に

定義済みのオブジェクト構造を変更する場合は、そのオブジェクト構造を複製して、変更に適したユーザー定義のバージョンを作成してください。

手順

1. オブジェクト構造アプリケーションで、更新するオブジェクト構造を選択します。

2. 組み込む非永続フィールドを含むビジネス・オブジェクトを選択します。

3. 「フィールドの選択」アクションを選択します。

4. 「非永続フィールド」タブをクリックして、ビジネス・オブジェクト内の非永続フィールドを表示します。

5. 非永続フィールドを組み込むかまたは除外するかを指定します。

オプションインクルード

フィールドのインクルード選択

フィールドの除外クリア


オブジェクト構造からの永続フィールドの除外:

ビジネス・オブジェクトは、永続フィールドを使用して処理データをデータベースに書き込みます。デフォルトでは、永続フィールドがオブジェクト構造定義内に含まれています。統合メッセージにマップしない永続フィールド・データを除外できます。


始める前に

定義済みのオブジェクト構造を変更する場合は、そのオブジェクト構造を複製して、変更に適したユーザー定義のバージョンを作成してください。


プライマリー・キーの一部となっているフィールドを除外することはできません。定義済みオブジェクト構造から永続フィールドを除外すると、インバウンド・メッセージ処理のときに、関連オブジェクトが正しく機能しない場合があります。インバウンド・メッセージをテストし、除外した永続フィールドがオブジェクト処理に影響しないことを確認してください。

手順

1. オブジェクト構造アプリケーションで、更新するオブジェクト構造を選択します。

2. 除外する永続フィールドが含まれているビジネス・オブジェクトを選択します。

3. 「フィールドの選択」アクションを選択します。

4. 「永続フィールド」タブをクリックして、ビジネス・オブジェクト内の永続フィールドを表示します。

5. 永続フィールドを除外するか、または組み込むかを指定します。

オプション除外

フィールドの除外選択

フィールドのインクルードクリア


別名の競合の解決:

オブジェクト構造に複数のオブジェクトが含まれ、フラット・ファイルまたはインターフェース・テーブルがサポートされる場合、オブジェクト内のすべてのフィールドで重複するフィールド名があってはなりません。インターフェース・テーブルとフラット・ファイル・レコードを生成する前に、フィールド名 (別名) の競合をすべて解決しておく必要があります。


別名の競合がある場合は、オブジェクト構造レコードの「別名の競合」チェック・ボックスがオンになっています。別名を変更できるのは、そのレコードの「フラット・ファイル構造をサポート (Support Flat File Structure)」チェック・ボックスが選択されている場合のみです。これは、インターフェース・テーブルまたはフラット・ファイルを使用してデータが処理されることを示しています。

手順

1. 別名の競合がある場合は、「ソース・オブジェクト」テーブルでビジネス・オブジェクトを選択します。

2. 「別名の追加/修正」アクションを選択します。フィールドの別名が重複している場合は、対応する「重複」チェック・ボックスがオンになっています。


3. 重複する別名を更新するには、以下の手順を実行します。

a. 重複する別名の「詳細の表示」をクリックします。

b. 「別名」フィールドに新しい値を指定します。

c. 「OK」をクリックします。

次のタスク

別名の競合をすべて解決したら、インターフェース・テーブルとフラット・ファイル・レコードを生成できます。インターフェース・テーブルを使用している場合は、更新されたオブジェクト構造を使用するテーブルをすべて再生成する必要があります。インターフェース・テーブルを再生成するには、外部システム・アプリケーションで「インターフェース・テーブルの作成」アクションを選択します。

インバウンド・メッセージのフィールドへの制限の設定:

標準の統合処理では、インバウンド・メッセージからの対応する値を使用して、オブジェクト・フィールドの値を設定します。フィールドを制限付きとして設定できるのは、インバウンド・メッセージによって値が更新されることを望まない場合で、例えば、フィールドが内部 ID を持つ場合や、フィールドを設定するロジックが処理クラスによって提供される場合などがあります。

手順

1. 「インバウンド設定の制限」アクションを選択します。

2. 「インバウンド設定の制限」ウィンドウで、設定の制限を適用するオブジェクトを選択します。「インバウンド設定の制限」テーブルは、選択されたオブジェクトについて構成されたフィールドのリストで最新表示されます。

3. インバウンド・メッセージの値で更新することを望まないフィールドについて、「制限」チェック・ボックスを選択します。

4. 「上書き」チェック・ボックスを選択して、フィールドに設定されている制限を除去することができます。システムが生成する ID を持つフィールドなど、一部のフィールドに設定された制限は上書きできません。


オブジェクト構造の詳細構成の設定:

オブジェクト構造の詳細構成を設定して、統合メッセージの一部のデフォルトの処理動作を変更することができます。詳細構成には、下位階層オブジェクトについてキー・フィールドがどのように処理されるか、下位階層オブジェクトのイベントが上位階層オブジェクトの対応するイベントをアクティブ化するかどうか、自動生成データが削除されるかどうかの構成が含まれます。

手順

1. 「詳細構成」アクションを選択します。

2. 属性を下位階層オブジェクトに含める場合、オブジェクトの「上位階層キー属性の除外」チェック・ボックスを選択解除します。チェックされている場合 (デフォルト)、下位階層オブジェクトに存在するキー・フィールドは、同じフィールドが上位階層オブジェクトのキーの一部である場合、下位階層オブジェクトのメッセージのセクションに含まれません。このオプションを選択解除すると、下


位階層オブジェクトのキー・フィールドは常に含められ、フィールドは、メッセージの下位階層オブジェクト・セクションと、上位階層オブジェクト・セクションの両方に含められます。

3. データを保持する必要がある場合、オブジェクトの「自動生成データの削除」チェック・ボックスを選択解除します。チェックされている場合 (デフォルト)、統合処理では、上位階層オブジェクトが作成されるときにビジネス・オブジェクト・ロジックによって自動的に作成されるすべての下位階層レベルのデータが常に削除されます。このオプションを選択解除すると、自動生成されるすべての追加データが保持されます。

4. 下位階層オブジェクトのイベントが、メイン・オブジェクトのイベントをトリガーする必要がある場合、オブジェクトの「イベントの伝搬」オプションをチェックします。オブジェクト・イベントに基づいてメッセージを送信するパブリッシュ・チャネルを構成すると、オブジェクト構造のメイン・オブジェクトについてイベント・リスナーが構成されます。場合によっては、下位階層オブジェクトの更新によってメイン・オブジェクトのイベントがトリガーされず、メッセージが開始されないこともあります。下位階層オブジェクトの更新によって、メイン・オブジェクトを更新することなくメイン・オブジェクトのイベントをトリガーするようにする場合、このオプションをチェックします。上位階層オブジェクトのイベントをトリガーするロジックが下位階層オブジェクトに含まれている場合、この構成でロジックを有効または無効にすることはできません。

チャネルおよびサービスチャネルおよびサービスは、それらのメッセージ内容のオブジェクト構造を参照し、外部システムとデータを同期的および非同期的に交換できるようにします。アウトバウンド・メッセージを処理するチャネルには、パブリッシュ・チャネルと呼び出しチャネルの 2 種類があります。インバウンド・メッセージを処理するサービスには、オブジェクト構造サービス、エンタープライズ・サービス、および標準サービスの 3 種類があります。

パブリッシュ・チャネルパブリッシュ・チャネルは、非同期メッセージを JMS キューを介して外部システムに送信するために使用されます。パブリッシュ・チャネル・メッセージは、イベントまたはデータのエクスポート機能を介して開始できます。

統合フレームワークには事前定義されたパブリッシュ・チャネルが組み込まれています。また、新しいパブリッシュ・チャネルを構成することもできます。パブリッシュ・チャネルを構成する場合は、オブジェクト構造に関連付ける必要があります。さらに、オプションでイベント・リスナーを有効にすることができます。外部システムでパブリッシュ・チャネルを構成して、メッセージの配信先を判別する必要もあります。

処理ルール、Java 処理クラス、または XSL マッピングを構成して、パブリッシュ・チャネルのトランザクション処理をカスタマイズすることもできます。

パブリッシュ・チャネルの構成:

データのエクスポートにパブリッシュ・チャネルを使用するには、パブリッシュ・チャネルを作成し、それをオブジェクト構造に関連付けて、イベント・リスナーを


有効にすることが必要です。また、トランザクションを指定の外部システムに送るエンドポイントを構成する必要もあります。トランザクション処理をカスタマイズするパブリッシュ・ルール、Java 処理クラス、または XSL マッピングを構成することもできます。

パブリッシュ・チャネルの作成:

パブリッシュ・チャネル・レコードを作成して、統合メッセージを外部システムに送信できます。

始める前に

パブリッシュ・チャネルの作成と構成を行う前に、オブジェクト構造アプリケーションを使用して、パブリッシュ・チャネルに関連付けるオブジェクト構造を構成します。

手順

1. パブリッシュ・チャネル・アプリケーションで、「新規パブリッシュ・チャネル」をクリックします。

2. 「パブリッシュ・チャネル」フィールドに、パブリッシュ・チャネルの名前を指定します。

3. 「オブジェクト構造」フィールドに、パブリッシュ・チャネルで使用するオブジェクト構造を指定します。「オブジェクト構造サブレコード」セクションは、このオブジェクト構造に含まれているオブジェクトの詳細情報で最新表示されます。

4. オプション: インターフェース・テーブルをデータ・ソースとして使用する場合は、「インターフェース・テーブル」フィールドにその名前を指定します。このオブジェクト構造を、インターフェース・テーブルで使用するフラット・ファイルをサポートするように構成する必要があります。

5. オプション: アウトバウンド処理ロジックをカスタマイズする場合は、以下の各フィールドに、Java クラスおよび XSL スタイル・シートのパスを指定します。

a. 処理クラス

b. ユーザー出口クラス

c. XSL マップ

d. イベント・フィルター・クラス

指定するすべての Java クラスが、アプリケーションの EAR ファイルに含まれている必要があります。 XSL ファイルは、EAR ファイル内、またはアクセス可能なファイル・システム上にあります。

6. オプション: パブリッシュ・チャネルの処理ルールを構成できます。

7. オプション: 必要に応じて、「オブジェクトの保存」チェック・ボックスをクリアして、パブリッシュ・チャネルがビジネス・オブジェクト・ベースのルールを処理しないようにします。

8. 「パブリッシュ・チャネルの保存」をクリックします。


次のタスク

パブリッシュ・チャネル・リスナーを有効にして、選択されたパブリッシュ・チャネルの作成と処理を統合フレームワークに指示することができます。また、外部システム・アプリケーションを使用して、パブリッシュ・チャネルを外部システムに関連付けて、パブリッシュ・チャネルからメッセージを送信するためのエンドポイントを識別することもできます。

パブリッシュ・チャネル・リスナーの有効化:

パブリッシュ・チャネルでイベント・リスナーを有効にすると、関連するパブリッシュ・チャネル・オブジェクトについての処理アクティビティーをモニターできます。パブリッシュ・チャネルの処理は、関連付けられているオブジェクト構造のメイン・オブジェクトでイベントが発生したときに開始されます。

手順

1. パブリッシュ・チャネル・アプリケーションで、イベント・リスナーと共に構成するパブリッシュ・チャネルを選択します。

2. 「イベント・リスナーを有効にする」アクションを選択します。

3. 「OK」をクリックして、パブリッシュ・チャネル・リスナーを有効にします。パブリッシュ・チャネルの詳細情報が最新表示され、「イベント・リスナー(Event Listener)」チェック・ボックスが選択されています。

次のタスク

イベント・リスナーを無効にしたい場合は、随時「イベント・リスナーを無効にする」アクションを選択します。

呼び出しチャネル呼び出しチャネルでは、処理ロジックと、インバウンド・データおよびアウトバウンド・データのマッピングを定義し、統合フレームワークが外部アプリケーションを呼び出して応答を処理することを可能にします。事前定義された呼び出しチャネルは提供されていません。

呼び出しチャネルの作成:

オブジェクト構造から外部システムにアウトバウンド・データを送信し、外部システムからの応答を処理するための呼び出しチャネル・レコードを作成できます。

始める前に

アプリケーション EAR ファイルに、定義済み処理クラス、ユーザー出口クラス、および XSL マッピング・ファイルを組み込む必要があります。アプリケーション・サーバーからアクセス可能な XSL マッピング・ファイル名のパスも定義する必要があります。

手順

1. 呼び出しチャネル・アプリケーションで、「新規呼び出しチャネル」をクリックします。

2. 「呼び出しチャネル」フィールドに、呼び出しチャネル ID を指定します。


3. 以下のフィールドに値を入力します。

v アダプター

v エンドポイント

4. オプション: この呼び出しチャネルが外部アプリケーションからの応答を処理する場合、「応答の処理」チェック・ボックスを選択します。

5. 「サービス要求構成」テーブル・ウィンドウの以下のフィールドに値を入力します。


要求オブジェクト構造アウトバウンド・データ処理の内容を定義するために使用するオブジェクト構造。

要求処理クラス呼び出しチャネルが定義済みアウトバウンド処理ロジックを必要とするときに使用される Java クラス・ファイル。

要求ユーザー出口定義済みアウトバウンド処理ロジックをカスタマイズするのに呼び出しチャネルが使用するクラス・ファイル

要求 XSL ファイル定義済みアウトバウンド呼び出しチャネル・マッピングをカスタマイズするのに使用する XSL ファイル。

6. オプション: 「応答の処理」チェック・ボックスを選択した場合、「サービス応答構成」テーブル・ウィンドウの以下のフィールドに値を入力します。


応答オブジェクト構造応答の内容を定義するために使用するオブジェクト構造。

応答処理クラス呼び出しチャネルが応答するために定義済みインバウンド処理ロジックを必要とするときに使用される Java クラス・ファイル。

応答ユーザー出口クラス応答用の定義済みインバウンド処理ロジックをカスタマイズするのに呼び出しチャネルが使用するクラス・ファイル。

応答 XSL ファイル応答用の定義済みインバウンド呼び出しチャネル・マッピングをカスタマイズするのに使用する XSL ファイル。

7. 「呼び出しチャネルの保存」をクリックします。

次のタスク

以下のフォーマットの URL を使用して、オブジェクト構造の XML スキーマを表示できます。

http://localhost:port/meaweb/schema/service/object_structure_name


呼び出しチャネルを呼び出すためのアクションの構成:

統合フレームワークには、システム・アクションとして構成できるデフォルトのアクション・クラスが用意されています。このアクション・クラスを指定することで、呼び出しチャネルを使用して外部サービスを呼び出すようにユーザー・インターフェース・コントロール、エスカレーション、またはワークフローを構成することができます。

手順

1. 呼び出しチャネル・アプリケーションで呼び出しチャネルを作成します。

2. アクション・アプリケーションでアクションを作成します。

3. アクションのオブジェクトを指定します。このオブジェクトは、呼び出しチャネルの要求オブジェクト構造のメイン・オブジェクト、およびアクションを呼び出すアプリケーション、ワークフロー、またはエスカレーションのメイン・オブジェクトと同じでなければなりません。

4. 「タイプ」フィールドに「カスタム・クラス」を指定します。

5. 「変数」フィールドに、カスタム・クラスの名前を指定します。この目的で用意されているデフォルト・クラスの名前であるpsdi.iface.action.InvokeCustomClass を使用できます。または、外部システムを呼び出すために独自のカスタム・クラスを作成している場合は、それに代わるクラス名を使用してもかまいません。

6. 「パラメーター/属性」フィールドに値を指定します。値は以下の順序で指定し、それぞれの値をコンマで区切ります。

a. 必須: 使用する呼び出しチャネルの名前。ここに指定する値は、呼び出しチャネルの名前と正確に一致している必要があります。

b. オプション: 応答オブジェクト構造のメイン・オブジェクトが、呼び出しチャネルの要求オブジェクト構造のメイン・オブジェクトと異なっている場合は、使用する関係の名前。応答オブジェクトが要求オブジェクトと同じ場合、関係は不要です。

c. オプション: 関係を指定した場合は、適用するアクションを指定します。デフォルトのアクションは「追加」です。これによってレコードが作成されます。既存のレコードを更新するには、アクションとして「変更」を指定します。要求オブジェクト構造と応答オブジェクト構造が同じ場合、更新されたフィールドが応答オブジェクト構造にマップされるとオブジェクトは更新されます。

7. アクションの適用先がすべてのアプリケーション、ワークフロー、またはアプリケーションのどれであるかを指定します。

8. アクションを保存します。

次のタスク

そのアクションにアプリケーション、ワークフロー、またはエスカレーションを関連付けます。メイン・オブジェクトはまずアクション・クラスに渡され、その後に呼び出しチャネルのオブジェクト構造に渡されて、要求 XML を形成します。


アプリケーションからの外部システムの呼び出し:

(呼び出しチャネルを介して) 外部システムを呼び出すようにアクション・クラスを構成すると、その呼び出しアクションをトリガーするボタンをアプリケーション内で構成することができます。また、アクション・クラスを拡張して、アプリケーションのダイアログ・ボックスにトランザクションの結果を表示することもできます。

始める前に

呼び出しアクションをアプリケーションに追加する前に、呼び出しチャネルとアクション・クラスを作成する必要があります。呼び出しの結果を表示する場合は、あらかじめ「結果」(ダイアログ・) ウィンドウを作成しておきます。

手順

1. アプリケーション・デザイナー・アプリケーションで、アプリケーションを開きます。このアプリケーションのメイン・オブジェクトは、アプリケーションから呼び出す呼び出しチャネルおよびアクションのメイン・オブジェクトと同じでなければなりません。

2. コントロール・パレットからワークスペースに「ボタン・グループ」コントロールを追加します。「ボタン・グループ」コントロールによって、「プッシュボタン」コントロールが自動的にワークスペースに追加されます。

3. 「プロパティー」をクリックして、「プッシュボタンのプロパティー」ウィンドウを開きます。

4. 「値」フィールドにボタンの名前 (「外部システムの呼び出し」など) を指定します。

5. 「ターゲット ID」フィールドに、「結果」ウィンドウの「コントロール ID」を指定します。

6. 「値」フィールドに、呼び出しチャネルを呼び出して結果を「結果」ウィンドウにリダイレクトするメソッドを指定します。例を以下に示します。

InvokeChannelCache.getInstance().getInvokeChannel(channelName).invoke(metaData, mbo, mbo.getMboSet(rel), action, null);

ここで、

v channelName 値は呼び出しチャネルの名前です。

v mbo 値はオブジェクトの名前です。

v rel 値は関係の名前です (該当する場合)。

v action 値は「追加」です。

オブジェクト構造サービスオブジェクト構造を構成するときに、サービスまたは REST リソースとして使用可能にするための追加の構成は不要です。

関連概念:



エンタープライズ・サービスエンタープライズ・サービスは、外部データのクエリーおよび外部システムからのデータのインポートを行うためのパイプラインです。エンタープライズ・サービスは、データの同期処理 (キューを使用しない)、または非同期処理 (キューを使用する) を実行することができます。エンタープライズ・サービスは、Web サービスやHTTP などの複数のプロトコルを使用することができます。

エンタープライズ・サービスには、データがターゲット・オブジェクトに到達する前にデータを変換してビジネス処理ルールを適用するデータ処理層があります。インバウンド・メッセージがオブジェクト構造層に到達する時点で、XML メッセージはオブジェクト構造スキーマのフォーマットになっていなければなりません。これで、統合フレームワークがメッセージを正しく処理できます。

エンタープライズ・サービスを構成して以下のトランザクション処理を実装することができます。

v 処理ルール

v ユーザー出口 Java 処理クラス

v エンタープライズ・サービス処理クラス

v XSL マッピング

ゲートウェイは、エンタープライズ・サービス・メッセージのエントリー・ポイントです (ただし、外部キューから統合キューに直接配信されるメッセージを除きます)。統合のシナリオによっては、ゲートウェイ・プロパティーを構成すると便利なことがあります。例えば、システム ID などのプロパティーがヘッダー情報ではなく、XML メッセージ内で提供される場合がこれに該当します。インタープリターJava クラスを構成して、インバウンド・メッセージで提供される外部システム ID

やエンタープライズ・サービス ID などの JMS メッセージ・ヘッダー・プロパティーを変更することができます。代わりに、エンタープライズ・サービス・アプリケーションでゲートウェイ・プロパティーを構成することもできます。

エンタープライズ・サービスの構成:

エンタープライズ・サービスを作成するとき、エンタープライズ・サービスをオブジェクト構造と関連付けます。また、インバウンド・メッセージのヘッダー情報に追加するゲートウェイ・プロパティーを構成することもできます。

エンタープライズ・サービスの作成:

エンタープライズ・サービス・レコードを作成して、外部システムからインバウンド・データを受け取ることができます。エンタープライズ・サービスでは、外部システムからインバウンド・データを受け取る際に統合フレームワークが使用する、データ形式変更および処理ルールを識別できます。

始める前に

エンタープライズ・サービスを作成して構成する前に、オブジェクト構造アプリケーションを使用して、エンタープライズ・サービスに関連付けるオブジェクト構造を構成します。



「外部スキーマの使用」チェック・ボックスを選択すると、「分割タグ」、「外部スキーマ・ファイル」、および「外部スキーマ要素」の各フィールドが編集可能になります。外部スキーマの値により、スキーマ・ロケーションと外部ルート要素名が識別されます。

手順

1. エンタープライズ・サービス・アプリケーションで、「新規エンタープライズ・サービス」をクリックします。

2. 「エンタープライズ・サービス」フィールドに、エンタープライズ・サービスID を指定します。


v オブジェクト構造

v アダプター

4. オプション: 以下のフィールドに値を入力します。


操作エンタープライズ・サービスによるデータの処理方法を決定します。例えば、オブジェクトを同期したり、新規オブジェクトを作成したりすることができます。

既存オブジェクトの更新、削除、またはクエリーもできます。

乗法コントロールエンタープライズ・サービスが複数の組織またはサイト用に 1 つのインバウンド・メッセージを乗算するときに使用する相互参照コントロールを決定します。

インターフェース・テーブルエンタープライズ・サービス・オブジェクト構造の内容を反映します。

分割タグ受信したメッセージに複数の文書インスタンスがあるかどうかを識別します。

例えば、1 つのメッセージに 10 個の注文書が含まれているとします。分割処理により、これらのインスタンスが個別に処理されます。インバウンド・キューには複数のファイルが書き込まれます。

これらのノード値の識別に使用する構文は、完全修飾 XPATH 式である必要があります。

5. オプション: 外部スキーマを使用するには、「外部スキーマの使用」チェック・ボックスを選択します。

6. オプション: 以下の手順を実行して、インバウンド・エンタープライズ・サービス処理ロジックをカスタマイズできます。


a. エンタープライズ・サービスに定義済みインバウンド処理ロジックが必要な場合は、「処理クラス」フィールドにクラス値を入力します。

b. 「ユーザー出口クラス」フィールドに、エンタープライズ・サービスが定義済みインバウンド処理ロジックをカスタマイズするために使用するクラス値を入力します。

c. 「XSL マップ」フィールドに、定義済みインバウンド・エンタープライズ・サービス・マッピングをカスタマイズするための値を入力します。

7. 「エンタープライズ・サービスの保存」をクリックします。

次のタスク

外部システム・アプリケーションを使用して、エンタープライズ・サービスを外部システムに関連付けることができます。

エンタープライズ・サービスの追加のオブジェクト構造の構成:

エンタープライズ・サービスは、プライマリー・オブジェクト構造に関連付けられている必要があります。エンタープライズ・サービスに別のオブジェクト構造を追加して、エンタープライズ・サービスのプライマリー・オブジェクト構造に含まれない追加のデータの更新をサポートすることができます。エンタープライズ・サービスは、定義されている処理順序に基づいて、プライマリー・オブジェクト構造を処理する前に、追加のオブジェクト構造を処理します。

手順

1. エンタープライズ・サービス・アプリケーションで、オブジェクト構造を追加するサービスを表示します。

2. 「追加オブジェクト構造の追加/変更」アクションを選択して、「新規行」をクリックします。



v 処理の順番

4. オプション: 以下の手順を実行して、インバウンド・エンタープライズ・サービス処理ロジックをカスタマイズできます。

a. エンタープライズ・サービスに定義済みインバウンド処理ロジックが必要な場合は、「処理クラス」フィールドにクラス値を入力します。

b. 「ユーザー出口クラス」フィールドに、エンタープライズ・サービスが定義済みインバウンド処理ロジックをカスタマイズするために使用するクラス値を入力します。

c. 「XSL マップ」フィールドに、定義済みインバウンド・エンタープライズ・サービス・マッピングをカスタマイズするための値を入力します。

d. 「乗法コントロール」フィールドに、エンタープライズ・サービスが複数の組織またはサイト用に 1 つのインバウンド・メッセージを乗算するときに使用する相互参照コントロールを定義する値を入力します。



ゲートウェイのプロパティーのエンタープライズ・サービスへの追加:

ゲートウェイは、エンタープライズ・サービス・メッセージのエントリー・ポイントです (ただし、外部キューから統合キューに直接配信されるメッセージを除きます)。外部システム (SENDER) またはエンタープライズ・サービス (INTERFACE)

を変更でき、必要に応じて他の JMS ヘッダー・プロパティーを設定できるインタープリター Java クラスを実装できます。エンタープライズ・サービス・アプリケーションでは、ゲートウェイ・プロパティーをハードコーディングされた値として、または XML タグを指定して設定できます。

始める前に

ゲートウェイのプロパティーを構成する前に、「ゲートウェイのプロパティー」の設定値について、以下の点を検討してください。

v 「XML タグ」チェック・ボックスをオンにして、「値」フィールドをヌルのままにした場合、ゲートウェイでは、該当のプロパティーの値として、XML メッセージ内のルート・エレメントの名前が使用されます。

v 「XML タグ」チェック・ボックスをオンにして、「値」フィールドにタグ名を入力した場合、ゲートウェイでは、該当のプロパティーの値として、そのタグの値が使用されます。

v XML メッセージにタグが複数回現れる場合は、最初に現れたそのタグの値がアダプターで使用されます。「XML タグ」チェック・ボックスをオフにして、「値」フィールドにデータ値を入力した場合、ゲートウェイでは、該当のプロパティーの値として、そのデータが使用されます。

手順

1. エンタープライズ・サービス・アプリケーションで、ゲートウェイのプロパティーを追加するサービスを表示します。

2. 「ゲートウェイのプロパティー」アクションを選択します。

3. 「エンタープライズ・サービスのゲートウェイのプロパティー」テーブル・ウィンドウで、「新規行」をクリックします。

4. 「プロパティー」フィールドに、メッセージに組み込むプロパティーの名前を指定します。

5. 「値」フィールドに、プロパティーの値として使用するデータを入力します。

6. オプション: 該当のプロパティーの値として、XML ルート・エレメントを使用するかどうかを指定します。

オプション XML タグ

XML ルート・エレメントを使用する選択

XML ルート・エレメントを使用しないクリア


標準サービス標準サービスは、アプリケーションで注釈が付けられているメソッドに基づいています。標準サービスは、オブジェクトの注釈が付けられたメソッドに固有であり、


他のオブジェクトで再使用することはできません。標準サービスは Web サービスとしてデプロイすることができます。REST API を使用して、標準サービスにアクセスできます。

標準サービスは、オブジェクトに対して固有の操作を実行するためにアプリケーションが提供するサービスです。標準サービスは、サービスの中で適切に注釈が付けられたメソッドでのみ使用可能です。標準サービス用に生成されたサービス・スキーマは、対応するアクションによってのみ使用されます。

関連概念:


エンドポイントおよびハンドラーエンドポイントとその関連ハンドラーは、アウトバウンド・メッセージを外部システムにルーティングします。エンドポイントとハンドラーの組み合わせは、使用するトランスポート・プロトコル (HTTP や Web サービスなど) を指定し、宛先に到達するために必要な通信データ (URL など) を提供します。

パブリッシュ・チャネルを使用してデータをエクスポートする場合は、アウトバウンド・キューのクーロン・タスクがハンドラーを呼び出します。呼び出しチャネルを使用してデータをエクスポートする場合は、呼び出しチャネルが直接ハンドラーを呼び出します。ハンドラーは、メッセージのメタデータ・プロパティーを使用して、外部システム (パブリッシュ・チャネル・トランザクションの場合) と、エンドポイント・プロパティーに対して構成されたオーバーライド値を判別します。これでハンドラーは、そのハンドラーが関連付けられているエンドポイントによって指定された宛先にデータを送信します。単一のハンドラーに複数のエンドポイントを設定して、エンドポイントごとに異なるパラメーターを指定することができます。

エンドポイントとハンドラーは、アウトバウンド統合の場合にのみ使用されます。ただし、インターフェース・テーブルのエンドポイントとハンドラーは、インバウンド統合に必要なインターフェース・テーブルの作成もサポートします。

エンドポイントは、ハンドラーが使用する実行パラメーター値を提供し、その機能を実行します。エンドポイント定義に含まれるメタデータが、アウトバウンド統合メッセージとともに実行時にハンドラーによって使用されます。一部のハンドラー(全部ではありません) にはエンドポイントが事前定義されています。エンドポイント・アプリケーションを使用して、これらを変更したり新しいエンドポイントを構成したりすることができます。事前定義されているエンドポイントを以下の表に示します。

エンドポイントハンドラー説明

MXFLATFILE FLATFILE アウトバウンド統合メッセージをフラット・ファイル形式で指定のディレクトリー位置に書き込みます。

MXIFACETABLE IFACETABLE アウトバウンド統合メッセージをインターフェース・テーブルに書き込みます。


エンドポイントハンドラー説明

MXXMLFILE XMLFILE アウトバウンド統合メッセージを XML ファイルの形式で指定のディレクトリー位置に書き込みます。

MXCMDLINE CMDLINE CMDLINE ハンドラーを実装します。コマンドおよびエンドポイントを入力データとして受け取り、SSH プロトコルを使用して、ターゲット・システムに対してコマンドを起動し、結果を戻します。

多くの定義済みのハンドラーが用意されています。一部のハンドラーについては、対応するエンドポイント定義が既に構成されています。エンドポイント定義は、ハンドラー・パラメーターのメタデータ値 (FLATFILE ハンドラーのディレクトリー名など) を提供します。

エンドポイントの構成エンドポイント・アプリケーションでは、エンドポイントを作成して、アウトバウンド・トランザクションの配信方法およびこれらのトランザクションをルーティングするハンドラーを指定できます。

エンドポイントの作成:

エンドポイントを作成して、ターゲット・ロケーションを識別するとともに、統合フレームワークまたはデプロイメント・マネージャーがデータをパブリッシュしたり、サービスを起動したりするために使用するトランスポート・メカニズムを識別します。

手順

1. エンドポイント・アプリケーションで、「新規エンドポイント」をクリックします。

2. 「エンドポイント」フィールドで、そのエンドポイントの ID を指定します。

3. 「ハンドラー」フィールドに値を指定します。「使用者」フィールドに、指定されたエンドポイント・ハンドラーに関連する情報が表示されます。

4. 「エンドポイントのプロパティー」ウィンドウで、「エンドポイントのプロパティー」フィールドにある「詳細の表示」をクリックし、以下のアクションを実行します。

a. 「値」フィールドに固有値を追加して、エンドポイント・プロパティーを識別します。

b. エンドポイント・プロパティーにストレージと表示に対する追加のセキュリティーが必要かどうかを識別する「暗号化された値」に、値を追加します。パスワード・プロパティーがあるエンドポイントでのみ、暗号化された値を更新できます。

c. エンドポイント・プロパティーのコードを上書きできるようにするかどうかを識別する「上書きを許可」チェック・ボックスを選択します。呼び出しチャネル処理クラスを使用する場合に、このチェック・ボックスを選択します。

5. 「エンドポイントの保存」をクリックします。


次のタスク

ハンドラーを追加して、特定のエンドポイント・ロケーションに特定のフォーマットでアウトバウンド・データを送る方法を指定できます。エンドポイントは、以下の統合フレームワーク・アプリケーションで使用できます。

v 外部システム

v パブリッシュ・チャネル

v 呼び出しチャネル

v 統合モジュール

v 論理管理操作

エンドポイントへのハンドラーの追加:

ハンドラーをエンドポイント・レコードに追加して、特定のエンドポイント・ロケーションにアウトバウンド・データを送る方法を指定できます。また、ハンドラーを追加して、データ転送に使用するデータ・フォーマットを定義することもできます。ハンドラーを作成するときには、データ転送に必要な処理ロジックが含まれる特定の Java™ クラス・ファイルを識別する必要があります。


定義済みのハンドラーは変更または削除できません。

手順

1. エンドポイント・アプリケーションで、ハンドラー情報を使用して更新するエンドポイントを選択します。

2. 「ハンドラーの追加/変更」アクションを選択します。

3. 「新規行」をクリックします。


v ハンドラー

v ハンドラー・クラス名

v 適用先


カスタム・ハンドラーの作成:

例えば、FTP サーバーとの通信をサポートするために、カスタム・ハンドラーを作成してエンドポイントに関連付けることができます。


ハンドラー・クラスには、値を指定する必要があるプロパティーが表示されます。psdi.iface.samples ディレクトリーの FTPHandler.java ファイルには、FTP ハンドラーの例が入っています。

手順

1. カスタム・ハンドラーを作成するには、RouterHandler インターフェースを実装します。


2. ハンドラーがエンドポイントへのデータ送信に使用するプロパティーのリストを返す、以下のメソッドを指定します。

getParameter()

このメソッドは RouterPropsInfo オブジェクトのリストを返します。RouterPropsInfo オブジェクトの isCrypto 属性は、データの保管時にプロパティー値を暗号化するかどうかを示します。パスワード・プロパティーの場合、この属性の値は True です。

3. 指定されたエンドポイントにデータを送信する、以下のメソッドを指定します。

sendData(Map metaData, byte[] data, Map destinationMap)

このメソッドは以下の情報を返します。

v metaData は外部システムおよびインターフェースに関する情報を提供します

v data は XML データです

v destinationMap はエンドポイントを指定します。

定義済みのエンドポイント・ハンドラーエンドポイントに関連付けることができる定義済みハンドラーが提供されています。さらに、必要に応じてカスタム・ハンドラーを作成して登録することもできます。

Enterprise Bean ハンドラー:

Enterprise Java Bean (EJB) ハンドラーは、Enterprise Bean クライアントで構成される Java コンポーネントです。このハンドラーは、クライアントがターゲット・クライアントとの通信およびターゲット・クライアントへの統合メッセージの配信に使用する、一組のプロパティーをパブリッシュします。ターゲット・クライアントはローカル・アプリケーション・サーバーまたはリモート・アプリケーション・サーバーのどちらで稼働していてもかまいません。

接続を確立するには、ハンドラーのクラス・パス内でリモート Java クラスとホームJava クラスが使用可能でなければなりません。ハンドラーのアプリケーション・サーバーと異なるリモート・アプリケーション・サーバー上にクライアントがある場合は、クライアントの JAR ファイルの参照がハンドラーのクラス・パス内になければなりません。Enterprise Bean クライアントがハンドラーのアプリケーション・サーバーと同じリモート・アプリケーション・サーバー上にある場合、ハンドラーはコンテキスト・ファクトリー・クラス名をローカル・アプリケーション・サーバーから取得します。

CONTEXTFACTORY プロパティー

この必須プロパティーは、J2EE コンテキスト・ファクトリー・クラス名を指定します。使用するデフォルトのコンテキスト・ファクトリーの名前はご使用のアプリケーション・サーバーの資料に記載されています。

CONTEXTFACTORY では、ターゲット・クライアントが IBM WebSphere

Application Server で稼働する場合に以下のプロパティーが使用されます。

com.ibm.websphere.naming.WsnInitialContextFactory


EJBEXIT プロパティー

このオプション・プロパティーは、カスタマイズ用に使用し、EJBExit インターフェースを実装するカスタム Java クラスの完全修飾名を指定します。

このプロパティーに値を指定しない場合、DefaultEJBExit インターフェースが実行され、Enterprise Bean のメソッド・シグニチャーとパラメーターの解決が試行されます。

Enterprise Bean クライアントに独自のメソッド・シグニチャーおよびパラメーターがある場合は、使用しているバージョンの EJBExit インターフェースと以下のメソッドの実装を含む Java クラスを作成します。

public Class getClassParams()

getClassParams() メソッドは、メソッド・シグニチャーを Java クラスのアレイの形式で返します。

public Object[] getObjectParams(byte[] data, String interfaceName, Map

String,? metaData)throws MXException

getObjectParams() メソッドは、Enterprise Bean ビジネス・メソッドのパラメーターを Java オブジェクトのアレイの形式で返します。

public void responseOk(Object response)throws MXException

responseOk() メソッドは、Enterprise Bean 呼び出しが正常に行われた後で呼び出されます。

public void responseError(Exception e) throws MXException

responseError() メソッドは、Enterprise Bean の呼び出し中にエラーが発生した場合に、原因となっている例外がパラメーターとして指定されて呼び出されます。

次のコードは、Enterprise Bean クライアントにバイト配列とストリングを含むビジネス・メソッドがある場合に、getClassParams() の実装がどのようになるかを示しています。

Class[] classParams = {byte[].class, String.class};return classParams;

次のコードは、Enterprise Bean クライアントにバイト配列とストリングを含むビジネス・メソッドがある場合に、getObjectParams () の実装がどのようになるかを示しています。

byte[] data = ...;String ifaceType = ...;

Object[] objParams = {data,ifaceType};return objParams;

EJBExit クラス・ファイルのパッケージ構造の場所を識別するには、以下のいずれかのアクションを実行します。

v クラスを applications/maximo/businessobjects/classes ディレクトリーのJava パッケージ構造に配置します。


v mboweb¥webmodule¥META-INF¥MANIFEST.MF クラス・パスを変更してパッケージ構造を組み込みます。

v アプリケーションの EAR ファイルを再作成して、EJBExit クラス・ファイルを組み込みます。

JNDINAME プロパティー

この必須プロパティーは、Enterprise Bean クライアントが WebSphere Application

Server の Java Naming and Directory Interface (JNDI) ツリーに登録されるときの名前を指定します。ファイル名は ibm-ejb-jar-bnd.xml で、プロパティーは以下のように設定します。

<ejbBindings xmi:id="Session_enterpriseservice_Bnd"jndiName="ejb/maximo/remote/enterpriseservice">

<enterpriseBean xmi:type="ejb:Session"href="META-INF/ejb-jar.xml#Session_enterpriseservice"/>

</ejbBindings>

METHODNAME プロパティー

この必須プロパティーは、このハンドラーで呼び出される Enterprise Bean クライアントによって公開されるパブリック・ビジネス・メソッドを指定します。

PROVIDERURL プロパティー

この必須プロパティーは、Enterprise Bean が実行されているターゲット・アプリケーション・サーバーの URL を指定します。これで、システムはjava.naming.provider.url プロパティーへのマッピングを行い、InitialContext オブジェクトを作成します。

次の例は IBM WebSphere Application Server プロバイダーの URL です。

corbaloc:iiop:hostname:iiopport

ハンドラーとターゲット Enterprise Bean が同じアプリケーション・サーバー・インスタンスで実行されている場合は、このプロパティーを指定しないでください。この場合、ローカル・サーバーの URL がデフォルトとして使用されるためです。

USERNAME および PASSWORD プロパティー

ユーザー名とパスワードのプロパティーは、InitialContext オブジェクトの作成に使用される java.naming.security.principal (USERNAME) プロパティーおよびjava.naming.security.credentials (PASSWORD) プロパティーに対応します。

フラット・ファイル・ハンドラー:

FLATFILE ハンドラーはアウトバウンド統合メッセージをフラット・ファイルに変換して、それをロケーションが構成可能なディレクトリーに書き込みます。フラット・ファイルには、ASCII データが行と列の形式で入っています。テキストの各行が 1 行になり、区切り文字は行の中の各列を区切ります。FLATFILE ハンドラーは標準の UTF-8 フォーマットでアウトバウンド・フラット・ファイルをエンコードします。


FLATFILE ハンドラーは、呼び出しチャネルではなく、パブリッシュ・チャネルでのみ使用できます。パブリッシュ・チャネルに関連付けられているオブジェクト構造は、フラット・ファイルをサポートするように構成されている必要があります。XML メッセージをフラット・ファイルに書き込む前に、オブジェクト構造のすべての別名の競合を解決し、オブジェクト構造スキーマに従ってそのメッセージをフォーマットする必要があります。

名前付け規則

ファイル名のフォーマットは次のようにする必要があります。

externalsystemname_publishchannelname_uniqueidentifier.dat

v externalsystemname はシステムの ID です (MAXVARS.MXSYSID の値)。

v publishchannelname はパブリッシュ・チャネルの名前です。

v uniqueidentifier は現在のシステム時刻に基づく数値です。

次のファイル名の例は、このファイルが外部システム EXTSYS1 に送られること、およびこのファイルは MXASSETInterface パブリッシュ・チャネルを介してパブリッシュされたことを示しています。

EXTSYS1_MXASSETInterface_10971102668641498.dat

このファイルの先頭 2 行にはヘッダー情報が入っています。先頭行の形式は次のとおりです。

外部システム名 <区切り記号> パブリッシュ・チャネル名 <区切り記号> [アクション] <区切り記号> 言語コード

ファイルの 2 行目には、区切り文字で区切られた列の名前が入っています。列名は、対応するインターフェース・テーブル内の名前と同じです。

フラット・ファイルの形式

フラット・ファイル内のデータにフラット・ファイル区切り文字が含まれる場合、データにはテキスト修飾子 " (二重引用符) が追加されます。データに引用符が含まれる場合、ハンドラーはその引用符をエスケープします。引用符は区切り文字として使用することはできません。

次の例のデータでは区切り文字としてコンマ (,) が使用されています。INVOICEDESC 値 (Rotating Custom Item, No 71) には、コンマが含まれています。フラット・ファイルが書き込まれると、INVOICEDESC 値は二重引用符で囲まれます。

EXTSYS1,MXINVOICEInterface,AddINVOICENUM,INVOICEDESC,PONUM,VENDOR,CONTACT,PAYMENTTERMS1071,"Rotating Custom Item, No 71",1000,A0001,,

次の例のデータでは区切り文字としてコンマ (,) が使用されています。INVOICEDESC 値 (Rotating "Custom" Item No 71) には二重引用符が含まれています。フラット・ファイルが書き込まれると、INVOICEDESC データの二重引用符は引用符で終了され、ストリング全体が引用符で囲まれます。


EXTSYS1,MXINVOICEInterface,AddINVOICENUM,INVOICEDESC,PONUM,VENDOR,CONTACT,PAYMENTTERMS1071,"Rotating ""Custom"" Item No 71",1000,A0001,,

次の例のデータでは区切り文字としてコンマ (,) が使用されています。INVOICEDESC データ (Rotating "Custom" Item, No. 71) には区切り文字と二重引用符が含まれています。フラット・ファイルが書き込まれると、INVOICEDESC

値がコードに表示されます。

EXTSYS1,MXINVOICEInterface,AddINVOICENUM,INVOICEDESC,PONUM,VENDOR,CONTACT,PAYMENTTERMS1071,"Rotating ""Custom"" Item, No. 71",1000,A0001,,

フラット・ファイルのプロパティー

FLATFILEDIR プロパティーは、フラット・ファイルのロケーションを指定するオプション・プロパティーです。このロケーションは、アウトバウンド・キューについての JMS クーロン・タスクが実行されているローカル・サーバーに存在するか、アクセス可能な共有ネットワーク・ドライブに存在しなければなりません。デフォルト値は、グローバル・ディレクトリー/フラット・ファイル・ディレクトリーを指します。グローバル・ディレクトリーのロケーションを指定するには、システムのプロパティー・アプリケーションで mxe.int.globaldir プロパティーを構成します。

FLATFILESEP プロパティーは、各行の中の列を区切る文字を指定する必須プロパティーです。

HTTP ハンドラー:

HTTP ハンドラーはプロパティーから成る Java コンポーネントです。このハンドラーは、HTTP プロトコルまたは HTTPS プロトコルを使用してアウトバウンド統合メッセージを XML 文書として URL に配信します。HTTP ハンドラーはさらに、外部システムから受信した応答コードの評価も行います。

HTTPEXIT プロパティー

このオプション・プロパティーはカスタマイズ用に使用され、HTTP 応答を解釈する Java クラスの完全修飾名を指定します。このプロパティーは、外部システムがHTTP 応答を解釈するために必要なコードの実装にも役立ちます。

この Java クラスは、アプリケーション EAR ファイル内で使用可能になっている必要があり、さらに、ハンドラーのクラスパス内になければなりません。

プロパティー値

Java クラス DefaultHTTPExit.java

パッケージ psdi.iface.router

HTTPEXIT プロパティー

psdi.iface.router.DefaultHTTPExit


このプロパティーに値を指定しない場合は DefaultHTTPExit 出口クラスが実行され、このクラスによって psdi.iface.router.HTTPExit インターフェースが実装されます。この Java クラスには以下のキー・メソッドがあります。

v processResponseData()

このメソッドには以下のシグニチャーがあります。

public void processResponseData(int responseCode, String responseMsg,

byte[] msgBodyData) throws MXException

デフォルトの実装環境は、外部システムからの応答コードを有効なコード (値200 から 299) の範囲と比較します。応答コードが範囲外にある場合、システムはメッセージが外部システムに配信されなかったと想定します。例外が発生して、メッセージはキューに残されます。

特定の実装環境用に追加の処理が必要な場合は、デフォルトの実装環境を拡張して、processResponseData () メソッドを指定変更します。代わりにpsdi.iface.router.HTTPExit インターフェースを実装することもできます。外部システムから受信した応答がこのクラスの妥当性検査にパスしない場合、指定変更するメソッドは例外を発行する必要があります。

このプロパティーに値を定義しない場合、HTTPExit のデフォルトの実装が実行されます。

v getURLProperties()


public Map String, String getURLProperties(Map String,? metaData, byte[]

data, Map String,MaxEndPointPropInfo httpInfo)

このメソッドは、url?prop1=value1&.. の形式の URL に追加される URL プロパティーのマップを返します。デフォルトの実装ではヌル値が返されます。

v getHeaderProperties()


public Map String, String getHeaderProperties(Map String,? metaData,

byte[] data, Map String,MaxEndPointPropInfo httpInfo)

このメソッドは、要求の HTTP ヘッダー・プロパティーのマップを返します。デフォルトの実装では、ヘッダー・プロパティー・マップが HEADERPROPS キーを持つメタデータ・マップに関連付けられていない限り、NULL 値が返されます。

v transformPayloadToFormData()


public Map String, String transformPayloadToFormData(Map String,?

metaData, byte[] data,Map String,MaxEndPointPropInfo destinationMap)


このメソッドは XML ペイロードをデータに変換します。デフォルトの実装ではNULL 値が返されます。

CONNECTTIMEOUT プロパティー

このオプションのプロパティーは、接続のタイムアウト値をミリ秒単位で指定します。

READTIMEOUT プロパティー

このオプションのプロパティーは、読み取りのタイムアウト値をミリ秒単位で指定します。

HTTPMETHOD プロパティー

この必須プロパティーは、エンドポイントによって実行される有効な HTTP メソッドを指定します。有効な HTTP メソッドは、GET、POST、PUT、および DELETE

です。

HTTPHEADER プロパティー

このオプションのプロパティーは、HTTP メッセージのヘッダー・セクションに、名前と値のコンマ区切りリストを追加できます。リストには、名前と値の情報が、Headername1:Headervalue1、Headername2:Headervalue2 という形式で含まれます。このプロパティーに値が指定されていない場合は、呼び出しチャネルの処理中に、カスタム・コードによってトランザクション・コンテキストに値を挿入することができます。

URL プロパティー

このオプションのプロパティーは、XML データを送ることができる有効な URL、または HTTP GET 操作を実行できる有効な URL を指定します。


URL が基本認証を要求する場合、これらのプロパティーが必要な値を指定します。両方の値が MIME でエンコードされ、URL に渡されます。

IFACETABLE ハンドラー:

IFACETABLE ハンドラーは複数のプロパティーで構成されます。このハンドラーは、ローカル・データベースまたはリモート・データベース内のインターフェース・テーブルに、アウトバウンド統合メッセージを書き込みます。このハンドラーに Java 出口クラスはありません。

IFACETABLE ハンドラーを使用できるのはパブリッシュ・チャネルのみです。呼び出しチャネルではこのハンドラーを使用できません。

ISREMOTE プロパティー

この必須プロパティーは、ローカル・データベースまたはリモート・データベースでインターフェース・テーブルが使用可能かどうかを指定するブール型の値です。値 0 (False) は、システム・スキーマのローカル・データベースでインターフェー


ス・テーブルが使用可能であることを示します。その他のハンドラー・プロパティーを入力する必要はありません。定義済みの MAXIFACETABLE ハンドラーでは、このプロパティーの値は 0 です。値 1 (True) は、インターフェース・テーブルがリモート・データベース内にあることを示します。必要な場合は、すべてのハンドラー・プロパティーに値を指定します。

DRIVER プロパティー

このプロパティーは、インターフェース・テーブルを含むリモート・データベースに接続するための JDBC ドライバーを指定します。このプロパティーは、ISREMOTE プロパティーの値が 1 である場合にのみ適用されます。

URL プロパティー

このプロパティーは JDBC URL を指定し、ISREMOTE プロパティーの値が 1 の場合のにみ適用されます。次の例には、ロケーション、ポート番号、およびデータベース名が含まれています。

jdbc:db2://hostname:port/maximodb


リモート・データベースへのアクセスにユーザー名とパスワードが必要な場合、これらのプロパティーがそれぞれの値を指定します。これらのプロパティーは、ISREMOTE プロパティーの値が 1 である場合にのみ適用されます。

JMS ハンドラー:

JMS ハンドラーは、JMS キューまたはトピックをサポートする JMS 準拠のメッセージング・システムにアウトバウンド統合メッセージを配信します。

このメッセージング・モデルには以下の特性があります。

v Point-to-Point メッセージング (1 対 1): 送信者がメッセージを生成してキューに入れます。 1 人の受信者のみがキューからメッセージを取得できます。

v パブリッシュ/サブスクライブ (1 対多): パブリッシャーがメッセージを生成してトピックに入れます。複数のサブスクライバーがトピックからメッセージを取得することができます。

これらのメッセージング・システムは、ローカル・アプリケーション・サーバー、リモート・アプリケーション・サーバー、またはリモート側の専用の待機システム(IBM® WebSphere MQ など) で使用可能なキューまたはトピックを表します。このハンドラーを使用するには、JMS を使用してメッセージング・システムを有効にします。メッセージング・システムは、ローカル・アプリケーション・サーバー上にある標準内部キューとは異なります。

CONFACTORYJNDINAME プロパティー

この必須プロパティーは、 JMS プロバイダーとの接続を作成するときに使用される Java オブジェクトを指定します。システムにあらかじめ接続ファクトリーへの参照が含まれていないと、そのシステムはキューまたはトピックに接続できません。


DESTINATIONTYPE プロパティー

このオプション・プロパティーは JMS 宛先タイプ (キューまたはトピック) を指定します。次の表に、DESTINATIONTYPE オプションと対応する値をリストします。

送信先値

トピック javax.jms.Topic

キュー javax.jms.Queue

DESTJNDINAME プロパティー

この必須プロパティーは、 JMS キューまたはトピックがアプリケーション・サーバーの Java Naming and Directory Interface (JNDI) ツリーに登録されるときの名前を指定します。

CONTEXTFACTORY プロパティー

この必須プロパティーは、初期コンテキスト・ファクトリー・クラス名を指定します。JMS ハンドラーが自身のアプリケーション・サーバーと同じ初期コンテキスト・ファクトリーを共用する JMS プロバイダーと通信する場合、このプロパティーは必須ではありません。このハンドラーと JMS プロバイダーが WebSphere

Application Server を共用する場合、これらは初期コンテキスト・ファクトリー・クラスを共用します。このハンドラーと JMS プロバイダーが WebSphere Application

Server を共用しない場合、コンテキスト・プロパティー値が必要です。

ISCOMPRESS プロパティー

この必須プロパティーは、メッセージをキューまたはトピックに入れる前に圧縮するかどうかを指定します。圧縮は、キューまたはトピックに配信するメッセージの容量を小さくする最適化手法です。次の表に、ISCOMPRESS オプションと対応する値をリストします。

オプション値

データを圧縮しません 0

データを圧縮します 1

圧縮されたメッセージは、受信後に解凍する必要があります。適切な JMS レシーバーまたはサブスクライバー・コンポーネントを作成して、Java 圧縮解除ロジックをレシーバーまたはサブスクライバーの中に配置して、メッセージを解凍します。java.util.zip パッケージに入っている標準 Java Inflater() クラスを使用します。デフォルトの圧縮では、標準 Java Deflator() クラスを使用します。

ISTEXT プロパティー

このオプション・プロパティーは、JMS ハンドラーがメッセージを別のキューにテキスト形式で配信するかどうかを指定します。


オプション値

メッセージをデフォルトの (バイト) 形式で配信します

0

メッセージをテキスト形式で配信します 1

JMSEXIT プロパティー

マルチテナンシー環境では、Java クラスを使用したカスタマイズを実装できるのはシステム・プロバイダーのみであり、ご使用の環境ではサポートされない可能性があります。

このオプション・プロパティーはカスタマイズ用に使用され、 JMSExit インターフェースを実行する Java クラスの完全修飾名を指定します。Java クラスは、JMSExit インターフェースで定義される getMessageProperties() メソッドを実装する必要があります。この Java クラスは、アプリケーション・サーバーまたはアプリケーション EAR ファイル用のクラスパスで使用可能になっている必要があります。

このオプションの変更または追加プロパティーを JMS メッセージで使用することができます。このプロパティーに値がない場合、メッセージが外部のキューまたはトピックに配信されるときにメッセージのヘッダー属性は変更されません。

PROVIDERURL プロパティー

この必須プロパティーは、JMS プロバイダーにアクセスできるローカルまたはリモートの URL を指定します。ターゲットの JMS プロバイダーがこのハンドラーのアプリケーション・サーバーのローカル側にある場合、このプロパティーは必須ではありません。次のプロパティーは WebSphere Application Server のPROVIDERURL 値の例です。

corbaloc:iiop:hostname:iiopport

PROVIDERUSER および PROVIDERPASWORD プロパティー

これらのプロパティーは JMS プロバイダーの認証に使用されます。これらのプロパティーは、JMS 内の connectionFactory.createConnection

(provideruser,providerpassword) API へのマッピングを行います。


これらのプロパティーは、InitialContext オブジェクトの作成に使用されるjava.naming.security.principal (USERNAME) プロパティーおよびjava.naming.security.credentials (PASSWORD) プロパティーに対応します。

Web サービス・ハンドラー:

Web サービス・ハンドラーは、WS-I BP 1.1 に準拠する任意の文書リテラル Web

サービスを呼び出すことができる Java クライアントです。アウトバウンド統合メッセージがペイロード (SOAP 本体) を形成し、このハンドラーが SOAP ヘッダーとエンベロープを提供します。このハンドラーはコンテナーから独立して動作します。


この Web サービス・ハンドラーは、Web サービスの以前の実装をサポートしており、既存の Web サービスとの後方互換性を維持するために提供されています。新しい Web サービスを実装する場合は、JAX-WS 用の Web サービス・ハンドラーを使用するように構成してください。

MEP プロパティー

このオプション・プロパティーは、Web サービスのメッセージ交換パターンを指定します。このプロパティーは以下の値をサポートします。値を指定しない場合、デフォルト値の sendreceive 値が使用されます。

値 Web サービスの操作タイプ

sendreceive 要求および応答

sendrobust 応答が無効または失敗の要求

fireandforget 要求のみ、応答なし、それ以外は失敗

ENDPOINTURL プロパティー

この必須プロパティーは、Web サービスの呼び出しで使用する有効な Web サービス URL を指定します。 Web サービスの呼び出し直前に WSEXIT クラスを使用して、ユーザー・インターフェースによって指定された値を指定変更することができます。

SERVICENAME プロパティー

この必須プロパティーは、URL にデプロイされた Web サービスの名前を指定します。

SOAPACTION プロパティー

このオプション・プロパティーは、Web サービスを呼び出すときに使用されるSOAPAction HTTP ヘッダーの値を指定します。デフォルト値は空ストリングです。プロパティーの値を設定するには、Web サービス用の WSDL ファイルを表示してアクションを判別し、この値を指定してください。Web サービスの呼び出し前にWSEXIT クラスを使用して、ユーザー・インターフェースで指定された値を指定変更することができます。

SOAPVERSION プロパティー

このオプション・プロパティーは、Web サービスの呼び出し時に使用される SOAP

仕様のバージョンを指定します。有効な値は SOAP11 および SOAP12 です。

HTTPVERSION プロパティー

このオプション・プロパティーは、Web サービス呼び出し用の HTTP プロトコルのバージョンを指定します。有効な値は HTTP/1.0 および HTTP/1.1 です。値を指定しない場合、システムはデフォルト値の HTTP/1.1 を使用します。


HTTPCONNTIMEOUT プロパティー

このオプションのプロパティーは、接続のタイムアウト値をミリ秒単位で指定します。このプロパティーのデフォルト値は 60000 ミリ秒です。

HTTPREADTIMEOUT プロパティー

このオプションのプロパティーは、読み取りのタイムアウト値をミリ秒単位で指定します。このプロパティーのデフォルト値は 60000 ミリ秒です。


指定された Web サービスが保護されている (HTTP 基本認証が有効になっている)

場合は、ユーザー名とパスワードを指定します。

WSEXIT プロパティー


このオプション・プロパティーはカスタマイズ用に使用されます。psdi.iface.router.WSExit インターフェースを実装するカスタム Java クラスの完全修飾名を指定します。このプロパティーは以下のメソッドを定義します。

responseOk() メソッドは、外部の Web サービスが正常に呼び出された後で呼び出されます。


Web サービスを呼び出すときにエラーが発生した場合は、原因となった例外をパラメーターとして指定して responseError() メソッドが呼び出されます。

WSExit インターフェースのデフォルトの実装は psdi.iface.router.DefaultWSExit

です。

Web サービス・ハンドラー (JAX-WS):

WEBSERVICE-JAX-WS ハンドラーは、WS-I BP 1.1 に準拠する任意の文書リテラル Web サービスを呼び出すことができる Java クライアントです。アウトバウンド統合メッセージがペイロード (SOAP 本体) を形成し、このハンドラーが SOAP ヘッダーとエンベロープを提供します。

この Web サービス・ハンドラーは、Web サービスの現在の実装をサポートしています。新しい Web サービスを実装する場合は、この Web サービス・ハンドラーを使用するように構成してください。

MEP プロパティー

このオプション・プロパティーは、Web サービスのメッセージ交換パターンを指定します。このプロパティーは以下の値をサポートします。値を指定しない場合、デフォルトの sendreceive 値が使用されます。


値 Web サービスの操作タイプ

sendreceive 要求および応答

sendrobust 応答が無効または失敗の要求

fireandforget 要求のみ、応答なし、それ以外は失敗

ENABLEAPPCONTEXT プロパティー

WS-* ポリシーのサポートを実装するときは、このプロパティーを 1 (True) に設定します。

ENDPOINTURL プロパティー

この必須プロパティーは、Web サービスの呼び出しで使用する有効な Web サービス URL を指定します。 Web サービスの呼び出し直前に WSEXIT クラスを使用して、ユーザー・インターフェースによって指定された値を指定変更することができます。

SERVICENAME プロパティー

この必須プロパティーは、このハンドラーが呼び出すターゲット Web サービスの名前を指定します。

SOAPACTION プロパティー

このオプション・プロパティーは、Web サービスを呼び出すときに使用されるSOAPAction HTTP ヘッダーの値を指定します。デフォルト値は空ストリングです。プロパティーの値を設定するには、Web サービス用の WSDL ファイルを表示してアクションを判別し、この値を指定してください。Web サービスの呼び出し前にWSEXIT クラスを使用して、ユーザー・インターフェースで指定された値を指定変更することができます。

SOAPVERSION プロパティー

このオプション・プロパティーは、Web サービスの呼び出し時に使用される SOAP

仕様のバージョンを指定します。有効な値は SOAP11 および SOAP12 です。

HTTPCONNTIMEOUT プロパティー

このオプションのプロパティーは、接続のタイムアウト値をミリ秒単位で指定します。このプロパティーのデフォルト値は 60000 ミリ秒です。

HTTPREADTIMEOUT プロパティー

このオプションのプロパティーは、読み取りのタイムアウト値をミリ秒単位で指定します。このプロパティーのデフォルト値は 60000 ミリ秒です。

HTTPHEADER プロパティー

このオプションのプロパティーは、HTTP メッセージのヘッダー・セクションに、名前と値のコンマ区切りリストを追加できます。リストには、名前と値の情報が、Headername1:Headervalue1、Headername2:Headervalue2 という形式で含まれます。こ


のプロパティーに値が指定されていない場合は、呼び出しチャネルの処理中に、カスタム・コードによってトランザクション・コンテキストに値を挿入することができます。


指定された Web サービスが保護されている (HTTP 基本認証が有効になっている)

場合は、ユーザー名とパスワードを指定します。

WSEXIT プロパティー


このオプション・プロパティーはカスタマイズ用に使用されます。psdi.iface.router.WSExit インターフェースを実装するカスタム Java クラスの完全修飾名を指定します。このプロパティーは以下のメソッドを定義します。

responseOk() メソッドは、外部の Web サービスが正常に呼び出された後で呼び出されます。


Web サービスを呼び出すときにエラーが発生した場合は、原因となった例外をパラメーターとして指定して responseError() メソッドが呼び出されます。

WSExit インターフェースのデフォルトの実装は psdi.iface.router.DefaultWSExit

です。

CFGXMLPATH プロパティー

このプロパティーは廃止されました。このプロパティーは使用しないでください。

XML ファイル・ハンドラー:

XML ファイル・ハンドラーは、アウトバウンド統合メッセージを XML フォーマットでファイルに書き込む Java コンポーネントです。

FILEDIR プロパティー

このオプション・プロパティーは、ハンドラーが XML ファイルを作成する場所を指定します。デフォルト値は mxe.int.globaldir/xmlfiles です。ファイル・ロケーションは、パブリッシュ・チャネル・メッセージ用のアウトバウンド・キューについての JMS クーロン・タスクによってアクセスできなければなりません。呼び出しチャネル・メッセージの場合、ファイル・ロケーションは、呼び出しチャネルを開始できるすべての Maximo Asset Management サーバーによってアクセス可能でなければなりません。

PRETTYPRINT プロパティー

この必須プロパティーは、ハンドラーが XML ファイルをフォーマットする場所を指定します。有効な値は 0 と 1 です。値 1 を指定すると、ハンドラーに XML フ


ァイルを pretty print でフォーマットするよう指示が出されます。パブリッシュ・チャネル、呼び出しチャネル、および呼び出し API のファイル名のフォーマットは、次のとおりです。

externalsystemname_publishchannelname_uniqueidentifier.xml

invocationchannelname_uniqueidentifier.xml

v externalsystemname はシステムの ID です (MAXEXTSYSTEM.EXTSYSNAME の値)。

v publishchannelname はパブリッシュ・チャネルの名前です。

v uniqueidentifier は現在のシステム時刻に基づく数値です。

例えば、ファイル名 MX_MXASSETInterface_10971102668641398.xml は、そのファイルがデータを外部システム EXTSYS1 に送信するために生成されたことを示します。このファイル名は、そのファイルに MXASSETInterface パブリッシュ・チャネルが含まれることも示します。

コマンド・ライン・ハンドラー:

CMDLINE ハンドラーはコマンドおよびエンドポイントを入力として受け入れます。 CMDLINE ハンドラーは、SSH プロトコルを使用してターゲット・システムでコマンドを実行し、結果を返します。

このハンドラーが呼び出されるときのシステムの呼び出し時に、メタデータ・パラメーターが渡されます。このパラメーターは、ターゲット・システムを表すエンドポイントの名前を含むマップです。呼び出し元は実行時に任意のシステムをターゲットとすることができ、そのエンドポイントをコマンド・ハンドラーに渡すことができます。呼び出し元は、呼び出し時のエンドポイントの構成をそのまま使用します。

CMDLINE ハンドラー・プロパティー

CMDLINE ハンドラーには以下のプロパティーがあります。

v CMDTIMEOUT – コマンド実行のタイムアウト値

v CONNTIMEOUT – 接続のタイムアウト値

v USERNAME – 接続のユーザー名

v PASSWORD – ユーザー名に対応するパスワード

v HOST – コマンドが実行されるターゲットのホスト名

v PORTNO – コマンドが実行されるターゲットのポート番号

v IGNORESETUPERR – セットアップ・コマンドの実行中にエラーを無視するかどうかを示すブール型の値

v RETRYINTERVAL – コマンドの再試行間隔の時間

v MAXRETRY – 例外を返す前にコマンドの実行を試行する回数

v SSHEXIT – ハンドラーの処理をカスタマイズするために実装できる Java 出口クラス


コマンド・データ・パラメーター

データ・パラメーターは XML 文書のバイト配列表現です。データ・パラメーターには、次の情報が含まれています。

v セットアップ・コマンドに対応するタグ

v 作業ディレクトリー

v 実行するコマンド

v 代入パラメーター

使用可能なタグ

以下のタグが使用可能です。

v CLWORKINGDIR – コマンドが実行される前にリモート・システムで指定する変更先ディレクトリー (cd)。

v CLSSETUPCMD – メイン・コマンドの前に実行するセットアップ・コマンド。このタグは、メイン・コマンドの発行前にリモート・システムで行う必要がある環境のセットアップ用に使用します。

v CLCMDPATTERN - 実行されるコマンドのパターンを定義するストリング。このパターンのフォーマットは、java.text.MessageFormat クラスに類似しています。一例として ls -l {0} があります。この {0} は値が代入されるパラメーターを表します。

v CLSUB0 - CLCMDPATTERN 内で {0} によってマークされる位置に代入される値。

v CLSUB1 - CLCMDPATTERN 内で {1} によってマークされる位置に代入される値。

v CLSUBn - CLCMDPATTERN 内で {n} によってマークされる位置に代入される値。CLSUBn タグは、CLCMDPATTERN タグ内のそれぞれの代入位置に対応している必要があります。

コマンドの結果

XML 文書の戻りバイト配列表現には、コマンドの結果が入っています。XML 文書には、戻り値 STDOUT および STDERR に対応するタグが入っています。

以下のタグが使用可能です。

v CLRETURNCODE リモート・コマンドからの戻りコード。

v CLRESPONSEOUT – STDOUT タグ内にリモート・コマンドによって返されるデータ。

v CLRESPONSEERR – STDERR タグ内にリモート・コマンドによって返されるデータ。

統合 Web サービス外部システムは統合フレームワーク Web サービスを使用してメッセージまたはクエリーを Maximo データベースに送信できます。Web サービスのソースとして統合フレームワーク・サービスを使用し、外部システムと通信するようにこの Web サービスをデプロイすることができます。


Web サービス・ソースWeb サービスのソースは、オブジェクト構造サービス、標準サービス、またはエンタープライズ・サービスのいずれかです。

オブジェクト構造サービス

事前定義のオブジェクト構造サービスまたはユーザー定義のオブジェクト構造サービスからオブジェクト構造 Web サービスを作成できます。オブジェクト構造 Web

サービスでサポートされる操作は、作成、更新、削除、同期、およびクエリーです。作成操作とクエリー操作では、応答もサポートされています。作成操作への応答は、オブジェクト構造で定義したプライマリー・オブジェクトのプライマリー・キーまたは代替キーに基づいています。クエリー操作への応答は、オブジェクト構造の XML スキーマ・フォーマットで提供されます。

標準サービス

標準 Web サービスは、アプリケーション・サービスで注釈を付けられたメソッドから作成できます。メソッドを Web サービスとして使用するには、アプリケーション内に ChangeStatus メソッドなどの注釈が付けられたメソッドが存在している必要があります。アプリケーション・サービスごとに 1 つの標準 Web サービスが作成され、そのサービス内で注釈が付けられたメソッドはすべて、Web サービス操作です。これらのメソッドの入出力パラメーターは、標準 Web サービスの入出力パラメーターに関連付けられます。


エンタープライズ Web サービスは、定義済みまたはユーザー定義のエンタープライズ・サービスから作成できます。エンタープライズ Web サービスでは、追加の出口処理、ビジネス・ルール、および変換がサポートされています。エンタープライズ・サービス・レコードに含まれる各操作ごとにサービスが存在します (1 つの操作に対して 1 つのサービス)。出口処理層を使用して、外部スキーマ XML を呼び出しおよび応答の両方のオブジェクト構造 XML にマップすることができます。エンタープライズ Web サービスは、キューで処理されている作成操作およびクエリー操作の応答の内容を提供します。エンタープライズ・サービス定義では、サービスで応答がサポートされているかどうかを示す ProcessResponse フラグが設定されています。

エンタープライズ Web サービスの JMS キュー設定:

エンタープライズ Web サービスは、Java Message Service (JMS) キューを使用してXML メッセージを処理できます。または、サービスが JMS キューをバイパスするように指定できます。

JMS キュー・ベースの処理では、非同期メッセージ処理が行われます。同期処理がサポートされているエンタープライズ・サービスの場合は、非キュー・ベースのメッセージ処理を指定する必要があります。統合フレームワークでは、エンタープライズ Web サービスに対して定義されているキュー設定に基づいて外部アプリケーションからの XML メッセージが処理されます。

キュー・ベースのメッセージ処理キュー・ベースのエンタープライズ Web サービスは、XML メッセージを


処理し、構成済みインバウンド JMS キューにこれらのメッセージを書き込みます。メッセージが JMS キューに移動すると、外部アプリケーションが呼び出しから解放されます。統合フレームワークはメッセージを処理し、メッセージを Maximo データベースに保存します。

エンタープライズ Web サービスは、外部アプリケーションへの応答を必要とする作成操作またはクエリー操作が含まれている場合は、JMS キューを使用できません。

非キュー・ベースのメッセージ処理非キュー・ベースのエンタープライズ Web サービスは、統合フレームワークからオブジェクト処理層へのメッセージを処理し、該当する場合には情報を Maximo データベースに保存します。エンタープライズ Web サービスによるメッセージの処理が完了すると、統合フレームワークが応答を外部アプリケーションに送信します。エンタープライズ Web サービスで、外部アプリケーションへの応答を必要とするクエリー操作または作成操作がサポートされている場合は、非キュー・ベースの処理を指定する必要があります。

Web サービスのデプロイメント・オプションWeb サービスを作成したら、デプロイメント・オプションを選択できます。Web サービスを製品 Web サービス・コンテナーにデプロイする場合、このデプロイは自動的に実行されます。Web サービスをアプリケーション・サーバーの Web サービス・コンテナーにデプロイする場合、このデプロイは手動で実行します。

Web サービスは、1 つのコンテナー・タイプにのみデプロイすることができます。いくつかの Web サービスを製品 Web サービス・コンテナーにデプロイし、他のWeb サービスをアプリケーション・サーバーの Web サービス・コンテナーにデプロイするということはできません。製品の Web サービス・コンテナーへのデプロイメントは自動的に実行されるため、他のデプロイメント・オプションよりも短い時間で完了できます。このタイプのデプロイメントでは、Maximo EAR ファイルの再デプロイメントや、アプリケーション・サーバーの再始動は必要ありません。

アプリケーション・サーバー上で Web サービスを呼び出すには、このサービスをアプリケーション・サーバーの Web サービス・コンテナーにデプロイする必要があります。アプリケーション・サーバーとの統合によって、Web サービスは拡張セキュリティー・ポリシーなどの追加サービスにアクセスできます。このタイプのデプロイメントを選択すると、情報が deplmodule.dar ファイルに追加されます。次にこのファイルをアプリケーション・サーバーのデプロイメント・ディレクトリーに追加し、EAR ファイルを再作成し、アプリケーション・サーバーを再始動する必要があります。

製品 Web サービス・コンテナーにデプロイされる既存の Web サービスを変換して、これらのサービスをアプリケーション・サーバーの Web サービス・コンテナーに再デプロイすることができます。

Web サービス導入アクションWeb サービスを導入するときには、Web サービス用の XML スキーマや Web サービス記述言語 (WSDL) ファイルの生成などの多数のイベントが発生します。

Web サービスを導入すると、以下のイベントが発生します。


v 新規 Web サービス用の XML スキーマが生成されるか、既存の Web サービス用のスキーマが再生成されます。

v サービス・インターフェースで、WSDL ファイルが使用可能になります。

v 選択されたサービス用に Web サービスが導入されます。

v Universal Description Discovery and Integration (UDDI) レジストリー・プロパティーが構成されている場合、Web サービスは UDDI レジストリーに登録されます。

導入された Web サービスは次の URL で使用できます。

http://hostname:port/meaweb/services/web service name

v host:port/meaweb は、統合 Web アプリケーションの URL プロパティーの値です。

v web service name は、Web サービスが導入されるサービスの名前です。

導入された Web サービスのリストは、「Web サービス・ライブラリー」アプリケーションで表示することができます。

スキーマの生成Web サービス・ライブラリー・アプリケーションでは、スキーマを生成し、あらゆる Web サービスの XML を表示できます。また、スキーマを再生成できます。これにより、スキーマが更新され、サービスに対して行った変更がすべて反映されます。

Web サービス・データの構造は、関連するオブジェクトの構造 (オブジェクト構造サービスまたはエンタープライズ・サービスの場合) またはメソッド・シグニチャー (標準 Web サービスの場合) に基づいています。Web サービス・データ構造は、標準 XML 表現でスキーマとして提供されます。このスキーマは、サービスのWSDL ファイルを作成するときに使用されます。

Web サービスに関連付けられているデータ構造を変更する場合、スキーマを再生成してそのスキーマと WSDL ファイルを更新します。データ・ディクショナリーに以下の変更を加えると、オブジェクト構造が変更されます。

v テーブルへの新規フィールドの追加

v フィールドのタイプの変更

v テーブルからのフィールドの削除

v オプション・フィールドから必須フィールドへの変更

XML には、オブジェクト構造で除外するようにマークされたフィールドは含まれません。

Web サービスを導入する前に、スキーマを生成して、最新のスキーマ情報を WSDL

ファイルに提供する必要があります。スキーマの生成時に、「XML データ」ウィンドウに入力要素が表示され、「応答の XML」ウィンドウに出力要素が表示されます。

生成されたスキーマは、以下の URL で参照できます。


v エンタープライズ・サービスとオブジェクト構造のスキーマの場合は、URL

http://localhost:port/meaweb/schema/service/MXSRService.xsd を使用します(MXSR はサービスに関連付けられているオブジェクト構造名)。

v 標準サービスのスキーマの場合は、URL http://localhost:port/meaweb/schema/

service/ss/ITEMService.xsd を使用します (ITEM はサービスの名前)。

システムのプロパティー・アプリケーションで mxe.int.resolveschema グローバル・プロパティーを True に設定すると、すべてのインクルード・ファイルが解決されます。スキーマ全体の内容は単一のファイルにあります。

Web サービス記述言語ファイルの生成WSDL ファイルは、Web サービスのデプロイメント時に生成されます。WSDL ファイルは Web サービスを記述し、Web サービスのロケーションを指示し、サービスで使用可能な操作を指定します。

WSDL ファイルは XML スキーマに基づき、操作の入出力メッセージの XML 構造を指定します。ファイルは Web サービスの URL と、Web サービスで使用可能な操作も指定します。

クライアント・プログラムには、クライアント・スタブを生成するためのスキーマ定義および WSDL ファイルが必要です。クライアント・プログラムは、Java や C#

などのプログラミング言語を使用して Web サービスを呼び出します。

生成された WSDL ファイルは、ブラウザーから http://localhost:port/meaweb/

wsdl/service_name?wsdl で表示できます (service_name は、MXASSET などのサービスの名前)。

UDDI への登録導入された Web サービスを UDDI レジストリーに登録できます。UDDI は Web

サービス・アプリケーションを記述する WSDL ファイルを公開および検索するための XML ベースのレジストリーです。

「システムのプロパティー」アプリケーションで以下のグローバル・プロパティーを構成することにより、導入された Web サービスを UDDI レジストリーに登録することができます。

システム・プロパティー説明

mxe.int.uddipuburl UDDI レジストリーの URL 公開

mxe.int.uddiinqurl UDDI レジストリーの URL 照会

mxe.int.uddiname UDDI レジストリーのユーザー ID

mxe.int.uddipassword UDDI レジストリーのパスワード

URL 公開プロパティーおよび URL 照会プロパティーに値を指定すると、Web サービスは UDDI レジストリーに登録されます。UDDI への登録をバイパスするには、これらのプロパティーに値を指定しないでください。WSDL ファイルのモデルのみが UDDI レジストリーに登録されます。 businessEntity、businessService、および bindingTemplate 値は登録されません。UDDI の登録項目には WSDL ファイルへの URL が含まれます。


Web サービスの作成およびデプロイシステムで定義されているオブジェクト構造サービス、標準サービス、またはエンタープライズ・サービスに基づいて Web サービスを作成することができます。次に、製品 Web サービス・コンテナーまたはアプリケーション Web サービス・コンテナーに Web サービスをデプロイします。

Web サービスの作成:

Web サービスを作成すると、外部システムは追加の通信プロトコルまたはサービスを構成することなく、Web ベースのメッセージおよびクエリーを、関連付けられたサービスに送信することができます。

始める前に

該当するサービスが、Web サービスを作成するために使用可能であることを確認するには、以下のチェックを実行します。

v オブジェクト構造サービスの場合は、オブジェクト構造アプリケーションで「適用先」フィールドが「統合」に設定されていることを確認します。

v 標準サービスの場合は、Web サービスで使用する操作ごとに、アプリケーション・サービスでメソッドに注釈が付けられていることを確認します。適切に注釈を付けたメソッドのみが、Web サービス・ライブラリー・アプリケーション内でアクセス可能になります。

v エンタープライズ・サービスの場合は、外部システム・アプリケーションでそのサービスが外部アプリケーションに関連付けられていることを確認します。

手順

1. Web サービス・ライブラリー・アプリケーションで適切な「Web サービスの作成」アクションを選択します。

2. 使用するサービスを選択するため、対応する「ソース名」チェック・ボックスを選択します。

3. オプション: 「名前」フィールドに、Web サービスの ID を指定します。

4. エンタープライズ・サービスに基づく Web サービスの場合は、その Web サービスをキュー・ベースにするか、または JMS キューをバイパスするかを指定します。

5. 「作成」をクリックします。

次のタスク

Web サービスを使用してインバウンド・メッセージおよびクエリーを処理するには、Web サービスをデプロイする必要があります。これで、スキーマを生成し、選択した Web サービスの XML 構造を表示することもできます。

製品 Web サービス・コンテナーへの Web サービスのデプロイ:

Web サービスを作成したら、この Web サービスで XML メッセージを処理開始できるようにするために、この Web サービスをデプロイする必要があります。Web

サービスを製品 Web サービス・コンテナーにデプロイすると、デプロイメント処理は自動的に実行され、サーバーを再始動する必要はありません。


手順

1. Web サービス・ライブラリー・アプリケーションで、デプロイする Web サービスを選択します。

2. 「製品の Web サービス・コンテナーにデプロイ」 > 「Web サービスの導入」アクションを選択します。


アプリケーション・サーバーの Web コンテナーへの Web サービスのデプロイ:

アプリケーション・サーバーの Web サービス・コンテナーに Web サービスをデプロイすると、デプロイメント・ファイルが生成されます。デプロイメント・ファイルを含むように Maximo EAR ファイルを再作成し、アプリケーション・サーバーを再始動して Web サービスをアクティブにする必要があります。


deplmodule.dar デプロイメント・ファイルは、mxe.int.globaldir システム・プロパティーによって指定されたディレクトリー内にあります。

手順

1. Web サービス・ライブラリー・アプリケーションで、デプロイする Web サービスを選択します。

2. 「アプリケーション・サーバーの Web サービス・コンテナーにデプロイ」 >

「デプロイメント・ファイル・エントリーの生成」アクションを選択します。このアクションにより、デプロイメント・ファイル deplmodule.dar にエントリーが生成されます。


4. 統合フレームワーク・グローバル・ディレクトリーから製品デプロイメント・ディレクトリーに deplmodule.dar ファイルをコピーします。

5. デプロイメント・ディレクトリーで buildmaximoear.cmd ファイルを実行します。

6. アプリケーション・サーバーの管理コンソールで、以下のようにしてdeplmodule.dar ファイル内のすべての Web サービスをデプロイします。

a. アプリケーション・サーバーを停止します。

b. maximo.ear ファイルを再デプロイします。

c. アプリケーション・サーバーを再始動します。

スキーマ情報の更新:

統合サービスのデータ構造を変更した場合、Web サービスを更新するために、WSDL ファイルに対してスキーマ情報を更新します。スキーマを再生成しないと、Web サービスによって使用されるスキーマと、関連付けられた統合サービスについて定義された構造が異なる可能性があります。

手順

1. Web サービスのデータ構造を変更したら、「スキーマ、WSDL の生成およびXML の表示」をクリックします。スキーマを再生成しないと、行った変更はWeb サービスによって認識されません。


2. アプリケーション・サーバーの Web サービス・コンテナーにデプロイされたWeb サービスの場合、システムのプロパティー・アプリケーションでスキーマ更新を自動化できます。

a. アプリケーション・サーバーの Web サービス・コンテナーに Web サービスをデプロイするため、mxe.int.containerdeploy プロパティーの値を 1 に設定します。

b. スキーマ情報が WSDL ファイルに組み込まれるようにするため、mxe.int.wsdlincludeschema プロパティーの値を 1 に設定します。

c. 含まれているすべてのフィールドが 1 つのファイルに解決されるようにするため、mxe.int.resolveschema プロパティーの値を 1に設定します。

d. 最新のスキーマの内容を WSDL ファイルに組み込むため、mxe.int.wsdlcurrentschema プロパティーの値を 1 に設定します。

Web サービス相互作用の概説相互作用では、Web サービスを開始して、データをアプリケーションからWeb サービスへ送信できます。相互作用では、その後、Web サービスから返されるデータを表示し、このデータをアプリケーション・データベースに保存できます。

相互作用を実装するには、以下の知識が必要です。

v XML スキーマ

v Web サービス

v 統合フレームワーク

v アプリケーションおよびアプリケーション・ユーザー・インターフェースのカスタマイズ

相互作用では、以下の処理を管理できます。

v Web サービスの要求を作成する。

v Web サービスをアプリケーションから呼び出す。

v Web サービスからの結果を応答の形式で取り出す。

v アプリケーションに結果を表示する。

v オプションで、システム・データベースに応答データを適用する。

v 要求処理中または応答処理中に発生したすべてのエラーを報告する。

以下に示すように、相互作用の作成および管理に役立つ 2 つのアプリケーションが用意されています。

v 相互作用の作成および構成は、相互作用の作成アプリケーションで行います。

v 相互作用の検討、変更、および削除は、相互作用アプリケーションで行います。

相互作用を作成した後、ユーザーはアプリケーション・ユーザー・インターフェースで以下のタスクを実行できます。

v 相互作用を開始する。

v Web サービスに対する要求のパラメーターを表示し、(構成済みの場合は) 変更する。

v 要求を送信することにより、Web サービスを呼び出す。


v オプションで、Web サービスから受信したデータを表示し、このデータをデータベースにコミットする。

相互作用の作成:

相互作用の作成ウィザード・アプリケーションでは、相互作用の作成および構成に必要なすべての手順が順を追って示されます。ウィザード・プロセスを完了して相互作用をテストした後、ユーザーは、追加の構成またはデプロイメントを行うことなく、相互作用の操作をすぐに開始できます。

始める前に

相互作用の作成アプリケーションを実行する前に、構成に必要なすべての情報が揃っていることを確認してください。この処理中に、Web サービスの指定、メッセージの構造の定義、およびアプリケーションと Web サービス間でのデータのマッピングを行う必要があります。

構成アクティビティーをログに記録し、構成される項目のログ・ファイルを維持するロギング・ツールが用意されています。構成の詳細なログを生成するには、ロギング・アプリケーションで、相互作用ロガーを DEBUG モードに設定してください。

手順

1. この作業の手順 1 では、相互作用の Web サービスを構成するために以下を実行します。

a. Web サービスの WSDL ファイルの URL を指定します。

b. 画面が WSDL ファイルの情報で最新表示されたら、相互作用のポートを 1

つ指定します。

c. 相互作用の実行中に Web サービスがアプリケーションへデータを返すようにする場合は、相互作用の操作を 1 つ指定して「応答の処理」にチェック・マークを付けます。

2. 手順 2 では、Web サービスに対する要求の内容を検討し、不必要な要素を削除することによって要求オブジェクト構造を変更します。

3. オプション: 手順 3 では、Web サービスからの応答の内容を検討し、不必要な要素を削除することによって応答オブジェクト構造を変更します。この手順は、手順 1 で「応答の処理」オプションにチェック・マークを付けた場合にのみ組み込まれます。

4. この作業の手順 4 では、相互作用のアプリケーションを構成するために以下を実行します。

a. 相互作用を使用するアプリケーションを指定します。

b. 相互作用のアプリケーション・バインディングを構成します。これには、メイン・オブジェクト、署名オプション、相互作用モード、およびユーザー・インターフェース・コンポーネントが含まれます。

c. 相互作用の開始権限を持つセキュリティー・グループを指定します。

5. 手順 5 では、「相互作用」ウィンドウの「要求」タブを構成します。これには、ユーザーが参照できるフィールドの指定や、ユーザーがそれらのフィールドを編集できるかどうかの指定が含まれます。


6. オプション: 手順 6 では、「相互作用」ウィンドウの「応答」タブを構成します。これには、ユーザーが参照できるフィールドの指定や、ユーザーがそれらのフィールドを編集できるかどうかの指定が含まれます。この手順は、手順 1 で「応答の処理」オプションにチェック・マークを付けた場合にのみ組み込まれます。

7. 手順 7 では、情報をアプリケーションから Web サービスにマップできます。マップされた情報は、ユーザーが相互作用を開始すると、要求に自動的に入力されます。

8. オプション: 手順 8 では、情報を Web サービスからアプリケーションにマップできます。「応答の確約」オプションにチェック・マークを付けた場合、マップされた情報はデータベースに自動的に保存されます。

9. 作業の最終手順では、構成を見直します。

次のタスク

相互作用を実行するための所要時間をモニターするには、ロギング・アプリケーションで、統合ロガーを INFO モードまたは DEBUG モードに設定します。

相互作用アプリケーションでは、相互作用を表示して、マッピング情報を変更できます。相互作用を変更する予定の場合は、「相互作用の非アクティブ化」を選択してから変更を行い、変更が完了したら相互作用を再アクティブ化してください。

外部システム統合フレームワークが通信する外部システムを構成できます。エンタープライズ内外の外部アプリケーションの外部システムを構成できます。定義済みの外部システムをコピーすると、構成されているチャネルおよびサービスがコピーされます。既存の JMS キューを使用するように新しい外部システムを構成することができます。

外部システムの構成外部システムを構成するには、外部システムを識別し、トランザクションを処理するために使用するチャネルまたはサービスを関連付けます。また、外部システムが使用する JMS キューを構成する必要もあります。統合コントロールについては、処理ルールを使用したカスタマイズをサポートするように構成できます。

外部システムの作成:

外部アプリケーションとデータを交換するには、外部システムを作成します。外部システムを作成すると、アプリケーションは、対応するパブリッシュ・チャネルとエンタープライズ・サービスについて定義されている統合コントロールをコピーします。次に、特定の外部システムに適用するデフォルトのコントロール値を指定します。

始める前に

外部システムを作成する前に、外部システムが使用するキューおよびエンドポイントを定義します。


手順

1. 外部システム・アプリケーションで、「新規外部システム」をクリックします。

2. 「システム」フィールドで、外部システム ID を指定します。

3. オプション: アウトバウンド・メッセージを送信する外部システムの場合は、以下の手順を完了します。

a. 「アウトバウンド用の連続キュー」フィールドに値を指定します。

b. 「エンドポイント」フィールドに値を指定します。

4. オプション: インバウンド・メッセージを受信する外部システムの場合は、以下の手順を完了します。

a. 「インバウンド用の連続キュー」フィールドに値を指定します。

b. 「インバウンド用の継続中のキュー」フィールドに値を指定します。

5. 「外部システムの保存」をクリックします。

次のタスク

メッセージ処理が行われるようにするためには、1 つ以上のパブリッシュ・チャネルまたはエンタープライズ・サービスを有効にする必要があります。

外部システムの有効化:

外部システム・レコードを構成した後、統合フレームワーク・メッセージ処理を開始する準備が整ったら、外部システムを有効にできます。また、インバウンドおよびアウトバウンド・メッセージ処理をすべて停止するために、外部システムを無効にすることもできます。

始める前に

メッセージ処理が行われるようにするためには、1 つ以上のパブリッシュ・チャネルまたはエンタープライズ・サービスを有効にする必要があります。


外部システムを無効にすると、統合フレームワークはインバウンド・メッセージの受信も、アウトバウンド・メッセージの送信も行いません。さらに、外部システムのデータのエクスポートおよびデータのインポート機能を使用できなくなります。キュー内にあるメッセージのみが処理されます。

手順

1. 外部システムアプリケーションで、更新するシステムを選択します。

2. 以下のようにして、外部システムを有効にするか、または無効にするかを指定します。

オプション有効にする

有効にする選択

無効にするクリア



パブリッシュ・チャネルの有効化:

外部システムに関連付けられたパブリッシュ・チャネルを使用してイベント・ベースのメッセージを外部システムにパブリッシュできるようにするには、そのパブリッシュ・チャネルを有効にする必要があります。デフォルトでは、外部システムに関連付けられたパブリッシュ・チャネル・レコードは無効に設定されます。パブリッシュ・チャネルが無効になっている場合、外部システムはアウトバウンド統合フレームワーク・メッセージを処理できません。

手順


2. 「パブリッシュ・チャネル」タブで、パブリッシュ・チャネルを有効にするか、または無効にするかを指定します。





パブリッシュ・チャネルを外部システムに関連付ける:

パブリッシュ・チャネルを外部システムに関連付けて、資産管理オブジェクト・データを外部アプリケーション・データに同期させることができます。作成して外部システムに関連付けるチャネルには、アウトバウンド・メッセージ処理ロジックを含めます。


チャネルが使用するエンドポイントを定義できます。パブリッシュ・チャネル・レベルでエンドポイントを定義しなければ、データは外部システム・レベルで定義されたエンドポイント・ロケーションに移動されます。アウトバウンド統合フレームワーク・メッセージ処理を実行する準備が整っている場合は、関連するパブリッシュ・チャネルを有効にすることもできます。

手順

1. 外部システム・アプリケーションで、更新する外部システムを選択します。

2. 「パブリッシュ・チャネル」タブで、「新規行」をクリックします。

3. 「パブリッシュ・チャネル」フィールドに値を入力します。

4. オプション: 「エンドポイント」フィールドに値を指定します。

5. オプション: 以下のようにして、パブリッシュ・チャネルを有効にするか、または無効にするかを指定します。






外部システムのパブリッシュ・チャネルの選択:

複数のパブリッシュ・チャネルを外部システムに関連付けて、資産管理オブジェクト・データを外部アプリケーション・データに同期させることができます。作成して外部システムに関連付けるチャネルには、アウトバウンド・メッセージ処理ロジックを含めます。

手順


2. 「パブリッシュ・チャネル」タブで「チャネルの選択」をクリックします。

3. 該当の「パブリッシュ・チャネル」チェック・ボックスを選択して、1 つ以上のパブリッシュ・チャネルを選択します。



次のタスク

チャネルが使用するエンドポイントを定義できます。パブリッシュ・チャネル・レベルでエンドポイントを定義しなければ、データは外部システム・レベルで定義されたエンドポイント・ロケーションに移動されます。統合フレームワーク・メッセージ処理を実行可能にするには、関連付けられたパブリッシュ・チャネルを有効にする必要があります。

パブリッシュ・チャネルへのエンドポイントの追加:

パブリッシュ・チャネルがアウトバウンド・データのパブリッシュ先を判別するために使用する、エンドポイントを定義することができます。エンドポイントは、アウトバウンド・データをパブリッシュするターゲット・ロケーションと、パブリッシュするために使用するトランスポート・メカニズムを識別します。パブリッシュ・チャネル・レベルでエンドポイントを定義しなければ、データは外部システム・レベルで定義されたエンドポイント・ロケーションに移動されます。

始める前に

パブリッシュ・チャネルを外部システムに関連付ける必要があります。

手順


2. 「パブリッシュ・チャネル」タブで、エンドポイントを追加するパブリッシュ・チャネルを選択します。

3. 「エンドポイント」フィールドに値を指定します。


次のタスク

アウトバウンド統合フレームワーク・メッセージ処理を実行する準備が整ったら、関連付けられたパブリッシュ・チャネルを有効にできます。


ファイル・ベースのデータのインポート:

データのインポート機能を使用して、XML ファイルまたは区切り文字で区切られたフラット・ファイルからデータをロードし、Maximo データベースを更新することができます。データをロードしてデータベースにコミットする前に、データをプレビューして確認できます。エラーは、メッセージ再処理アプリケーションで管理することも、インポートされたファイル形式と同じファイル形式に抽出して管理することもできます。

始める前に

データをフラット・ファイル (.csv ファイルなど) からインポートする予定の場合、データをインポートするには、エンタープライズ・サービス・オブジェクト構造がフラット・ファイル構造をサポートしていなければなりません。オブジェクト構造アプリケーションで、関連付けられたオブジェクト構造レコードに対して「フラット・ファイル構造のサポート (Support Flat File Structure)」チェック・ボックスが選択されていることを確認してください。また、データをインポートするには、外部システムとエンタープライズ・サービスの両方が有効になっている必要もあります。


インポートするデータは、コンマ区切りなどの区切り文字で区切られたフラット・ファイルまたは XML ファイルの形式である必要があります。データのインポート・プロセスでは、定義済みまたはユーザー定義のエンタープライズ・サービスを使用できます。

手順

1. 外部システム・アプリケーションで、データのインポート元となるエンタープライズ・サービスが含まれる外部システムを表示します。

2. 「エンタープライズ・サービス」タブで、データのインポート元となるエンタープライズ・サービスを選択します。

3. 「データのインポート」をクリックします。

4. オプション: 「インポートのプレビュー」チェック・ボックスを選択して、データをデータベースにインポートしてコミットする前に、データを確認します。データ・レコードをサンプリングするには、プレビュー・オプションを使用します。この機能は、数百のレコードが含まれる大きなサイズのファイルをサポートすることは意図していません。同期処理により、更新内容をデータベースにコミットせずにファイルをビジネス・オブジェクトに処理して、エラー・メッセージが検出された場合にはそのメッセージを返します。

5. ファイルのインポートに使用するファイルのタイプを指定します。


XML ファイルデータは XML 形式でインポートされます。

フラット・ファイルデータは区切り文字で区切られたフラット・ファイルでインポートされます。必要に応じて、「区切り文字」および「テキスト修飾子」の値を変更します。


6. 「インポート・ファイルの指定」フィールドに、インポートされるファイルを識別および保管するためのファイル名パスを入力します。

7. ファイルで検出されたエラーを、インポートされたファイルと同じ形式で管理するには、「ファイル・ベース・エラー管理」チェック・ボックスを選択します。このオプションは、エラーをメッセージ再処理アプリケーションで管理する代わりの手段となります。

8. 「OK」をクリックして、データのインポート・プロセスを開始します。

次のタスク

データのインポートが実行されると、インポート対象として選択されたファイルが複数のメッセージに変換されて、エンタープライズ・サービスとそれに対応する外部システム用に構成されたインバウンド・キューに入れられます。インバウンド・キューに入れられたメッセージが処理されると、更新対象のアプリケーション・オブジェクトに配信されます。インバウンド・キューからのメッセージを処理するためには、連続キューの使用時には JMS クーロン・タスクを有効にし、継続中のキューの使用時にはメッセージ駆動型 Bean を有効にする必要があります。ファイルの処理中にエラーが発生した場合は、メッセージ再処理アプリケーションで、エラーのフラグが立てられたデータ・インポート・メッセージを管理および表示できます。

エンタープライズ・サービスの有効化:

外部システムに関連付けられたエンタープライズ・サービスを使用してインバウンド外部アプリケーション・データを受信できるようにするには、そのエンタープライズ・サービスを有効にする必要があります。デフォルトでは、外部システムに関連付けられたエンタープライズ・サービス・レコードは無効に設定されます。エンタープライズ・サービスが無効になっている場合、外部システムはインバウンド外部アプリケーション・メッセージを処理できません。

手順

1. 外部システムアプリケーションで、更新するシステムを表示します。

2. 「エンタープライズ・サービス」タブで、エンタープライズ・サービスを有効にするか、または無効にするかを指定します。





エンタープライズ・サービスを外部システムに関連付ける:

エンタープライズ・サービスを外部システムに関連付けて、インバウンド外部アプリケーション・データを資産管理オブジェクトに同期させることができます。作成して外部システムに関連付けるサービスには、インバウンド・メッセージ処理ロジックを含めます。



関連付けられたエンタープライズ・サービスに、連続キューまたは継続中のキューのどちらからデータを受信させるかを指定できます。インバウンド統合フレームワーク・メッセージ処理を実行する準備が整っている場合は、関連付けられたエンタープライズ・サービスを有効にすることもできます。

手順

1. エンタープライズ・システム・アプリケーションで、更新するシステムを表示します。

2. 「エンタープライズ・サービス」タブで「新規行」をクリックします。

3. 「エンタープライズ・サービス」フィールドに値を入力します。

4. オプション: 以下のようにして、エンタープライズ・サービスを有効にするか、または無効にするかを指定します。




5. サービス・メッセージに継続中のキューまたは連続キューのどちらからデータを受信させるかを指定します。

オプション継続中のキューの使用

継続中のキュー選択

連続キュークリア


外部システムのエンタープライズ・サービスの選択:

複数のエンタープライズ・サービスを外部システムに関連付けて、インバウンド外部アプリケーション・データを資産管理オブジェクトに同期させることができます。作成して外部システムに関連付けるサービスには、インバウンド・メッセージ処理ロジックを含めます。

手順


2. 「エンタープライズ・サービス」タブで「サービスの選択」をクリックします。

3. 該当の「エンタープライズ・サービス」チェック・ボックスを選択して、1 つ以上のエンタープライズ・サービスを選択します。



次のタスク

統合フレームワーク・メッセージ処理を実行可能にするには、関連付けられたエンタープライズ・サービスを有効にする必要があります。また、関連付けられたエンタープライズ・サービスに、連続キューまたは継続中のキューのどちらからデータ


を受信させるかを指定することもできます。

エンタープライズ・サービス・キュー・タイプの選択:

外部システムに関連付けられたエンタープライズ・サービスに、継続中のキューまたは連続キューのどちらからデータを受信させるかを指定することができます。エンタープライズ・サービス用に選択したキューによって、Java Message Service

(JMS) キューがインバウンド・メッセージを処理する方法が決まります。

始める前に

エンタープライズ・サービスを外部システムに関連付ける必要があります。


継続中のキューは、メッセージ処理がエラーの結果になったとしても、キュー内にあるメッセージの処理を続行します。逆に、連続キューは、処理エラーがクリアされるまで、キュー内にあるメッセージの処理を停止します。また、連続キューでは厳格な先入れ先出し方式でメッセージも処理されます。

手順


2. 「エンタープライズ・サービス」タブで、キューを選択するエンタープライズ・サービスを選択します。

3. サービス・メッセージに継続中のキューまたは連続キューのどちらからデータを受信させるかを指定します。

オプション継続中のキューの使用

継続中のキュー選択

連続キュークリア


次のタスク

インバウンド統合フレームワーク・メッセージ処理を実行する準備が整ったら、関連付けられたエンタープライズ・サービスを有効にすることができます。

ファイル・ベースのデータのエクスポート:

データのエクスポート機能により、ファイルから外部システムへのメッセージ・データの一括エクスポートを実行できます。外部システムに関連付けられたパブリッシュ・チャネルごとに、エクスポート・プロセスを開始できます。

始める前に

マルチテナンシー環境では、アプリケーション・サーバーからアクセス可能なファイル・サーバーへのアクセス権限がシステム・プロバイダーによってユーザーに提供される場合にのみ、データのエクスポート機能を使用することができます。そして、このファイル・サーバーのロケーションを指すようにファイル・ベースのエンドポイントを構成する必要があります。


データをエクスポートできるようにするには、外部システムとパブリッシュ・チャネルの両方を有効にする必要があります。エクスポートするデータは、オブジェクト構造スキーマに従った XML ファイルの形式、あるいはコンマ区切りなどの区切り文字で区切られたフラット・ファイルの形式 (オブジェクト構造スキーマ形式をフラット化したもの) である必要があります。


「条件のエクスポート」フィールドに入力するオプションの SQL クエリーは、エクスポートされる XML メッセージのサイズに影響を与えます。この内容をフィルターに掛けると、エクスポートするデータ量を制限できます。エクスポート・プロセスでは、選択されたパブリッシュ・チャネルのクエリー結果セットに対し、標準のアウトバウンド処理が実行されます。

手順

1. 外部システム・アプリケーションで「パブリッシュ・チャネル」タブをクリックし、エクスポートするパブリッシュ・チャネルを選択します。

2. 「エンドポイント」フィールドに、XML ファイル形式またはフラット・ファイル形式のいずれかについてのファイル・ベースのエンドポイント・ハンドラーを指定します。


4. オプション: 「条件のエクスポート」フィールドに SQL クエリーを入力します。クエリーは、パブリッシュ・チャネル・オブジェクト構造内の主または最上位のオブジェクトに対して行う必要があります。

5. オプション: 「エクスポート・カウント」フィールドに整数値を指定して、エクスポートされるファイル内のレコード数を制限します。クエリーの結果に、指定した数より多くのレコードが含まれる場合、超過した分のレコードはエクスポートされるファイルに組み込まれません。

6. 「OK 」をクリックして、データのエクスポート・プロセスを開始します。

次のタスク

データのエクスポートが実行されると、選択したデータがメッセージに変換されて、パブリッシュ・チャネルとそれに対応する外部システム用に構成されたアウトバウンド・キューに入れられます。アウトバウンド・キューに入れられたメッセージが処理されると、構成済みエンドポイントに配信されます。エンドポイントへのメッセージ配信時にエラーが発生した場合は、メッセージ再処理アプリケーションで、エラーのフラグが立てられたデータ・エクスポート・メッセージを管理および表示できます。

外部システムへのキューの追加:

Java Message Service (JMS) キューを使用して、外部アプリケーションとエンタープライズ・サービスおよびパブリッシュ・チャネル・データを交換できます。メッセージを受信または送信すると、メッセージは JMS キューに書き込まれます。これらのメッセージは、正常に処理されるまで、または削除されるまで、そのキューに残されます。


始める前に

外部システムにキューを追加する前に、アプリケーション・サーバーにキューを作成する必要があります。連続キューを追加する場合、定期的にキューでメッセージをポーリングするクーロン・タスクをセットアップする必要があります。


外部システムごとに独自のインバウンド・キューとアウトバウンド・キューを割り当てるか、複数のシステムがキューを共有するように構成することができます。定義済みのインバウンド・メッセージ・キューおよびアウトバウンド・メッセージがニーズを満たさない場合には、独自のユーザー定義メッセージ・キューを追加するか、または既存のキューを変更することができます。

手順

1. 外部システム・アプリケーションで、JMS キューを追加する対象のシステムを選択します。

2. 「キューの追加/修正」アクションを選択します。




キューの JNDI 名 JMS キューの名前。

キューの接続ファクトリーキューにアクセスするために使用される接続ファクトリー。デフォルト値はjms/mro/int/queues/sqin です。

最大試行回数メッセージがエラー・ログに書き込まれて、電子メール通知がシステム管理者に送信される前にメッセージが処理される回数。



初期コンテキスト・ファクトリー JMS サーバーへの接続に使用されるクラス。

プロバイダーの URL JMS サーバーの URL。

ユーザー ID 新規キューへのアクセスに使用されるユーザー ID。

パスワードキューへのアクセスに使用するパスワード。

電子メール・アドレスキューでトランザクション・エラーが発生した場合に通知を受けるユーザーの電子メール・アドレス。この値は、通常はシステム管理者の電子メール・アドレスです。

6. オプション: キューを使用してインバウンド・メッセージを配信し、そのキューを継続中のキューとして機能させる場合、「連続」チェック・ボックスをクリアします。

7. オプション: キューがアウトバウンド・メッセージを配信する場合、「インバウンド」チェック・ボックスをクリアします。



9. 「システム」タブで、以下のフィールドに値を入力します。

v アウトバウンド用の連続キュー

v インバウンド用の連続キュー

v インバウンド用の継続中のキュー


インターフェース・テーブルの作成:

インターフェース・テーブルを作成して、データベース表を使用してデータ交換を行う外部システムを統合することができます。インターフェース・テーブルは、パブリッシュ・チャネルやエンタープライズ・サービスのオブジェクト構造の内容を反映します。該当のオブジェクト構造の定義を変更した場合に、既存のテーブルを再作成する必要があります。

始める前に

あるインターフェース・テーブルの未処理のメッセージが MXIN_INTER_TRANS

キュー・テーブルにある場合は、そのインターフェース・テーブルを再作成できません。インターフェース・テーブルを再作成する前にデータをバックアップしない場合、データは失われます。オブジェクト構造アプリケーションで、別名の競合が解決されていること、および関連付けられたオブジェクト構造レコードで「フラット・ファイル構造のサポート (Support Flat File Structure)」チェック・ボックスが選択されていることを確認してください。


「インターフェース・テーブルの作成」ダイアログ・ボックスに、以下の特性があるパブリッシュ・チャネルとエンタープライズ・サービスに関連付けられているインターフェース・テーブルが表示されます。

v 選択された外部システムに登録されている。

v インターフェース・テーブル名が NULL ではない。

v 該当のオブジェクト構造がフラット・ファイル形式をサポートする。

手順

1. 外部システム・アプリケーションで、「インターフェース・テーブルの作成」アクションを選択します。

2. 「インターフェース・テーブルの作成」ダイアログ・ボックスで、更新および作成するインターフェース・テーブルを選択します。

3. 「エンドポイント」フィールドに値を入力します。

4. オプション: 「既存のものを名前変更する」チェック・ボックスを選択して、選択したインターフェース・テーブルのコピーを作成します。資産管理システムでは、インターフェース・テーブルのコピーが保存され、名前に「BAK」サフィックスが追加されます。



6. テーブルを作成する場合は「OK」、処理を停止する場合は「キャンセル」をクリックします。作成するインターフェース・テーブルの数に応じて、処理に時間がかかる場合があります。

7. 「OK」をクリックして「インターフェース・テーブルの作成」ダイアログ・ボックスを閉じます。

統合コントロールの処理:

統合チャネルまたはサービスに、統合コントロールに基づく処理ルールあるいは終了クラスが含まれる場合は、外部システム用に統合コントロールの値を構成することができます。処理ルールに取り込むことができるブール値、一覧、および値の統合コントロールを構成できます。

ブール型コントロールのセットアップ:

true または false の値を指定するコントロールが必要な場合には、外部システムでブール型コントロールをセットアップできます。ブール型コントロールに、特定の組織レベル値およびサイト・レベル値を追加することができます。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価でこのブール型コントロールを使用できます。外部システムのコントロールに割り当てる True

または False の値によって、エンタープライズ・サービスまたはパブリッシュ・チャネルが処理ルールを適用するかどうかが決まります。

始める前に

コントロールに割り当てるブール型値は、すでにパブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのコントロールの定義に存在している必要があります。その定義がドメインをポイントしている場合、割り当てるすべての組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。

手順


2. 「統合コントロールのセットアップ」アクションを選択します。

3. 更新するブール型コントロールを選択します。


5. 以下のいずれかのアクションを実行します。

v 「組織」フィールドに値を入力します。

v 「サイト」フィールドに値を入力します。

6. ブール型コントロールのデフォルト値を True にするか False にするかを指定します。

オプションデフォルト True

True 値選択

False 値クリア

7. 「OK」をクリックして「ブール型コントロール」ダイアログ・ボックスを閉じます。


8. 「OK」をクリックして「統合コントロールのセットアップ」ダイアログ・ボックスを閉じます。

クロス・リファレンス・コントロールの設定:

値を置き換えるコントロールが必要な場合には、クロス・リファレンス・コントロールを設定できます。クロス・リファレンス・コントロールでは、資産管理システムでの値を外部システムでの値にマップできます。

始める前に

変換するために割り当てる値は、最初にパブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのコントロールの定義に存在している必要があります。その定義がドメインをポイントしている場合、割り当てる組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。

手順



3. 更新するクロス・リファレンス・コントロールを選択します。


5. 「MAXIMO 値」フィールドに、資産管理システムが外部システム値に変換するアプリケーション値、または外部システム値から変換するアプリケーション値を入力します。

6. 「外部の値」フィールドに、資産管理システムが「Maximo 値」に変換する外部システム値、または「Maximo 値」から変換する外部システム値を入力します。

7. 「OK」をクリックして「クロス・リファレンス・コントロール」ダイアログ・ボックスを閉じます。


リスト・コントロールの設定:

値の一覧を含むコントロールが必要な場合は、リスト・タイプの統合コントロールを作成します。リスト・コントロールには、特定の組織レベル値およびサイト・レベル値を追加することができます。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価でこのリスト・コントロールを使用できます。外部システムのコントロールに割り当てる値によって、エンタープライズ・サービスまたはパブリッシュ・チャネルが処理ルールを適用するかどうかが決まります。

始める前に

リスト・コントロールに追加する値は、既にパブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのコントロールの定義に存在している必要があります。その定義がドメインをポイントしている場合、割り当てる組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。


手順



3. 更新するリスト・コントロールを選択します。


5. 「値」フィールドに、ドメインに存在する値を入力します。

6. 「OK」をクリックして「リスト・コントロール」ダイアログ・ボックスを閉じます。


値コントロールのセットアップ:

1 つの値を含むコントロールが必要な場合は、外部システムで値タイプの統合コントロールを設定できます。値コントロールには、特定の組織レベル値およびサイト・レベル値を追加することができます。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価でこの値コントロールを使用できます。外部システムのコントロールに割り当てる値によって、エンタープライズ・サービスまたはパブリッシュ・チャネルが処理ルールを適用するかどうかが決まります。

始める前に

割り当てる値は、最初にパブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのコントロールの定義に存在している必要があります。その定義がドメインをポイントしている場合、割り当てる組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。

手順



3. 更新する値コントロールを選択します。





6. 「値」フィールドに、ドメインに存在する値を入力します。

7. 「OK」をクリックして「値コントロール」ダイアログ・ボックスを閉じます。


クロス・リファレンス・コントロールの値の上書き:

クロス・リファレンス・コントロールをセットアップして、サイトと組織の値を上書きできます。エンタープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで以前に定義したクロス・リファレンス値を上書きすることができま


す。有効な資産管理システムと外部システムのマッピングを維持できるように、値の上書きはそれぞれの外部システムに応じて構成できます。

始める前に

変換するために使用する値は、パブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのクロス・リファレンス・コントロールの定義に、あらかじめ存在している必要があります。その定義がドメインをポイントしている場合、割り当てる組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。


シノニムを使用する場合は、内部のアプリケーション値ではなく、外部の値をコントロール値として入力します。

手順



3. 更新するクロス・リファレンス・コントロールを選択します。

4. 「上書き」をクリックします。「クロス・リファレンス・コントロールの値を上書き」ダイアログ・ボックスに、コントロールに既存の組織レベル値およびサイト・レベル値が表示されます。





7. 「組織/サイトの値」テーブル・ウィンドウで、「新規行」をクリックします。

8. 「デフォルト値」フィールドおよび「外部の値」フィールドの値を入力します。コントロールを乗法コントロールとして使用するには、同じ外部の値、および異なる組織値またはサイト値を持つ複数のレコードを入力します。

9. 「OK」をクリックして「クロス・リファレンス・コントロールの値を上書き」ダイアログ・ボックスを閉じます。



例

5 つの外部システムが、統合フレームワークとデータを交換するように構成されています。そのうち 4 つの外部システムは同じサイト値を使用しますが、1 つのサイト値は異なります。4 つの外部システムの不一致の値と資産管理システム値との間で変換を行うクロス・リファレンス・コントロールは、外部システム・レベルで上書きできます。残り 1 つの一致しない外部システムのサイト値を資産管理システムの保管場所の値に変換するには、値の上書きを構成できます。


エンタープライズ・サービスのクロス・リファレンス・コントロールでは、外部システムのサイト値 EX001 を資産管理システムのサイト MX001 に変換できます。外部システムのクロス・リファレンス・コントロールの上書きでは、定義済みの値EX001 を上書きし、値の変換で値 EX002 を使用できます。

リスト・コントロールの値の上書き:

リスト・コントロールをセットアップして、サイトと組織の値を上書きできます。エンタープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで以前に定義したリスト・コントロールの値を上書きすることができます。ルールでは、データ・フィールド値が、上書きされたリスト・コントロールの値のいずれにも一致しない場合には、トランザクションの処理を省略できるようにすることもできます。

始める前に

割り当てる値は、最初にパブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションのコントロールの定義に存在している必要があります。その定義がドメインをポイントしている場合、割り当てる組織レベル値またはサイト・レベル値がそのドメインに存在している必要があります。


コントロール値に 10 進数を使用する場合は、アプリケーション・サーバーまたはデータベースのロケール設定とは無関係に、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側の数字はフォーマットされません。このフォーマットはインバウンドとアウトバウンドのデータに適用されます。例えば、$1,738,593.64 は 1738593.64 とする必要があります。

手順



3. 更新するリスト・コントロールを選択します。

4. 「上書き」をクリックします。「リスト・コントロールの値を上書き」ダイアログ・ボックスに、コントロールに既存の組織レベル値およびサイト・レベル値が表示されます。





7. 「組織/サイトの値」テーブル・ウィンドウで、「新規行」をクリックします。

8. 「値」フィールドに値を入力します。シノニムを使用する場合、内部のアプリケーション値ではなく、外部の値を入力します。

9. 「OK」をクリックして「リスト・コントロールの値を上書き」ダイアログ・ボックスを閉じます。




例

作業指示書は、そのステータスに基づいて、外部システムに送信されます。エンタープライズ・サービスまたはパブリッシュ・チャネルに定義された処理ルールでは、APPR (承認済) と COMPLETE の 2 つのステータス値を含むリスト・コントロールと照合して、作業指示書のステータスを検査できます。このリストの上書きを構成して、2 つの異なる作業指示書のステータス値、WAPPR (承認待ち) またはWSCH (予定の設定待ち) を評価することができます。作業指示書のステータスが、上書きされたリスト・コントロールの値に一致しない場合には、作業指示書のトランザクションは外部システムに送信されません。

事前定義統合コンテンツ統合フレームワークには、事前定義統合コンテンツがあります。これには、外部システムからのデータのインポートまたは外部システムへのデータのエクスポートをサポートするオブジェクト構造、パブリッシュ・チャネル、およびエンタープライズ・サービスが含まれます。

場合によっては、オブジェクト構造のみが提供され、関連のパブリッシュ・チャネルまたはエンタープライズ・サービスが提供されないことがあります。統合フレームワークは、オブジェクト構造内部のビジネス・オブジェクトで定義されているビジネス・ルールに従った、データの挿入、更新、削除、および照会を計画的にサポートしています。アクションまたは画面上の処理ボタンで選択できる機能など、アプリケーションを介して利用できる機能が必ずしもすべて提供されるわけではありません。一部のオブジェクト構造では、アクションの一部や画面上の処理ボタンがサポートされる場合があります。

マスター・データ・オブジェクト統合フレームワークでは、通常は会計、担当者、保管場所、作業員、分類、および販売元データで構成されているマスター・データの事前定義統合コンテンツを選択できます。

資産オブジェクト:

MXASSET オブジェクト構造では、資産情報 (計測を定義する属性など) の双方向同期を行うことができます。

目的

MXASSET オブジェクト構造は、個別の資産を同期しますが、資産階層を全体として同期するわけではありません。資産に関連付けられている計測の追加と更新はサポートしますが、計測値の更新はサポートしません。 ASSETMETER のインバウンド処理は、計測値自体または計測値に関連するその他の情報ではなく、その計測を定義する属性に制限されています。


前提条件

資産をロードする前に、適用可能な稼働ロケーション、保管場所、計測、および項目を同期する必要があります。

ASSETMETER MBO を取得するために使用される MBO 関係は、資産アプリケーションで使用される MBO 関係とは異なります。そのため、この MBO のいずれの値についても、XML での変更属性 (アウトバウンド処理) は設定されません。

このオブジェクト構造は、ステータス変更または資産移動はサポートしません。稼働ロケーションに存在する資産の移動をサポートする、資産のための標準サービスが提供されています。この資産のための標準サービスでは、資産を移動するための機能をサポートする操作 assetmoveSingleAsset を実行できます。

アウトバウンド統合処理

以下の表は、アウトバウンド統合処理で使用される事前定義値を示します。

事前定義された統合コンポーネント値および説明

オブジェクト構造の定義クラス機能 MoutAssetProcess - 分類が資産に関連付けられている場合、階層フィールドを取り込みます。

パブリッシュ・チャネル MXASSETInterface

処理ルールなし

統合コントロールなし

インバウンド統合処理

以下の表は、インバウンド統合処理で使用される事前定義値を示します。


オブジェクト構造の処理クラス機能 MaxAssetProcess - 階層パスが指定されている場合、処理クラスでは、資産に対応するクラス構造 ID フィールドの取り込みが行われ、資産と分類の関連付けが作成されます。

エンタープライズ・サービス MXASSETInterface



勘定科目オブジェクトのチャート:

MXCOA オブジェクト構造では、勘定科目データのチャートのインバウンド同期を行うことができます。

前提条件

勘定科目のチャートをロードする前に、GL コンポーネントをロードする必要があります。このオブジェクト構造について、事前定義されているパブリッシュ・チャネルはありません。





オブジェクト構造の定義クラス機能なし

パブリッシュ・チャネルなし






オブジェクト構造の処理クラス機能 MaxCOAProcess - 区切られたセグメントの組み合わせとして、または GLACCOUNT データ型定義の一部である個別コンポーネントとして処理できます。

エンタープライズ・サービス MXCOAInterface



インバウンド処理の例

区切られたセグメントの組み合わせとしての処理は、XML およびインターフェース・テーブルで使用できます。この方法を使用して、すべてのオブジェクト構造でGL 勘定科目を指定できます。

<GLACCOUNT><VALUE>6400-2-10</VALUE>

</GLACCOUNT>

オブジェクト構造は、各セグメントを検証してから、以下の値を使用して、データベース内に勘定科目レコードのチャートを作成します。

v GLACCOUNT=6400-2-10

v GLCOMP01-6400

v GLCOMP02=2

v GLCOMP03=10

GLACCOUNT データ型定義の一部である個別コンポーネントとしてオブジェクトを処理することもできます。

<GLACCOUNT><GLCOMP glorder="0">6400</GLCOMP><GLCOMP glorder="1">2</GLCOMP><GLCOMP glorder="2">10</GLCOMP></GLACCOUNT>

オブジェクト構造はコンポーネントを検証し、各セグメントについてGLCONFIGURE テーブル内で定義されている区切り文字を使用して勘定科目を作成


します。このオプションは、XML のみで使用できます。

分類項目オブジェクト:

MXCLASSIFICATION オブジェクト構造では、分類 (使用するクラス、クラス仕様、および使用するクラス仕様など) の双方向同期を行うことができます。





パブリッシュ・チャネル MXCLASSInterface






オブジェクト構造の処理クラス機能 MaxClassificationProcess - 階層パスを使用して分類および上位階層を検出するための処理ロジック。システムは重複分類 (階層パス)

を許可するため、分類を更新しようとしたときに重複分類が存在した場合、例外が生成されます。

エンタープライズ・サービス MXCLASSInterface



職種オブジェクト:

MXCRAFT オブジェクト構造では、職種情報の双方向同期を行うことができます。職種情報には、職種、職種技能、および職種別時間単価が含まれます。

前提条件

職種が技能または契約を参照している場合、職種をロードする前に、その情報が存在する必要があります。

職種には、標準単価 (職種の技能レベルごとの単価) を設定できます。また、契約ごとにオプションの技能レベル単価を使用して、その職種を指定する契約ごとに異なる単価を設定することもできます。

CRAFT および CRAFTSKILL レコードには、職種ごとに、または職種に関連付けられている技能ごとに、時間単価の STANDARDRATE フィールドがあります。


CRAFTRATE レコードは、職種を提供する販売元の単価を指定します。また、オプションで、技能、職種、および販売元の組み合わせごとに異なる単価を指定することもできます。





パブリッシュ・チャネル MXCRAFTInterface






オブジェクト構造の処理クラス機能なし

エンタープライズ・サービス MXCRAFTInterface



会計プロジェクト・オブジェクト:

MXPROJ オブジェクト構造では、会計プロジェクト情報の双方向同期を行うことができます。このオブジェクト構造は、個別のタスクおよびプロジェクトを、それぞれ個別のメッセージとして同期します。プロジェクトと、そのすべての子タスクを、1 つのメッセージとして同期するわけではありません。





パブリッシュ・チャネル MXPROJInterface







エンタープライズ・サービス MXPROJInterface





総勘定元帳 (GL) コンポーネント・オブジェクト:

MXGLCOMP オブジェクト構造では、GL コンポーネントのインバウンド同期を行うことができます。












エンタープライズ・サービス MXGLCOMPInterface



作業員オブジェクト:

MXLABOR オブジェクト構造では、作業員情報 (担当者および作業員の職種別単価など) の双方向同期を行うことができます。

前提条件

作業員をロードする前に、関連付けられている職種、作業ロケーション、または保管場所ロケーションを同期する必要があります。各担当者レコードには、それぞれ1 つの作業員レコードのみ使用できます。




オブジェクト構造の定義クラス機能 MoutLaborProcess - 処理ロジックは無効です。

パブリッシュ・チャネル MXLABORInterface








オブジェクト構造の処理クラス機能 MaxLaborProcess - ステータス変更をサポートします。上位階層 MBO の LaborCraftRate

MBO の ORGID を設定します。また、LABOR レコードの PERSONID に基づいて、PERSON レコードの PERSONID を設定します。

エンタープライズ・サービス MXLABORInterface



担当者オブジェクト:

MXPERSON オブジェクト構造では、担当者情報 (電話番号、電子メール、およびSMS データなど) の双方向同期を行うことができます。

目的

このオブジェクト構造は、個別の担当者データの同期をサポートします。担当者レコードの作業可能時間情報の更新はサポートしません。また、このオブジェクト構造は、ステータス変更をサポートします。





パブリッシュ・チャネル MXPERSONInterface







オブジェクト構造の処理クラス機能 MaxPersonProcess - すべての担当者の更新において、すべての下位階層オブジェクトのデータ (PHONE、EMAIL、SMS) が指定されている必要があります。これらのオブジェクトには固有キーが存在しないため、このロジックでは、常にすべての下位階層オブジェクトが削除され、再度追加されます。ある担当者の電子メール・レコードがシステム内に 3

個存在し、担当者メッセージを 2 個の電子メール・レコードで受信した場合、この担当者メッセージに含まれていなかった残りの電子メール・レコードは削除されます。このオブジェクト構造は、ステータス変更をサポートします。

エンタープライズ・サービス MXPERSONInterface



担当者/ユーザー・オブジェクト:

MXPERUSER オブジェクト構造では、担当者/ユーザー情報の双方向同期を行うことができます。このオブジェクト構造は、ステータス変更をサポートします。





パブリッシュ・チャネル MXPERUSERInterface






オブジェクト構造の処理クラス機能 MaxPersonUserProcess - ユーザー・データを保存する前に、担当者データを保存する処理が必要です。このオブジェクト構造は、ステータス変更をサポートします。

エンタープライズ・サービス MXPERSUSERnterface





保管場所ロケーション・オブジェクト:

MXSTORELOC オブジェクト構造では、保管場所、作業員、および運送業者の各ロケーションの双方向同期を行うことができます。




オブジェクト構造の定義クラス機能 MoutLocProcess - 保管場所、運送業者、または作業員のいずれかのロケーションのみを送信するフィルターを指定します。

パブリッシュ・チャネル MXSTORELOCInterface






オブジェクト構造の処理クラス機能 MaxLocProcess - 保管場所、運送業者、または作業員のいずれかのロケーションのみを受け入れるフィルターを指定します。

エンタープライズ・サービス MXSTORELOCInterface



販売元 (企業) マスター・オブジェクト構造オブジェクト:

MXVENDORMSTR オブジェクト構造では、販売元マスター・データの双方向同期を行うことができます。





パブリッシュ・チャネル MXVENDORMSTRInterface








エンタープライズ・サービス MXVENDORMSTRInterface



販売元 (企業) オブジェクト:

MXVENDOR オブジェクト構造では、組織レベルの販売元データ (契約など) の双方向同期を行うことができます。

前提条件

このオブジェクト構造を有効にして企業マスター・レコードを作成するには、販売元レコードの追加先である組織に関連付けられているセットについて、「企業を企業マスターに自動的に追加」オプションを選択します。 MXVENDOR オブジェクト構造は、ステータス変更をサポートします。





パブリッシュ・チャネル MXVENDORInterface






オブジェクト構造の処理クラス機能 MaxComProcess - 企業マスター・レコードの作成をサポートするロジックを提供します。

エンタープライズ・サービス MXVENDORInterface



部品オブジェクトおよび在庫オブジェクト統合フレームワークでは、サービス項目、工具部品、在庫販売元、出庫などの部品オブジェクトおよび在庫オブジェクトの事前定義統合コンテンツを選択できます。


部品オブジェクト:

MXITEM オブジェクト構造では、部品データ (変換、部品仕様、および状態など)

の双方向同期を行うことができます。このオブジェクト構造は、ステータス変更をサポートします。




オブジェクト構造の定義クラス機能 MoutItemProcess - 工具項目またはサービス項目を設定しないようにフィルター処理します。項目のクラス構造 ID の階層パスの取得をサポートします。

パブリッシュ・チャネル MXITEMInterface






オブジェクト構造の処理クラス機能 MaxItemProcess - インバウンド・トランザクションが部品の更新であり、部品の資産計上されたフラグが変更された場合、部品の資産計上ステータスを変更するメソッドが呼び出されます。部品タイプが ITEM または有効なシノニムでない場合。ステータス変更をサポートします。

エンタープライズ・サービス MXITEMInterface



サービス項目オブジェクト:

MXSERVITEM オブジェクト構造では、サービス項目データの双方向同期を行うことができます。このオブジェクト構造のメイン・オブジェクト SERVICEITEMS

は、非永続オブジェクトです。





パブリッシュ・チャネル MXSERVITEMInterface









エンタープライズ・サービス MXSERVITEMInterface



工具項目オブジェクト:

MXTOOLITEM オブジェクト構造では、工具部品データ (工具部品仕様など) の双方向同期を行うことができます。




オブジェクト構造の定義クラス機能 MoutToolItemProcess - 項目のクラス構造 ID

の階層パスの取得をサポートします。

パブリッシュ・チャネル MXTOOLITEMInterface






オブジェクト構造の処理クラス機能 MaxToolItemProcess - インバウンド・トランザクションが部品の更新であり、部品の資産計上されたフラグが変更された場合、部品の資産計上ステータスを変更するメソッドが呼び出されます。

エンタープライズ・サービス MXTOOLITEMInterface



在庫オブジェクト:

MXINVENTORY オブジェクト構造では、在庫 (部品と保管場所) のデータ (在庫コストなど) の双方向同期を行うことができます。





オブジェクト構造の定義クラス機能 MoutInvProcess - ITEM オブジェクトのITEMTYPE フィールドの値を設定します。

パブリッシュ・チャネル MXINVENTORYInterface

処理ルール SKIPINVENTORY - その ITEMTYPE がSKIPITEMTYPE 統合コントロール内にある場合、レコードをスキップします。

統合コントロール SKIPITEMTYPE




オブジェクト構造の処理クラス機能 MaxInvProcess - ステータス変更をサポートします。

エンタープライズ・サービス MXINVENTORYInterface



在庫量オブジェクト:

MXINVBAL オブジェクト構造では、在庫量データの双方向同期を行うことができます。このオブジェクト構造における在庫量変更情報は、アプリケーション内の末端レベル (BIN または LOT) を対象としています。




オブジェクト構造の定義クラス機能 MoutInvBalancesProcess - ITEM オブジェクトの ITEMTYPE フィールドの値を設定します。

パブリッシュ・チャネル MXINVBALInterface

処理ルール SKIPINVBALITM - その ITEMTYPE がSKIPITEMTYPE 統合コントロール内にある場合、レコードをスキップします。

統合コントロール SKIPITEMTYPE





オブジェクト構造の処理クラス機能 MaxInvBalancesProcess - インバウンド在庫量オブジェクト構造は、現在の在庫量調整メソッドを内部的に呼び出し、これによりCURBALADJ 財務トランザクションがINVTRANS で作成されます。

エンタープライズ・サービス MXINVBALInterface MXINVBALQInterface -

操作クエリーに対して構成されている 2 つ目のエンタープライズ・サービス。



部品販売元オブジェクト:

MXINVVENDOR オブジェクト構造では、販売元と部品のデータの双方向同期を行うことができます。




オブジェクト構造の定義クラス機能 MoutInvVendorProcess - ITEM オブジェクトの ITEMTYPE フィールドの値を設定し、販売元 (企業) オブジェクトのCURRENCYCODE の値を設定します。

パブリッシュ・チャネル MXINVVENDORInterface

処理ルール INVVITEMTYPE - その ITEMTYPE がITEMTYPEFORINV 統合コントロール内にある場合、レコードをスキップします。

統合コントロール ITEMTYPEFORINV




オブジェクト構造の処理クラス機能 MaxInvVendorProcess - インバウンド・メッセージに通貨コードが含まれており、そのコードが販売元の通貨コードと異なる場合、エラーが報告されます。

エンタープライズ・サービス MXINVENDORInterface




在庫予約オブジェクト:

MXINVRES オブジェクト構造では、在庫 (保管場所) の予約の双方向同期を行うことができます。このオブジェクト構造は、システムにより作成された直接出庫予約レコードは処理しません。




オブジェクト構造の定義クラス機能 MoutRSVProcess - 直接出庫のための予約をスキップします。

パブリッシュ・チャネル MXINVRESInterface







エンタープライズ・サービス MXINVRESInterface



在庫出庫オブジェクト:

MXINVISSUE オブジェクト構造では、在庫 (保管場所) の出庫および返却の双方向同期を行うことができます。




オブジェクト構造の定義クラス機能 MoutISUProcess - 直接出庫のための予約をスキップします。

パブリッシュ・チャネル MXINVISSUEInterface - 直接出庫は受領(MXRECEIPTInterface) オブジェクト構造により処理されるため、直接出庫をMATUSETRANS からフィルターで除外します (PONUM は非 NULL、ISSUETYPE はISSUE または RETURN)。請求書の承認プロセスで MATUSETRANS に書き込まれる差異トランザクションをフィルターで除外します。








オブジェクト構造の処理クラス機能 MaxISUProcess - 指定されているアクションが「追加」アクションでない場合、例外が生成されます。 ISSUETYPE を検証し、ISSUE、RETURN、または NULL であることを確認します。これ以外の値である場合、エラーが報告されます。 NULL である場合、値はデフォルトで ISSUE に設定されます。

エンタープライズ・サービス MXINVISSUEInterface



ドキュメント・オブジェクト統合フレームワークでは、購買レコード、請求書、作業指示書レコードなど、ドキュメントの事前定義統合コンテンツを選択できます。

STATUSIFACE フィールドと処理:

すべての購買ドキュメントおよび作業指示書ドキュメントには、ステータスがあります。 STATUSIFACE フィールドは、関連のトランザクションに新規レコードまたは更新済みレコードがあるか、あるいはステータス変更のみがあるかを示します。

通常、フィールド STATUSIFACE は、ステートフル MBO を基にして作成されたすべてのオブジェクト構造サブレコードに適用されます。ステートフル MBO は「ステータス」フィールドを持ち、ステータス変更アクションをサポートする MBO

です。STATUSIFACE フィールドは、統合がステータス変更をサポートするオブジェクトに対する非永続フィールドとして提供されます。

STATUSIFACE フィールドとアウトバウンド処理

アウトバウンド統合処理では、ステートフル MBO を基にして作成したオブジェクト構造サブレコードの処理中に、MBO 内の STATUS フィールドと、対応するオブジェクト構造サブレコード内の STATUSIFACE フィールドが検索されます。これらのフィールドが両方とも存在する場合は、処理により、STATUSIFACE フィールドの値が、対応する STATUS フィールドの変更済み属性の値に設定されます。値が 0

の場合は、ステータスが変更されなかったことを示しています。値が 1 の場合は、ステータスが変更されたことを示しています。

この処理が適用されるのは、イベントによって生成されたアウトバウンド・メッセージのみであり、データのエクスポート機能やプログラム呼び出しによってエクスポートされたメッセージには適用されません。


STATUSIFACE フィールドとインバウンド処理

プライマリー (トップ) MBO がステートフルであるオブジェクト構造を処理する場合、インバウンド処理では、対応するオブジェクト構造サブレコードのSTATUSIFACE フィールドが検索され、インバウンド・メッセージをドキュメント更新とステータス変更の両方として処理するか、またはステータス変更のみとして処理するかが判別されます。

以下の表では、ステートフルなプライマリー (トップ) MBO を持つオブジェクト構造を使用したインバウンド処理について説明しています。これは、オブジェクト構造内の下位階層のオブジェクトとして組み込まれているステートフル MBO には適用されません。

表 2. STATUSIFACE フィールドのインバウンド処理中に行われるアクション

STATUSIFACE の値データベース内にドキュメントが存在する場合

データベース内にドキュメントが存在しない場合

指定なし、または 0 v データベース内のドキュメントを更新する

v インバウンド・ドキュメントのステータスがデータベース内のステータスと異なる場合は、データベース内のステータスを更新する

v データベースにドキュメントを追加する

v データベース内のステータスをインバウンド・メッセージのステータスに設定する

1 データベース内のステータスを更新する

エラー

購買契約オブジェクト:

MXPC オブジェクト構造では、購買契約情報を双方向で同期できます。このオブジェクト構造が現在サポートしているのは、一括契約および価格契約の購買契約タイプのみです。



表 3. アウトバウンド統合処理用の購買契約オブジェクトの事前定義コンポーネント


オブジェクト構造の処理クラス機能

MoutPCProcess - 直接出庫を対象とする予約をスキップします。

パブリッシュ・チャネル MXPCInterface - ステータス変更の場合にのみ完全な購買契約ドキュメントを送信するように、処理ルールを使用します。


表 3. アウトバウンド統合処理用の購買契約オブジェクトの事前定義コンポーネント (続き)


処理ルール 1. SKIPPC - 以下の条件が両方とも満たされている場合には、ドキュメントの送信をスキップします。

v ドキュメントは以前に送信されていません。

v 新しいステータスは PCSEND コントロールに一覧されていません。

2. SKIPPCUPDATE - 更新されたがステータス変更はない場合、ドキュメントの送信をスキップします。

3. SETSTATUSIFACE - PCSEND コントロールに一覧されている値を除き、すべてのステータス値についてSTATUSIFACE フィールドの値を 0 (False) に設定します。

4. CHECKSTATUS - ステータスが変更され、新しいステータスが PCSEND コントロールに存在しない場合、購買契約ヘッダー・データのみを送信します。(この場合は完全なドキュメントが以前に送信されており、これで送信されるのはステータス変更通知のみです。)

統合コントロール PCSEND



表 4. インバウンド統合処理用の購買契約オブジェクトの事前定義コンポーネント



MaxPCProcess - ステータス変更をサポートします。購買契約は既に存在するが、改訂は存在しない場合、新規の改訂を作成します。一括契約および価格契約の契約タイプのみをサポートします。

パブリッシュ・チャネル MXPCInterface



購買要求書オブジェクト:

MXPR オブジェクト構造では、購買要求書情報を双方向で同期でき、ステータス変更がサポートされます。




表 5. アウトバウンド統合処理用の購買要求書オブジェクトの事前定義コンポーネント


オブジェクト構造の定義クラス機能

なし

パブリッシュ・チャネル MXPRInterface – 処理ルールを使用します。完全な購買要求ドキュメントは、ステータス変更の場合にのみ送信されます。

処理ルール 1. SKIPPR - 以下の条件が両方とも満たされている場合には、ドキュメントの送信をスキップします。


v 新しいステータスは PRSEND コントロールに一覧されていません。

2. SKIPPRUPDATE - 更新されたがステータスは変更されない場合、ドキュメントの送信をスキップします。

3. SETSTATUSIFACE - PRSEND コントロールに一覧されている値を除き、すべてのステータス値についてSTATUSIFACE フィールドの値を 0 (False) に設定します。

4. CHECKSTATUS - ステータスが変更され、新しいステータスが PRSEND コントロールに存在しない場合、購買要求書ヘッダー・データのみを送信します。(この場合は完全なドキュメントが以前に送信されており、これで送信されるのはステータス変更通知のみです。)

統合コントロール PRSEND



表 6. インバウンド統合処理用の購買要求書オブジェクトの事前定義コンポーネント



MaxPRProcess - ステータス変更をサポートします。購買要求書の現在のステータスが承認された場合、処理クラスは、更新をサポートするために、ステータスを承認待ちに戻し、更新を実行してから、XML メッセージで特定された内容にステータスを戻します。

パブリッシュ・チャネル MXPRInterface




注文書オブジェクト:

MXPO オブジェクト構造では、注文書情報を双方向で同期でき、ステータス変更もサポートされます。



表 7. アウトバウンド統合処理用の注文書オブジェクトの事前定義コンポーネント



なし

パブリッシュ・チャネル MXPOInterface - 処理ルールを使用します。完全な注文書ドキュメントは、ステータス変更の場合にのみ送信されます。

処理ルール 1. SKIPPO - 以下の条件が両方とも満たされている場合には、ドキュメントの送信をスキップします。


v 新しいステータスは POSEND コントロールに一覧されていません。

2. SKIPPOUPDATE - 更新されたがステータスは変更されない場合、ドキュメントの送信をスキップします。

3. SETSTATUSIFACE - POSEND コントロールに一覧されている値を除き、すべてのステータス値についてSTATUSIFACE フィールドの値を 0 (False) に設定します。

4. CHECKSTATUS - ステータスが変更され、新しいステータスが POSEND コントロールに存在しない場合、注文書ヘッダー・データのみを送信します。(この場合は完全なドキュメントが以前に送信されており、これで送信されるのはステータス変更通知のみです。)

統合コントロール POSEND



表 8. インバウンド統合処理用の注文書オブジェクトの事前定義コンポーネント



MaxPOProcess - ステータス変更をサポートします。

注文書の現在のステータスが承認された場合、処理クラスは、更新をサポートするために、ステータスを承認待ちに戻し、更新を実行してから、XML メッセージで特定された内容にステータスを戻します。


表 8. インバウンド統合処理用の注文書オブジェクトの事前定義コンポーネント (続き)


パブリッシュ・チャネル MXPOInterface



請求書オブジェクト:

MXINVOICE オブジェクト構造では、請求書情報を双方向で同期でき、ステータス変更がサポートされます。



表 9. アウトバウンド統合処理用の請求書オブジェクトの事前定義コンポーネント



パブリッシュ・チャネル MXINVOICEInterface - 処理ルールを使用します。完全な請求書ドキュメントは、ステータス変更の場合にのみ送信されます。

処理ルール 1. SKIPINVOICE - 以下の条件が両方とも満たされている場合には、ドキュメントの送信をスキップします。


v 新しいステータスが IVSEND コントロールに一覧されていません。

2. SKIPINVIOCEUPDATE - 更新されたがステータスは変更されない場合、ドキュメントの送信をスキップします。

3. SETSTATUSIFACE - IVSEND コントロールに一覧されている値を除き、すべてのステータス値について STATUSIFACE フィールドの値を 0 (False)

に設定します。

4. CHECKSTATUS – ステータスが変更され、新しいステータスが IVSEND

コントロールに存在しない場合、請求書ヘッダー・データのみを送信します。(この場合は完全なドキュメントが以前に送信されており、これで送信されるのはステータス変更通知のみです。)

統合コントロール IVSEND




表 10. インバウンド統合処理用の請求書オブジェクトの事前定義コンポーネント事前定義された統合コンポーネント値および説明

オブジェクト構造の処理クラス機能インバウンド処理では、以下のいずれかの条件を満たす場合にのみ、INVOICECOST 行が作成および更新されます。

v 請求書明細が注文書明細を参照していない。

v 対応する注文書明細に分配がない。

v 注文書明細が保管場所を参照していない。

その他のすべての場合には、インバウンド処理による請求書の作成または更新時に、INVOICECOST 情報は無視されます。

インバウンド・メッセージに INVOICETERMS があると、インバウンド処理によって以前の条件は削除され、新しい条件が追加されます。

請求書照合を外部システムで実行し、外部システムで判別された価格差異を送信して差異トランザクションを作成し、作業指示書および保管場所を更新した場合、ユーザーは、各請求書明細の PRICEVAR フィールドに価格差異をオプションで指定できます。これらの差異を処理するには、インバウンド請求書に OWNERSYSID の値が存在する必要がありますが、その値を MAXVARS.MXSYSID の値と同じにすることはできません。

請求書照合を外部システムで実行し、外部システムで判別された価格差異を送信して差異トランザクションを作成し、作業指示書および保管場所を更新した場合、ユーザーは、各請求書明細の PRICEVAR フィールドに価格差異をオプションで指定できます。これらの差異を処理するには、インバウンド請求書に OWNERSYSID の値が存在する必要がありますが、その値を MAXVARS.MXSYSID の値と同じにすることはできません。

IVMATCH コラボレーション・スイッチには、以下の値が必要です。

v OWNER1SYSID 値は、常に「THISMX」にする。

v OWNER2SYSID 値は、INVOICE.OWNERSYSID の値にする。

評価結果が false である場合、明細レベルの請求書差異は請求書処理時に無視されます。

以下は、請求書インターフェースを使用する場合の代表的なシナリオです。

v システムでの請求書照合 (AP アウトバウンド): サード・パーティーから電子的に、または手動で受け取った請求書がシステムによって処理されます。つまり、請求書は (該当する場合) 受領書と照合された後に承認されます。あるいは、システムで作成された支払い予定により、スケジュールに基づいて作成される承認済みの請求書が得られます。これらの承認済み請求書により、支払い通知が外部 AP システムに送信されることになります。照合の処理により、会計項目が GL に記入されることにもなります。

v 外部システムでの請求書照合 (差異インバウンド): システムは請求書処理を実行しませんが、外部システムからの照合済み請求書を受け入れて、差異をそれぞれの作業指示書、保管場所などに戻して適用します。支払勘定または差異あるいはその両方に関連する会計項目は、外部システムに記録する必要があります。これらは送信されません。

このインターフェースの主な目的は、作業指示書コストを更新するのに必要なすべての差異情報をシステムに入力することです。

パブリッシュ・チャネル MXINVOICEInterface




以下の表に、考えられる INVOICE.OWNERSYSID 値の例、生成される評価、および評価のデフォルトの結果を示します。

表 11. 評価の例

INVOICE.OWNERSYSID

の値評価結果 (デフォルト)

Null OWNER1SYSID=”THISMX”および OWNER2SYSID=”THISMX” False

MXSYSID OWNER1SYSID=”THISMX”および OWNER2SYSID=”THISMX” False

EXTSYSID OWNER1SYSID=”THISMX”および OWNER2SYSID=”EXT” True

その他の値 OWNER1SYSID=”THISMX”および OWNER2SYSID=”EXT” True

作業指示書インターフェースに対するアウトバウンド処理ルール:

購買ドキュメント・インターフェースとは異なり、作業指示書ドキュメント・インターフェースには STATUSIFACE フィールドが存在せず、ステータス変更通知も送信されません。作業指示書ドキュメント・インターフェースは、作業指示書のステータスが WOSTART に変更されたときに初めて送信され、その後は更新されるたびに、作業指示書のステータスとは関係なく送信されます。

ユーザーは、WOSTART コントロールの開始値を構成できます。コントロールに指定するステータスは MAXVALUE 以外の値です。 1 つのステータスに複数のシノニム値が存在する場合は、該当するすべてのシノニムを列挙してください。

作業指示書オブジェクト:

MXWO オブジェクト構造では、作業指示書情報を双方向で同期でき、ステータス変更もサポートされます。

目的

システムは、WOSTART コントロールのステータスに到達したときに初めて作業指示書を送信し、その後は更新されるたびに送信します。作業指示書ドキュメントは、常に全体が送信されます。

作業指示書インターフェースには、作業指示書に関してシステムにより定義されたすべての情報が格納されていますが、プロジェクトに関する追加情報や、標準の作業指示書の一部ではない、会計管理データ、設備、およびロケーションの情報は提供されません。必要な場合は、ユーザー・フィールドを介して情報を追加できます。

システムは、作業指示書タスクを作業指示書として処理します。これらには、両方とも似た特性があり、同じテーブルに格納されています。ユーザーが作業指示書を作成し、タスク/下位階層作業指示書を作業指示書に追加して、作業指示書を承認すると、作業指示書の「ステータスの変更を継承」フラグに、作業指示書の承認によって、その特定の作業指示書のすべてのタスク/下位階層作業指示書も承認されるかどうかが示されます。デフォルトは「Y」であるため、作業指示書を承認すると、このフラグに基づいて上位階層の承認を継承するすべての下位階層タスクまたは作業指示書も承認されます。


作業指示書 MBO のアウトバウンド・イベント・リスナーは、複数の独立したイベントを作業指示書ごとに 1 つずつ受信します。これらのイベントは、それぞれ単独で処理され、送信されます。このため、3 つのタスクと 2 つの下位階層作業指示書がある作業指示書は、6 つの独立したアウトバウンド作業指示書になります。



表 12. アウトバウンド統合処理用の作業指示書オブジェクトの事前定義コンポーネント



なし

パブリッシュ・チャネル MXWOInterface - 処理ルールを使用します。完全な作業指示書ドキュメントは、ステータス変更の場合にのみ送信されます。

処理ルール SKIPWO - 以下の条件が両方とも満たされている場合には、ドキュメントの送信をスキップします。


v 新しいステータスは WOSTART コントロールに一覧されていません。

統合コントロール WOSTART



表 13. インバウンド統合処理用の作業指示書オブジェクトの事前定義コンポーネント



StatefulMicSetIn - ステータス変更をサポートする汎用クラス。

パブリッシュ・チャネル MXWOInterface



作業指示書詳細オブジェクト:

MXWODETAIL オブジェクト構造では、計画資材、作業員、サービス、工具などの作業指示書情報を双方向に同期できます。

目的

システムは、WOSTART コントロールのステータスに到達したときに初めて作業指示書を送信し、その後は更新されるたびに送信します。作業指示書ドキュメントは、常に全体が送信されます。


予約 MBO (INVRESERVE) を取得するときに使用する MBO 関係は、作業指示書管理アプリケーションで使用される関係とは異なります。このため、XML の変更された属性は、この MBO からの値に対しては設定されません。



表 14. アウトバウンド統合処理用の作業指示書詳細オブジェクトの事前定義コンポーネント



MoutWORsvProcess - invreserve MBO の sendersysid 列を更新するために必要なコードを指定します。

パブリッシュ・チャネル MXWODETAILInterface - 処理ルールを使用します。計画情報付きの完全な作業指示書ドキュメントは、ステータス変更の場合にのみ送信されます。







表 15. インバウンド統合処理用の作業指示書詳細オブジェクトの事前定義コンポーネント



なし




作業指示書階層オブジェクト:

MXWOHIER オブジェクト構造では、下位階層作業指示書などの作業指示書情報を双方向で同期でき、ステータス変更もサポートされます。システムは、WOSTART

コントロールのステータスに到達したときに初めて作業指示書を送信し、その後は更新されるたびに送信します。作業指示書ドキュメントは、常に全体が送信されます。




表 16. アウトバウンド統合処理用の作業指示書階層オブジェクトの事前定義コンポーネント



なし

パブリッシュ・チャネル MXWOHierInterface - 下位階層 MBO が上位階層 MBO を介して送信される場合に下位階層 MBO の送信を防止するイベント・フィルター・クラスである WOHierarchyEventFilter が格納されています (この場合は、上位階層 MBO と下位階層MBO が同じイベント・アクションによって開始されます)。







表 17. インバウンド統合処理用の作業指示書階層オブジェクトの事前定義コンポーネント



MaxWOHierarchyProcess - ステータス変更およびコミット処理をサポートし、複数の関連作業指示書を単一のメッセージに読み込むことをサポートします。

パブリッシュ・チャネル MXWOHierInterface



トランザクション・インターフェース・オブジェクト統合フレームワークでは、受領、GL トランザクション、作業時間レポート、計測値などのトランザクション・インターフェース・オブジェクトの事前定義統合コンテンツを選択できます。

資材およびサービスの受領オブジェクト:

MXRECEIPT オブジェクト構造では、資材およびサービスの受領についての注文書受領情報の双方向同期を行うことができます。また、ステータス変更をサポートします。このオブジェクト構造では、非永続オブジェクトを使用して、資材(MATRECTRANS) とサービス (SERVRECTRANS) の両方の受領をサポートします。


目的

アウトバウンド方向において、このオブジェクト構造は、注文書の受領、移動 (受領に対する移動、または内部注文書に対する受領)、および返却 (受領検査後の販売元への返却、または受け入れおよび商品移動後の検査保持ロケーションから販売元への返却) を処理します。

検査を必要とする受領では、ユーザー定義フィールド INSPECTED により、受領明細が外部システムで検査されたかどうかが示されます。このインターフェースは、移動を単独で処理するわけではありません。各移動は、受領に関連付けられています。

インバウンド受領が、資材受領であるのか、サービス受領であるのかを指定する必要はありません。統合処理は、POLINE を使用して判別を行います。

すべての数量 (返却数量を含む) は、正数である必要があります。

2 つのタイプの移動レコードは、RECEIPTREFID フィールドの以下の値で識別できます。

v NULL: 内部注文書に対する受領

v NULL 以外: 受領に対する移動

返却の場合、RECEIPTFREF の値は指定しないでください。返却は、対応する受領とは切り離して処理されます。




表 18. アウトバウンド統合処理用の受領オブジェクトの事前定義コンポーネント



MoutProcess - 出庫タイプ RECEIPT または RETURN の受領を処理します。出庫タイプが指定されていない場合、RECEIPT として処理されます。

RECEIPT 出庫タイプで「検査が必要」= N の場合の処理:

資材受領およびサービス受領:

v インバウンド RECEIPTQUANTITY (資材受領の場合) または QTYTORECEIVE (サービス受領の場合) を使用して受領を作成します。

v インバウンド REJECTEDQTY を、受領における REJECTEDQTY フィールドにマップします。

v 他の数量は無視します。

v インバウンド INSPECTED フィールドは確認しません。

資材受領 (MATRECTRANS レコード):

v RECEIPT および RETURN タイプのレコードと、PONUM が含まれる TRANSFER タイプのレコード (保管場所移動ではない) のみを送信します。新規の受領のみを送信し、既存の受領は更新しません。

サービス受領 (SERVRECTRANS レコード):

v RECEIPT および RETURN タイプのレコードを送信します。新規の受領を送信し、既存の受領を更新します。


MXRECEIPTInterface

処理ルールサービス受領:

ステータスが SERVRECSTAT コントロールの値と同じ場合にレコードを送信します (デフォルト COMP)。これは、以下の条件に該当する場合に発生します。

v 検査を必要としないレコードが挿入されている。

v 既存のレコードがデータベース内で更新され、ステータス・フィールドが COMP に変更されている。

統合コントロール SERVRECSTAT コントロールは、システムがサービス受領トランザクションを送信する条件となるすべてのステータスを識別します。複数の値である場合があります。デフォルトでは、値は COMP です。




表 19. インバウンド統合処理用の受領オブジェクトの事前定義コンポーネント事前定義された統合コンポーネント値および説明

オブジェクト構造の処理クラス機能 MaxRCVProcess -

RECEIPT 出庫タイプで「検査が必要」= Y の場合の処理:

資材受領:

INSPECTED = N の場合:

v インバウンド RECEIPTQUANTITY フィールドのみを使用して受領を作成します。容認および拒否された数量値は無視します。

v STATUS = WINSP (検査待ち) であり、RECEIPTQUANTITY から導出された数量を持つ受領を作成します。

INSPECTED = Y の場合:

v インバウンド RECEIPTQUANTITY、ACCEPTEDQTY、および REJECTEDQTY フィールドを使用して受領を作成します。

v 部分的な検査または受け入れは許可しません。RECEIPTQUANTITY は、ACCEPTEDQTY +

REJECTEDQTY と等しい必要があります。

v STATUS = WASSET (ローテーション部品の場合) または COMP (その他すべての部品の場合) を持つ受領を作成します。

v 指定されている数量に応じて、最大 3 つのトランザクション (RECEIPT、TRANSFER、およびRETURN) を作成できます。

サービス受領:

INSPECTED = N の場合:

v インバウンド AMTTORECEIVE (POLINE 注文数量が NULL の場合) または QTYTORECEIVE (他のすべての場合) を使用して受領を作成します。他のすべての数量値は無視します。

v STATUS = WINSP (検査待ち) であり、QTYTORECEIVE から導出された数量を持つ受領を作成します。

INSPECTED = Y の場合:

v インバウンド QTYTORECEIVE、ACCEPTEDQTY、および REJECTEDQTY フィールドを使用して受領を作成します。

v 部分的な検査または受け入れは許可しません。QTYTORECEIVE は、ACCEPTEDQTY +

REJECTEDQTY と等しい必要があります。

v STATUS = COMP である RECEIPT タイプの単一トランザクションを作成します。

RETURN 出庫タイプの処理:

資材受領およびサービス受領:

v 同じ明細の以前の受領が存在していた場合のみ、POLINE の返却トランザクションを受け入れます。POLINE について「検査が必要」= Y である場合、受領が承認されている必要があります。承認されていない場合、エラーが報告されます。

v インバウンド RECEIPTQUANTITY (資材受領の場合) または QTYTORECEIVE (サービス受領の場合) フィールドのみを使用して受領を作成します。他のすべての数量値は無視します。

v 出庫タイプが RETURN であり、RBNI 勘定として GL 貸方勘定科目を持つ単一トランザクションを作成します。

パブリッシュ・チャネル MXRECEIPTInterface




資材およびローテーション部品受領オブジェクト:

MXRCVROTITM オブジェクト構造では、部品 (ローテーション部品など) の受領情報のインバウンド同期を行うことができます。

目的

このオブジェクト構造は、インバウンド処理のみをサポートします。

このインターフェースでは、受領のステータスを指定する必要はありません。ステータスは、常に COMP と認識されます。

このインターフェースは、資材受領を排他的に処理し、ユーザーはローテーション部品の受領時に作成される連続ローテーション資産を識別できるため、MXRECEIPTInterface とは異なります。

資産番号のあるローテーション部品を受領することも、資産番号がないローテーション部品を受領することもできます。資産番号がないローテーション部品を受領する場合、購買受領アプリケーションの「ローテーション部品の受領」ダイアログ・ボックスを使用して、資産番号を手動で指定する必要があります。

ローテーション部品では、インバウンド・トランザクションの数は、ローテーション部品の数より 1 つ大きい数になります。合計受領数量のために 1 つのトランザクションが存在し、受領に関連付けられたローテーション部品ごとに 1 つのトランザクションが存在します。例えば、10 個のローテーション部品の受領では、11 個のトランザクションが存在します。



表 20. アウトバウンド統合処理用の資材およびローテーション部品受領オブジェクトの事前定義コンポーネント









表 21. インバウンド統合処理用の資材およびローテーション部品受領オブジェクトの事前定義コンポーネント


オブジェクト構造の処理クラス機能 MaxRcvRotItmMProcess - 処理される注文書明細が LINETYPE = SERVICE または STDSERVICE である場合、エラーを報告します。

処理は、MXRECEIPTInterface を使用した資材受領でのインバウンド統合ポイント処理クラスの機能と同じですが、以下の追加処理があります。

v 受領: 明細項目がローテーション部品であり、「検査が必要」= N またはINSPECTED = Y である場合、処理では、インターフェースで指定されている項目に対応する資産情報を検査します。情報が使用可能である場合、処理では、資産レコードの数を検証し、この数が RECEIPTQTY またはACCETPTEDQTY (いずれか該当する方) と同じであることを確認します。数が同じである場合、受領機能を呼び出し、必要に応じて資産を作成します。

v 返却: 返却対象の部品がローテーション部品である場合、資産情報は無視されます。

システムにおいて、ローテーション・タイプの部品の返却は、元の受領により作成された資産に影響しません。資産レコードは変更されないままになります。部品の在庫量のみ更新されます (該当する場合)。

パブリッシュ・チャネル MXRCVROTITMInterface



総勘定元帳 (GL) オブジェクト:

MXGLTXN オブジェクト構造では、GL トランザクションのアウトバウンド同期を行うことができます。このインターフェースにより、サイト・レベルのトランザクションを外部 GL アプリケーションに送付して、会計上の差分検出を実施できます。

目的

このインターフェースは、以下のサブレコードのデータとともに非永続 MBO を使用します。

v SERVRECTRANS

v MATRECTRANS

v INVTRANS

v INVOICETRANS

v MATUSETRANS

v LABTRANS

v TOOLSTRANS

イベント・フィルター・クラス GLEventFilter を使用して、イベントを、リストされた適用可能な永続オブジェクトに設定します。


SOURECEMBO フィールドは、トランザクションが発生する元となったデータベース表を識別します。その値は、GLSOURCEMBO シノニム・ドメインから導出されます。



表 22. アウトバウンド統合処理用の GL オブジェクトの事前定義コンポーネント事前定義された統合コンポーネント値説明


MoutGLProcess - サービス受領

サービス受領には、以下の項目が含まれます。

v 注文書で注文されたサービスについて、受領アプリケーションにより作成された非配布サービス受領の勘定項目 (ISSUETYPE = RECEIPT、COSTINFO=1)

v 注文書で注文されたサービスについて、受領アプリケーションにより作成された配布サービス受領の勘定項目 (ISSUETYPE = POCOST)

v 受領の代わりに直接請求される、「受領書が必要」= N である注文書サービスの勘定項目 (ISSUETYPE = INVOICE)

v 注文書に対するサービスの勘定項目ではなく、直接請求されるサービスの勘定項目(ISSUETYPE = INVOICE)

v サービス受領に対して記録される請求書差異のトランザクション (ISSUETYPE =

INVOICE)

サービス受領 (SERVRECTRANS) 処理:

v SOURCEMBO を SERVRECTRANS に設定し、ISSUETYPE を、リストされた値に設定します。

v INVOICE タイプ・トランザクション: 挿入時に送信されます。

v POCOST および RECEIPT タイプ・トランザクション: 対応する POLINE について「検査が必要」= N である場合、挿入時に送信されます。「検査が必要」= Y である場合、ステータスが COMP に変更されたときに送信されます。


表 22. アウトバウンド統合処理用の GL オブジェクトの事前定義コンポーネント (続き)

事前定義された統合コンポーネント値説明

MoutGLProcess - 資材受領

資材受領には、以下のものが含まれます。

v 注文書で注文された部品/工具について、受領アプリケーションにより作成された非配布資材受領の勘定項目 (ISSUETYPE = RECEIPT、COSTINFO=1)

v 注文書で注文された部品/工具について、受領アプリケーションにより作成された配布資材受領の勘定項目 (ISSUETYPE = POCOST)

v 保管場所間の部品の移動の勘定項目 (ISSUETYPE = TRANSFER およびPONUM=NULL)

v 受領検査保管場所と注文書明細保管場所の間での部品の受領検査移動についての勘定項目 (ISSUETYPE = TRANSFER、RECEIPTREF!=NULL、および PONUM!=NULL)

v 内部注文書に対する受領の勘定項目 (ISSUETYPE =

TRANSFER、RECEIPTREF=NULL、および PONUM!=NULL)

v 部品および資材の受領検査商品返却の勘定項目 (ISSUETYPE = RETURN)

v 保管場所または直接出庫注文書明細から販売元への返却の勘定項目 (ISSUETYPE =

RETURN)

v 資材受領に対して記録される請求書差異のトランザクション (ISSUETYPE =

INVOICE)

v キットの作成時に、キット部品の INVENTORY 統括勘定値を増加させるための勘定トランザクション (ISSUETYPE = KITMAKE)。キットの分解時に、キットの各構成部品の INVENTORY 統括勘定を増加させるためのトランザクション (ISSUETYPE =

KITBREAK)。

資材受領 (MATRECTRANS) 処理:

v SOURCEMBO を MATRECTRANS に設定し、ISSUETYPE を、リストされた値に設定します。

v 挿入時に、INVOICE、RECEIPT、TRANSFER、RETURN、KITMAKE、およびKITBREAK タイプ・トランザクションが送信されます。

v POCOST タイプ・トランザクションでは、ステータスが COMP である場合の挿入時(「検査が必要」= N である場合の挿入時、および「検査が必要」= Y である場合のステータスの COMP への変更時) にトランザクションが送信されます。

MoutGLProcess - 在庫調整トランザクション

在庫調整トランザクションには、以下のものが含まれます。

v 現在の在庫量調整 (ITTYPE = CURBALADJ)

v 在庫の標準/平均コスト調整 (ITTYPE = STDCOSTADJ/AVGCOSTADJ)

v キットが分解され、キットの値とキット・コンポーネント値の合計が異なる場合の、コスト差異 (ITTTYPE = KITCOSTVAR)

v 実棚数の差分検出 (ITTYPE = RECBALADJ)

v 資産計上コスト調整 (ITTYPE = CAPCSTADJ)

v 標準単価受領調整 (ITTYPE = STDRECADJ)

在庫調整 (INVTRANS) 処理:

v SOURCEMBO を INVTRANS に設定し、ITTYPE を、リストされた値に設定します。

v ITTTYPE = INSERTITEM、CREATEASSET、および PHYSCNT であるトランザクションは、勘定トランザクションではなく監査レコードとして認識されるため、これらのトランザクションは送信されません。

v 挿入時に他のすべてのトランザクションが送信されます。


表 22. アウトバウンド統合処理用の GL オブジェクトの事前定義コンポーネント (続き)

事前定義された統合コンポーネント値説明

MoutGLProcess - 請求書トランザクション

請求書トランザクションには、請求書承認により作成された以下のトランザクションが含まれます。

v 請求書 TOTAL トランザクション (請求書の販売元に支払い可能な額、TRANSTYPE

= TOTAL)

v 請求書明細の税金トランザクション (請求書明細の各 TAX コードの税金勘定、TRANSTYPE = TAX1:TAX5)

v 請求通貨差異トランザクション (TRANSTYPE = CURVAR)

v 請求額差異トランザクション (TRANSTYPE = INVCEVAR)

請求書トランザクション (INVTRANS) 処理:

v SOURCEMBO を INVOICETRANS に設定し、TRANSTYPE を、リストされた値に設定します。

v 作成時にすべてのトランザクションが送信されます。

MoutGLProcess - 資材出庫と返却のトランザクション

資材出庫と返却のトランザクションには、以下のものが含まれます。

v システムにおいて保管場所から出庫された部品の勘定項目 (ISSUETYPE = ISSUE)

v 保管場所に返却された部品の勘定項目 (ISSUETYPE = RETURN)

資材出庫と返却 (MATUSETRANS) 処理:

v SOURCEMBO を MATUSETRANS に設定し、ISSUETYPE を、リストされた値に設定します。

v MATUSETRANS で注文書受領/請求書差異により作成される直接出庫トランザクションは、MATRECTRANS で計上されるため、これらのトランザクションは送信されません。このようなトランザクションは、PONUM により識別されるため、注文書参照があるすべての MATUSETRANS トランザクションは、このインターフェースでは送信されません。

v 作成時に他のすべてのトランザクションが送信されます。

MoutGLProcess - 作業員トランザクション

作業員トランザクション (LABRTRANS) 処理:

v SOURCEMBO を LABTRANS に設定します。

v 承認が必要ない場合、挿入時に作業指示書に対して作業時間実績が送信されます。

v 承認が必要な場合、承認後 (GENAPPSERVRECEIPT が Y) にトランザクションが送信されます。

MoutGLProcess - 工具トランザクション

工具トランザクション (TOOLTRANS) 処理:

v SOURCEMBO を TOOLTRANS に設定します。

v TOOLTRANS の作成時に、作業指示書の工具の用途が送信されます。


MXGLTXNInterface

処理ルール SKIPGL GLSOURCE 統括に存在する SOURCEMBO の値に基づいて、GL トランザクションの送信をスキップします。

統合コントロール GLSOURCE



表 23. インバウンド統合処理用の GL オブジェクトの事前定義コンポーネント




表 23. インバウンド統合処理用の GL オブジェクトの事前定義コンポーネント (続き)





作業時間レポート・オブジェクト:

MXEMPACT オブジェクト構造では、システムで報告されたサイト・レベルの実作業時間を外部アプリケーションに送信できます。ステータスにかかわらず、承認された作業時間実績が送信され、すべてのインバウンド作業時間実績が受け入れられます。インバウンド・トランザクションの処理時、既存レコードのステータスは更新されません。



表 24. アウトバウンド統合処理用の作業時間レポート・オブジェクトの事前定義コンポーネント



なし


MXEMPACTInterface

処理ルール SKIPEMPACT - トランザクションが承認されていない場合 (GENAPPRSERVRECEIPT =

0)、作業員支払の送信 (LABTRANS) をスキップします。

統合コントロール



表 25. インバウンド統合処理用の作業時間レポート・オブジェクトの事前定義コンポーネント


オブジェクト構造の処理クラス機能 MaxEmpactProcess - 追加アクションのみ許可します。NULL アクションは、追加アクションとして処理されます。 LABTRANSID は追加アクション中にプログラムにより生成されるため、値を指定して LABTRANSID を渡すことはできません。

パブリッシュ・チャネル MXEMPACTInterface




計測値オブジェクト:

MXMETERDATA オブジェクト構造では、計測値データのインバウンド同期を行うことができます。このオブジェクト構造は、インバウンド処理のみをサポートします。このインターフェースは、作業指示書タスクの計測値の処理はサポートしません。



表 26. アウトバウンド統合処理用の計測値オブジェクトの事前定義コンポーネント



なし


なし






表 27. インバウンド統合処理用の計測値オブジェクトの事前定義コンポーネント


オブジェクト構造の処理クラス機能 MaxMeterDataProcess - 処理クラスにより、以下の属性が指定されていることが検証されます。

v サイト ID

v 資産またはロケーション

v 計測値 ID または状態モニター・ポイント

v 計測値、計測日時、検査官

作業指示書が指定された場合、以下の処理が行われます。

v 計測ポイントが指定されている場合、処理クラスは、サイトおよび計測ポイントに対応する資産またはロケーション計測値を識別し、その資産またはロケーション計測値の計測値を作成します。

v 計測値が指定されている場合、資産またはロケーションが指定されている必要があります。両方が指定されている場合、処理クラスは、その計測値が資産に属すると認識し、それに従って計測値を処理します。資産またはロケーションの一方のみが指定されている場合、対応するエンティティーの計測値が更新されます。

作業指示書が指定されていない場合、以下の処理が行われます。

v 計測ポイントが指定されている場合、その計測ポイントの計測値が記録されます。

v 計測値が指定されている場合、資産またはロケーションが指定されている必要があります。両方が指定されている場合、処理クラスは、その計測値が資産に属すると認識し、それに従って計測値を処理します。資産またはロケーションの一方のみが指定されている場合、対応するエンティティーの計測値が更新されます。

パブリッシュ・チャネル MXMETERInterface



システム・オブジェクトシステム・オブジェクトは、通常、アプリケーションまたはメタデータの構成に使用される MBO です。システム・オブジェクトを使用したデータの更新には、特定のポストプロセッシング・アクティビティー (データベースの再構成など) が必要な場合があります。

エンタープライズ・サービス、パブリッシュ・チャネル、およびオブジェクト構造の使用には、以下の制限が適用されます。

v パブリッシュ・チャネルのリスナーを有効にすることはできません。

v インターフェース・テーブルまたはフラット・ファイルを介してシステム・インターフェースを処理することはできません。

v インバウンド・システム・インターフェースにアクション・コードを指定する必要があります。


オブジェクト構造オブジェクト:

MXINTOBJECT オブジェクト構造では、オブジェクト構造の定義 (カラム別名など)

のインバウンド同期を行うことができます。事前定義のオブジェクト構造を追加、削除、および変更するユーザーに適用されるシステム検証は、オブジェクト構造オブジェクト構造サービスを使用したオブジェクト構造の変更に適用されます。




オブジェクト構造の定義クラス機能 N/A

パブリッシュ・チャネル N/A






オブジェクト構造の処理クラス機能 N/A

エンタープライズ・サービス N/A



エンタープライズ・サービス・オブジェクト:

MXENTSRV オブジェクト構造では、エンタープライズ・サービスの定義、その対応する処理ルール、およびコントロール値のインバウンド同期を行うことができます。

前提条件

エンタープライズ・サービスの作成前に、エンタープライズ・サービスが使用するすべてのコントロールが存在することを確認してください。
















パブリッシュ・チャネル・オブジェクト:

MXIFACEOUT オブジェクト構造では、パブリッシュ・チャネルの定義、その対応する処理ルール、およびコントロール値のインバウンド同期を行うことができます。パブリッシュ・チャネルの作成前に、パブリッシュ・チャネルが使用するすべてのコントロールが存在することを確認してください。















エンドポイント・オブジェクト:

MXENDPOINT オブジェクト構造では、エンドポイントの定義のインバウンド同期を行うことができます。

前提条件

エンドポイントの作成前に、エンドポイントが使用するハンドラーが存在することを確認してください。
















外部システム・オブジェクト:

MXEXTSYSTEM オブジェクト構造では、外部システムの定義、外部システムが使用するエンタープライズ・サービスとパブリッシュ・チャネル、およびその対応するコントロール値のインバウンド同期を行うことができます。

前提条件

外部システムの作成前に、外部システムが使用するすべてのエンタープライズ・サービス、パブリッシュ・チャネル、エンドポイント、およびコントロールが存在することを確認してください。

















統合コントロール・オブジェクト:

MXIFACECONTROL オブジェクト構造では、統合コントロールおよびシステム・レベルのデフォルト値のインバウンド同期を行うことができます。















呼び出しチャネル・オブジェクト:

MXIFACEINVOKE オブジェクト構造では、呼び出しチャネル定義のインバウンド同期を行うことができます。
















統合キュー・オブジェクト:

MXQUEUE オブジェクト構造では、統合キュー定義のインバウンド同期を行うことができます。















メッセージ定義オブジェクト:

MXMESSAGE オブジェクト構造では、システム・エラーおよび警告メッセージのインバウンド同期を行うことができます。

前提条件

このオブジェクト構造を使用して追加される新規メッセージに加えて、messages.xml ファイルが対応するメッセージ・テキストで更新されている必要があります。
















MBO 構成オブジェクト:

MXOBJECTCFG オブジェクト構造では、MBO 定義情報のインバウンド同期を行うことができます。

前提条件

このオブジェクト構造を使用する際は、注意が必要です。

このオブジェクト構造を使用してインバウンド・データを同期する場合は、追加、追加変更、または変更のいずれかのアクション・コードのみを使用します。MAXOBJECTCFG データおよび MAXATTRIBUTECFG データを完全に置き換える場合を除き、置換アクションは使用しないでください。

削除アクションでは、MAXOBJECTCFG および MAXATTRIBUTECFG の MBO に関連付けられているデータベース表にある事前定義レコードを削除してしまうリスクがあります。

CHANGED、EAUDITENABLED、EAUDITFILTER、EAUDITTBNAME、IMPORTED、STORAGEPARTITION、および MAXOBJECTID の各列にはインバウンド設定制限があるため、MBO に対して XML 値が設定されることはありません。

このインターフェースを使用してインバウンド・データを同期した後、変更内容を有効にするには、データベース構成アプリケーションを使用して、「構成変更の適用」アクションを選択します。












オブジェクト構造の処理クラス機能 psdi.iface.app.configure.MaxObjcfgProcess -

MAXOBJECTCFG がビュー(MAXOBJECTCFG.VIEW=1) を作成している場合、処理クラスは、参照されているMAXOBJECTCFG に関連付けられたすべての MAXATTRIBUTECFG MBO をスキップします。

また、このクラスは、関連付けられているすべての属性がデータベースに正常に追加されるまで、MAXOBJECTCFG での SAVE 検証を遅らせます。




ドメイン・オブジェクト:

MXDOMAIN オブジェクト構造では、ドメイン情報のインバウンド同期を行うことができます。

目的

データベース内の一部のフィールドは、値の選択一覧に関連付けられています。これらの定義された値の一覧は、ドメイン (値一覧と呼ばれることもあります) として知られています。

このオブジェクト構造は、ALN、数値、数値範囲、テーブル、およびクロスオーバーの各ドメイン定義を同期します。

前提条件

更新および削除の操作では、外部システムが有効な DOMAINID 値を指定している必要があります。
















通信テンプレート・オブジェクト:

MXCTEMPLATE オブジェクト構造では、通信テンプレートの双方向同期を行うことができます。ユーザーは、この通信テンプレートを利用して、頻繁に使用される電子メール通信および電子メール通知を標準化できます。

目的

通信テンプレートとは、特定のノードが現行ノードになった場合、またはノード間で指定されているワークフロー・ルーティング・パスに達した場合に処理される、件名、メッセージ、および受信者の各情報が含まれるメール・メッセージの定義です。

このオブジェクト構造は、アプリケーション、ステータス変更、カスタム・クラス、コマンド・ライン、および値設定の各アクションを同期しますが、アクション・グループは同期しません。

前提条件

更新および削除の操作では、外部システムが有効な ACTIONID 値を指定している必要があります。

このオブジェクト構造は、アクション・グループの作成はサポートしません。







パブリッシュ・チャネル MXCTEMPLATEInterface










アクション定義オブジェクト:

MXACTION オブジェクト構造では、エスカレーション、サービス・レベル契約(SLA)、およびワークフロー・プロセスで使用できるワークフロー・アクション定義のインバウンド同期を行うことができます。

目的

アクションとは、エスカレーション・ポイント、サービス・レベル契約、またはワークフロー・プロセスで定義された条件に一致するレコードが検出されたときに、トリガーされるイベントのことです。次の動作を指定できます。

このオブジェクト構造は、アプリケーション、ステータス変更、カスタム・クラス、コマンド・ライン、および値設定の各アクションを同期しますが、アクション・グループは同期しません。

前提条件

更新および削除の操作では、外部システムが有効な ACTIONID 値を指定している必要があります。

このオブジェクト構造は、アクション・グループの作成はサポートしません。
















システム・プロパティー・オブジェクト:

MXPROP オブジェクト構造では、システム・プロパティーおよび値のインバウンド同期を行うことができます。

目的

前提条件















統合モジュール・オブジェクト:

MXIM オブジェクト構造では、統合モジュール定義 (プロパティーおよび LMO 関係など) のインバウンド同期を行うことができます。
















論理管理操作 (LMO) オブジェクト:

MXLMO2 オブジェクト構造では、LMO (属性など) のインバウンド同期を行うことができます。
















運用管理製品 (OMP) オブジェクト:

MXOMP オブジェクト構造では、OMP (CI との関係、IM と LMO での構成など)

のインバウンド同期を行うことができます。















起動エントリー・オブジェクト:

MXLAUNCH オブジェクト構造では、起動エントリーおよびコンテキスト情報のインバウンド同期を行うことができます。

















データのロード順序統合フレームワークを使用して複数のデータ・セットをアプリケーション・データベースにロードする場合は、データが正常にロードされるように依存関係を維持する必要があります。以下の事前定義オブジェクト構造の順序を指針として使用して、データをロードする順序を決定します。

オブジェクト構造MXGLCOMP

MXCOA

MXVENDORMSTR

MXVENDOR

MXPERSON

MXPERUSER

MXCRAFT

MXLABOR

MXSTORELOC

MXCLASSIFICATION

MXITEM

MXINVENTORY

MXINVBAL

MXINVVENDOR

MXSERVITEM

MXPROJ

MXASSET

MXWO

MXWODETAIL

MXWOHIER

MXINVRES

MXEMPACT

MXINVISSUE

MXGLTXN

MXTOOLITEM

MXPC

MXMETERDATA

MXPR

MXPO

MXRECEIPT

MXRCVROTITM


MXINVOICE

システム・オブジェクト構造MXINTOBJECT

MXIFACECONTROL

MXENTSRV

MXIFACEOUT

MXENDPOINT

MXQUEUE

MXEXTSYSTEM

MXIFACEINVOKE

MXIM

MXLMO2

MXOMP

MXLAUNCH

MXMESSAGE

MXOBJECTCFG

MXDOMAIN

MXCTEMPLATE

MXACTION

MXPROP

統合データ処理統合要件を満たす統合コンポーネントの構成には、さまざまな方法があります。複数の外部アプリケーションとの統合が可能ですが、各アプリケーションは、そのアプリケーションが提供する統合サポートに応じて異なる方法で統合する必要があります。

統合のためのデータ処理の計画統合トランザクションを開始する前に、使用する統合コンポーネントを決定しなければなりません。また、外部の宛先と正常に統合できるように、コンポーネントの実装方法を計画することも必要です。

使用するコンポーネントとその実装方法の選択は、統合に使用する外部アプリケーションによって決まる場合がよくあります。選択の際には、以下の点を検討します。

データ型該当のデータ (例えば、作業指示書および担当者データ) を定義してください。定義が完了したら、各データ・セットをサポートするオブジェクト構造が事前に定義されているか、あるいは追加のオブジェクト構造を作成する必要があるかを判断します。

方向各データ・セットについて、実装しようとしている統合シナリオの方向は何


か (送信用のアウトバウンド・トランザクションか、受信用のインバウンド・トランザクションか、あるいはその両方か)? 統合の方向は、データ・セットごとに異なる場合があります。

メッセージ交換これは外部アプリケーションの機能に応じて異なります。オプションには、ファイル (XML またはフラット) を使用したデータの統合、Web サービスの呼び出し、HTTP 経由での XML のポストを含めることができます。データ交換のメソッドとそれを実行する頻度は、データ・セットによって異なる場合があります。

カスタマイズデータの交換に伴い、メッセージ内容を変換するため、あるいは統合ビジネス・ルールを適用するために、アプリケーション内でカスタマイズが必要か?カスタマイズが必要な場合は、カスタマイズで統合フレームワークの機能 (Java 出口クラス、自動化スクリプト、XSL マップ、処理ルールなど)

を使用するか、それとも外部アプリケーションでカスタマイズを実装するか?

これらの問いに対する回答に応じて、異なるタイプのコンポーネントおよび API 構成が必要になります。構成には以下を含めることができます。


v パブリッシュ・チャネルと呼び出しチャネル

v エンタープライズ・サービス

v オブジェクト構造サービス、エンタープライズ・サービス、および標準サービス

v Web サービス

v REST API および OSLC

v 外部システム


インバウンド・データ処理統合フレームワークは、オブジェクト構造サービス、エンタープライズ・サービス、または標準サービスという種類のサービスで、インバウンド統合メッセージの非同期処理および同期処理をサポートします。

非同期処理の場合、外部システムはメッセージが JMS キューに渡されるまで接続を確立および維持します。同期処理の場合、外部システムはメッセージ処理が完了するまで接続を確立および維持します。

インバウンド・メッセージの非同期処理インバウンド・メッセージの非同期処理中に、外部アプリケーションは、エンタープライズ・サービスを呼び出し、メッセージが JMS キューに保存されて接続が終了するまで、その接続を維持します。メッセージのキューへの保存中にエラーが発生した場合、外部アプリケーションがメッセージの再処理を行います。


非同期処理は、連続 JMS キューまたは継続中の JMS キューによって管理されます。連続キュー内での処理は、先入先出法に基づくメッセージの配信の順序を保証します。継続中のキュー内での処理では、メッセージは任意の順序で配信されます。

エンタープライズ・サービスを使用して、以下のトランザクションをサポートすることができます。

v フラット・ファイルまたは XML ファイルからのデータのインポート

v インターフェース・テーブルからのデータのロード

v HTTP POST 要求からの XML メッセージの受信

v JMS キューを使用するように構成されている Web サービスの呼び出し

v EJB の呼び出し

v 直接 JMS 接続の使用

これらのオプションはいずれも、統合メッセージが JMS キューに渡される場合のエンタープライズ・サービスの使用をサポートしています。メッセージがキューに入れられると、クーロン・タスクまたはメッセージ駆動型 Bean (MDB) を使用する別個のプロセスがそのメッセージをキューから取り出します。その後メッセージは、エンタープライズ・サービス層 (関連するオブジェクト構造層) を介して処理され、ビジネス・オブジェクトが更新されます。メッセージは JMS キューを介して処理されるため、サービスを呼び出すアプリケーションに対して応答は送信されず、この処理モデルではクエリー操作がサポートされません。

インバウンド・メッセージの同期処理同期インバウンド統合は、オブジェクト構造サービス、エンタープライズ・サービス、または標準サービスを使用して実装することができます。これらのトランザクションでは、トランザクションの期間中、外部アプリケーションから統合フレームワークへの直接接続を確立して維持することが必要です。

外部アプリケーションは、Maximo データベースでビジネス・オブジェクトが更新されるまで、またはクエリー操作に応答してビジネス・オブジェクトが返されるまで、サービスに対する接続を維持します。統合フレームワークは、メッセージ処理の成否を確認する応答を外部アプリケーションに返します。

以下のオプションは、同期統合メッセージをサービスに送信するために使用できます。

v HTTP の使用による XML メッセージのポスト

v JMS キューをバイパスするように構成されている Web サービスの開始

v EJB の開始

オブジェクト構造サービスおよびエンタープライズ・サービスでは、これらの 3 つのオプションをどれでも使用して、作成、更新、削除、同期、およびクエリーの各操作をサポートできます。

REST API または OSLC REST API を使用して、統合オブジェクト構造、標準サービス、およびアプリケーション・ビジネス・オブジェクトにアクセスすることもできます。

関連概念:



インバウンド・データの非同期処理の開始統合処理を開始するため、外部システムは、サポートされているいずれかの方法を使用して接続を確立します。外部システムおよびエンタープライズ・サービスが検証された後、メッセージは、エンタープライズ・サービスに指定された JMS キュー内に置かれます。

初期接続を確立するための手順は、トランザクションに使用する統合方法によって異なります。以下の表では、使用可能な方法と、これらの方法で使用される接続について説明します。

方法接続手順

HTTP または HTTPS

POST メソッド以下の URL を使用します。

hostname:port/meaweb/esqueue/extsysname/entservname。ここで、

v extsysname は外部システムの名前です。

v entservname はエンタープライズ・サービスの名前です。

EJB 以下のコードを使用して、Java Platform, Enterprise Edition クライアントから EJB を開始します。

public byte{} processExternalDataAsync(byte[] extData,

String serviceName, String sender)

クライアントでは、Enterprise JavaBean の JNDI 名ejb/maximo/remote/enterpriseservice を指定して Enterprise

JavaBean 参照のルックアップおよびメソッドの開始を行うことができます。Java プラットフォーム、Enterprise Edition クライアント上では、以下の構成が必要です。

v Home および Remote クラス・ファイルへのアクセス

v サーバーの Java プラットフォーム、Enterprise Edition JAR ファイルへのアクセス

v Enterprise JavaBean をホストするサーバーの URL

v コンテキスト・ファクトリーのクラス名

クライアント・コードは、デフォルトの IntialContext オブジェクトをインスタンス化する必要があります。コンテキストは、プロバイダーの URL およびコンテキスト・ファクトリーを環境から取得します。

XML またはフラット・ファイルを使用するデータのインポート機能

ユーザーがアプリケーションの「データのインポート」をクリックします。


方法接続手順

データのインポート・クーロン・タスク

XMLFILECONSUMER クーロン・タスクまたはFLATFILECONSUMER クーロン・タスクが、データのインポート用に構成されているソース・ディレクトリーをポーリングします。

インターフェース・テーブル

外部システムがメッセージ・データを該当のインターフェース・テーブルに書き込み、インターフェース・テーブル内のレコードを処理する順序に関する情報を使用して MXIN_INTER_TRANS キュー・テーブルを更新します。

クーロン・タスクは、処理されるレコードがあるか確認するためにMXIN_INTER_TRANS キュー・テーブルをポーリングします。

Web サービス外部システムは、JMS キューをバイパスしないように構成されている Web サービスとしてデプロイされたエンタープライズ・サービスを開始します。

JMS 直接外部システムは、WebSphere MQ などの別のキューイング・システムから JMS キューに直接 XML メッセージを渡します。

接続が確立されるか、クーロン・タスクが実行されてデータのインポート準備が完了していることが確認されると、以下の手順が実行されます。

1. 統合フレームワークは外部システムとエンタープライズ・サービスが有効で使用可能であるか検査します。

2. メッセージがフラット・ファイル形式である場合、統合フレームワークはオブジェクト構造がフラット構造をサポートしていることを検査します。

3. 検査が失敗すると、統合フレームワークは送信者にエラーを通知して、データを処理しません。

4. 検査が正常に行われると、統合フレームワークはエンタープライズ・サービスに割り当てられたインバウンド用の JMS キューを識別して、メッセージをキューに書き込みます。

5. 統合フレームワークは外部システムおよびエンタープライズ・サービスの名前を使用して JMS メッセージ・ヘッダーを更新します。

レコードの複数インスタンスを含むトランザクションにエラーが発生した場合、エラー処理は、使用されている交換方法によって異なります。交換タイプに応じて、以下のエラー処理が実行されます。

v HTTP または EJB トランザクションの場合のみ: 1 つのトランザクションに 1

つのドキュメントの複数のインスタンスが含まれる場合 (例えば、10 個の担当者レコードが含まれる場合) は、10 個の個別メッセージではなく、1 つのメッセージが JMS キューに書き込まれます。いずれかのレコードに処理エラーがある場合は、そのメッセージ全体に対して処理例外が発生し、データベースにコミットされるレコードはありません。

v データのインポート・トランザクションの場合のみ: 1 つのトランザクションに1 つのドキュメントの複数のインスタンスが含まれる場合 (例えば、10 個の担当者レコードが含まれる場合)、アプリケーションは 10 個の個別メッセージを JMS

キューに書き込みます。いずれかのメッセージに処理エラーがある場合は、そのメッセージについてのエラー・トランザクションが記録され、残りの 9 つのメッセージの処理がアプリケーション内で続行されます。


インバウンド・データの同期処理の開始同期処理を開始するため、外部システムは、サポートされているいずれかの方法を使用して接続を確立します。接続プロセスで、統合フレームワークは、外部システムおよび参照されているエンタープライズ・サービスが有効で使用可能であるか検査します。

初期接続を確立するための手順は、トランザクションに使用するサービスによって異なります。以下の表では、使用可能な方法と、これらの方法で使用される接続について説明します。

方法接続手順

HTTP または HTTPS

POST メソッドv エンタープライズ・サービスを使用するトランザクションの場合は、以下の URL を使用します。

hostname:port/meaweb/es/extsysname/entservname

ここで、

– extsysname は外部システムの名前です。

– entservname はエンタープライズ・サービスの名前です。

v オブジェクト構造サービスを使用するトランザクションの場合は、以下の URL を使用します。

hostname:port/meaweb/os/osname

ここで、osname はオブジェクト構造サービスの名前です。

v Web サービスを呼び出すトランザクションの場合は、以下のURL を使用します。

hostname:port/meaweb/ss/application service name

ここで、application service name は標準サービスの名前です。


方法接続手順

EJBv エンタープライズ・サービス・トランザクションの場合は、以下のコードを使用して、Java プラットフォーム、Enterprise Edition

クライアントから EJB を開始します。

public byte{} processExternalDataSync(byte[] extData,

String serviceName, String sender)

クライアントは、Enterprise JavaBean の JNDI 名(ejb/maximo/remote/enterpriseservice) を使用して、Enterprise

JavaBean 参照のルックアップを行い、メソッドを開始することができます。Java プラットフォーム、Enterprise Edition クライアント上では、以下の構成が必要です。

v オブジェクト構造サービス・トランザクションの場合は、以下のコードを使用して、Java プラットフォーム、Enterprise Edition クライアントから EJB を開始します。

public byte{} processMOS(byte[] reqmosData, String

mosName)

クライアントは、Enterprise JavaBean の JNDI 名(ejb/maximo/remote/mosservice) を使用して、Enterprise

JavaBeans 参照のルックアップを行い、メソッドを開始することができます。Java プラットフォーム、Enterprise Edition クライアント上では、以下の構成が必要です。

v オブジェクト構造サービス・トランザクションの場合は、以下のコードを使用して、Java プラットフォーム、Enterprise Edition クライアントから EJB を開始します。

public byte{} action(byte[] actionData, String

maxServiceName)

クライアントは、Enterprise JavaBean の JNDI 名(ejb/maximo/remote/actionservice) を使用して、Enterprise

JavaBean 参照のルックアップを行い、メソッドを開始することができます。Java プラットフォーム、Enterprise Edition クライアント上では、以下の構成が必要です。

Java プラットフォーム、Enterprise Edition クライアント上では、以下の構成が必要です。

v Home および Remote クラス・ファイルへのアクセス

v サーバーの Java プラットフォーム、Enterprise Edition JAR ファイルへのアクセス

v Enterprise JavaBean をホストするサーバーの URL

v コンテキスト・ファクトリーのクラス名

クライアント・コードは、デフォルトの IntialContext オブジェクトをインスタンス化する必要があります。コンテキストは、プロバイダーの URL およびコンテキスト・ファクトリーを環境から取得します。


方法接続手順

Web サービス Web サービスを開始するトランザクションの場合は、以下の URL

を使用します。


ここで、web service name は導入された Web サービスの名前です。

関連概念:


処理シーケンスエンタープライズ・サービスを使用する非同期メッセージと同期メッセージには、同じ処理シーケンスが適用されます。オブジェクト構造または標準サービスを使用する同期メッセージの場合は、処理シーケンスが異なります。

エンタープライズ・サービスの処理シーケンス:

エンタープライズ・サービス・メッセージは、いくつかの層を介して処理されて、ビジネス・オブジェクト・データのクエリーと更新を実行します。これらの処理層を使用して処理をカスタマイズしたり制御したりすることで、外部アプリケーションとの統合の要件を満たすことができます。

非同期処理の場合、以下の交換方法から発生するデータを使用できます。

v インターフェース・テーブル

v XML メッセージの HTTP ポスト

v JMS キューを使用するように構成されている Web サービスの開始

v EJB の開始

v 直接 JMS 接続

v フラット・ファイルまたは XML ファイルのデータ・インポート

同期処理の場合、以下の交換方法によって発生するデータを使用できます。

v XML メッセージ (HTTP) の HTTP ポスト

v JMS キューを使用するように構成されている Web サービスの開始

v EJB の開始

非同期処理と同期処理のいずれにも同じ処理シーケンスが適用されます。

エンタープライズ・サービス処理は、以下の順序で行われます。

1. 外部システムがエンタープライズ・サービスを呼び出します。

2. エンタープライズ・サービスの処理中のいくつかのポイントで、カスタム処理を実行できます。メッセージ・データを操作するカスタム Java クラスまたは自動化スクリプトを実行するか、または XSL マップを適用することができます。カスタム処理は、以下の順序で行われます。


a. ユーザー出口クラスでプリプロセッシング・メソッドを定義している場合は、このメソッドが最初に適用されます。

b. 外部出口クラスを指定している場合は、この処理が適用されます。

c. ユーザー出口クラスでポストプロセッシング・メソッドを定義している場合は、このメソッドが適用されます。

d. エンタープライズ・サービスに対して XSL マップを指定している場合は、このマップが適用され、エンタープライズ・サービス形式がオブジェクト構造形式に変換されます。

処理のこの時点で、メッセージはエンタープライズ・サービスに関連付けられているオブジェクト構造の形式に一致している必要があります。

3. オブジェクト構造処理は、以下の順序で行われます。

a. オブジェクト構造の処理中にデータを操作するカスタム Java クラスまたは自動化スクリプトを実行できます。

b. オブジェクト構造に対する処理ルールを構成している場合は、そのルールが次に実行されます。

c. 処理ルールの実行の結果、サイトや組織のデータに乗算が行われる場合は、オブジェクト構造のメッセージが追加のサイトや組織用に複製されます。

d. オブジェクトが作成され、オブジェクトの処理が開始します。

4. オブジェクト処理は、以下の順序で行われます。

a. ユーザー出口クラスでプリプロセッシング・メソッドを定義している場合は、このメソッドが適用されます。

b. 外部出口クラスを指定している場合は、この処理が適用されます。

c. ユーザー出口クラスでポストプロセッシング・メソッドを定義している場合は、このメソッドが適用されます。

d. ビジネス・オブジェクトが処理され、データがデータベースに保存されます。

5. 同期トランザクションの場合に限り、作成、更新、削除、および同期の各操作の場合に、エンタープライズ・サービスが開始側アプリケーションに応答を返します。応答には以下の情報が含まれます。

v メッセージが正常に処理されたかどうかを示します。

v メイン・オブジェクトの内部 ID 列の値。列がメイン・オブジェクトのプライマリー・キーの一部であるかどうかは関係ありません。

v メイン・オブジェクトのプライマリー・キー・フィールドの値。

v メイン・オブジェクトの代替キー・フィールドがあれば、その値 (オブジェクトまたはオブジェクト構造用に構成されている場合)。

6. 同期トランザクションの場合に限り、クエリー操作に対してオブジェクト構造全体が返されます。応答データを操作するカスタム Java クラスまたは自動化スクリプトを実行するか、XSL マップを適用することができます。


オブジェクト構造サービスによる同期統合:

オブジェクト構造サービスは、HTTP ポスト、EJB、および Web サービス呼び出しメソッドを使用して、オブジェクト構造サービスの同期メッセージを受け取ることができます。作成、更新、削除、同期、およびクエリーの操作がサポートされています。

オブジェクト構造サービスに基づく統合処理は、以下の順序で発生します。

1. 外部システムが、以下の呼び出しメソッドのいずれかを使用して、統合フレームワークとの通信を開始します。

v HTTP 呼び出し

v EJB 呼び出し

v Web サービス呼び出し

2. 統合フレームワークが、メッセージと関連付けられたオブジェクト構造を識別するインバウンド・メッセージを受け取ります。

3. 統合フレームワークが、オブジェクト構造およびインバウンド・メッセージの内容に基づいてオブジェクトを作成します。

4. 統合フレームワークは定義済みロジックをオブジェクト構造に適用します。

5. オブジェクトが処理され、データがデータベースにコミットされる (メッセージに更新操作が含まれている場合) か、データが要求者に返されます (メッセージにクエリー操作が含まれている場合)。

6. 処理エラーが発生すると、エラー・メッセージを伴う応答がサービスの呼び出し元に返されます。

標準サービスによる同期統合:

標準サービスは、HTTP ポスト、EJB、および Web サービス呼び出しメソッドを使用してアクセスでき、標準サービスの同期メッセージを受け取ることができます。

標準サービスに基づく統合処理は、以下の順序で発生します。

1. 外部システムが、以下の呼び出しメソッドのいずれかを使用して、統合フレームワークとの通信を開始します。

v HTTP 呼び出し

v EJB 呼び出し

v Web サービス呼び出し

2. オブジェクトはシステムに渡され、標準システム処理が適用されます。

アウトバウンド・データ処理パブリッシュ・チャネルは、外部システムからの応答を必要としないアウトバウンド・メッセージの非同期処理を実行します。外部システムからの応答を必要とするアウトバウンド・メッセージの場合、同期処理を実行する呼び出しチャネルを使用することができます。

パブリッシュ・チャネルとの非同期統合統合フレームワークでは、パブリッシュ・チャネルを使用して非同期アウトバウンド・メッセージを処理します。パブリッシュ・チャネル・メッセージの送信は、オ


ブジェクト・イベントによって開始できますが、「データのエクスポート」機能を使用してパブリッシュ・チャネル・メッセージをオンデマンドで送信することもできます。

パブリッシュ・チャネルはオブジェクト構造に対して構成され、オブジェクト構造のメイン・オブジェクトの更新時にイベント・ベースの統合ができるようにします。更新が発生するのは、例えば、ユーザーがアプリケーションでレコードを保存した場合や、ワークフロー・プロセスで 1 つのステージを完了した場合です。オブジェクト構造のメイン・オブジェクトが更新されると、そのオブジェクト構造に関連付けられ、イベントを listen するように構成されているすべてのパブリッシュ・チャネルに対してイベントが開始されます。ユーザーは、外部システム・アプリケーションの「データのエクスポート」機能を使用して、パブリッシュ・チャネル・メッセージをいつでも開始することができます。

パブリッシュ・チャネル・メッセージがイベントまたは「データのエクスポート」によって開始されると、統合フレームワークは以下の一連のタスクを実行します。

1. パブリッシュ・チャネルに関連付けられたオブジェクト構造およびコンポーネント・オブジェクトを識別します。

2. トランザクションのオブジェクト構造を構成し、そのオブジェクトの内容に基づいて XML メッセージを形成します。

3. パブリッシュ・チャネル・アプリケーションで定義されている処理ルールを適用します。

4. パブリッシュ・チャネルが複数の外部システムと関連付けられている場合、パブリッシュ・チャネルと外部システムの組み合わせごとに 1 つずつ、オブジェクト構造のコピーを作成します。

5. パブリッシュ・チャネルに関連付けられているカスタム処理 Java クラス、自動化スクリプト、または XSL マップがある場合は、それらを以下の順序で処理します。

a. イベント・フィルター・クラスを実行します (提供されている場合)。

b. ユーザー出口処理クラスのプリプロセッシング・メソッドを実行します (提供されている場合)。

c. パブリッシュ・チャネル処理クラスを実行します (提供されている場合)。

d. ユーザー出口クラスのポストプロセッシング・メソッドを実行します (提供されている場合)。

e. XSL マップを適用します (提供されている場合)。

6. 外部システム用に指定されたアウトバウンド・キューに XML メッセージを書き込みます。

7. クーロン・タスクは、パブリッシュ・チャネル・メッセージを取得し、構成されたエンドポイントに基づいてそのメッセージを外部システムに配信します。

パブリッシュ・チャネル処理の概要:

パブリッシュ・チャネル用に構成されているオブジェクト構造は、チャネルのメッセージの内容を提供します。外部システムは、統合メッセージがどのような形で、どこに送信されるかを判別します。パブリッシュ・チャネル・レイヤー内には、メッセージ内容の変換とビジネス・ルールの適用をサポートするオプションの処理レイヤーがあります。


イベント・ベースの統合:

パブリッシュ・チャネルは、オブジェクトの更新などのシステム・トランザクションの処理に応答して、統合メッセージを開始することができます。

関連するオブジェクト構造のプライマリー・オブジェクトで発生するイベントをlisten するようにパブリッシュ・チャネルを構成するには、パブリッシュ・チャネル・アプリケーションで「リスナーを有効にする」チェック・ボックスを選択します。オブジェクト構造のメイン・オブジェクトが更新されると、パブリッシュ・チャネル・メッセージにより、更新された情報が外部システムに送信されます。

下位階層オブジェクトの更新によりメイン・オブジェクトの更新が開始された場合、この情報も同様に外部システムに送信されます。ただし、下位階層オブジェクトの更新の中には、メイン・オブジェクトの更新を開始しないものもあります。この場合、更新された情報は外部システムに送信されません。例えば、オブジェクト構造が、添付ファイルを下位階層オブジェクトとしてサポートするように構成されている場合にユーザーが添付ファイルを追加しても、このイベントは外部システムに通知されません。

オブジェクト構造の下位階層オブジェクトからプライマリー・オブジェクトへイベントを伝搬させるには、オブジェクト構造アプリケーションで「詳細構成」アクションを使用して、イベントの伝搬を構成します。下位階層オブジェクトからメイン・オブジェクトへイベントを伝搬するようにオブジェクト構造を構成すると、メイン・オブジェクトは更新された情報を外部システムに送信します。

オブジェクト構造のイベント伝搬を構成する場合は、メッセージのアクティビティーを慎重にモニターする必要があります。これは、外部システムで処理するように設計されているメッセージの数よりも多くのメッセージが、構成で開始される可能性があるためです。下位階層オブジェクトが、上位階層オブジェクトを更新する組み込みロジックを持っている場合は、下位階層オブジェクトから上位階層オブジェクトへのイベント伝搬の有効化または無効化という点において、この構成は何の影響も与えません。

データのエクスポート機能:

パブリッシュ・チャネルは、データのエクスポート機能を使用して、統合データのバッチ処理をサポートします。

データのエクスポート機能を開始するには、オブジェクト構造のプライマリー・オブジェクト、および送信するレコードの数についての SQL クエリーを実行します。クエリーが成功すると、エクスポートが開始されます。

「データのエクスポート」ウィンドウで、オブジェクト構造のプライマリー・オブジェクトに関する SQL Where 文節を指定すると、データのエクスポート機能が開始されます。送信するレコード数を構成することもできます。クエリーが成功すると、エクスポートが開始され、そのパブリッシュ・チャネル用に構成されているエンドポイントに基づいてデータが送信されます。


呼び出しチャネルとの同期統合統合フレームワークは、外部アプリケーションからの確認または応答の内容が必要な同期アウトバウンド・メッセージを処理するために、呼び出しチャネルを使用します。エクスポートは、呼び出しチャネルを呼び出すアクション・クラスによって開始されます。

呼び出しチャネル・メッセージの送信は、チャネルを開始するようにコーディングされたアクション Java クラスによって開始されます。呼び出しチャネルは、例えば、外部アプリケーションを呼び出してデータを検証したり、外部アプリケーションでの処理を開始したり、データを取得したりするために使用します。呼び出しチャネルは、チャネルを開始するアクション・クラスを呼び出すように構成されたユーザー・インターフェース・コントロールによって起動できます。

アクション・クラスによって呼び出しチャネル・メッセージが開始されると、統合フレームワークは以下の一連のタスクを実行します。

1. 各呼び出しチャネルに関連付けられたオブジェクト構造を識別し、コンポーネント・オブジェクトを識別します。

2. トランザクションのオブジェクト構造を構成し、そのオブジェクトの内容に基づいて XML メッセージを形成します。

3. カスタム処理の Java クラス、自動化スクリプト、または XSL マップが呼び出しチャネル要求に関連付けられている場合は、それらを以下の順序で処理します。

a. 要求ユーザー出口処理クラスにプリプロセッシング・メソッドが指定されている場合は、そのメソッドを実行します。

b. 呼び出しチャネルの要求処理クラスが指定されている場合は、そのクラスを実行します。

c. 要求ユーザー出口クラスにポストプロセッシング・メソッドが指定されている場合は、そのメソッドを実行します。

d. XSL マップを適用します (提供されている場合)。

4. エンドポイントによって指定された宛先に XML メッセージを書き込みます。

5. エンドポイント・ハンドラーが、使用するトランスポート・メカニズムを指定します。

6. エンドポイントから応答を受信した場合に、応答にカスタム Java クラス、自動化スクリプト、または XSL マップが関連付けられていたときは、それらを以下の順序で処理します。

a. 応答ユーザー出口処理クラスのプリプロセッシング・メソッドを実行します(提供されている場合)。

b. 呼び出しチャネルの応答処理クラスが指定されている場合は、そのクラスを実行します。

c. 応答ユーザー出口クラスのポストプロセッシング・メソッドを実行します (提供されている場合)。

d. XSL マップを適用します (提供されている場合)。

7. 応答オブジェクト構造のデータからオブジェクトが作成され、標準の処理が適用されるシステムに渡されます。


8. 応答オブジェクト構造から作成されたすべてのオブジェクトが正常に処理された場合は、それらのオブジェクトがデータベースにコミットされます。

応答の内容を、統合要件に基づいて呼び出し側で管理して、例えばビジネス・オブジェクトのデータを更新したり、ユーザーに応答を表示したりすることができます。デフォルトのアクション・クラスが用意されており、そのクラスを使用または拡張して呼び出しチャネル統合を実装することができます。

呼び出しチャネルのメタデータ・プロパティーのカスタマイズ:

呼び出しチャネルの外部出口クラスまたはユーザー出口クラスの中で、エンドポイント用に構成したパラメーターのオーバーライド値など、追加のデータを更新できます。

例えば、呼び出しチャネルのオブジェクト構造にあるデータからエンドポイント・パラメーター (URL など) を導出するためにこの種のカスタマイズを使用できます。多くのメタデータ・プロパティーの値をオーバーライドできます。

値説明

ENDPOINT この値をオーバーライドすると、外部システムを介して構成したエンドポイントの代わりに、指定したエンドポイントを使用できます。

ENDPOINTPROPS この値は、対応するオーバーライド値を持つ1 つ以上のエンドポイント・パラメーターを格納できるハッシュ・マップを指します。エンドポイント構成でプロパティーをオーバーライドできないと規定されている場合、統合コンテキストのオーバーライド値はすべて無視されます。

TARGETOBJECT この値は、呼び出しチャネルのターゲット・オブジェクト構造です。

SOURCEOBJECT この値は、呼び出しチャネルのソース・オブジェクト構造です。

統合処理の構成統合メッセージの処理は、インバウンド・トランザクションおよびアウトバウンド・トランザクションの統合メッセージの移動中にいくつかのポイントで発生します。統合処理を構成するときは、ソース・データと宛先データの間で、データ構造およびデータ形式の互換性を保つようにする必要があります。

エンタープライズ・サービスを使用したインバウンド・メッセージの非同期処理の構成エンタープライズ・サービスは、Maximo Asset Management からの応答を必要としないインバウンド・メッセージに対して非同期処理を使用します。エンタープライズ・サービス処理を有効にするには、オブジェクト構造、エンタープライズ・サービス、外部システム、JMS クーロン・タスクなどのいくつかの統合コンポーネントを構成します。



外部システムは接続を開始し、外部システムの名前およびエンタープライズ・サービスの名前を含むメッセージを送信します。エンタープライズ・サービスがこのトランザクションに対して有効になっていることを統合フレームワークが検査する間、外部システムは接続を維持します。有効なトランザクションはインバウンドの連続 JMS キューに入れられ、外部システムとの接続が終了します。クーロン・タスクは JMS キューをポーリングし、エンタープライズ・サービス処理のためにメッセージを転送し、オブジェクト構造処理のためにメッセージをさらに送信してからメッセージはデータベースにコミットされます。

手順1. オブジェクト構造アプリケーションで、使用する定義済みのオブジェクト構造を指定するか、オブジェクト構造を作成します。

2. エンタープライズ・サービス・アプリケーションで、使用する定義済みのエンタープライズ・サービスを識別するか、エンタープライズ・サービスを作成します。

3. オブジェクト構造を使用するようにエンタープライズ・サービスを構成し、有効な操作を指定します。エンタープライズ・サービスでの非同期処理の場合、クエリー操作は無効です。

4. 外部システム・アプリケーションで、使用する外部システムを指定するか、または外部システムを作成し、外部システムをエンタープライズ・サービス用に構成します。

a. インバウンド JMS キューを使用するよう外部システムを構成して、外部システムを有効にします。

b. エンタープライズ・サービスを使用するよう外部システムを構成して、サービスを有効にします。

5. オプション: 統合メッセージの送信元を構成します。

メッセージ送信元構成

クーロン・タスクの使用によるファイルからのメッセージ

クーロン・タスクのセットアップ・アプリケーションで、データのインポート・クーロン・タスクをアクティブに設定します。

Web サービス呼び出しからのメッセージ

「Web サービス・ライブラリー」アプリケーションで、エンタープライズ・サービスに基づく Web サービスを作成します。

インターフェース・テーブルからのメッセージ

クーロン・タスクのセットアップ・アプリケーションで、インターフェース・テーブル・クーロン・タスクをアクティブに設定します。

6. 統合メッセージを受け取るためのキューを構成します。

キュー・タイプ説明

連続アプリケーション・サーバー上で、キュー・メッセージをコンシュームするメッセージ駆動型 Bean を構成します。


キュー・タイプ説明

連続クーロン・タスクのセットアップ・アプリケーションで、JMS クーロン・タスクをアクティブに設定することで、JMS クーロン・タスクがキューからのメッセージをコンシュームできるようにします。

パブリッシュ・チャネルを使用したアウトバウンド・メッセージの非同期処理の構成パブリッシュ・チャネルは、メッセージの宛先からの応答を必要としないアウトバウンド統合メッセージを処理します。パブリッシュ・チャネル処理を有効にするには、オブジェクト構造、パブリッシュ・チャネル、外部システム、クーロン・タスクなどのいくつかの統合コンポーネントを構成します。


オブジェクト構造は、パブリッシュ・チャネルにメッセージ内容を提供します。パブリッシュ・チャネル処理によりメッセージが変換され、次に、外部システムによりメッセージがその宛先キューに転送されます。クーロン・タスクは定期的なスケジュールに基づいてキューをポーリングし、メッセージをその宛先に配信します。オブジェクトのステータス変更などのイベントや、外部システム・アプリケーションでのデータ・エクスポート・トランザクションを開始することで、パブリッシュ・チャネル・トランザクションを開始することができます。

手順1. オブジェクト構造アプリケーションで、使用する定義済みのオブジェクト構造を指定するか、オブジェクト構造を作成します。

2. パブリッシュ・チャネル・アプリケーションで、使用する事前定義のパブリッシュ・チャネルを指定するか、パブリッシュ・チャネルを作成します。

3. オプション: イベント・ベースの統合を有効にするには、イベントのリスナーを構成します。

a. パブリッシュ・チャネル・アプリケーションで、「パブリッシュ・チャネル・リスナーを有効にする (Enable Publish Channel Listener)」アクションを選択します。リスナーが有効になり、オブジェクト構造のプライマリー・オブジェクトが更新されると、パブリッシュ・チャネル・トランザクションが開始されます。

b. 下位階層オブジェクトのイベントがパブリッシュ・チャネル・トランザクションを開始するようにするには、オブジェクト構造アプリケーションで「詳細構成」アクションを選択し、イベント伝搬を構成します。

4. オプション: パブリッシュ・チャネル・アプリケーションで、処理ルールを検討し、必要に応じてルールを追加または変更します。処理ルールは、「順序」フィールドに示されている順序で実行されます。順序の値を変更した場合、ルールは異なる順序で実行されるため、予期しない結果が生じることがあります。

5. オプション: 変換処理中にカスタム・ロジックを提供する自動化スクリプト、カスタム Java クラス・ファイル、または XSL マップを指定します。

6. 外部システム・アプリケーションで、外部システムにパブリッシュ・チャネルを追加し、アウトバウンドの連続 JMS キューへのファイル・パスを指定します。


7. クーロン・タスクのセットアップ・アプリケーションで、JMSQSEQCONSUMER

クーロン・タスクの SEQOUT インスタンスを有効にします。このクーロン・タスクは、JMS キューでメッセージを受信したのと同じ順序で、JMS キューからその宛先にメッセージを配信します。

ルール・ベースのカスタマイズ処理ルールを使用すると、Java クラス、自動化スクリプト、または XSL マップを作成せずに、事前定義された統合処理の動作を変更することができます。処理ルールは、パブリッシュ・チャネルまたはエンタープライズ・サービスでのみ実装できます。

処理ルールにより、XML フィールド、オブジェクト・フィールド、オブジェクト・セット、統合コントロール、およびシステム・コントロールの値にアクセスして、それらを評価することができます。また処理ルールにより、XML フィールドやオブジェクト・フィールドの値を変更したり、メッセージの全体または一部を停止またはスキップしたりすることもできます。

オブジェクトおよびレコードのルール定義オブジェクト構造は、1 つ以上のオブジェクト・レコードで構成されています。オブジェクトが作成されると、標準アプリケーション処理が適用される前に、対応するレコード・フィールドからオブジェクト・フィールドに取り込みが行われます。

アウトバウンド処理時に、対応するフィールドから元のオブジェクトにレコード・フィールドが取り込まれます。一部の汎用統合フィールドを除き、システム・オブジェクトはアウトバウンド・メッセージでは更新されません。

ルールをオブジェクト構造レコードまたはオブジェクトに適用する場合は、次のガイドラインに従ってください。

v アウトバウンド処理の場合は、オブジェクト構造レコードのみに処理ルールを適用できます。

v インバウンド処理の場合は、オブジェクト構造レコードまたはオブジェクトに処理ルールを適用できます。

– インバウンド・ルールによってオブジェクトのキー・フィールドの値が変更された場合は、ルールをオブジェクト構造レコードに適用します。

– インバウンド・ルールでオブジェクトまたはオブジェクト・セットが評価または操作されない場合は、ルールをオブジェクト構造レコードに適用します。

– インバウンド・ルールでユーザー定義フィールドが評価または操作された場合は、ルールをオブジェクト構造レコードに適用します。

– インバウンド・ルールによってオブジェクトまたはオブジェクト・フィールドが評価または操作された場合は、ルールをオブジェクトに適用します。

エンタープライズ・サービスに関するすべてのルールは、オブジェクトまたはオブジェクト構造レコードのどちらかに適用します。ルールをオブジェクトとオブジェクト構造レコードの両方に適用することは避けてください。処理ルールをオブジェクト構造とオブジェクトの両方に適用すると、インバウンド・トランザクションの処理時間が長くなります。


処理ルールの定義処理ルールでは、レコードまたはオブジェクト内のフィールドに対して、あるいはレコードまたはオブジェクトそのものに対してアクションが実行されます。処理ルールを定義する場合は、トランザクションに使用するサービスまたはチャネルで、そのルールを適用するレコードまたはオブジェクトを指定することができます。

処理ルールの開始:

アウトバウンド・トランザクションでは、オブジェクト構造のプライマリー・オブジェクトのビジネス・オブジェクト・イベントが処理ルールを開始します。インバウンド・トランザクションでは、処理ルールを開始するイベントは、インバウンドXML メッセージのプライマリー・オブジェクトのアクション属性の値によって識別されます。

パブリッシュ・チャネルおよびエンタープライズ・サービスを構成するときに、各処理ルールを開始するために使用するイベントを指定します。処理ルールは、プライマリー・レコード、下位階層レコード、またはオブジェクトに対して適用できますが、ルールを開始するイベントは、プライマリー・オブジェクトで開始される必要があります。

例えば、停止ルールを PERSON オブジェクトに実装して、そのルールが更新時に適用されることを指定することにより、その担当者レコードの属性をユーザーが変更できないようにすることができます。この構成では、ユーザーは担当者レコードを作成または削除できますが、ユーザーが担当者レコードを更新することはできません。

アウトバウンド・トランザクションの場合は、パブリッシュ・チャネル・アプリケーションで、プライマリー・オブジェクトの次の 1 つ以上のアクションによってルールを開始するように構成できます。

v 挿入

v 削除

v 更新

「データのエクスポート」機能を使用してアウトバウンド・メッセージが生成された場合や、パブリッシュ・チャネルに対するプログラマチックな呼び出しによってアウトバウンド・メッセージが生成された場合は、イベントの設定に関係なく、有効なすべての処理ルールが実行されます。

インバウンド・トランザクションの場合は、エンタープライズ・サービス・アプリケーションで、プライマリー・オブジェクトの次の 1 つ以上のアクションによってルールを開始するように、構成できます。

v 追加

v 変更または置換 (更新と同等)

v 削除

これらの値の 1 つをインバウンド・トランザクションのプライマリー・オブジェクトのアクション属性として設定できます。


処理ルール・アクション:

処理ルールは、エンタープライズ・サービスまたはパブリッシュ・チャネル全体に作用することができます。例えば、ルールによってメッセージをバイパスしたり、メッセージ内のデータ・フィールドの値を操作したりすることができます。

サービスまたはチャネル・メッセージに対しては、停止、スキップ、および下位階層の停止、という 3 つの処理ルール・アクションが実行されます。サービスまたはチャネル・メッセージ内のフィールドの値は、結合、分割、設定、および置換の 4

つの処理ルール・アクションによって変換されます。

メッセージ処理アクション:

メッセージ処理アクションでは、エンタープライズ・サービスまたはパブリッシュ・チャネルのメッセージ全体を停止またはスキップするか、メッセージ内のレコード全体をスキップします。

スキップ・アクション

スキップ・アクションは、指定された基準に適合するメッセージをバイパスします。スキップ・アクションがインバウンド・メッセージに適用された場合、そのメッセージは処理されず、インバウンド・キューから消去されます。スキップ・アクションがアウトバウンド・メッセージに適用された場合、キューに何も書き込まれず、メッセージは外部システムに送信されません。スキップ処理ではエラーは生成されませんが、システム・ログ・ファイルはスキップ・アクションの原因となったルールによって更新されます。

スキップ・アクションにはいくつかのルールが事前に定義されています。これらのルールでは、統合コントロール値を調べることにより、外部システムへの送信前にアウトバウンド・メッセージが有効なステータスにあることが確認されます。

停止アクション

停止アクションは、指定された基準に適合するメッセージの処理を停止します。アウトバウンド・メッセージはロールバックされ、エラー・メッセージが表示されます。インバウンド・トランザクションの場合、メッセージはインバウンド用の JMS

キューに残されます。エンタープライズ・サービスの同期呼び出しの結果エラーが発生した場合は、呼び出し側プログラムにエラーが通知されます。

停止アクションの場合には、定義済みのルールはありません。このオプションは、ユーザーがサービスまたはチャネルの動作をカスタマイズするためのユーティリティーです。

インバウンド・エンタープライズ・サービスでは、可能な場合は、停止アクションでなくスキップ・アクションを使用してください。停止アクションを使用すると、処理エラーが発生し、メッセージがインバウンド・キューに残されるか起動側がエラー応答を受信します。スキップ・アクションを使用すると、このような結果は生じません。

停止アクションを指定した処理ルールがデータのエクスポート機能によって生成されたパブリッシュ・チャネルに適用される場合、停止アクションはスキップ・アク


ションとして扱われます。停止アクションの評価が True である場合、メッセージはスキップされます。

下位階層のスキップ・アクション

下位階層のスキップ・アクションは、パブリッシュ・チャネルのアウトバウンド・メッセージのみに適用できます。処理ルールは下位階層レベルのレコードがスキップされるレコードまたはオブジェクトに適用します。

担当者構造に電話および電子メールの担当者オブジェクトと下位階層オブジェクトがある場合、担当者に対して下位階層のスキップ・アクションを使用して、メッセージから電話と電子メールのデータを除去することができます。下位階層のスキップ・アクションは、ステータス変更が起こり、付随する電話および電子メールの情報を外部システムが必要としない場合に使用します。

レコードのスキップ・アクション

レコードのスキップ・アクションは、パブリッシュ・チャネルのアウトバウンド・メッセージのみに適用できます。レコードのスキップ・アクションでは、適用されたルールを含むレコードまたはオブジェクトが削除されます。処理ルールは、スキップしたいレコードまたはオブジェクト、およびそのすべての下位階層レコードと下位階層オブジェクトに適用します。

担当者オブジェクト構造に電話の担当者オブジェクトと下位階層オブジェクトがある場合、レコードのスキップ・アクションを使用して、特定の電話レコードをメッセージから除外することができます。レコードのスキップ・アクションは、例えば、担当者の職場の電話番号を送信したいが自宅の電話番号は送信したくないという場合に使用します。レコードのスキップ・ルールには、自宅の電話番号レコードを確実にスキップするために、そのレコードを識別する条件が必要です。

フィールド変換アクション:

フィールド変換ルールは、変換するフィールドが入っているレコードまたはオブジェクトに適用します。フィールド変換ルールは、選択されたレコードの 1 つのフィールドまたは複数のフィールドに適用することができます。

設定アクション

設定アクションでは、指定されたデータ・フィールドに値が書き込まれます。ルールを定義する際、設定されるデータおよび新しい値のソースを指定します。そのルールでは新しい値が常にターゲット・フィールドに書き込まれるか、フィールドがNULL の場合にのみ書き込まれる (デフォルトのアクション) かを示します。このアクションを使用して、データ・フィールドの値を初期化することができます。ルールによって、新しい値が常にターゲット・フィールドに書き込まれる場合、フィールドの既存の値は上書きされます。

ソースを以下のいずれかの値にすることができます。

v 値の統合コントロール

v ハードコーディングされた値

v システム・コントロール (MAXVARS データベース表内)


v 指定されたレコードまたはオブジェクトの別のフィールド

v 関連オブジェクトのフィールド

置換アクション

置換アクションでは、データ・フィールドの値が別の値に置き換えられます。ルールを定義するときは、更新するデータ・フィールドを指定します。使用するコントロールはクロス・リファレンス・コントロールでなければなりません。データ・フィールドの置換前の元の値および置換後の値が含まれるクロス・リファレンス・コントロールの名前を指定してください。

このアクションは、データベースと外部システムで、同じエンティティーの ID が異なる場合に使用します。例えば、パブリッシュ・チャネルの SITEID 値を外部のPLANTID 値と置き換え、エンタープライズ・サービスの外部の PLANTID 値をSITEID 値と置き換えることができます。

結合アクション

結合アクションは、複数のソース・フィールドの値を単一のターゲット・フィールドに連結します。ルールを定義する際は、ターゲット・フィールド、ソース・フィールド、およびソース・データを書き込む順序を指定します。ソース・データは、データ・フィールドまたはデータ値が入った統合コントロールにすることができます。また、ターゲット・フィールド内のセグメントを区切るための区切り記号を含む統合コントロールを指定することもできます。

このアクションは、1 つのエンティティーに対するシステムの定義と外部システムの定義が一致していない場合に、エンタープライズ・サービス処理ルールで使用します。エンタープライズ・サービス処理ルールでは、例えば、外部システムの販売元 ID と販売元ロケーション・フィールドを COMPANY フィールドに結合することができます。その後、データを外部システムに送信するときに、パブリッシュ・チャネル処理ルールが分割アクションを使用して、結合されたフィールドを別々の値に分割することができます。

ソース・フィールドとターゲット・フィールドは、同一のオブジェクト内になければなりません。このアクションでは常にターゲット・フィールドの既存の値が上書きされます。ソース・フィールドおよびターゲット・フィールドは必ず英数字フィールドでなければなりません。そうでないときは、処理エラーが発生する可能性があります。

分割アクション

分割アクションは結合アクションの逆です。分割アクションは、1 つのフィールドにある値を複数のフィールドに分離します。ルールを定義する際、1 つのソース・フィールド、1 つ以上のターゲット・フィールド、およびルール・プロセッサーがソース・フィールドのセグメントを識別する方法を定義します。

フィールドに以下のソースを指定することができます。

v 選択されたレコードまたはオブジェクトのフィールド

v ソース・フィールドにあるセグメントを区切るための区切り文字を含む統合コントロール



インバウンド・メッセージで複数のフィールドを結合した場合、アウトバウンド方向では、結合したフィールドを個々のフィールドに分割します。フィールドを分割するには 2 通りの方法があります。ソース・フィールドの各セグメントの長さを指定するか、セグメントを区切る区切り文字を指定することができます。

ソース・データの各セグメントのフィールド長が固定されている場合、指定したフィールド長、順序、および値に基づいて、ルール・プロセッサーがソース・フィールドを左から右に分割します。例えば、文字長が 6 のターゲット・フィールド A

には、ソース・フィールドの 1 桁目から 6 桁目が保持されます。また、文字長が3 のターゲット・フィールド B には、ソース・フィールドの 7 桁目から 9 桁目が保持されます。

ソース・フィールド・セグメントの長さが可変でも、そのソース・フィールドにセグメントを識別する固有の区切り記号が含まれる場合は、「区切り記号」オプションを使用します。「区切り記号」オプションは、区切り記号を定義する統合コントロールを識別します。同じ区切り記号がすべてのセグメントを区切る必要があります。ルール・プロセッサーは、ソース・フィールドを左から右に解析します。プロセッサーは、区切り文字を見つけて、ストリングを複数の値に分割し、それぞれの値を指定されたターゲット・フィールドに移動します。

処理シーケンス:

処理ルールは、1 つのオブジェクト構造内の各レコードまたはオブジェクトに対して順番に適用されます。最初はプライマリー・オブジェクトに適用され、下位階層オブジェクトへと下に移動していきます。

1 つのレコードまたはオブジェクトに対して複数の処理ルールを定義する場合に、デフォルトの処理シーケンスを変更することができます。この変更は、前のルールが正常に適用されていないとそのルールが適用されない、という場合に特に重要です。停止アクションまたはスキップ・アクションを伴うルールが正常に適用されると、それ以降の検査は行われません。

条件および評価処理ルールは条件付きで適用されます。ルールに指定された処理またはアクションを実行するには、事前にすべての条件が満たされていなければなりません。

条件は、XML フィールド・データ、オブジェクト・フィールド、オブジェクト・セット、統合コントロール、またはシステム・コントロールの評価または比較に関連します。

条件の指定:

条件は、1 つ以上の評価のグループです。複数の条件を指定することができ、その順序は条件番号で識別されます。


それぞれの評価は、値 True または False を返します。例えば、評価で 2 つのフィールドの値が等しいかどうかを検査する場合、2 つのフィールドが等しければ True

の値が返され、等しくなければ False の値が返されます。条件でも値 True またはFalse が返されます。条件の中の評価がすべて True の場合、条件は True です。条件のいずれかの評価が False である場合、条件は False です。処理ルールに複数の条件が含まれる場合、その処理ルールに関連付けられたアクションに関する 1 つの条件のみが True でなければなりません。

評価カテゴリーの指定:

評価の詳細を定義する前に、評価する必要があるデータのタイプを選択します。

次の表に、評価で使用できるカテゴリーについて説明します。

カテゴリー使用

XML フィールド統合オブジェクトのレコード・フィールドの値を評価するか、2 つのレコード・フィールドの値を比較します。

オブジェクト・フィールドオブジェクト・フィールドの値を評価するか、関連オブジェクトの 2 つのフィールドの値を比較します。オブジェクト・フィールドをオブジェクト構造定義の一部にすることができます。またそのオブジェクト・フィールドは、オブジェクト構造定義内のオブジェクトとの関係でアクセスされるオブジェクトの一部であってもかまいません。

オブジェクト・セット関連したオブジェクトにレコードが存在するかどうかを検査します。

コントロール値またはブール型の統合コントロールまたはシステム・コントロールを評価します。

エンタープライズ・サービス処理ルールはオブジェクトの作成前に適用されるため、この処理ルールでオブジェクト・フィールドまたはオブジェクト・セットを評価することはできません。評価では、カテゴリー、処理方向 (アウトバウンドまたはインバウンド)、およびレコード・タイプ (レコードまたはオブジェクト) を次のように組み合わせて使用することができます。

処理ルールの方向

XML フィールドの評価

オブジェクト・フィールドの評価

オブジェクト・セットの評価

コントロールの評価

アウトバウンド使用可能使用可能使用可能使用可能

インバウンド(レコード)

使用可能使用不可使用不可使用可能

インバウンド(オブジェクト)

使用可能使用可能使用可能使用可能


評価するフィールド:

XML フィールドおよびオブジェクト・フィールドの評価では、評価するフィールドを指定します。

オブジェクトの評価の場合、オブジェクトおよびフィールドにアクセスする関係を指定します。フィールドの値がレコードと一致するオブジェクトから派生したものである場合、関係を指定する必要はありません。

評価のタイプ:

一般に、評価では 2 つの値が比較されるか、またはオブジェクト・セットまたはNULL 値が存在するかどうかが検査されます。

ユーザー・インターフェースには、評価のカテゴリー (XML フィールド、オブジェクト・フィールド、オブジェクト・セット、またはコントロール) に応じたタイプのサブセットが表示されます。次の表に、使用が可能な評価のタイプをリストします。

評価のタイプ説明

EQUALS 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値と同じです。

NOTEQUALS 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値と等しくありません。

GREATER 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値より大きくなっています。

GREATEROREQUAL 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値以上です。

LESS 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値未満です。

LESSOREQUAL 指定されたフィールドの値は、2 番目のフィールド (比較フィールド) の値以下です。

LIKE 値には、予期された値が含まれます。

NOTLIKE 値には、予期された値が含まれていません。

NULL 指定されたフィールドには値が含まれていないか、NULL 値が含まれています。

ISNOTNULL 指定されたフィールドには値が含まれています。

NONE このオブジェクトは、「評価する時期」フィールドが「変更」または「変更なし」として構成されている場合にのみ使用可能です。「NONE」を選択する場合、これ以上の評価は必要ありません。

EXISTS 指定されたオブジェクト・セットにレコードが存在します。

NOTEXISTS 指定されたオブジェクト・セットにレコードは存在しません。


「評価する時期」フィールド:

XML フィールドおよびオブジェクト・フィールドの評価の場合、処理ルールでは最初に、指定されたデータを評価するかどうかが判別されます。

システムは、以下のいずれかの値が指定された「次の場合に評価」フィールドを検査してデータを評価します。

値アクション

変更済メッセージを生成したアクティビティーで指定のフィールドが変更される場合にのみ、評価が続行されます。

変更なしメッセージを生成したアクティビティーで指定のフィールドが変更されない場合にのみ、評価が続行されます。

常時メッセージ (デフォルト) を生成したアクティビティーの値によって指定のフィールドが変更されるかどうかに関係なく、評価が続行されます。このオプションを指定すると、比較タイプ「NONE」は指定できません。

レコードが更新されると、changed 属性 (changed="1") がアウトバウンド・メッセージの対応するフィールドに出力されます。この属性により、そのフィールドが「次の場合に評価」フィールドの基準に適合するかどうかが判別されます。

この属性は、データのエクスポート機能によって作成されたメッセージには表示されません。値が変更されたときに適用された評価では、データ・エクスポート・シナリオで正しい出力が生成されない可能性があります。

changed 属性はインバウンド・メッセージには適用されません。

比較フィールドの仕様:

ユーザー・インターフェースには、評価のタイプ (XML フィールド、オブジェクト・フィールド、オブジェクト・セット、またはコントロール) に応じたサブセットが表示されます。処理ルールによって先頭の 8 つの評価タイプのいずれかが使用される場合、比較を行うフィールド (評価フィールド) をそのルールに指定する必要があります。

次の表に、フィールドの比較で使用できる比較フィールドのタイプを示します。英数字のソース・フィールドの比較では、大文字と小文字が区別されます。


フィールド使用

統合コントロール指定されたフィールドの値を、リストまたは値の統合コントロールの値と比較します。リスト・コントロールに一致する値が複数ある場合、評価は True になります。True の評価が返されるのは、フィールドの値がリスト・コントロールのいずれかの値と一致する場合のみです。

例: 注文書の STATUS を検証します。STATUS フィールドの現行値は WAPPR

で、条件を満たす可能性のある許容値はPOSEND というリスト・コントロールにあります。POSEND にある値はWAPPR、APPR、および CLOSE です。評価タイプが EQUALS である場合、評価の値として True が返されます。

値指定したフィールドの値を、定義済みの値と比較する。このオプションは、ユーザー定義の条件の場合にのみ使用できます。

アプリケーション・サーバーまたはデータベースのロケール設定に関係なく、すべての10 進数フィールドでは、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側の数字はフォーマットされません。このフォーマットはインバウンドとアウトバウンドのデータに適用されます。例えば、$1,738,593.64 は1738593.64 の形式にする必要があります。

例: 処理ルールにより POLIN1 フィールドの値が値 SPARE と比較されます。評価タイプが EQUALS で、2 つの値が同じである場合、評価の値として True が返されます。

MAXVAR 指定されたフィールドの値を、システム・コントロールの値 (MAXVARS データベース表内の値) と比較します。

例: エンタープライズ・サービスまたはパブリッシュ・チャネルの OWNERSYSID を評価して、MAXVARS.MXSYSID と同じであるかどうかを判別します。

ブール型指定されたフィールドの値を、ブール型の値(True または False) と比較します。


フィールド使用

比較フィールド指定されたフィールドの値を、同じオブジェクトの別のフィールドと比較します。

例: 注文書明細またはジャーナル項目のGLDEBITACCT 値と GLCREDITACCT 値を比較して、それらが等しいかどうかを判別します。

オブジェクト、関係、およびフィールド指定されたフィールドの値を、別のオブジェクトのフィールドと比較します。

例: システム内の在庫の OWNERSYSID を検査して、受領明細または注文書明細の部品保管場所の値があるか調べます。

統合コントロール統合コントロールにより、任意のエンタープライズ・サービスおよびパブリッシュ・チャネルの動作を個々の組織およびサイトの要件に従って構成することができます。評価を行うために、処理ルールと Java クラスが統合コントロールにアクセスすることができます。

統合コントロールはシステム・レベルで定義されます。このコントロールは 1 つ以上のエンタープライズ・サービスおよびパブリッシュ・チャネルに割り当てることができます。このコントロールの値は外部システム・レベルで構成することができます。同じエンタープライズ・サービスを処理する 2 つの外部システムは同じ処理ロジック、クラス・ファイル、および処理ルールを共用することができますが、異なるコントロール設定を使用しているためにデータの処理方法は異なります。

コントロール・レベル:

すべてのマスター・データおよび文書はシステム・レベル、組織レベル、またはサイト・レベルで保管されます。部品データはシステム・レベルで、会計情報は組織レベルで、作業指示書はサイト・レベルで保管されます。これらのレベルの間には暗黙の階層が存在します。

統合コントロールを構成することで、以下のどのレベルの値でもオーバーライドできます。

コントロール値説明

システム・レベルシステム・レベルの値は、すべてのシステム組織およびサイトに適用されます。コントロールが組織レベルまたはサイト・レベルの値に合わせて構成されていない場合、システム処理ではシステム・デフォルトが使用されます。コントロールが組織レベルまたはサイト・レベルの値に合わせて構成されていても、特定の組織またはサイト用の値が存在しない場合、システム処理ではシステム・レベルの値が使用されます。


コントロール値説明

組織レベル組織レベルの値は、組織内のすべてのシステム・サイトに適用されます。コントロールが組織レベルの値に合わせて構成されていても、特定の組織用の値が存在しない場合、システム処理ではシステム・レベルの値が使用されます。

サイト・レベルサイト・レベルの値は、システム組織内の特定のサイトに適用されます。コントロールがサイト・レベルの値に合わせて構成されていても、特定のサイト用の値が存在しない場合、システム処理で組織の値 (存在する場合)

またはシステム・レベルの値が使用されます。

組織またはサイトの指定変更を伴うコントロールを使用するエンタープライズ・サービスまたはパブリッシュ・チャネルによって処理されるデータは、組織レベルまたはサイト・レベルでなければなりません。

コントロール・タイプ:

それぞれのビジネス・ニーズに合わせて、4 つのタイプの統合コントロール・タイプを作成することができます。

ブール型コントロール

ブール型統合コントロールは、0 (False) または 1 (True) の値を指定します。

リスト・コントロール

リスト統合コントロールには値のリストが含まれています。コントロールの複数の値を入力して、オプションでシステム・ドメインをコントロールに割り当てることができます。ドメインをコントロールに割り当てると、そのコントロールに入力された値の妥当性検査を任意のレベルで実行できます。ドメインが割り当てられない場合、入力された値の妥当性検査は行われません。

例えば、作業指示書のステータスが「承認済」または「完了」である場合のみ、作業指示書は外部システムに送信されます。作業指示書を送信するかどうかを判別するために、Java コードまたは処理ルールにより、この 2 つの値を含むリスト・コントロールと照合して作業指示書のステータスを検査することができます。

値コントロール

値の統合コントロールには単一の値が含まれていますコントロールの単一値を入力して、オプションでシステム・ドメインをコントロールに割り当てることができます。

クロス・リファレンス・コントロール

クロス・リファレンス・コントロールは 1 つの値を他の値に変換します。パブリッシュ・チャネルでは、システム値が外部システム値に変換されます。エンタープラ


イズ・サービスでは、外部システム値がシステム値に変換されます。オプションで、システム・ドメインをクロス・リファレンス・コントロールに割り当てることができます。ドメインが指定されると、コントロールに指定されたシステム値の妥当性がそのドメインと照合して検査されます。ドメインが割り当てられない場合、入力された値の妥当性検査は行われません。

クロス・リファレンス・コントロールでは、システム値と外部値の間で 1 対 1 のマッピングを行う必要があります。2 つのシステム値が 1 つの外部システム値に関連付けられている場合、または 2 つの外部システム値が 1 つのシステム値に関連付けられている場合、処理エラーが発生します。

エンタープライズ・サービスで乗法コントロールとして機能するクロス・リファレンス・コントロールを作成すると、1 対多数のマッピングが可能になります。乗法コントロールは、インバウンド・メッセージを複数の組織またはサイト用にコピー、つまり乗算するクロス・リファレンス・コントロールです。乗法コントロールには 1 つの外部値と複数のシステム値があります。

乗法コントロールは常に外部システムに固有のものです。「エンタープライズ・サービス」アプリケーションの「エンタープライズ・サービス」タブで、コントロールを乗法コントロールとして指定します。

例えば、システム・サイトは外部システムの業務部門に対応しますが、この 2 つのシステムはこれらのエンティティーに対して異なる値を使用します。クロス・リファレンス・コントロールは、2 つの値の変換を実行できます。エンタープライズ・サービスのクロス・リファレンス・コントロールは、業務部門 EX001 をシステム・サイト MX001 に変換できます。パブリッシュ・チャネルでは、このコントロールが MX001 を EX001 に変換することができます。

乗法コントロール

乗法コントロールは、システム・データベース内のすべての組織の企業を更新できます。例えば、乗法コントロールを使用してシステム内のすべての組織の企業を更新することができます。システムがエンタープライズ・サービスを使用して企業のデータを受信すると、値の更新が行われます。

新しいコントロールの作成:

エンタープライズ・サービスまたはパブリッシュ・チャネルの定義済みの処理をカスタマイズする場合、通常はコントロール値を外部システム・レベルで変更するだけで十分です。ただし、新しいビジネス・ルールが導入された場合、または新しいパブリッシュ・チャネルおよびエンタープライズ・サービスが導入された場合は、新しいコントロールの作成が必要になる場合があります。

新しいコントロールを作成する場合は、以下のガイドラインに従ってください。

v コントロール名は固有でなければなりません。

v 処理ルールの一部としてコントロールを使用する場合、および値を外部システム・レベルで設定する場合は、コントロールをパブリッシュ・チャネルまたはエンタープライズ・サービスと関連付けます。


v パブリッシュ・チャネルまたはエンタープライズ・サービスを外部システムと関連付けると、関連付けられたコントロールはすべて外部システム・レベルでコピーされます。値は外部システム・レベルで割り当てることができます。

処理ルールの構成オブジェクト構造の処理ルールは、パブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションで構成することができます。

統合コントロールまたはシステム・コントロールの評価の定義:

コントロールの評価を使用すると、指定したフィールドの値と統合コントロールの値を比較できます。コントロールの評価を使用して、指定したフィールドの値とシステム・コントロールの値 (MAXVARS 値) を比較することもできます。


統合コントロールを評価する場合、統合コントロールはブール型または値タイプでなければなりません。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、評価が適用されるサービスまたはチャネルのレコードを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、評価が適用されるオブジェクト構造を選択します。


v エンタープライズ・サービスの場合は、「オブジェクト構造の処理ルール」タブまたは「オブジェクトの処理ルール」タブで、「条件の追加/変更」をクリックします。

v パブリッシュ・チャネルの場合は、「サブレコードの処理ルール」テーブル・ウィンドウで「条件の追加/変更」をクリックします。

4. 「条件」テーブル・ウィンドウで「新規行」をクリックします。

5. 「条件」フィールドに値を入力します。この条件値によって、統合フレームワークが条件を評価する順序が決まります。

6. コントロール値とフィールド値を比較するには、以下のいずれかのラジオ・ボタンを選択して、該当するフィールドに値を入力します。

v 統合コントロール

v MAXVAR



評価タイプ XML フィールドで実行される評価のタイプを定義します。

値コントロールの評価で使用する値。



オブジェクト・フィールドの評価の定義:

オブジェクト・フィールドの評価を使用して、オブジェクト構造の定義に含まれているオブジェクト内のフィールドの値を評価することができます。WHERE 文節を使用してアクセスできるその他のビジネス・オブジェクトを評価することもできます。


アプリケーション・サーバーまたはデータベースのロケール設定に関係なく、すべての 10 進数フィールドでは、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側に数字のフォーマットはありません。このフォーマットはインバウンドとアウトバウンドのデータに適用されます。例えば、$1,738,593.64 は 1738593.64 とする必要があります。

オブジェクト・フィールドの評価を使用して、以下の評価を実行することができます。

v フィールドが Null か、または Null 以外かをチェックします。

v オブジェクト・フィールドの値を、統合コントロールまたはシステム・コントロールの値と比較します。

v オブジェクト・フィールドの値を、定義済みの値と比較します。

データが比較条件を満たしていない場合は、評価の結果として False が返されます。データが比較条件を満たしている場合は、評価の結果として True が返されます。

手順

1. パブリッシュ・チャネル・アプリケーションで、評価を適用するチャネル・レコードを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、評価を適用するオブジェクト構造を選択します。

3. 「サブレコードの処理ルール」テーブル・ウィンドウで「条件の追加/変更」をクリックします。



6. 「オブジェクト・フィールド」タブで、「新規行」をクリックします。



オブジェクト評価されるフィールドを含んでいるビジネス・オブジェクト。

オブジェクト関係定義されたビジネス・オブジェクトとルール・ビジネス・オブジェクトの間の関係。

フィールド評価されるビジネス・オブジェクト・フィールド。



評価タイプビジネス・オブジェクト・フィールドに対して実行される評価のタイプ。

次の場合に評価評価が実行される頻度。

ビジネス・オブジェクト値は、ルールが作成されるビジネス・オブジェクト内に値がない場合にのみ入力します。

8. ビジネス・オブジェクト・フィールドの値を別の値と比較するには、以下のラジオ・ボタンのいずれかを選択し、適切なフィールドに値を入力します。


v 値

v MAXVAR



オブジェクト・セットの評価の定義:

2 つのビジネス・オブジェクト間の関係にレコードが存在するかどうかを判別するには、オブジェクト・セットの評価を使用します。関係からビジネス・オブジェクト・セットが返された場合は、評価の結果として True が返されます。

手順

1. パブリッシュ・チャネル・アプリケーションで、評価を適用するチャネル・レコードを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、評価を適用するオブジェクト構造を選択します。

3. 「サブレコードの処理ルール」テーブル・ウィンドウで「条件の追加/変更」をクリックします。



6. 「オブジェクト・セット」タブで、「新規行」をクリックします。



オブジェクト評価されるフィールドを含んでいるビジネス・オブジェクト。

オブジェクト関係定義されたビジネス・オブジェクトとルール・ビジネス・オブジェクトの間の関係。

評価タイプビジネス・オブジェクト・フィールドに対して実行される評価のタイプ。




XML フィールドの評価の定義:

XML フィールドの評価を使用して、オブジェクト構造サブレコードの値を評価することができます。XML フィールドの評価を使用すると、フィールドが Null かどうかを検査したり、ビジネス・オブジェクト・フィールドの値を統合コントロール、システム値、または事前定義値と比較したりできます。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、評価が適用されるサービスまたはチャネルのレコードを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、評価が適用されるオブジェクト構造を選択します。


v エンタープライズ・サービスの場合は、「オブジェクト構造の処理ルール」タブまたは「オブジェクトの処理ルール」タブで、「条件の追加/変更」をクリックします。

v パブリッシュ・チャネルの場合は、「サブレコードの処理ルール」テーブル・ウィンドウで「条件の追加/変更」をクリックします。


5. オプション: 「条件」フィールドに値を入力します。この条件値によって、統合フレームワークが条件を評価する順序が決まります。

6. 「XML フィールド」タブで、「新規行」をクリックします。



フィールド評価される XML フィールド。

評価タイプ XML フィールドで実行される評価のタイプ。

次の場合に評価評価が実行される頻度。

8. XML フィールドの値を別の値と比較するには、以下のいずれかのラジオ・ボタンを選択して、該当するフィールドに値を入力します。


v 値

v MAXVAR

v 比較フィールド


処理ルールの定義:

処理ルールを定義して、エンタープライズ・サービスおよびパブリッシュ・チャネルのカスタム処理を実行することができます。処理ルールを使用すると、Java クラスを使用せずに、インバウンドおよびアウトバウンドのカスタム処理を実行できます。


始める前に

処理ルールを作成する前に、以下の定義について検討してください。

v エンタープライズ・サービスまたはパブリッシュ・チャネルのルールが XML フィールドを評価するか、ビジネス・オブジェクト・フィールドを評価するか。

v ルールが定義される特定のサブレコードまたはビジネス・オブジェクト。

v ルールをトリガーするアクション。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、ルールが適用されるサービスまたはチャネルを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、ルールが適用されるオブジェクト構造サブレコードを選択します。

3. エンタープライズ・サービスの場合は、以下のいずれかのアクションを実行します。

v 「オブジェクト構造の処理ルール」タブで「新規行」をクリックして、オブジェクト構造のインバウンド処理ルールを定義します。

v 「オブジェクトの処理ルール」タブで「新規行」をクリックして、ビジネス・オブジェクトのインバウンド処理ルールを定義します。

4. パブリッシュ・チャネルの場合は、「サブレコードの処理ルール」タブで「新規行」をクリックして、ビジネス・オブジェクトのアウトバウンド処理ルールを定義します。

5. 「ルール」フィールドにルール ID を入力します。

6. 「アクション」フィールドに値を入力します。

7. オブジェクトの処理ルールを適用する順序を変更するには、「順序」フィールドの値を変更します。統合フレームワークは、プライマリー・レベルのオブジェクトから順番にルールを適用します。

8. 以下のアクションを 1 つ以上実行します。

v 「プライマリー・オブジェクト挿入時に適用」チェック・ボックスをオン、またはオフにします。

v 「プライマリー・オブジェクト更新時に適用」チェック・ボックスをオン、またはオフにします。

v 「プライマリー・オブジェクト削除時に適用」チェック・ボックスをオン、またはオフにします。

上記の設定は、オブジェクト構造内のプライマリー・ビジネス・オブジェクトに行が挿入、更新、または削除されるときに、統合フレームワークが処理ルールを適用するかどうかを決定します。

9. 「エンタープライズ・サービスの保存」または「パブリッシュ・チャネルの保存」をクリックします。

処理ルールの有効化:

処理ルールをエンタープライズ・サービス・オブジェクトまたはパブリッシュ・チャネル・オブジェクトに適用するには、処理ルールを有効にする必要があります。


有効になっている処理ルールは、インバウンドおよびアウトバウンドのカスタム処理を実行する準備ができていることを示します。


事前定義された処理ルールを無効にすると、統合フレームワークの処理エラーが発生することがあります。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、有効にする処理ルールが含まれているサービスまたはチャネルを表示します。

2. 「オブジェクト構造サブレコード」テーブル・ウィンドウで、処理ルールが適用されるオブジェクト構造サブレコードを選択します。

3. 処理ルールを有効にするか無効にするかを指定します。




エンタープライズ・サービスの場合は、「オブジェクト構造の処理ルール」タブまたは「オブジェクトの処理ルール」タブで、処理ルールを有効または無効に設定できます。パブリッシュ・チャネルの場合は、「サブレコードの処理ルール」タブで、処理ルールを有効または無効に設定できます。

4. 「エンタープライズ・サービスの保存」または「パブリッシュ・チャネルの保存」をクリックします。

コントロールの追加:

統合コントロールを使用して、任意のエンタープライズ・サービスまたはパブリッシュ・チャネルの動作を、個々の組織およびサイトの要件に応じて構成します。コントロールのタイプとしては、ブール型コントロール、クロス・リファレンス・コントロール、リスト・コントロール、および値コントロールがあります。

ブール型コントロールの追加:

True または False の値を指定する統合コントロールが必要な場合は、ブール型のコントロールを追加できます。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価にこのブール型コントロールを使用できます。コントロールに割り当てる True または False の値によって、エンタープライズ・サービスまたはパブリッシュ・チャネルが処理ルールをトランザクションに適用するかどうかが決まります。

手順

1. エンタープライズ・サービス・アプリケーションで、「アクションの選択」メニューから「統合コントロールの作成」を選択します。

2. 「新規コントロールの追加」 > 「新規ブール型コントロールの追加」をクリックします。

3. 「統合コントロール」フィールドに、ブール型コントロールの ID を入力します。


4. ブール型コントロールのデフォルト値を True にするか False にするかを指定します。

オプションデフォルト True

True 値選択

False 値クリア

5. 「OK」をクリックして「ブール型コントロール」ダイアログ・ボックスを閉じます。

6. 「OK」をクリックして「統合コントロールの作成」ダイアログ・ボックスを閉じます。

例

ブール型コントロールを使用して、エンタープライズ・サービスまたはパブリッシュ・チャネルが注文書トランザクションを送受信するかどうかを示すことができます。トランザクションをスキップするための処理ルール・アクションをエンタープライズ・サービスまたはパブリッシュ・チャネルに設定できます。ブール型コントロールに割り当てたデフォルト値が True の場合で、かつ処理ルールの評価が True

であると、エンタープライズ・サービスまたはパブリッシュ・チャネルは注文書トランザクションの更新内容を送受信します。

次のタスク

エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けることができます。この関連付けにより、統合コントロールをインバウンドおよびアウトバウンド・メッセージ処理に使用できるようになります。外部システム・アプリケーションで、統合コントロールを外部システムに関連付けることもできます。外部レベルでコントロールに定義した値は、エンタープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで定義されたコントロール値を上書きします。

クロス・リファレンス・コントロールの追加:

ある値を別の値に置き換える統合コントロールが必要な場合は、クロス・リファレンス・タイプの統合コントロールを追加します。複数の組織またはサイトにわたって、インバウンド・メッセージ内またはアウトバウンド・メッセージ内の値を置換できます。クロス・リファレンス・コントロールにより、資産管理システムの値と外部システムの値との間で変換を実行できます。


パブリッシュ・チャネルは、クロス・リファレンス・コントロールを使用して、アウトバウンド資産管理システム値を外部システム値に変換します。エンタープライズ・サービスは、クロス・リファレンス・コントロールを使用して、インバウンド外部システム値を資産管理システム値に変換します。シノニムを使用する場合は、内部のアプリケーション値ではなく、外部の値をコントロール値として入力します。コントロール値として 10 進数を入力する場合は、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側の数字は


変換されません。例えば、$1,738,593.64 は 1738593.64 とする必要があります。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、「統合コントロールの作成」アクションを選択します。

2. 「新規コントロールの追加」 > 「新規 XRef コントロールの追加」をクリックします。



統合コントロール値コントロールの ID。

ドメイン統合コントロールに入力された値のチェックに使用するドメイン。

4. 「値」テーブル・ウィンドウで「新規行」をクリックします。



デフォルト値外部システム値に変換される値、または外部システム値から変換される値。

デフォルトの外部の値デフォルト値に変換される外部システム値、またはデフォルト値から変換される外部システム値。



例

資産管理システム・サイトは外部システムの業務部門に対応しますが、2 つの外部システムはこれらのエンティティーに対して異なる値を使用します。クロス・リファレンス・コントロールは、一致しないこの 2 つの値と、資産管理システム値との間の変換を実行できます。

エンタープライズ・サービスのクロス・リファレンス・コントロールは、外部システム・サイト値 EX001 を資産管理システム・サイト値 MX001 に変換できます。

次のタスク

エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けることができます。この関連付けにより、統合コントロールをインバウンドおよびアウトバウンド・メッセージ処理に使用できるようになります。外部システム・アプリケーションで、統合コントロールを外部システムに関連付けることもできます。外部レベルでコントロールに定義した値は、エン


タープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで定義されたコントロール値を上書きします。

リスト・コントロールの追加:

値の一覧を含むコントロールが必要な場合は、リスト・タイプの統合コントロールを作成します。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価にこのリスト・コントロールを使用できます。このルールにより、データ・フィールドの値が定義済みのどのリスト・コントロール値にも一致しない場合は、トランザクションの処理がスキップされる可能性があります。


コントロール値として 10 進数を入力する場合は、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側の数字は変換されません。例えば、$1,738,593.64 は 1738593.64 とする必要があります。

手順

1. エンタープライズ・サービス・アプリケーションで、「アクションの選択」メニューから「統合コントロールの作成」を選択します。

2. 「新規コントロールの追加」 > 「新規リスト・コントロールの追加」をクリックします。





4. 「値」テーブル・ウィンドウで「新規行」をクリックします。

5. 「デフォルト値」フィールドに、評価用の値を入力します。

6. 「OK」をクリックして「リスト・コントロール」ダイアログ・ボックスを閉じます。


例

作業指示書のステータスが「承認済」または「完了」である場合のみ、作業指示書は外部システムに送信されます。処理ルールでは、この 2 つのステータス値を含むリスト・コントロールと照合して作業指示書のステータスを検査することができます。作業指示書のステータスが 2 つのリスト・コントロール値と一致しない場合、作業指示書トランザクションは外部システムに送信されません。

次のタスク

エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けることができます。この関連付けにより、統合コントロールをインバウンドおよびアウトバウンド・メッセージ処理に使用できるよう


になります。外部システム・アプリケーションで、統合コントロールを外部システムに関連付けることもできます。外部レベルでコントロールに定義した値は、エンタープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで定義されたコントロール値を上書きします。

値コントロールの追加:

単一値を持つコントロールが必要な場合は、値タイプの統合コントロールを作成できます。エンタープライズ・サービスまたはパブリッシュ・チャネルでは、処理ルールの評価にこの値コントロールを使用できます。このルールにより、データ・フィールドの値が定義済みのコントロール値と一致しない場合は、トランザクションの処理がスキップされる可能性があります。


コントロールにデフォルトのコントロール値に提供し、ドメインを割り当てて、そのコントロールに入力した値の有効性チェックを実行できます。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションの「アクションの選択」メニューから、「統合コントロールの作成」を選択します。

2. 「新規コントロールの追加」 > 「新規値コントロールの追加」をクリックします。





デフォルト値統合コントロールのデフォルト値。

4. 「OK」をクリックして「値コントロール」ダイアログ・ボックスを閉じます。


例

注文書は、企業タイプ値が「EX」の場合のみ、資産管理システムによって受信されます。注文書を受信するかどうかを決定するため、処理ルールでは、コントロールに定義されている値と照合して企業タイプの値を検査できます。企業の値 EX がコントロールに含まれる値と一致しない場合、注文書トランザクションは資産管理システムに送信されません。

次のタスク

エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けることができます。この関連付けにより、統合コントロールをインバウンドおよびアウトバウンド・メッセージ処理に使用できるよう


になります。外部システム・アプリケーションで、外部システムに統合コントロールを設定することもできます。外部システム・レベルでコントロールに定義した値は、エンタープライズ・サービス・レベルまたはパブリッシュ・チャネル・レベルで定義されたコントロール値を上書きします。

統合コントロールとエンタープライズ・サービスまたはパブリッシュ・チャネルの関連付け:

統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けると、コントロールをインバウンドおよびアウトバウンド・メッセージ処理に使用できるようになります。エンタープライズ・サービスまたはパブリッシュ・チャネルは、1 つ以上の統合コントロールと関連付けることができます。


統合コントロールをエンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けると、サービスまたはチャネルのレベルで設定されたコントロールの事前定義値を上書きできます。個々の組織およびサイトの要件に応じて、統合コントロールをグローバルに定義し、外部システムごとにコントロールを構成することができます。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、統合コントロールを関連付けるサービスまたはチャネルを表示します。

2. 「統合コントロールの関連付け」アクションを選択します。



統合コントロールを個別に選択する 1. 「新規行」をクリックします。

2. 「統合コントロール」フィールドにコントロール値を入力します。

複数の統合コントロールを選択する 1. 「コントロールの選択」をクリックします。

2. 適切なコントロールを選択します。


4. 「OK」をクリックして「統合コントロールの関連付け」ダイアログ・ボックスを閉じます。

サブレコード・フィールドのデータの管理:

統合の一環として、単一ソース・データ・フィールドの値を処理し、値の設定、値の結合、値の分割、または値の置換を行うことができます。

サブレコード・フィールドの値の設定:

指定したデータ・フィールドに値を割り当てて、そのデータ・フィールドの既存の値を上書きすることができます。値を常に割り当てるか、ターゲット・データ・フィールドが Null の場合にのみ割り当てるかを指定できます。


始める前に

サブレコード・フィールドの値を設定するには、設定アクションを含む処理ルールを作成する必要があります。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、サブレコード・フィールドの設定アクションが適用されるサービスまたはチャネルのレコードを表示します。

2. 「エンタープライズ・サービス」または「パブリッシュ・チャネル」タブで、サブレコード・フィールドの設定アクションが適用される処理ルールを選択します。


v エンタープライズ・サービスの場合は、「オブジェクト構造の処理ルール」タブまたは「オブジェクトの処理ルール」タブで、「サブレコード・フィールド」をクリックします。

v パブリッシュ・チャネルの場合は、「サブレコードの処理ルール」テーブル・ウィンドウで「サブレコード・フィールド」をクリックします。


5. 「フィールド」フィールドに、ターゲット・データ・フィールドの名前を入力します。この値は、置換するフィールドを定義します。

6. 値を常に割り当てるか、ターゲット・データ・フィールドが Null の場合にのみ割り当てるかを指定します。

オプション Null のときに交換

データ・フィールドが Null のときに割り当てる

選択

常に割り当てるクリア

7. ソース・フィールドを指定するには、以下のいずれかのラジオ・ボタンを選択して、該当するフィールドに値を入力します。


v MAXVAR

v フィールド



サブレコード・フィールドの値の結合:

複数のソース・データ・フィールドまたは統合コントロールの値を結合して、1 つのターゲット・データ・フィールドにすることができます。資産管理システム値と外部システム値の間で不一致が生じた場合は、値を結合できます。例えば、2 つの部分から成る外部システム・キーを、資産管理システム内の 1 つの部分から成るキーにマップできます。


始める前に

サブレコード・フィールドの値を結合するには、結合アクションを含む処理ルールを作成する必要があります。



手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、サブレコード・フィールドの結合アクションが適用されるサービスまたはチャネルのレコードを表示します。

2. 「エンタープライズ・サービス」または「パブリッシュ・チャネル」タブで、サブレコード・フィールドの結合アクションが適用される処理ルールを選択します。




4. 「対象サブレコード・フィールド」テーブル・ウィンドウで、以下のいずれかのアクションを実行します。


ターゲット・フィールドを個別に選択する 1. 「新規行」をクリックします。

2. 「フィールド」フィールドに、ターゲット・データ・フィールドを入力します。

3. 「区切り記号統合コントロール」フィールドに、ターゲット・フィールド内のセグメントを分離する区切り文字の値を入力します。

複数のターゲット・フィールドを一度に選択する

1. 「フィールドの選択」をクリックします。

2. 適切なフィールドを選択します。




5. 「ターゲットのソース・サブレコード・フィールド」テーブル・ウィンドウで、以下のいずれかのアクションを実行します。


ソース・フィールドを個別に選択する 1. 「新規行」をクリックします。

2. 以下のいずれかのラジオ・ボタンを選択して、該当するフィールドに値を入力します。

v フィールド


3. 「順序」フィールドに値を入力して、アプリケーションがソース・フィールドのセグメントをターゲット・フィールドに移動する順序を定義します。

複数のソース・フィールドを一度に選択する 1. 「フィールドの選択」をクリックします。





サブレコード・フィールドの値の分割:

単一ソース・データ・フィールドの値を複数のターゲット・フィールドに分割できます。資産管理システム値と外部システム値の間で不一致が生じる場合は、値を分割できます。例えば、1 つの部分から成る資産管理システム・キーを、外部システム内の 2 つの部分から成るキーにマップできます。

始める前に

サブレコード・フィールドの値を分割するには、分割アクションを含む処理ルールを作成する必要があります。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、サブレコード・フィールドの分割アクションが適用されるサービスまたはチャネルのレコードを表示します。

2. 「エンタープライズ・サービス」または「パブリッシュ・チャネル」タブで、サブレコード・フィールドの分割アクションが適用される処理ルールを選択します。





4. 「対象サブレコード・フィールド」テーブル・ウィンドウで、以下のいずれかのアクションを実行します。


ターゲット・フィールドを個別に選択する 1. 「新規行」をクリックします。

2. 「フィールド」フィールドに、ターゲット・データ・フィールドを入力します。


複数のターゲット・フィールドを一度に選択する





5. 「ソースのターゲット・サブレコード・フィールド」テーブル・ウィンドウで、以下のいずれかのアクションを実行します。


ソース・フィールドを個別に選択する 1. 「新規行」をクリックします。

2. 「フィールド」フィールドに、ソース・データの最初のセグメントまたは次のセグメントを受け取るターゲット・フィールドの名前を入力します。

3. 「区切り記号統合コントロール」フィールドに値を指定しなかった場合は、「フィールド長」フィールドに数値を入力します。




複数のソース・フィールドを一度に選択する




4. 「区切り記号統合コントロール」フィールドに値を指定しなかった場合は、「フィールド長」フィールドに数値を入力します。



サブレコード・フィールドの値の置き換え:

データ・フィールドの値を別の値に置き換えることができます。同じエンティティーの ID が外部システムと資産管理システムで異なる場合に、値を置換できます。例えば、外部システムの工場 ID を、資産管理システムのサイト ID に変換できます。

始める前に

サブレコード・フィールドの値を置き換えるには、置換アクションを含む処理ルールを作成する必要があります。データ・フィールドの元の値と新しい値を含むクロス・リファレンス・コントロールも作成する必要があります。

手順

1. エンタープライズ・サービス・アプリケーションまたはパブリッシュ・チャネル・アプリケーションで、サブレコード・フィールドの置換アクションが適用されるサービスまたはチャネルのレコードを表示します。

2. 「エンタープライズ・サービス」または「パブリッシュ・チャネル」タブで、サブレコード・フィールドの置換アクションが適用される処理ルールを選択します。





5. 「フィールド」フィールドに、ターゲット・データ・フィールドの名前を入力します。この値は、置換するフィールドを定義します。対象フィールドは、ダイアログ・ボックスの上部に表示されるサブレコード・オブジェクト内に存在している必要があります。


6. 「統合コントロール」フィールドに、ターゲット・フィールドの元の値と新しい値を含むクロス・リファレンス・タイプ・コントロールの名前を入力します。


コード・ベースのカスタマイズ統合フレームワークには、トランザクション処理をカスタマイズするロジックを指定するための独自のコードを挿入できるプレースホルダーが、トランザクション・フロー内に用意されています。オブジェクト構造、パブリッシュ・チャネル、エンタープライズ・サービス、および呼び出しチャネルの処理内の選択したポイントに、Java クラスまたは自動化スクリプトを挿入することができます。メッセージを変換するための XSL マップを使用することもできます。

Java クラス・ファイルを作成または更新するときには、統合コンポーネントが使用できるように、アプリケーション EAR ファイルの再ビルドと再デプロイを行う必要があります。自動化スクリプト・アプリケーションで、サポートされるいずれかのスクリプト言語でスクリプトを作成するか、または外部で作成したスクリプトをインポートした後、すぐに使用できるようにアクティブにすることができます。XSL マップを作成または更新する場合は、アプリケーション EAR ファイル、またはご使用のファイル・システム上のディレクトリーに XSL マップを保存できます。

カスタマイズ・コードが使用できるように構成されると、統合フレームワークによって、トランザクション処理中の該当するポイントで、そのコードが呼び出されます。

サンプルの Java クラス・ファイルまたは XSL ファイルは IBM Tivoli® Open

Process Automation Library (OPAL) からダウンロードできます。

カスタマイズ Java クラスおよびメソッドJava クラスを使用して、アウトバウンド・メッセージおよびインバウンド・メッセージの標準処理を拡張することができます。メッセージの処理フローには、いくつものプレースホルダーが存在します。このプレースホルダーに、メッセージの内容または処理、あるいはこの両方に影響を与えるカスタム Java コードを挿入することができます。

外部出口クラス:

外部出口クラスが提供する基本クラス ExternalExit を拡張して、パブリッシュ・チャネル、エンタープライズ・サービス、および呼び出しチャネルの処理をカスタマイズすることができます。

アウトバウンド・メッセージでの外部出口クラスの入力は、XML メッセージのirData エレメントです。クラス処理の出力は XML メッセージの erData エレメントで、ターゲットの宛先に送信されます。インバウンド・メッセージでの外部出口クラスの入力は、インバウンド・メッセージの erData エレメントです。出力はirData エレメントで、Maximo Asset Management 内での処理のために関連するオブジェクト構造に送信されます。


外部出口クラスをカスタマイズに使用するには、パブリッシュ・チャネル・アプリケーションまたは呼び出しチャネル・アプリケーションで「処理クラス」フィールドに Java クラスを指定します。

統合カスタマイズには、ユーザー出口クラスを実装する方法もあります。Oracle または SAP 用のアダプターがインストールされている場合は、定義済みの処理クラスが提供されているため、ユーザー出口クラスを使用してカスタマイズを実行する必要があります。定義済みの処理クラスがない場合は、外部出口クラスまたはユーザー出口クラスのどちらでカスタム・コードを実装するかを選択できます。

ユーザー出口クラス:

パブリッシュ・チャネル、エンタープライズ・サービス、または呼び出しチャネルのインバウンド・トランザクションおよびアウトバウンド・トランザクションでは、ユーザー出口クラスにプリプロセッサー・メソッドとポストプロセッサー・メソッドを定義することができます。インバウンド・トランザクションの場合は、追加のメソッドとして、ビジネス・オブジェクトをデータベースにコミットする前に処理するメソッドをユーザー出口クラスに定義できます。

アウトバウンド・トランザクションのプリプロセッシング・メソッド:

最初のアウトバウンド・ユーザー出口点への入力は、オブジェクト構造によって生成される XML です。ERP アダプター処理クラスを使用している場合は、それぞれの要件に応じて、プリプロセッシング・メソッドまたはポストプロセッシング・メソッドを使用してカスタム・ロジックを実装することができます。

プリプロセッシング出口点を使用すると、メッセージ内のデータを変更できます。この変更は、後から実装されたときに、処理クラスの処理ロジックを変更します。

プリプロセッサー・メソッドでアウトバウンド・メッセージをカスタマイズするには、以下のメソッドを使用します。

public StructureData setUserValueOut(StructureData irData)

このメソッドは次の処理を実行することができます。

v データを検証する。

v 外部システムに送信する IR レコードを変更してシステム・データを変更する。

v システム例外をスローして、Maximo Asset Management からのメッセージの送信を停止する。メッセージ全体がロールバックされます。メッセージがイベントによって開始される場合も、アプリケーションで行った変更も含めてメッセージ全体がロールバックされます。

v SKIP_TRANSACTION 例外をスローして、メッセージの外部システムへの送信を停止する。

v トランザクションをログに記録する。

アウトバウンド・トランザクションのポストプロセッシング・メソッド:

ユーザー出口のポストプロセッシング・メソッドでは、オブジェクト構造からの IR

エレメントおよび処理クラスの XML 出力からの ER エレメントの両方を、処理に使用することができます。


アウトバウンド・メッセージをカスタマイズするには、次のメソッドを使用します。

public StructureData setUserValueOut(StructureData irData, StructureData erData)



v 外部システムに送信する ER レコードを変更してデータを変更する。

v irData エレメントから erData エレメントに追加データをマップする。

v システム例外をスローして、Maximo Asset Management からのトランザクションの送信を停止する。メッセージ全体がロールバックされます。メッセージがイベントによって開始される場合も、アプリケーションで行った変更も含めてメッセージ全体がロールバックされます。

v SKIP_TRANSACTION 例外をスローして、メッセージの外部システムへの送信を停止する。


パブリッシュ・チャネル・ユーザー出口クラスの指定は、「パブリッシュ・チャネル」アプリケーションで行います。

インバウンド・トランザクションのプリプロセッシング・メソッド:

インバウンド・トランザクションのプリプロセッシング・メソッドでは、外部システムから配信される XML メッセージが入力となります。必要に応じてメッセージ内のデータを変更し、処理クラスの処理ロジックに影響を与えることができます。

インバウンド・トランザクションのカスタマイズは、最初の出口で次のメソッドを使用して実行することができます。

public StructureData setUserValueIn(StructureData erData)



v ER レコードが IR レコードにマップされ、システムに保存される前に、その ER

レコードを変更して外部データを変更する。

v 例外をスローしてそれ以降のトランザクション処理を停止する。キュー・ベースのメッセージの場合は、トランザクションが再処理のためにキューに残されます。キュー・ベースでないメッセージの場合は、エンタープライズ・サービスを開始したクライアントにメッセージが返されます。

v SKIP_TRANSACTION 例外をスローして、Maximo Asset Management 内でのメッセージの処理を停止する。この場合、メッセージはシステムに保存されません。キュー・ベースのメッセージの場合、メッセージはキューから削除されます。


インバウンド・トランザクションのポストプロセッシング・メソッド:

インバウンド・トランザクションのポストプロセッシング・メソッドでは、IR とER の両方のレコードを処理に使用できます。


インバウンド・トランザクションのカスタマイズは、次のメソッドを使用してポストプロセッシング・フローで実行することができます。

public StructureData setUserValueIn(StructureData irData, StructureData erData)



v システムに保存する IR レコードを変更して外部データを変更する。

v ER レコードから IR レコードに追加データをマップする。

v 例外をスローしてそれ以降のトランザクション処理を停止する。キュー・ベースのメッセージの場合は、トランザクションが再処理のためにキューに残されます。キュー・ベースでないメッセージの場合は、エンタープライズ・サービスを開始したクライアントにメッセージが返されます。

v skip_transaction 例外をスローして、Maximo Asset Management 内でのメッセージの処理を停止する。この場合、メッセージはシステムに保存されません。キュー・ベースのメッセージの場合、メッセージはキューから削除されます。


エンタープライズ・サービス・ユーザー出口クラスの指定は、エンタープライズ・サービス・アプリケーションで行います。

インバウンド・トランザクションでのビジネス・オブジェクトの処理:

エンタープライズ・サービスのユーザー出口クラスには、setUserMboIn という追加のメソッドがあります。このメソッドは、ビジネス・オブジェクトがオブジェクト構造 XML から作成されたが、まだデータベースに保存されていない時点でのカスタム処理を可能にします。

このユーザー出口はシステム処理の後に呼び出され、次のメソッドを使用して、システム内で作成されたオブジェクトに対して実行することができます。

public void setUserMboIn(MboRemote mbo)

オブジェクト・パラメーターは、オブジェクト構造内のプライマリー・オブジェクトへの参照です。

このメソッドは、プライマリー・オブジェクトに対して 1 回呼び出されます。複数の名詞を含む XML トランザクションでは、各名詞ごとにオブジェクト出口が 1 回呼び出さされます。



v システム例外をスローして、システムへのトランザクションの保存を停止する。キュー・ベースのメッセージの場合、トランザクションはキューに残され、再試行されます。


ユーザー出口クラスの指定は、エンタープライズ・サービス・アプリケーションで行います。


イベント・フィルター・クラス:

パブリッシュ・チャネルを使用する非同期アウトバウンド・トランザクションに対し、イベント・フィルター・クラスを使用してカスタム Java クラスまたは自動化スクリプトを実行できます。イベント・フィルター・クラスの処理は、アウトバウンド・メッセージのオブジェクト構造層でデータがシリアライズされる前に行われます。イベント・フィルター・クラスは、この処理ポイントで、統合メッセージの作成に影響するロジックを挿入できます。

イベント・フィルター・クラスの主な用途は、シリアライズ・プロセスでのデータ量を削減するために、メッセージから不要なフィールドやオブジェクトを削除するロジックを組み込むことです。クラスのもう 1 つの一般的な用途は、インバウンド統合からのイベントがアウトバウンド統合メッセージを送信することを阻止するデフォルトの反復ロジックをオーバーライドすることです。このシナリオでデフォルトの動作をオーバーライドすると、インバウンド・メッセージによってトリガーされたイベントからアウトバウンド・メッセージを開始できるようになります。

ハンドラー出口クラス:

データを外部システム (HTTP、Enterprise Java Beans 呼び出し、インターフェース・テーブルなど) に送信できるように、複数の定義済みメソッド (ハンドラー) が提供されています。これらのメソッドの一部に、カスタマイズに使用できるユーザー出口プレースホルダーがあります。

Enterprise Bean 処理のユーザー出口クラス:

クラスのカスタマイズ用の出口プレースホルダーは、Enterprise Bean によってトランザクションが外部システムに送信されるときに使用することができます。この出口クラスはオプションであり、Enterprise Bean が呼び出される前に呼び出されます。

この Java クラスの実装では、このハンドラーが開始する Enterprise Bean のメソッド・シグニチャーと、そのメソッドに必要なパラメーターを解決する必要があります。このプロパティーに値が指定されない場合、DefaultEJBExit というデフォルト出口がシステムによって適用されます。このデフォルト出口は Enterprise Bean メソッド・シグニチャーおよびパラメーターの解決を試みます。

このクラスは psdi.iface.router.EJBExit インターフェースおよび次のメソッドを実装する必要があります。

v getClassParams() メソッドは、メソッド・シグニチャーを Java クラスの配列の形式で返します。

public Class getClassParams()

v getObjectParams メソッドは、Enterprise Bean のパラメーターの配列を Java オブジェクトの配列で返します。

public Object[] getObjectParams(byte[] data, String interfaceName, String

destinationName)

v Enterprise Bean が正常に呼び出された後に、呼び出しの応答としてのオブジェクトを指定して responseOk() メソッドが呼び出されます。

public void responseOk(Object response)throws MXException


v Enterprise Bean の呼び出し中にエラーが検出されると、原因となった例外がパラメーターとして指定されて responseError() メソッドが呼び出されます。


Enterprise Bean ハンドラーを実装するエンドポイントの EJBEXIT プロパティーに、Java クラスの完全修飾名を入力します。

HTTP 処理のユーザー出口クラス:

HTTP を使用して外部システムにアウトバウンド・トランザクションを送信する際に、HTTP 出口プレースホルダーを使用してカスタマイズすることができます。この出口クラスはオプションであり、HTTP 呼び出しからの応答に含めて呼び出されます。

HTTP 処理出口クラスは、応答が外部システムから HTTP ポストに返されるときに実行されます。psdi.iface.router.DefaultHTTPExit クラスのデフォルトの実装では、外部システムから受信された応答コードが、ある範囲の応答コードと比較されます。デフォルトの実装で使用される範囲は、200 から 299 です。コードがこの範囲から外れている場合は、トランザクションが外部システムに送信されておらず、例外が発行されます。

一部の外部システムでは、その外部システムがメッセージを受け入れたかどうかを確認するために HTTP 呼び出しからの応答が解釈されます。この解釈のロジックは、HTTP 出口クラスに実装することができます。

パブリッシュ・チャネル・メッセージが受け入れられない場合、コードで例外を発行する必要があります。アウトバウンド・キュー内の該当のメッセージにエラーのマークが付けられ、そのメッセージはキューから除去されません。メッセージが受け入れられた場合、そのメッセージはアウトバウンド用のキューから除去されます。呼び出しチャネルのメッセージが失敗だった場合、例外がチャネルの呼び出し側に返され、呼び出し側は設計上の要件に従ってその例外を処理します。

HTTP 処理出口クラスは psdi.iface.router.HTTPExit インターフェースおよび次のメソッドを実装する必要があります。

public void processResponseData(int responseCode, String responseMsg,

byte[] msgBodyData)

必要な場合は、このクラスが応答コードを解釈し、例外をスローします。クラスでは、以下のアクションを実行できます。

v HTTP ポストからの応答コードを検査します。

v 応答コードがエラー範囲に入っている場合、ERROR レベルで例外が記録され、システム例外がスローされます。

v 応答コードが有効な場合、そのトランザクションは DEBUG レベルで記録されます。

HTTP ハンドラーを実装するエンドポイントの HTTPEXIT プロパティーには、Java

クラスの完全修飾名を指定する必要があります。


JMS 処理のユーザー出口クラス:

JMS を使用してシステムから外部システムにトランザクションを送信する際に、出口プレースホルダーを使用してカスタマイズすることができます。この出口クラスはオプションであり、JMS が呼び出される前に呼び出されます。

このクラスは psdi.iface.router.JMSExit クラスおよび次のメソッドを実装する必要があります。

public Map getMessageProperties(Map metaData, (byte[] data, Map

origProps)throws MXException


v JMS メッセージのプロパティーを変更する

v JMS メッセージと一致するように、データを複数のプロパティーに分割する

JMS ハンドラーを実装するエンドポイントの JMSEXIT プロパティーに、Java クラスの完全修飾名を入力します。

Web サービス処理のユーザー出口クラス:

Web サービスを使用してシステムから外部システムにトランザクションを送信する際に、出口プレースホルダーを使用してカスタマイズすることができます。この出口クラスはオプションであり、Web サービスが開始される前に呼び出されます。

このクラスは psdi.iface.router.WSExit インターフェースおよび次のメソッドを実装する必要があります。

getServiceName() メソッドgetServiceName() メソッドは、開始される Web サービスのサービス名を返します。

public String getServiceName(Map metaData, String endpointURL,

String serviceName, String interfaceName, String targetNameSpace)

throws MXException

getEndpointURL() メソッドgetEndpointURL() メソッドは、開始される Web サービスのエンドポイント URL を返します。

public String getEndpointURL(Map metaData, String endpointURL,

String serviceName, String interfaceName, String targetNameSpace)

throws MXException

responseOk() メソッドresponseOk() メソッドは、外部の Web サービスが正常に呼び出された後に呼び出されます。

public void responseOk(org.w3c.dom.Document response) throws

MXException


responseError() メソッドWeb サービスの呼び出し中にエラーが検出されると、原因となった例外がパラメーターとして指定されて responseError() メソッドが呼び出されます。


getOneWayWsInfo() メソッドgetOneWayWsInfo() メソッドは、開始する Web サービスが片方向かどうかを指定するブール値を返します。

public boolean getOneWayWsInfo(Map metaData, String endpointURL,

String serviceName, String interfaceName, String targetNameSpace,

boolean oneWayWs) throws MXException

getSoapAction() メソッドgetSoapAction() メソッドは、Web サービスを開始する際に使用するSOAPAction HTTP ヘッダーを返します。

public String getSoapAction(Map metaData, String endpointURL, String

serviceName, String interfaceName, String targetNameSpace, String

soapAction) throws MXException

Web サービス・ハンドラーを実装するエンドポイントの WSEXIT プロパティーには、Java クラスの完全修飾名を指定する必要があります。

psdi.iface.router.DefaultWSExit クラスは、WSExit インターフェースのデフォルトの実装です。このクラスは、getEndpointURL() メソッドをオーバーライドして、エンドポイント URL の末尾にサービス名を連結して新しいエンドポイント URL

を形成します。

自動化スクリプトを使用したカスタマイズ事前定義された統合コンポーネントに対して、Java クラスの代わりに自動化スクリプトを使用して、主要な Java 処理クラスを拡張することができます。自動化スクリプトを使用して、オブジェクト構造、パブリッシュ・チャネル、エンタープライズ・サービス、および呼び出しチャネルの処理中のさまざまなポイントでカスタム・ロジックを適用することができます。

自動化スクリプト・アプリケーションを使用して、統合のための自動化スクリプトを定義します。統合のためのスクリプトの定義によって、スクリプトをどの統合コンポーネントに関連付けるか、およびスクリプトを処理フロー内のどのポイントで実行するかを指定します。スクリプトをテストするために、ログ・レベルを「デバッグ」に設定して、スクリプトをアクティブ化し、データのインポートまたはデータのエクスポート機能を使用して、統合トランザクションを開始することができます。

統合のための自動化スクリプトの作成:

自動化スクリプトは、インバウンド・トランザクションおよびアウトバウンド・トランザクションについての統合メッセージの処理をカスタマイズできます。自動化スクリプトを統合コンポーネントに関連付け、統合処理に挿入するタイミングを構成します。


手順

1. 自動化スクリプト・アプリケーションで、「作成」 > 「統合のスクリプト」アクションを選択します。

2. 自動化スクリプトに関連付ける統合コンポーネントを指定し、次にスクリプトを挿入する位置を指定します。

3. オプション: スクリプトを即時にアクティブにする場合は、「アクティブにする」チェック・ボックスをオンにします。

4. オプション: スクリプトを実行するときに適用するロギング・レベルを指定します。テスト目的でロギング・レベルをデバッグに設定した場合、ログにはすべての問題をトラブルシューティングする際に役立つ有用な情報が含まれます。

5. スクリプトのスクリプト言語を指定します。

6. 「ソース・コード」フィールドにスクリプトを直接入力するか、スクリプトが保管されているロケーションを参照して「インポート」をクリックします。


自動化スクリプトを使用したオブジェクト構造の処理のカスタマイズ:

オブジェクト構造の処理では、カスタマイズのために自動化スクリプトと Java クラスを併用することができます。オブジェクト構造に定義された自動化スクリプトは、オブジェクト構造によって直接処理されるデータの処理 (REST API など) や、パブリッシュ・チャネル、エンタープライズ・サービスなどの他の統合コンポーネントによって処理されるデータの処理に影響を与えます。

自動化スクリプトを使用したオブジェクト構造処理のカスタマイズのための挿入ポイント:

統合処理中にオブジェクト構造を変換する Java 定義クラスおよび Java 処理クラスに、スクリプト・ベースの処理を挿入することができます。

この図は、オブジェクト構造のインバウンド処理およびアウトバウンド処理を行っているときの自動化スクリプトの挿入を示します。


��コンポーネント

---- REST API OSLC API- Web- Web-

-

パブリッシュ・チャネルエンタープライズ・サービスびしチャネル

およびサービスサービス

アプリケーションのインポートおよびエクスポートマイグレーション・マネージャー

� �

��

��のターゲットとソース

-( : )

- Maximo-

ファイルスプレッドシートアプリケーション

システム

��

Maximo Asset Management

アウトバウンド �

インバウンド �

Maximo ��フレームワーク


オブジェクト��


Java��クラス

��スクリプト


Java �クラス


オブジェクト構造のアウトバウンド処理では、ビジネス・オブジェクト・データのXML メッセージへのシリアライゼーションの実行中にカスタム処理を挿入できるようにする Java 定義クラスを実装します。また、オブジェクト構造の処理をカスタマイズする自動化スクリプトを実装することもできます。統合フレームワークでは、オブジェクト構造の Java クラスまたは自動化スクリプトとしてのカスタマイズ、あるいはこの両方を併用したカスタマイズがサポートされます。

オブジェクト構造のインバウンド処理では、インバウンド XML メッセージからのデータがビジネス・オブジェクト・データにマップされる前に、そのデータのカスタム処理を挿入できるようにする Java 処理クラスを実装します。オブジェクト構造内で処理をカスタマイズするために、Java 処理クラスに加えて、自動化スクリプトを実装することができます。

オブジェクト構造のアウトバウンド処理:

オブジェクト構造のアウトバウンド処理では、ビジネス・オブジェクト (mbo) データの XML メッセージへのシリアライゼーションを行います。この処理の間に、自動化スクリプトによってカスタムの処理ロジックを挿入することで、オブジェクト構造のデフォルトの処理動作を変更できます。スクリプトを Java 定義クラスの代わりに使用することも、両方を併用することもできます。

シリアライゼーションでは、skipMbo(ctx) などの関数が使用されます。関数名に含まれる ctx は、統合フレームワークによって用意される関数内のオブジェクトで、統合フレームワークと自動化スクリプトの間でデータのやり取りを行います。自動


化スクリプトを使用すると、データの処理に影響を与えることができ、それらの変更を統合フレームワークに通知することができます。

シリアライゼーションに含まれる関数のうち、カスタマイズされたロジックをデータ処理に挿入するために自動化スクリプトが使用できるものは以下のとおりです。

skipMbo(ctx)XML メッセージからオブジェクト・データをフィルタリングします。XML

メッセージからデータをフィルタリングし、XML メッセージ内の必要なデータを引き続き処理して、データがフィルタリングで除外された後のオブジェクト構造の処理を完了するための API が用意されています。例えば、オブジェクト構造で注文書の XML メッセージを作成する場合は、明細項目タイプがサービス明細項目である注文書明細データをフィルタリングで除外するロジックを、自動化スクリプトによって挿入できます。

skipCols(ctx)オブジェクト構造から 1 つ以上のカラムをフィルタリングします。例えば、オブジェクト構造で資産の XML メッセージを作成する場合は、XML

メッセージの受信側システムで必要とされない一部のカラムをフィルタリングで除外するロジックを、自動化スクリプトによって挿入できます。

overrideValues(ctx)XML メッセージ内でオブジェクト構造フィールドの値を設定します。例えば、オブジェクト構造で資産の XML メッセージを作成する場合は、作成される XML メッセージの受信側システムで必要とされない一部のカラムをフィルタリングで除外するロジックを、自動化スクリプトによって挿入できます。

オブジェクト構造のアウトバウンド処理で使用される関数:

オブジェクト構造のアウトバウンド処理に使用される自動化スクリプトでは、skipMBO(c) 関数、skipCols(ctx) 関数、および overrideValues(ctx) 関数が使用されます。各関数には、オブジェクト構造内のデータを処理するために用意された独自のAPI があります。スクリプト例は、すべて Jython で記述されています。

skipMbo(ctx) 関数を使用したビジネス・オブジェクトの処理のスキップ:

skipMbo(ctx) 関数は、シリアライゼーション処理の間に作成された XML メッセージからデータをフィルタリングします。skipMbo(ctx) 関数を使用すると、Maximo

ビジネス・オブジェクトのフィルタリング、ビジネス・オブジェクトのスキップ後のメッセージ処理の継続、または実行ポイントでのメッセージの処理の停止を行うことができます。

ctx.skipMbo() API

ctx.skipMbo() API は、XML メッセージ内の任意の Maximo ビジネス・オブジェクトの処理をフィルタリングで除外します。

例えば、以下のスクリプトは ctx.skipMbo() API で実行され、すべての注文書明細と、1234 注文書明細に関連する注文書コスト・データをフィルタリングで除外します。


def skipMbo(ctx):if ctx.getMboName()=='POLINE' and ctx.getMbo().getString("itemnum")=="1234":ctx.skipMbo()

ctx.skipMbo() API を、オブジェクト構造のルート・オブジェクトまたはプライマリー・オブジェクトで使用すると、if 文内の基準を満たすすべてのビジネス・オブジェクトが、XML メッセージからフィルタリングされます。

ctx.process() API

ctx.process() API は、ctx.skipMbo() API によるフィルタリングの対象ではない行を引き続き処理します。以下に例を示します。

def skipMbo(ctx):if ctx.getMboName()=='POLINE' and ctx.getMbo().getString("itemnum")=="1234":ctx.skipMbo()elsectx.process()

ctx.process() API をデータ行に対して実行すると、そのデータのシリアライズが有効化されます。Java 定義クラスによってそのデータ行がスキップされている場合は、ctx.process() API がその Java 定義クラスをオーバーライドして、データのシリアライズが実行されます。

ctx.complete() API

ctx.complete() API が呼び出されると、現在のビジネス・オブジェクト・インスタンス、その下位階層ビジネス・オブジェクト・インスタンス、およびそのピア・レベルのビジネス・オブジェクト・インスタンスに対するオブジェクト構造のアウトバウンド処理が停止されます。

例えば、PO オブジェクトは、POLINE と POTERM という下位階層オブジェクトによって構成されています。POLINE オブジェクトには、下位階層オブジェクトPOCOST があります。ctx.complete() API が PO オブジェクトに対して呼び出されると、その PO に関連する POLINE、POTERM、および POCOST の各オブジェクトは処理されません。

以下のスクリプト例では、ステータスが COMPLETE であるすべての注文書について、その注文書明細データがシリアライズされずに処理が行われます。

def skipMbo(ctx):if ctx.getMboName()=='PO' and ctx.getMbo().getString("status")=="COMPLETE":ctx.complete()elsectx.process()

skipCols(ctx) 関数を使用したビジネス・オブジェクトのカラム処理のスキップ:

skipCols(ctx) 関数は、Maximo ビジネス・オブジェクトのカラムを、XML メッセージの処理からフィルタリングします。ctx.skipCol(String) API は、1 つのストリング引数を受け取って単一のカラムをフィルタリングするか、複数のコンマ区切りのストリング引数を受け取って複数のカラムをフィルタリングすることができます。

ctx.skipCol(String) API は、Maximo ビジネス・オブジェクトの単一のカラムをフィルタリングできます。以下のスクリプト例は、資産オブジェクトの説明カラムをフィルタリングで除外します。


def skipCols(ctx):if ctx.getMboName()==’ASSET’:

ctx.skipCol("description")

ctx.skipCol(String) API を使用して、複数のカラムをフィルタリングすることもできます。以下のスクリプト例は、資産オブジェクトの説明カラムと資産番号カラムをフィルタリングで除外します。

def skipCols(ctx):if ctx.getMboName()==’ASSET’:

ctx.skipCol("description",”assetnum”)

ctx.skipCol(String) API は、オブジェクト構造内の下位階層オブジェクトのカラムをフィルタリングできます。例えば、以下のスクリプト例は、資産計測値オブジェクトの計測値名カラムをフィルタリングで除外します。

def skipCols(ctx):if ctx.getMboName()==’ASSETMETER’:

ctx.skipCol("metername”)

ctx.skipCol(String) API を使用して、指定した値に基づいてカラムをフィルタリングすることもできます。例えば、以下のスクリプト例は、資産タグ属性の値が 12593

である場合に、説明カラムをフィルタリングで除外します。

def skipCols(ctx):if ctx.getMboName()==’ASSET’ and ctx.getMbo().getString("assettag")=="12593":

ctx.skipCol("description")

overrideValues(ctx) 関数を使用したフィールドの値の設定:

overrideValues(ctx) 関数は、XML メッセージ内のフィールドの値を設定します。

ctx.overrideCol() API は、XML メッセージ内のフィールドの値を設定します。例えば、以下のスクリプトは、サイト ID の値を ABC に設定します。

def overrideValues(ctx):

if ctx.getMboName()==’ASSET’:ctx.overrideCol("SITEID","ABC")

以下のスクリプト例では、注文書の説明フィールドが空である場合に、説明フィールドが注文書番号に設定されます。

def overrideValues(ctx):if ctx.getMboName()=='PO':mbo = ctx.getMbo()if mbo.isNull("description"):ctx.overrideCol("DESCRIPTION",mbo.getString("ponum"))

Java 定義クラスと自動化スクリプト:

オブジェクト構造で、Java 定義クラスと自動化スクリプトを同時に使用することができます。各関数で、自動化スクリプトの前に Java 定義クラスが実行されます。

統合フレームワークおよびマイグレーション・マネージャーに含まれているオブジェクト構造の一部は、データをフィルター処理する Java 定義クラスを提供しています。例えば、部品オブジェクト構造では TOOL タイプの部品がフィルター処理されます。Java 定義クラスで自動化スクリプトを実装すると、そのスクリプトで Java

定義クラスのフィルター処理をオーバーライドできます。また、Java クラスのフィ


ルター処理を削除したり、フィルター基準を変更して XML メッセージから除外するデータや XML メッセージに包含するデータを増やしたりすることができます。

例えば、MXOPERLOC オブジェクト構造の Java 定義クラスでは、LABOR タイプのロケーションが除外され、OPERATING タイプのロケーションがメッセージに包含されます。このフィルター処理を変更したり、フィルター処理を追加したり、デフォルトのフィルター処理を置き換えたりすることができます。以下のサンプル・スクリプトでは、OPERATING タイプのロケーションがフィルター処理されるように処理を変更し、かつ LABOR タイプのロケーションの処理を続行します。

def skipMbo(ctx):if ctx.getMboName()==’LOCATIONS’:

if ctx.getMbo().getString("type")=="LABOR":ctx.process()

if ctx.getMbo().getString("type")=="OPERATING":ctx.skipMbo()

以下のサンプル・スクリプトでは、MXOPERLOC オブジェクト構造に対してCOURIER タイプを除外するフィルター処理を追加しています。

if ctx.getMboName()==’LOCATIONS’:if ctx.getMbo().getString("type")=="COURIER":

ctx.skipMbo()

以下のサンプル・スクリプトでは、定義クラスのフィルター処理を置き換えて、COURIER タイプのロケーションのみが除外されるようにしています。

def skipMbo(ctx):if ctx.getMboName()==’LOCATIONS’:

if ctx.getMbo().getString("type")=="COURIER":ctx.skipMbo()

else:ctx.process()

オブジェクト構造のインバウンド処理:

統合フレームワークによるインバウンド・メッセージの処理では、オブジェクト構造で自動化スクリプトを使用して、カスタム・ロジックをサポートすることができます。自動化スクリプトを使用することにより、オブジェクト構造を使用するインバウンド統合メッセージのカスタマイズや、マイグレーション・マネージャー・データの処理のカスタマイズが可能になります。

統合処理では、オブジェクト構造に実装されたスクリプトが、以下のソースからのメッセージに適用されます。

v データ・インポート

v REST

v アプリケーション・インポート

v Web サービス

v OSLC

v 統合サーブレット

v 統合テーブル


オブジェクト構造は、Java 処理クラスまたは自動化スクリプトをサポートします。同じオブジェクト構造で、Java 処理クラス、自動化スクリプト、またはその両方を使用できます。この処理では、クラス・ファイル内または自動化スクリプト内の関数がサポートされます。

インバウンド・オブジェクト構造の処理クラスと自動化スクリプトの間でコンテキスト (ctx) が渡されて、カスタム・コードが実装されます。コンテキストは双方向にサポートされます。コンテキストには、事前定義の API を使用できます。スクリプト・フレームワークには、コンテキストを準備する Java クラスが組み込まれています。

以下のコード例とコード・フラグメントは、いずれも JavaScript を使用しています。処理内でロジックを実装できるポイントは以下のとおりです。

v Maximo ビジネス・オブジェクトの処理の前。例えば、beforeProcess(ctx) 関数は、インバウンド・メッセージに関連したビジネス・オブジェクトが作成される前に、そのメッセージの各名詞に対して 1 回ずつ処理されます。

v Maximo ビジネス・オブジェクトの処理中。例えば、beforeCreateMboSet(ctx) 関数は、インバウンド・メッセージに含まれるすべての名詞内で各オブジェクトに対して順番に処理されます。順番に処理される関数には、このほかにafterCreateMboSet(ctx)、mboRules(ctx)、 beforeMboData(ctx)、afterMboData(ctx) などがあります。

v Maximo ビジネス・オブジェクトの処理が完了した後。例えば、preSaveRules(ctx)

関数と changeStatus(ctx) 関数は、ビジネス・オブジェクトが作成された後にインバウンド・メッセージの各名詞に対して 1 回ずつ処理されます。

自動化スクリプト・アプリケーションでは、オブジェクト構造の処理に含める統合用のスクリプトを作成できます。

オブジェクト構造のインバウンド処理で使用される関数:

各関数には、オブジェクト構造内のデータの処理をカスタマイズするために使用できる API が用意されています。

beforeProcess(ctx) 関数の使用によるメッセージ処理のスキップまたは変更:

beforeProcess(ctx) 関数は、ビジネス・オブジェクトが作成される前に、自動化スクリプト内のロジックを実行するための挿入ポイントを提供します。

例えば、XML メッセージ内のデータの評価に基づいて、メッセージの処理をスキップすることができます。別の例として、メッセージのアクション属性を Sync からCreate に変更することもできます。

以下の JavaScript の例は、メッセージ・アクションを Sync に設定します。

function beforeProcess(ctx){

ctx.setMsgType("Sync");}


beforeCreateMboSet(ctx) 関数を使用したビジネス・オブジェクト・セットの作成:

beforeCreateMBOSet(ctx) 関数は、フレームワークによって Maximo ビジネス・オブジェクトまたはビジネス・オブジェクト・セットが作成される前にインバウンド・データを処理するもので、オブジェクト構造内のすべてのビジネス・オブジェクトを操作することができます。

オブジェクト構造を処理している自動化スクリプトによってビジネス・オブジェクト・セットが作成される場合、基本クラスの createMboSet() 関数はスキップされます。下位階層ビジネス・オブジェクトの処理では、getParentMbo() 関数を使用することで、上位階層オブジェクトへのアクセスがサポートされています。

beforeCreateMboSet(ctx) 関数を使用すると、XML メッセージに含まれるデータに基づいて、条件付きでビジネス・オブジェクトを作成することもできます。

上位階層ビジネス・オブジェクトに依存しない下位階層ビジネス・オブジェクトを作成することはできません。

以下の例は、上位階層ビジネス・オブジェクトから下位階層ビジネス・オブジェクトを作成する方法を示しています。

importPackage(Packages.psdi.server);function beforeCreateMboSet(ctx){var struc=ctx.getData();var ponum=struc.getCurrentData("PO",ctx.getUserInfo();var siteid=struc.getCurrentData("SITEID");var poSet = MXServer.getMXServer().getMboSet("PO",ctx.getUserInfo());poSet.setQbeExactMatch(true);poSet.setQbe("ponum",ponum);poSet.setQbe("siteid",siteid);var poMbo = poSet.moveFirst();var polineSet = poMbo.getMboSet("POLINE");ctx.setMboSet(polineSet);}

afterCreateMboSet(ctx) 関数を使用したビジネス・オブジェクトまたはビジネス・オブジェクト・セットの変更:

afterCreateMboSet(ctx) 関数は、フレームワークによって Maximo ビジネス・オブジェクトまたはビジネス・オブジェクト・セットが作成された後に、インバウンド・オブジェクト構造を処理します。

afterCreateMboSet(ctx) 関数を使用すると、オブジェクト構造内のすべてのビジネス・オブジェクトを操作できます。この関数は、フレームワークによって作成されたビジネス・オブジェクトまたはビジネス・オブジェクト・セットを変更することや、ビジネス・オブジェクト・セットに別のビジネス・オブジェクトを挿入することができます。

作成ロケーションのタイプが Storeroom であることを示すために、MboSet プロパティーを設定する例を以下に示します。このロジックにより、MXSTORELOC 処理クラス内のデフォルトのロジックが置き換えられます。importPackage(Packages.psdi.server);function afterCreateMboSet(ctx){

var loc type = MXServer.getMXServer().getMaximoDD().getTranslator().toInternalString("LOCTYPE",ctx.getData().getCurrentData("TYPE"));


if (loc Type=="STOREROOM"){

ctx.getPrimaryMboSet().setStoreroom();}

else{

ctx.getPrimaryMboSet().setNonStoreroom();}

}

mboRules(ctx) 関数を使用したルール処理の変更:

mboRules(ctx) 関数は、ビジネス・オブジェクトの処理をスキップすることや、トランザクションをスキップすることができるほか、処理を継続することや、ビジネス・オブジェクトを作成することができます。この関数は、各 Maximo ビジネス・オブジェクトが作成される前に機能します。

以下の例は、トランザクションをスキップする方法を示します。

function mboRules(ctx){

ctx.skipTxn();}

beforeMboData(ctx) 関数を使用したフィールドの値の設定:

beforeMboData(ctx) 関数は、Maximo ビジネス・オブジェクトの作成後、統合フレームワークによってビジネス・オブジェクト内の値が設定される前に使用可能になります。オブジェクト構造の処理によって、ビジネス・オブジェクト・データの設定値を変更することができます。また、処理によって、samevaluevalidation フラグなどのフラグをフィールドに設定することもできます。samevaluevalidation フラグは、フィールド値がそのフィールドの現行値に設定された場合でも、フィールドの検証を起動します。

afterMboData(ctx) 関数を使用したビジネス・オブジェクトの追加とフィールド内の値の変更:

afterMboData(ctx) 関数は、トランザクションに含める別の関連 Maximo ビジネス・オブジェクトを作成するためのカスタム・ロジックや、Maximo ビジネス・オブジェクト内のデータを変更するためのカスタム・ロジックを実装します。この関数は、統合フレームワークによってビジネス・オブジェクトが作成され、Maximo ビジネス・オブジェクト内の値が設定された後に使用可能になります。

オブジェクト構造内のカラムに制限がある場合、統合フレームワークによって値を設定する代わりに、afterMboData(ctx) 関数を使用して、これらのカラムに値を設定するロジックを提供することができます。

以下の例では、EXTERNALREFID フィールドと、オブジェクト構造から渡される説明フィールドを組み合わせたものを説明フィールドに設定して、資産が作成されます。importPackage(Packages.psdi.server);importPackage(Packages.psdi.mbo);function afterMboData(ctx){

var mbo = ctx.getMbo();var struc = ctx.getData();mbo.setValue("description", "FROM: "+struc.getCurrentData("EXTERNALREFID")+ " DESC: "+struc.getCurrentData("DESCRIPTION"));

}


preSaveRules(ctx) 関数を使用したデータベースへの保存前のトランザクションの変更:

preSaveRules(ctx) 関数では、トランザクション全体に関連する追加の処理を実行できます。preSaveRules(ctx) 関数を使用すると、関連オブジェクトを作成して、それをトランザクションに追加できます。この関数は、保存アクションの前に、メッセージ内の各名詞に対して呼び出されます。

changeStatus(ctx) 関数の使用によるステータスまたはステータス変更日の変更:

changeStatus(ctx) 関数は、統合フレームワークに用意されている statefulMicSetIn クラス外でのステータス変更を実装します。この関数を使用すると、ステータス変更日を、システム日付を使用せずに、特定の値に設定することもできます。

自動化スクリプトで changeStatus(ctx) 関数を使用するには、statefulMicSetin クラス、または statefulMicSetin クラスの拡張クラスが、オブジェクト構造で処理クラスとして登録されている必要があります。この関数を使用すると、5 つのパラメーターのステータス変更をサポートできます。基本クラスは、3 つのパラメーターのみサポートしています。

以下の例では、NP_STATUSMEMO フィールドに値が設定されていない場合に、ステータスの変更アクションに関連する memo フィールドにストリング値を設定します。importPackage(Packages.psdi.server);importPackage(Packages.psdi.mbo);

function changeStatus(ctx){

var mbo = ctx.getMbo();var struc = ctx.getData();var stat = struc.getCurrentData("STATUS");var memo = struc.getCurrentData("NP_STATUSMEMO");if(struc.isCurrentDataNull("NP_STATUSMEMO")){

memo = "Status change via Integration";}mbo.changeStatus(stat, MXServer.getMXServer().getDate(), memo, MboCon-stants.NOACCESSCHECK);

}

オブジェクト構造のインバウンド処理のコンテキスト API:

コンテキスト (ctx) は、自動化スクリプトがデータの受け渡しやアクションの起動を行うための便利メソッドを提供するオブジェクトです。コンテキストは双方向にサポートされます。コンテキストには定義済みの API が用意されており、各関数はさまざまなコンテキストを使用できます。

自動化スクリプトでは、処理ロジックを実装するために、コンテキスト・メソッドを使用する必要があります。コンテキストは、オブジェクト構造の処理と、カスタム・コードを実装する自動化スクリプトの間で受け渡されます。以下の表に、コンテキスト API と、各関数でその API が一般的に使用されるかどうかを示します。

表 28. コンテキスト API の関数での使用

コンテキスト API

beforeProcess

(ctx)

beforeCreateMBOSet

(ctx)

afterCreateMboSet

(ctx)

mboRules

(ctx)

beforeMboData

(ctx)

afterMboData

(ctx)

preSaveRules

(ctx)

changeStatus

(ctx)

ctx.setMsgType() U

ctx.getProcessTable() U U U U U

ctx.setProcessTable(String

ProcessTable)

U

ctx.setMboSet(MboSet mboSet) U


表 28. コンテキスト API の関数での使用 (続き)

コンテキスト API

beforeProcess

(ctx)

beforeCreateMBOSet

(ctx)

afterCreateMboSet

(ctx)

mboRules

(ctx)

beforeMboData

(ctx)

afterMboData

(ctx)

preSaveRules

(ctx)

changeStatus

(ctx)

ctx.setMbo(Mbo mbo) U

ctx.getData() U U U U U U U U

ctx.getMosDetailInfo() U U U U U U U

ctx.setSkipBaseAdditionalRules() U

ctx.skipMbo() U

ctx.skipTxn() U U U U U U U U

ctx.complete() U

ctx.process() U

ctx.getUserInfo() U U U U U U U U

ctx.getParentMbo() U U U U U

ctx.isPrimary() U U U U U U U

ctx.bypassMbo() U

ctx.getMsgType() U U U U U U U U

ctx.getPrimaryMboSet() U U U U U U

ctx.getPrimaryMbo() U U U U

ctx.processAsUpdate() U

ctx.processAsAdd() U

ctx.processAsAddAtEnd() U

ctx.log () U U U U U U U U

インバウンドのデータ処理に使用できる API は以下のとおりです。

ctx.getMosDetailInfo()処理対象のオブジェクト構造のデータ・ディクショナリー・キャッシュに関する情報を、統合フレームワークに提供します。

ctx.skipMbo()Maximo ビジネス・オブジェクトの処理をスキップします。

ctx.skipTxn()トランザクション全体 (メッセージなど) の処理をスキップします。

ctx.complete()オブジェクト構造の処理を実行時点で終了します。したがって、下位階層データは処理されません。

ctx.process()実行時点で処理を継続します。この API は、通常、条件付きロジックの一部として使用されます。

ctx.getParentMbo()上位階層ビジネス・オブジェクトを取得します。この API は、ビジネス・オブジェクトがまだ作成されていない下位階層オブジェクトから使用できます。

ctx.isPrimary()現在のビジネス・オブジェクトが、オブジェクト構造のルート・レベルのビジネス・オブジェクトであるかどうかを示します。

ctx.getUserInfo()スクリプトで新規ビジネス・オブジェクトを作成する場合に必要となるユーザー情報を取得します。

ctx.bypassMbo()ビジネス・オブジェクトの作成をバイパスし、次の処理対象であるビジネス・オブジェクトから処理を継続します。

ctx.getMsgType()メッセージ・タイプ (Sync、Create など) へのアクセスを提供します。


ctx.setMsgType()メッセージ・タイプ (Sync、Create など) を設定します。この API は、処理が開始される前に使用できます。

ctx.getData()StructureData (XML メッセージ) へのアクセスを提供します。

ctx.setMboSet(MboSet mboSet)ビジネス・オブジェクト・セット内の値を設定します。

ctx.setMbo(Mbo mbo)ビジネス・オブジェクト内の値を設定します。

ctx. getPrimaryMboSet()下位階層ビジネス・オブジェクトの処理中に、オブジェクト構造のルート・ビジネス・オブジェクトを取得します。

ctx.setProcessTable(String processTable)処理対象のテーブルを設定します。このメソッドは、MATRECTRANS テーブルと SERVRECTRANS テーブルのどちらが更新されているかを判断する処理ロジックを持つ MXRECEIPT などの非永続ビジネス・オブジェクトがある場合に使用します。ctx.setProcessTable(String processTable) API は、beforeProcess(ctx) 関数内で使用されます。

ctx.getProcessTable()ctx.setProcessTable(String processTable) API によって設定されたテーブル名を取得します。

ctx.setSkipBaseAdditionalRules()処理で準備された完成したオブジェクト構造で実行されるカスタム・ロジックを preSaveRules(ctx) 関数に追加します。

ctx.processAsUpdate()ビジネス・オブジェクトの処理アクションを、追加アクションまたは削除アクションではなく更新アクションに設定します。

ctx.processAsAdd()ビジネス・オブジェクトの処理アクションを、更新アクションまたは削除アクションではなく追加アクションに設定します。

ctx.processAsAddAtEnd()ビジネス・オブジェクトの処理アクションを、更新アクションまたは削除アクションではなく追加アクションに設定し、コレクションの先頭ではなく末尾にビジネス・オブジェクトを作成します。

ctx.log ()オブジェクト構造の処理コンテキストからログ・ステートメントを実行します。

自動化スクリプトを使用したチャネルおよびサービスの処理のカスタマイズ:

自動化スクリプトを作成する場合は、スクリプトを実行するチャネルまたはサービスを指定します。また、処理フロー内でスクリプトを挿入する場所を指定します。


パブリッシュ・チャネルの処理におけるカスタマイズ・ポイント:

パブリッシュ・チャネルは、応答を必要としないアウトバウンドの統合メッセージを処理します。パブリッシュ・チャネルに関連付けられている Java 処理クラスには、カスタム・ロジックを指定するためのコードを挿入できるいくつかのフックが含まれています。

この図は、パブリッシュ・チャネルを使用して統合メッセージのアウトバウンド処理を行っているときのカスタマイズ・ポイントを示します。







Java��クラス


JMS キュー

��ターゲット

-( : )

-

ファイルスプレッドシート

システム

��


Java

(before)

ユーザークラス

メソッド

�� スクリプト

Java �クラス


Java

(after)

ユーザークラス

メソッド

�� スクリプト

Javaイベント・フィルター・クラス


オブジェクト構造の処理により統合メッセージが作成された後、その統合メッセージは関連付けられているパブリッシュ・チャネルに転送されます。パブリッシュ・チャネルの処理中の以下のポイントに、カスタム・ロジックを追加することができます。

v 外部出口クラス

v 外部出口クラスの前に実行されるユーザー出口クラス

v 外部出口クラスの後に実行されるユーザー出口クラス

v イベント・フィルター・クラス

この後メッセージは、ターゲット宛先への配信のために JMS キューに送信されます。


パブリッシュ・チャネル用の外部出口スクリプトまたはユーザー出口スクリプトを構成すると、スクリプトを実行するために使用されるチャネルに、事前定義の Java

クラスが挿入されます。この事前定義のクラスは、com.ibm.tivoli.maximo.script.ScriptExternalExit クラスとcom.ibm.tivoli.maximo.script.ScriptUserExit クラスです。スクリプトと Java クラスを同一の処理ポイントで実装することはできません。Java クラスが構成されている処理ポイントでスクリプトを作成しようとした場合、スクリプトを保存できません。

エンタープライズ・サービスの処理におけるカスタマイズ・ポイント:

エンタープライズ・サービスは、インバウンド統合メッセージの同期処理と非同期処理を提供します。インバウンド処理用の Java 要求処理クラス、およびアウトバウンド処理用の Java 応答処理クラスにカスタム・ロジックを指定するためのコードを挿入することができます。

この図は、エンタープライズ・サービスを使用して統合メッセージのインバウンド処理およびアウトバウンド処理を行っているときのカスタマイズ・ポイントを示します。








Java��クラス



Java �クラス


エンタープライズ・サービス��

Java

(before )

ユーザークラスメソッド

��

Java �クラス

Java

(after )


��




エンタープライズ・サービス��

Java

(before )


��

Java �クラス

Java

(after )


��




��クライアント

�� ( )トランザクション

応答を必要としない非同期メッセージでは、外部サービスが接続を開き、エンタープライズ・サービスの要求を送信します。要求が検証されると、メッセージはエンタープライズ・サービスの処理のために JMS キューにドロップされます。応答を必要とする同期メッセージでは、外部サービスは、トランザクションの間、応答を受け取るまで継続して接続を維持します。


自動化スクリプト・アプリケーションでエンタープライズ・サービス用の自動化スクリプトを構成するときに、スクリプトに以下のいずれかの挿入ポイントを指定します。

v インバウンドの非同期処理の挿入ポイント:

– 要求、インバウンド: 外部出口クラスの前に実行されるユーザー出口クラス

– 要求、インバウンド: 外部出口クラス

– 要求、インバウンド: 外部クラスの後に実行されるユーザー出口クラス

v 応答が必要とされるインバウンドの同期処理の挿入ポイント:

– 要求、インバウンド: 外部出口クラスの前に実行されるユーザー出口クラス

– 要求、インバウンド: 外部出口クラス

– 要求、インバウンド: 外部クラスの後に実行されるユーザー出口クラス

– 応答、アウトバウンド: 外部出口クラスの前に実行されるユーザー出口クラス

– 応答、アウトバウンド: 外部出口クラス

– 応答、アウトバウンド: 外部クラスの後に実行されるユーザー出口クラス

外部サービスの要求または応答用の外部出口スクリプトまたはユーザー出口スクリプトを構成すると、スクリプトを実行する事前定義の Java クラスが挿入されます。この事前定義のクラスは、com.ibm.tivoli.maximo.script.ScriptExternalExit クラスとcom.ibm.tivoli.maximo.script.ScriptUserExit クラスです。スクリプトと Java クラスを同一の処理ポイントで実装することはできません。Java クラスが構成されている処理ポイントでスクリプトを作成しようとした場合、スクリプトを保存できません。

呼び出しチャネルの処理におけるカスタマイズ・ポイント:

呼び出しチャネルは、応答を必要とするアウトバウンド統合メッセージを処理します。呼び出しチャネルの要求クラスおよび呼び出しチャネルの応答クラスには、カスタム・ロジックを指定するためのコードを挿入できるいくつかのフックが含まれています。

この図は、呼び出しチャネルを使用して統合メッセージのインバウンド処理およびアウトバウンド処理を行っているときのカスタマイズ・ポイントを示します。







Java��クラス



Java �クラス


��サービス

� � ��びしチャネルの

Java

(before )


��

Java �クラス

Java

(after )


��




� � ��びしチャネルの

Java

(before )


��

Java �クラス

Java

(after )


��






�� ( )トランザクション

Maximo Asset Management でユーザー・アクションによって、応答を必要とするアウトバウンドの統合トランザクションが開始されると、呼び出しチャネルが要求と応答の統合処理を提供します。

自動化スクリプト・アプリケーションで呼び出しチャネル用の自動化スクリプトを構成するときに、スクリプトに以下のいずれかの挿入ポイントを指定します。

v 要求、アウトバウンド: 外部出口クラスの前に実行されるユーザー出口クラス

v 要求、アウトバウンド: 外部出口クラス

v 要求、アウトバウンド: 外部出口クラスの後に実行されるユーザー出口クラス

v 応答、インバウンド: 外部出口クラスの前に実行されるユーザー出口クラス

v 応答、インバウンド: 外部出口クラス

v 応答、インバウンド: 外部出口クラスの後に実行されるユーザー出口クラス

呼び出しチャネルの要求または応答用の外部出口スクリプトまたはユーザー出口スクリプトを構成すると、スクリプトを実行する事前定義の Java クラスが挿入されます。この事前定義のクラスは、com.ibm.tivoli.maximo.script.ScriptExternalExit クラスと com.ibm.tivoli.maximo.script.ScriptUserExit クラスです。スクリプトと Java クラスを同一の処理ポイントで実装することはできません。Java クラスが構成されている処理ポイントでスクリプトを作成しようとした場合、スクリプトを保存できません。

チャネルおよびサービスによる処理における自動化スクリプトの使用例:

チャネルおよびサービスの処理では、ソース・システムからデータ・レコードを入力値として取得し、そのデータを必要に応じて操作して、ターゲット・システム用


のデータ・レコードを作成します。入力データにクエリーを行って、出力データが作成される前にそのデータを操作するロジックを提供する Python スクリプトの例を示します。

Maximo Asset Management が統合トランザクションを開始すると、オブジェクト構造により、パブリッシュ・チャネルまたは呼び出しチャネルに内部レコード・データ (irData) エレメントが提供されます。処理によりこの irData エレメントに対して操作が行われ、外部レコード・データ (erData) エレメントが作成された後、メッセージが宛先に転送されます。呼び出しチャネルのトランザクションでは、外部システムからの応答が必要になることがあります。応答処理により、呼び出しチャネルに erData エレメントが渡され、呼び出しチャネルがこの応答データを操作してirData エレメントを作成します。

外部システムが統合トランザクションを開始すると、メッセージによってエンタープライズ・サービスに erData エレメントが提供されます。処理により erData エレメントに対する操作が行われ、irData エレメントが作成された後、メッセージが関連付けられているオブジェクト構造に転送されます。応答を必要とするメッセージの場合、オブジェクト構造によりエンタープライズ・サービスに irData エレメントが提供されます。処理によりデータに対する操作が行われ、宛先に転送されるerData エレメントが作成されます。

ここで示す例は、テスト目的で使用できる単純なスクリプトで構成されています。外部システム・アプリケーションのデータのインポート機能およびデータのエクスポート機能を使用して、トランザクションを開始し、スクリプトをテストすることができます。

例: アウトバウンド・トランザクションで運転資産の説明を変更するスクリプト

このシナリオでは、MXASSET オブジェクト構造が、MYASSET パブリッシュ・チャネルに処理のために irData を提供します。パブリッシュ・チャネルの外部出口クラスで実行する自動化スクリプトが構成されています。このスクリプトは、irData

エレメント内の資産のステータスをチェックします。資産のステータスが「運転」である場合、このスクリプトは、説明フィールドに値を挿入して、ログ・ファイルにメッセージを出力します。次に erData エレメントが作成され、外部システムに転送されます。

if irData.getCurrentData("STATUS") == ’OPERATING’ :irData.setCurrentData("DESCRIPTION","hello")print "MYASSET description change"

例: インバウンド・トランザクションで運転資産の説明を変更するスクリプト

この例では、MYASSET エンタープライズ・サービスが、MXASSET オブジェクト構造のインバウンド・メッセージを処理します。自動化スクリプトが、エンタープライズ・サービスの外部出口クラスでスクリプトを挿入します。このスクリプトは、erData エレメント内の資産のステータスをチェックします。資産のステータスが「運転」である場合、このスクリプトは、説明フィールドに値を挿入して、ログ・ファイルにメッセージを出力します。次に irData エレメントが作成され、関連付けられているオブジェクト構造に処理のために転送されます。

if erData.getCurrentData("STATUS") == ’OPERATING’:erData.setCurrentData("DESCRIPTION","hello inbound")print "MYASSET inbound description has changed"


例: 自動化スクリプトの変数を使用して注文書の明細の説明を変更するスクリプト

この例では、MXPO オブジェクト構造が、MYPO パブリッシュ・チャネルに処理のために irData エレメントを提供します。パブリッシュ・チャネルの外部出口クラスで実行する自動化スクリプトが構成されています。この自動化スクリプトの入力変数として、リテラル値 world が定義されています。このスクリプトは、irData エレメントにクエリーを行って、注文書明細が含まれている注文書を探します。スクリプトは、各注文書明細に 1 から始まる番号を順に割り当て、説明フィールドの値に「hello」を設定して、自動化スクリプトの入力変数を追加します。スクリプトが上位階層の注文書を更新し、その後、erData エレメントが作成され、外部システムに転送されます。

lines = irData.getChildrenData("POLINE")i = 0if lines is not None:

for value in lines:++iirData.setAsCurrent(lines,i);irData.setCurrentData("DESCRIPTION","hello"+world)

irData.setParentAsCurrent()

例: レコードのステータスに基づいてトランザクションをスキップするスクリプト

この例では、MXPO オブジェクト構造が、処理のために MYPO2 パブリッシュ・チャネルに送信されます。外部出口クラスの実行前のユーザー出口クラスで実行する自動化スクリプトが構成されています。このスクリプトは、irData エレメントにクエリーを行ってステータスが「WAPPR」である注文書を探し、このような注文書の処理をスキップします。

if irData.getCurrentData("STATUS") == ’WAPPR’ :errorgroup = "iface"errorkey ="SKIP_TRANSACTION"

例: トラブルシューティングの支援のためにトランザクション情報をログ・ファイルに出力するスクリプト

この例では、MXASSET オブジェクト構造が、MYASSET2 パブリッシュ・チャネルに処理のために irData を提供します。外部出口クラスで実行する自動化スクリプトが構成されています。このスクリプトは、irData エレメントにクエリーを行ってステータスが「運転」である資産を探し、トランザクション情報をログ・ファイルに出力して、変更を行わずに erData エレメントを作成します。トランザクションに関する情報を出力するには、ロギングを「デバッグ」に設定する必要があります。ロギング・アプリケーションで、ロガーが「自動化スクリプト」に設定され、ロギング・レベルが「DEBUG」に設定されます。自動化スクリプト・アプリケーションで、スクリプトのロギング・レベルが「DEBUG」に設定されます。

if irData.getCurrentData("STATUS") == ’OPERATING’ :print "Test script

variable VAR_EXIT_IFACETYPE " + ifaceTypeprint "Test scriptvariable VAR_EXIT_IFACENAME " + ifaceNameprint "Test scriptvariable VAR_EXIT_EXTSYSTEM " + extSystemprint "Test scriptvariable VAR_EXIT_MESSAGETYPE " + messageTypeprint "Test scriptvariable VAR_EXIT_EXTSYSTEM " + extSystemprint "Test scriptvariable VAR_EXIT_OSNAME " + osNameprint "Test script

資産がエクスポートされると、以下のデバッグ情報がログ・ファイルに出力されます。


18 Mar 2014 11:35:06:877 [DEBUG] [MXServer] [CID-MXSCRIPT-2022] execution completedfor cached compiled script PUBLISH.MYASSET.EXTEXIT.OUT for launch point nullTest script variable VAR_EXIT_IFACETYPE MAXIMOTest script variable VAR_EXIT_IFACENAME MYASSET2Test script variable VAR_EXIT_EXTSYSTEM MYEXTSYSTest script variable VAR_EXIT_MESSAGETYPE PublishTest script variable VAR_EXIT_OSNAME MXASSET

XSL マッピングアウトバウンド・トランザクションの場合は、XSL ファイルを実装して、Java 出口処理の完了後に外部システムに送信されるデータを操作することができます。インバウンド・トランザクションの場合は、XSL ファイルを実装して、Java 出口処理の完了後にオブジェクト構造に対して設定されるデータを操作することができます。

XSL ファイルは常に、Java 出口処理からの出力である XML メッセージによって呼び出されます。businessobjects/classes/ ディレクトリーのアプリケーションEAR ファイルに XSL ファイルを登録できるほか、アプリケーション EAR ファイルに含まれないディレクトリー・ファイル・パスを使用して XSL ファイルを参照することもできます。

.xsl のファイル拡張子を省略し、businessobjects/classes/psd/iface/xsl ディレクトリーにファイルを登録します。例を次に示します。

psdi.iface.xsl.mapping

.xsl のファイル拡張子を含めて、アプリケーション・サーバーがアクセス可能なファイル・ディレクトリーにファイルを登録します。例を次に示します。

c:/psdi/iface/xsl/mapping.xsl

インターフェース・テーブルのユーザー出口クラスインターフェース・テーブルを使用して外部システムからメッセージを受信する場合、データをインターフェース・テーブルから取得し、データをシステムに送信するポーリング・プログラムでカスタマイズを実行することができます。

クーロン・タスク・マネージャーは、インターフェース・テーブルのポーリング・プログラムを実行します。IFACETABLECONSUMER クーロン・タスクには、オプションの EXITCLASS プロパティーがあり、そこで Java 出口クラスの完全修飾名を指定することができます。

Java データ構造リストはインターフェース・テーブルからのレコードを表します。このリストの最初の要素は常にメッセージのアクションです。リストの残りの要素はマップされたデータ構造で、各マップは各メッセージのインターフェース・テーブル内の行を表します。このマップ内のキーはカラム名であり、値は対応するカラム値です。すべてのカラム値は、マップ内で設定される前に、翻訳されたストリング・フォーマットに変換されます。

EXITCLASS クラスは、psdi.iface.intertables.IfaceTbExit インターフェースおよび以下のメソッドを実装する必要があります。

v public void beforeQueue(long transid, String extSys, String ifaceName,

List data, Connection conn)


このメソッドは、データがインターフェース・テーブルから受信された後、データがインバウンド用キューのいずれかに挿入される前に呼び出されます。

v public void afterCommit(long transid, String extSys, String ifaceName,

Connection conn)

このメソッドは、データがインバウンド用キューに挿入され、インターフェース・キュー・テーブルから削除され、さらにデータベース・コミットが実行された後に呼び出されます。

v public void afterRollback(long transid, String extSys, String ifaceName,

Connection conn)

このメソッドは afterCommit と似ていますが、トランザクションがロールバックされた場合に呼び出されます。

このクラスは、以下の処理を実行することができます。


v システムに保存する IR レコードを変更して外部データを変更する。

v 例外をスローして、キューへのトランザクションの保存を停止する。この場合、エラー・メッセージが出されてトランザクションが MXIN_INTER_TRANS テーブルに残され、再処理されます。

v skip_transaction 例外をスローして、外部システムへのメッセージの送信を停止する。この場合、システムはメッセージを保存せず、メッセージはキューから除去されます。

v トランザクションをログに記録する

afterCommit メソッドまたは afterRollback メソッドを使用するユーザー出口は、以下のプロセスを実行することができます。

v カスタム処理およびクリーンアップを実行する。


このクラスは、「クーロン・タスクのセットアップ」アプリケーションで識別します。

統合フレームワークの構成統合フレームワークをセットアップするには、関連したシステム・プロパティー、JMS キュー、およびセキュリティーを構成する必要があります。統合シナリオを実装するには、アプリケーション・サーバー上にキューを構成するための知識と、J2EE および製品セキュリティー・サポートの知識が必要です。

統合システム・プロパティーシステム・プロパティーは、統合フレームワークの動作と特性を定義します。統合フレームワークのプロパティーを確認または変更するには、システムのプロパティー・アプリケーションでプロパティーをフィルタリングします。


一般統合プロパティー

一般的な統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.int を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。

表 29. 一般統合プロパティープロパティー説明デフォルト値

mxe.int.containerdeploy Web サービスをアプリケーション・サーバー・コンテナーにデプロイします。0 (False) に設定すると、Web

サービスはプロダクト・コンテナーにデプロイされます。

0

mxe.int.credentialmapperclassname 資格情報マッパー・クラス名。統合モジュールの実装時に資格情報のマッピングに使用できるクラス・ファイルです。

mxe.int.genboolasbool ブール値をスキーマ・ブール値として生成します。 1

mxe.int.globaldir 統合グローバル・ディレクトリーを指定します。 1

mxe.int.queueusercachesize インバウンド・キュー・メッセージにキャッシュされたユーザー数。

10

mxe.int.resolveschema インライン・スキーマ定義を含めるために、すべてのスキーマ・インクルードを解決します。

1

mxe.int.servicedeployer Web サービス・デプロイヤー・クラスは、デフォルトのデプロイヤー・クラスが使用されない場合の Web

サービス・デプロイメント用のカスタム Java クラスです。

mxe.int.uddiinqurl 統合 UDDI レジストリーの URL 照会を表します。

mxe.int.uddiname 統合 UDDI レジストリーのユーザー ID を表します。

mxe.int.uddipassword 統合 UDDI レジストリーのパスワード。

mxe.int.uddipuburl 統合 UDDI レジストリーの URL 公開。

mxe.int.validatedbupdates 統合によって完了したデータベース更新を検証します。1 (True) に設定すると、データベース構成アプリケーションを通じてユーザーが実行したビジネス・オブジェクト、属性、インデックス、および関係の削除が、統合コンテンツと照らし合わせて検証されます。検証では、削除されるデータが統合コンポーネントによって参照されていないことが確認されます。参照が存在する場合、ユーザーは削除アクションを完了できません。

1

mxe.int.validatemmpackage 統合によるマイグレーション・マネージャー・データベース更新を検証します。

0

mxe.int.verifywebappurl スキーマ・ファイルの生成時に Web アプリケーションの URL を検証します。

1

mxe.int.webappurl 統合 Web アプリケーションの URL を表します。このプロパティーは、正しいホスト名とポート番号が含まれるように構成します。

http://localhost:9998/meaweb

mxe.int.wsdlcurrentschema 現在のスキーマ定義を WSDL で表示します。 1

mxe.int.wsdlincludesschema スキーマを直接 WSDL に含めます。 1

mxe.int.wsdlnamespace 統合 WSDL ネーム・スペースを表します。 http://www.ibm.com/maximo/wsdl

mxe.int.xmlnamespace 統合 XML ネーム・スペースを表します。 http://www.ibm.com/maximo

mxe.int.binarytext テキスト値を Base64 エンコード値に変換します。 10

mxe.int.defaultaction フラット・ファイルのインポートのデフォルト・アクション。

AddChange


表 29. 一般統合プロパティー (続き)

プロパティー説明デフォルト値

mxe.int.defaultoperation アプリケーション・エクスポートのデフォルトの操作。

Sync

mxe.int.dfltuser 統合のデフォルト・ログイン・ユーザーを表します。 mxintadm

mxe.int.doclink.maxfilesize 統合メッセージの一部として含まれている添付ファイルの最大ファイル・サイズ (MB) を表します。

10

mxe.int.enabledatemillis ミリ秒部分までの日付を有効化します。 0

mxe.int.expupdatesender データのエクスポート中にプライマリー・オブジェクトの SENDERSYSID フィールドを更新します。

0

mxe.int.extracttrycount ファイル抽出再試行数は、ファイル・ベース・エラー管理の使用時に、データのインポート中に再試行されるエラー・メッセージの数です。

0

mxe.int.flatfiledelimiter 統合フラット・ファイルのテキスト区切り文字は、アプリケーション・インポートの有効化とデータ・インポート用に使用されるデフォルトの区切り文字値です。

,

mxe.int.flatfilenewline 改行文字をフラット・ファイルに保持します。改行文字を含めることができるフィールド (説明など) では、このプロパティーの値が 1 (True) であれば、これらの文字は統合メッセージに保持されます。

0

mxe.int.interactiveimport アプリケーション・インポートを対話式で実行します。

0

mxe.int.keyresponse すべての操作に関するインバウンド統合メッセージに応答の内容を提供します。 1 (True) に設定すると、すべてのサービス操作に対して応答の内容 (プライマリー・オブジェクトのキー値を含む) が提供されます。0 (False) に設定すると、クエリーおよび作成の操作のみに対して応答の内容が提供されます。

1

mxe.int.maxextractdocs 抽出ファイルの作成時に各一時ファイルに書き込まれるエラー文書の数を表します。

1000

mxe.int.mdbdelay エラー・キューからのメッセージを処理するまでの待機時間 (ミリ秒単位) を表します。

-1

mxe.int.propagateuser インバウンド・キューを介して認証済みユーザーを伝搬します。 1 (True) に設定すると、統合メッセージのユーザーがキュー・メッセージとともに保存され、メッセージの処理で使用されます (そのユーザーがキューからビジネス・オブジェクトに処理されるため)。

0

mxe.int.savemessage JMS メッセージの保存を示します。 0

mxe.int.setclobasaln インターフェース・テーブルに送信される文字の短縮を制御します。

0

mxe.int.textqualifier フラット・ファイル・テキスト修飾子は、アプリケーション・インポートの有効化とデータ・インポートにおけるデフォルトのテキスト修飾子の値です。

"

mxe.int.updatecoafromglcomp 特定されたコンポーネントを含む勘定科目一覧を更新します。1 (True) に設定すると、インバウンド GL 勘定科目構成データの処理により、GL 勘定科目構成を参照する勘定科目一覧データに対する関連の更新が開始されます。

1

mxe.int.usescientific 2 つの値に浮動小数を使用します。 1




mxe.int.validatexmltext XML 要素の値を検証して、無効な XML 文字があるか確認します。1 (True) に設定すると、アウトバウンド・メッセージが検証され、メッセージ内のすべてのデータに有効な XML 文字が使用されていることが確認されます。メッセージに無効文字が含まれる場合、操作は停止し、アウトバウンド・メッセージは配信されません。

0

mxe.int.whereclausepolicy 統合クエリーの where 文節ポリシーを設定します。 parse

mxe.int.adminfromemail 統合で電子メールが開始されるときに From 電子メール・アドレスとして使用される、電子メール・アドレスの FROM 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。

mxe.int.admintoemail 統合で電子メールが開始されるときに To 電子メール・アドレスとして使用される、電子メール・アドレスの TO 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。複数の電子メール・アドレスをコンマ区切りリストで指定することができます。

表 30. 一般統合プロパティー：

プロパティー説明デフォルト値プロパティーを編集できるユーザー

mxe.int.containerdeployWeb サービスをアプリケーション・サーバー・コンテナーにデプロイします。0 (False) に設定すると、Web サービスはプロダクト・コンテナーにデプロイされます。

0 グローバル管理者

mxe.int.credentialmapperclassname資格情報マッパー・クラス名。統合モジュールの実装時に資格情報のマッピングに使用できるクラス・ファイルです。

グローバル管理者

mxe.int.genboolasboolブール値をスキーマ・ブール値として生成します。


mxe.int.globaldir統合グローバル・ディレクトリーを指定します。


mxe.int.queueusercachesizeインバウンド・キュー・メッセージにキャッシュされたユーザー数。


mxe.int.resolveschemaインライン・スキーマ定義を含めるために、すべてのスキーマ・インクルードを解決します。


mxe.int.servicedeployerWeb サービス・デプロイヤー・クラスは、デフォルトのデプロイヤー・クラスが使用されない場合の Web サービス・デプロイメント用のカスタムJava クラスです。


mxe.int.uddiinqurl統合 UDDI レジストリーの URL 照会を表します。


mxe.int.uddiname統合 UDDI レジストリーのユーザー ID を表します。


mxe.int.uddipassword統合 UDDI レジストリーのパスワード。



表 30. 一般統合プロパティー (続き)：


mxe.int.uddipuburl統合 UDDI レジストリーの URL 公開。


mxe.int.validatedbupdates統合によって完了したデータベース更新を検証します。1 (True) に設定すると、データベース構成アプリケーションを通じてユーザーが実行したビジネス・オブジェクト、属性、インデックス、および関係の削除が、統合コンテンツと照らし合わせて検証されます。検証では、削除されるデータが統合コンポーネントによって参照されていないことが確認されます。参照が存在する場合、ユーザーは削除アクションを完了できません。


mxe.int.verifywebappurlスキーマ・ファイルの生成時に Web アプリケーションの URL を検証します。


mxe.int.webappurl統合 Web アプリケーションの URL を表します。このプロパティーは、正しいホスト名とポート番号が含まれるように構成します。

http://localhost:9998/

meaweb


mxe.int.wsdlcurrentschema現在のスキーマ定義を WSDL で表示します。


mxe.int.wsdlincludesschemaスキーマを直接 WSDL に含めます。


mxe.int.wsdlnamespace統合 WSDL ネーム・スペースを表します。

http://www.ibm.com/maximo/

wsdl


mxe.int.xmlnamespace統合 XML ネーム・スペースを表します。

http://www.ibm.com/maximo グローバル管理者

mxe.int.binarytextテキスト値を Base64 エンコード値に変換します。

10 グローバル管理者、テナント管理者

mxe.int.defaultactionフラット・ファイルのインポートのデフォルト・アクション。

AddChange グローバル管理者、テナント管理者

mxe.int.defaultoperationアプリケーション・エクスポートのデフォルトの操作。

Sync グローバル管理者、テナント管理者

mxe.int.dfltuser統合のデフォルト・ログイン・ユーザーを表します。

mxintadm グローバル管理者、テナント管理者

mxe.int.doclink.maxfilesize統合メッセージの一部として含まれている添付ファイルの最大ファイル・サイズ (MB) を表します。


mxe.int.enabledatemillisミリ秒部分までの日付を有効化します。


mxe.int.expupdatesenderデータのエクスポート中にプライマリー・オブジェクトの SENDERSYSID フィールドを更新します。


mxe.int.extracttrycountファイル抽出再試行数は、ファイル・ベース・エラー管理の使用時に、データのインポート中に再試行されるエラー・メッセージの数です。


mxe.int.flatfiledelimiter統合フラット・ファイルのテキスト区切り文字は、アプリケーション・インポートの有効化とデータ・インポート用に使用されるデフォルトの区切り文字値です。

, グローバル管理者、テナント管理者




mxe.int.flatfilenewline改行文字をフラット・ファイルに保持します。改行文字を含めることができるフィールド (説明など) では、このプロパティーの値が 1 (True) であれば、これらの文字は統合メッセージに保持されます。


mxe.int.interactiveimportアプリケーション・インポートを対話式で実行します。


mxe.int.keyresponseすべての操作に関するインバウンド統合メッセージに応答の内容を提供します。 1 (True) に設定すると、すべてのサービス操作に対して応答の内容(プライマリー・オブジェクトのキー値を含む) が提供されます。 0 (False) に設定すると、クエリーおよび作成の操作のみに対して応答の内容が提供されます。


mxe.int.maxextractdocs抽出ファイルの作成時に各一時ファイルに書き込まれるエラー文書の数を表します。


mxe.int.mdbdelayエラー・キューからのメッセージを処理するまでの待機時間 (ミリ秒単位) を表します。

-1 グローバル管理者、テナント管理者

mxe.int.propagateuserインバウンド・キューを介して認証済みユーザーを伝搬します。 1 (True) に設定すると、統合メッセージのユーザーがキュー・メッセージとともに保存され、メッセージの処理で使用されます (そのユーザーがキューからビジネス・オブジェクトに処理されるため)。


mxe.int.savemessageJMS メッセージの保存を示します。


mxe.int.setclobasalnインターフェース・テーブルに送信される文字の短縮を制御します。


mxe.int.textqualifierフラット・ファイル・テキスト修飾子は、アプリケーション・インポートの有効化とデータ・インポートにおけるデフォルトのテキスト修飾子の値です。

" グローバル管理者、テナント管理者

mxe.int.updatecoafromglcomp特定されたコンポーネントを含む勘定科目一覧を更新します。1 (True) に設定すると、インバウンド GL 勘定科目構成データの処理により、GL 勘定科目構成を参照する勘定科目一覧データに対する関連の更新が開始されます。


mxe.int.usescientific2 つの値に浮動小数を使用します。


mxe.int.validatexmltextXML 要素の値を検証して、無効な XML 文字があるか確認します。1 (True) に設定すると、アウトバウンド・メッセージが検証され、メッセージ内のすべてのデータに有効な XML 文字が使用されていることが確認されます。メッセージに無効文字が含まれる場合、操作は停止し、アウトバウンド・メッセージは配信されません。


mxe.int.whereclausepolicy統合クエリーの where 文節ポリシーを設定します。

parse グローバル管理者、テナント管理者




mxe.int.adminfromemail統合で電子メールが開始されるときに From 電子メール・アドレスとして使用される、電子メール・アドレスの FROM 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。

テナント管理者

mxe.int.admintoemail統合で電子メールが開始されるときに To 電子メール・アドレスとして使用される、電子メール・アドレスの TO 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。複数の電子メール・アドレスをコンマ区切りリストで指定することができます。


REST 統合プロパティー

REST API 統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.rest を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。

表 31. REST API 統合プロパティープロパティー説明デフォルト値

mxe.rest.format.json.mimetypes REST がサポートする json 用MIME タイプ。

application/json

mxe.rest.format.xml.mimetypes REST がサポートする json 用MIME タイプ。

application/xml,text/xml

mxe.rest.handler.mbo REST MBO リソース・ハンドラー。

com.ibm.tivoli.maximo.rest.

MboResourceRequestHandler

mxe.rest.handler.os REST オブジェクト構造リソース・ハンドラー。


OSResourceRequestHandler

mxe.rest.handler.ss REST 標準サービス・リソース・ハンドラー。


MaxServiceResourceRequestHandler

mxe.rest.serializer.mbo.

imglib.image

イメージ・フォーマット用imagelib MBO の REST シリアライザー。


ImageLibSerializer

mxe.rest.serializer.mbo.json json フォーマット用 MBO のREST シリアライザー。


MboJSONSerializer

mxe.rest.serializer.mbo.xml XML フォーマット用 MBO のREST シリアライザー。


MboXMLSerializer

mxe.rest.serializer.os.json json フォーマット用オブジェクト構造の REST シリアライザー。


OSJSONSerializer

mxe.rest.serializer.os.xml XML フォーマット用オブジェクト構造の REST シリアライザー。


OSXMLSerializer

mxe.rest.serializer.ss.json json フォーマット用標準サービスの REST シリアライザー。


ServiceMethodResponseJSONSerializer

mxe.rest.serializer.ss.xml XML フォーマット用標準サービスの REST シリアライザー。


ServiceMethodResponseXMLSerializer

mxe.rest.webappurl Web アプリケーション URL のトークン認証。


表 31. REST API 統合プロパティー (続き)


mxe.rest.mbo.blockaccess MBO のコンマ区切りリストへのアクセスをブロックします。

mxe.rest.mbo.defaultformat すべての MBO の REST デフォルト・フォーマット。

xml

mxe.rest.mbo.imglib.defaultformat MBO imglib の REST デフォルト・フォーマット。

image

mxe.rest.os.blockaccess オブジェクト構造の区切りリストへのアクセスをブロックします。

10

mxe.rest.os.defaultformat すべてのオブジェクト構造のREST デフォルト・フォーマット。

xml

mxe.rest.ss.defaultformat すべての標準サービス応答のREST デフォルト・フォーマット。

xml

mxe.rest.supportedformats REST がサポートする応答用のフォーマット。

xmljsonimage

mxe.rest.whereclausepolicy REST クエリーの where 文節ポリシーを設定します。

parse

OSLC 統合プロパティー

OSLC 統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.oslc を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。

表 32. OSLC 統合プロパティープロパティー説明デフォルト値

mxe.oslc.dfltconsumerversion コンシューマーが使用するデフォルトのOSLC バージョン。

2

mxe.oslc.dfltversion OSLC プロバイダーのデフォルトの OSLC

バージョン。2

mxe.oslc.enableprovider OSLC プロバイダーを有効にします。 1

mxe.oslc.idleexpiry アイドル状態の有効期限切れ時間を示します。

300

mxe.oslc.webappurl プロバイダーのパブリック URL。 http://localhost/maximo/oslc/

mxe.oslc.collectioncount OSLC コレクション内の合計カウントを追加します。

0

mxe.oslc.defaultep デフォルトの OSLC エンドポイント。 OSLCDEFAULT

mxe.oslc.defaultformat OSLC のデフォルトの形式。 oslcjson

mxe.oslc.errorresponse OSLC のエラー応答形式。 1

mxe.oslc.preferproviderdesc リソース・レジストリー調整 URL のOSLC プロバイダーの説明を優先します。

False

mxe.oslc.prefersmallpreview OSLC コンシューマーの簡易プレビューを優先します。

False

mxe.oslc.prettyjson 読みやすく整えられた JSON。 0

mxe.oslc.prettyrdf 読みやすく整えられた RDF。 0

mxe.oslc.prqueryep プロバイダー・レジストリー・クエリー・エンドポイント。

PROVIDERREGISTRY


表 32. OSLC 統合プロパティー (続き)


mxe.oslc.prcreateep プロバイダー・レジストリー作成エンドポイントを表します。

JMS キュー構成パブリッシュ・チャネルまたはエンタープライズ・サービスを使用して交換される非同期トランザクションでは、Java Message Service (JMS) キューを使用して外部システムとデータを交換します。

インバウンド処理の場合、エンタープライズ・サービス・メッセージが受信されると、そのメッセージは即時に JMS キューに書き込まれ、サービスの呼び出し元はトランザクションから解放されます。メッセージは、アプリケーション・ビジネス・オブジェクトを介してインバウンド JMS キューから処理され、データベースに保存されます。メッセージは、正常に処理されるまで、またはキューから削除されるまで、インバウンド・キューの中に残っています。インバウンド・キューを実装する際の一般的な方法は、キューおよびキュー・コンシューマーを別個のサーバーまたはサーバー・クラスターに分離することです。この方法により、インバウンド・メッセージ処理がアプリケーション・ユーザーにパフォーマンス上の影響を与えないようにすることができます。

アウトバウンド処理の場合、パブリッシュ・チャネルを使用して送信されるメッセージは JMS キューに書き込まれ、そのメッセージを開始したユーザーがトランザクションから解放されます。メッセージは、構成済みのエンドポイントを使用してアウトバウンド JMS キューから処理され、外部アプリケーションに配信されます。メッセージは、外部アプリケーションに正常に配信されるまで、またはキューから削除されるまで、アウトバウンド・キューの中に残っています。

デフォルトのメッセージ・キューには以下の 3 種類があります。

v 1 個のアウトバウンド用の連続キュー

v 1 個のインバウンド用の連続キュー

v 1 個のインバウンド用の継続中のキュー

JMS キューの実装は、単一のアプリケーション・サーバー上、またはアプリケーション・サーバーのクラスター全体で動作することができます。

キューの作成および構成複数の外部システムに単一の JMS キューを使用することも、使用する外部システムごとに別個のキューを作成することもできます。キューの作成と構成では、複数のステップを実行します。統合の要件に応じて、デフォルトのキューを使用することも、追加のキューを作成することもできます。


アウトバウンド・トランザクションとインバウンド・トランザクションをサポートするために、それぞれ別個のキューが使用されます。キューは、インバウンド・トランザクションまたはアウトバウンド・トランザクションのいずれか (両方ではなく) をサポートするように構成します。パブリッシュ・チャネルで使用する場合は


アウトバウンド・キューを構成し、エンタープライズ・サービスで使用する場合はインバウンド・キューを構成します。

手順1. アプリケーション・サーバーでメッセージ・キューを作成および構成します。

WebSphere Application Server では、JMS キューを自動または手動で構成できます。 WebLogic Server では JMS キューを手動で構成する必要があります。

2. 「外部システム」アプリケーションで、プロパティーをキューに追加します。システムの要件に合わせて、追加のキューを作成することが可能です。デフォルトのキューを使用しない場合は、キューの構成用にアプリケーション・サーバー・プロバイダーを使用します。

3. 「外部システム」アプリケーションで、これらのキューを使用するように外部システムとエンタープライズ・サービスを構成します。

キューのプロパティー:

外部システム・アプリケーションで、各 JMS キューのいくつかのプロパティーを構成できます。

プロパティー説明

キューの JNDI 名アプリケーション・サーバーで構成されている Java Naming and Directory Interface

(JNDI) 名を参照します。デフォルト値が用意されています。

キューの接続ファクトリー名アプリケーション・サーバーで構成されている接続ファクトリー名を参照します。デフォルト値が用意されています。

初期コンテキスト・ファクトリーデフォルトのキューを使用せず、提供されたアプリケーション・サーバーを使用しない場合に構成する必要がある値。

プロバイダーの URL デフォルトのキューを使用せず、提供されたアプリケーション・サーバーを使用しない場合に構成する必要がある値。

ユーザー ID キューがアプリケーション・サーバーで保護されている場合に構成するユーザー ID。

パスワードキューがアプリケーション・サーバーで保護されている場合に、ユーザー ID に対応して構成するパスワード。

インバウンドキューがインバウンド処理に使用されるかどうかを指定します。インバウンドの値が null

の場合、システムはそのキューをアウトバウンド処理に使用します。

連続キューが連続キューであるかどうかを指定します。連続の値が null の場合、システムはそのキューを継続中キューの処理に使用します。



圧縮メッセージをキューに書き込むときに圧縮し、キューから取り出すときに圧縮解除するかどうかを指定します。圧縮を行うとメッセージのサイズが大幅に縮小されます。圧縮には標準 Java Inflater および Deflater API

(java.util.zip) が使用されます。

最大試行回数統合フレームワークがエラーの検出後にメッセージの再処理を試みる回数を指定します。システムはこの回数の値に達するまでメッセージの処理の再試行を続けます。エラー・キューが実装されている場合、このプロパティーの値はゼロに設定する必要があります。

連続キュー連続キューは、システムの定義済みクーロン・タスクを使用してメッセージを取り込む JMS キューです。連続キューのメッセージは厳密な先入れ先出し方式で処理され、メッセージが生成および受信された順序で処理されるようにします。

メッセージの結果としてエラーが発生すると、システムはメッセージ再処理アプリケーションで管理可能なエラーを生成し、そのエラーがクリアされるまではキューにある後続のメッセージを処理しません。

インバウンドおよびアウトバウンドのメッセージ処理用に 2 つのシステム連続キューを構成することができます。定義済みクーロン・タスクの JMSQSEQCONSUMER

はキューをポーリングします。タスクのインスタンスは 2 つあり、1 つはインバウンド用のキューをポーリングし、もう 1 つはアウトバウンド用のキューをポーリングします。追加の連続キューを作成する場合、クーロン・タスクの追加インスタンスを構成してそれらの追加のキューを指すことができます。

以下の表に、構成可能なクーロン・タスク・パラメーターをリストします。

パラメーター説明

MESSAGEPROCESSOR キューからのメッセージを処理する Java クラス。システムはこのクラスを提供します。

QUEUENAME キューがアプリケーション・サーバーで作成されるときのキューの JNDI 名。

SELECTOR キュー内のメッセージのサブセットを処理するクーロン・タスクのインスタンスを構成するための WHERE 文節。このパラメーターはオプションです。

TARGETENABLED 値がデフォルトの 0 (false) であることを確認してください。このフラグの機能は、donotrun 機能に置き換えられました。クーロン・タスク・フレームワークの donotrun パラメーターを使用して、クーロン・タスクの実行先のサーバーを制御します。


継続中のキュー継続中のキューは、メッセージ駆動型 Bean (MDB) がコンシューマーとして指定された JMS キューです。継続中のキューはエンタープライズ・サービスの場合にのみ事前定義されており、マルチスレッド処理を使用してシステム・パフォーマンスを向上させます。継続中のキューは、連続キューの場合と同様に、メッセージの処理順序を保証しません。

メッセージの処理でエラーが発生し、そのエラーをメッセージ再処理アプリケーションで管理できない場合は、システムはエラー・メッセージを生成してから、キューにある後続のメッセージの処理を続行します。インバウンド・メッセージの処理用にデフォルトの継続中のキューが 1 つあります。統合の要件に応じて、継続中のキューを追加で実装することができます。

メッセージ Bean の使用可能化:

アプリケーション・サーバーのメッセージ Bean は、継続中のキューからのメッセージのコンシューマーとして機能します。メッセージ Bean が継続中のキューをサポートできるようにするには、アプリケーション・サーバーで XML デプロイメント・ファイルの行をアンコメントする必要があります。

手順

1. WebSphere Application Server および WebLogic Server の両方の環境で、...¥applications¥maximo¥mboejb¥ejbmodule¥META-INF¥ フォルダーにあるejb-jar.xml ファイルの以下のコード行をアンコメントします。



2. WebSphere Application Server 環境にある...¥applications¥maximo¥mboejb¥ejbmodule¥META-INF¥ibm-ejb-jar-bnd.xmi ファイルの以下の行をアンコメントします。




3. WebLogic Server 環境にある...¥applications¥maximo¥mboejb¥ejbmodule¥META-INF¥weblogic-ejb-jar.xml

ファイルの以下の行をアンコメントします。



4. XML ファイルに変更を加えたら、その変更を有効にするために、EAR ファイルを再作成してアプリケーション・サーバーに再デプロイする必要があります。

継続中のキューのパフォーマンス:

キューのパフォーマンスを向上させるために、キューに対するメッセージ駆動型Bean の数を増やし、クラスター内に追加のアプリケーション・サーバーを導入することができます。メッセージ処理はマルチスレッド化されているため、処理の順序がランダムであることが原因でエラーが生じる可能性があります。

以下の例は、発生する可能性があるエラーを示しています。いずれのシナリオでも、システム管理者がエラーを確認できる前に、統合エラー管理処理でエラーの再処理を正しく行うことができます。

例えば、継続中のキュー内の大量の部品および在庫のメッセージのバッチ・ロードを実行していて、同じ部品番号の在庫レコードが複数存在するとします。部品 A をシステムに追加する部品メッセージより前に部品 A の在庫メッセージが処理された場合、部品 A が存在しないために在庫メッセージでエラーが発生します。処理は、次のメッセージから続行されます。

最終的に、部品 A の部品メッセージは処理され、部品 A はシステムに追加されます。これで、失敗したメッセージを正しく処理することができます。この場合、手操作による介入を行わなくてもエラーが訂正されます。

このタイプの状況は、継続中のキューで関連のあるメッセージを同時にロードすると起こる可能性があります。このような状況は、トランザクションの量が多いときに起こる可能性がありますが、2 つのメッセージが関連のあるデータを同時に処理する場合にも起こることがあります。

例えば、2 つのメッセージが同時に同じシステム・レコードの更新を試みるとします。1 つのメッセージは成功し、もう 1 つは失敗します。ただし、システムのエラー管理処理では、最初の更新が完了した後に 2 番目のメッセージの処理を行わなければなりません。


メッセージ Bean の構成:

作成できる Bean の最大数は、サーバー固有の拡張機能によって制御されます。

WebSphere Application Server でのメッセージ Bean の構成:

デフォルトでは、サーバーは 5 つのメッセージ駆動型 Bean を含むように構成されます。

手順

1. 管理コンソールで、JMS 活動化仕様を選択します。

2. 「intjmsact」を選択します。

3. 「最大並行エンドポイント数」フィールドに値を指定します。

WebLogic Server でのメッセージ Bean の構成:

デフォルトでは、WebLogic Server は 3 つのメッセージ駆動型 Bean を含むように構成されます。

手順

1. テキスト・エディターで weblogic-ejb-jar.xml ファイルを開きます。

2. 以下のコード行を検索します。

<pool><max-beans-in-free-pool>3</max-beans-in-free-pool></pool>

3. 必要に応じて、3 の値を別の値に置き換えます。最初はメッセージ駆動型 Bean

を比較的少ない数に設定し、パフォーマンスをモニターします。

4. このファイルを変更して、継続中のキュー内のメッセージの処理パフォーマンスが満足するレベルに達するまで、メッセージ駆動型 Bean の数を徐々に増やしていきます。

次のタスク

システム・パフォーマンスが低い場合、一部のシステム・パフォーマンスの問題は、サーバーをクラスター化して、インバウンド・メッセージの処理を特定のサーバー・クラスターに限定することによって解決できる場合があります。

メッセージのキャッシング:

継続中のキューの処理では、活動化仕様定義の下の「最大バッチ・サイズ」プロパティーを使用して、単一のバッチでメッセージング・エンジンから受信するメッセージの数を制御します。

3 つのメッセージ駆動型 Bean が使用可能で、バッチ・サイズが 10 の場合、最大30 個のメッセージがキャッシュに保存されます。設定した値がアプリケーション・ユーザーまたはサーバー・プロセスに影響を与えないことを確認するために、さまざまな値を指定してテストしてください。

WebLogic サーバー環境で「最大バッチ・サイズ」の値を -1 に設定すると、処理できるメッセージ数は無制限になります。


WebSphere Application Server のエラー・キューの使用を計画している場合は、バッチ・サイズのデフォルト値を使用してください。

継続中のキューのためのエラー・キューの構成:

アプリケーション・サーバーでエラー・キューを実装し、メッセージがエラーになった場合にメッセージをメインのキューから 2 次的なキューに移動することができます。統合シナリオで特に少量のメッセージを想定していない限り、エラー・キューを構成して、継続中のキューを介したメッセージ処理に対応してください。

継続中のキューは、MDB を使用してメッセージをコンシュームします。メッセージがエラーになった場合、MDB は、メッセージの処理回数が構成されている最大試行回数に達した後も、エラーがあるメッセージを引き続きコンシュームします。これらのメッセージが継続的に選択されると、システム・リソースが消費され、他のメッセージの処理がスローダウンする可能性があるだけでなく、処理が阻害されることも考えられます。継続中のキューに対してエラー・キューを構成すると、エラーがあるメッセージを 2 次的なキューにバイパスすることで、パフォーマンスの遅れやトランザクションのボトルネックが発生するのを回避することができます。

WebSphere Application Server でのエラー・キューの構成:

継続キューに対応するエラー・キューを構成することができます。メッセージでエラーが検出された場合、配信失敗最大回数パラメーターに設定された再試行回数に達すると、そのメッセージは継続中のキューから出され、エラー・キューに移動されます。これによって、継続中のキューで新しいキュー・メッセージが処理されます。


システム・プロバイダーは、テナントの代わりにこのタスクを実行する必要があります。

手順

1. 継続中のキューがある同じバス・メンバー内でエラー・キューの宛先を構成します。

2. 継続中のキューの宛先定義を、例外の宛先を含むように構成します。例外の宛先は、定義したエラー・キューの宛先を指していなければなりません。

3. エラー・キューで、自身を指している例外の宛先を追加します。エラー・キュー内のエラーは、エラー・キューの先頭から末尾へと移動されます。エラーのあるメッセージの処理は、継続的に再試行されます。

4. テキスト・エディターで ejb-jar.xml ファイルを開き、MDBDELAY プロパティーを使用可能にします。メッセージの再処理中にシステム・リソースが過剰に使用されないように、MDBDELAY プロパティーによってメッセージの処理を遅らせます。

5. 以下のコード行をアンコメントし、適切な値を設定します。

<env-entry><env-entry-name>MDBDELAY</env-entry-name><env-entry-type>java.lang.Long </env-entry-type><env-entry-value>30000</env-entry-value></env-entry>


デフォルト値は 30 秒 (30000 ミリ秒) です。

6. ibm-ejb-jar-bnd.xmi ファイルを開き、以下のコード行をアンコメントして、エラー・キューでメッセージ駆動型 Bean を使用可能にします。



WebLogic Server の継続中のキューのエラー:

WebLogic Server キューには再配信の遅延プロパティーがあり、これによってエラーのあるメッセージの再処理方法を制御することができます。再配信の遅延プロパティーは、メッセージのエラーが報告されてからそのメッセージが再処理されるまでの時間を表します。

再配信の遅延プロパティーに指定した時間の間は、キューにあるメッセージを表示することはできません。再配信の遅延により、システムのパフォーマンスが向上します。エラーのあるメッセージ以外のメッセージは、再配信の遅延プロパティーで定義された時間の間に処理することができます。処理の遅延はメッセージに適用され、メッセージを処理するスレッドには適用されません。

バッチ・サイズ・プロパティーを -1 (無制限) に設定し、再配信の遅延プロパティーを 30 秒 (30,000 ミリ秒) に設定すると、キューにある新しいメッセージを処理することができます。多数のエラーが再処理されている場合でも、処理は続行されます。

連続キューと継続中のキューの両方に同じ接続ファクトリーが使用されます。順次コンシューマー処理の問題を回避するには、宛先キュー構成に再配信の遅延の値を設定します。接続ファクトリー・レベルの構成は設定しないでください。

エラーのあるメッセージの処理回数が構成済みの試行回数を超えた場合、そのメッセージは処理を停止し、エラー管理のためにリダイレクトされます。

代わりに、エラー・キューを実装することもできます。エラー・キューを実装するには、ejb-jar.xml ファイルおよび weblogic-ejb-jar.xml ファイル内のエラー・キューのエントリーをアンコメントする必要があります。

キュー・メッセージのフォーマット統合フレームワークによって JMS キューにロードされるメッセージには、コンポーネントとフォーマットが定義されています。メッセージの本文には、システム内で処理される、または外部システムに送信される XML メッセージが含まれます。

メッセージ・ヘッダー

メッセージ・ヘッダーには、JMS メッセージ ID および標準 JMS ヘッダーの値を含めることができます。


ヘッダー説明

JMSMessageID システムによって生成されるメッセージID。

JMSRedelivered メッセージが再処理されるかどうかを指定します。

メッセージのプロパティー

このプロパティーには、 JMS プロバイダーと統合フレームワークからのプロパティーが次のように含められています。統合フレームワークのプロパティーはストリング・データ型のものです。


MEAMessageID 統合フレームワークによって生成されるメッセージ ID。

destjndiname メッセージが書き込まれるキューまたはトピックの名前。

INTERFACE パブリッシュ・チャネル (アウトバウンド用キュー) およびエンタープライズ・サービス(インバウンド用キュー) の名前。

destination アウトバウンド・メッセージの外部システム名。

SENDER インバウンド・メッセージの外部システム名。

USER インバウンド統合メッセージに関連付けられているユーザーの名前。この値は、必要に応じて許可セキュリティーに使用できます。

compressed メッセージを圧縮するかどうかを示します。値は True または False です。デフォルト値は False です。

圧縮には標準 Java Inflater および Deflater

API (java.util.zip) が使用されます。

uncompressed_length 圧縮前の元のメッセージのペイロード・サイズを保管します。この値は int [xsd:int] スキーマ・タイプに準拠していなければならず、compressed プロパティーが True に設定されている場合にのみ存在します。

MSG_TRK_ENABLED 内部値

MSG_OP_MODE アウトバウンド・メッセージのエンドポイント名。インバウンド・メッセージの場合は、固定ストリング MXJMS。

MSG_TRK_STORE_MSG 内部値

MSG_TRK_EXTSYS アウトバウンド・メッセージおよびインバウンド・メッセージの外部システム名。

Msgkeyval フィールド名のメッセージ・キー。

searchfieldval コンマ区切りの検索フィールド値。



msgoperation パブリッシュ・チャネルまたはエンタープライズ・サービスに、同期、作成、更新、または削除のどの操作が含まれるかを示します。

msgstatus メッセージにRECEIVED、ERROR、DELETED、またはPROCESSED のどのステータス値が含まれるかを示します。

msgerrmsg 例外メッセージ・テキストを含みます。

テキスト形式のメッセージ:

統合フレームワークによってキューに書き込まれるメッセージは、デフォルトでは、バイト形式です。外部システム・アプリケーションを使用して、テキスト形式のメッセージもサポートされるようにすることができます。

テキスト形式のメッセージをサポートするには、外部システム・アプリケーションの「キューの追加/変更」ウィンドウで、「テキスト」チェック・ボックスを選択します。テキスト形式のメッセージをサポートするようにキューが構成されている場合は、統合コンポーネントによってキューに書き込まれる後続のすべてのメッセージは、デフォルトの javax.jms.BytesMessage 形式ではなく、javax.jms.TextMessage 形式になります。

キューがテキスト形式のメッセージ用に構成されている場合は、外部システム・アプリケーションの「テキスト・メッセージのエンコード」フィールドで、外部システム用に構成されたすべてのインバウンド・キューにおけるテキスト形式メッセージのエンコードを指定します。値を指定しなければ、メッセージは UTF-8 でエンコードされているものと想定されます。アウトバウンド・キューに書き込まれるメッセージは常に、UTF-8 でエンコードされます。

キューのセレクターセレクターは JMS キューのコンシューマーの WHERE 文節の働きをします。セレクターは、継続中のキューまたは連続キューのどちらでもメッセージのヘッダーとプロパティーに適用することができます。

次の表に、JMS キューのコンシューマーで継続中のセレクターを使用する方法を示します。

キューのタイプセレクターを確認する場所

連続キュークーロン・タスクのプロパティーとして指定されます。

継続中のキューメッセージ駆動型 Bean の ejb-jar.xml コード内で指定されます。

セレクターを適用するとキューがさらに小さなキューに分割されます。それぞれの小さなキューには、各クーロン・タスクまたはメッセージ駆動型 Bean が使用するデータのサブセットが含まれます。データのサブセットの 1 つでエラーが発生しても、連続キュー内のその他のサブセットの処理は停止されません。


セレクターによってトランザクションの処理の分離を柔軟に行えるようになりますが、ポーリング処理のパフォーマンスは低下します。トランザクションの量によっては、複数のセレクターを含む 1 つのキューを実装するのでなく、複数のキューを実装する方が適切な場合があります。通常、複数のキューがあるとパフォーマンスは向上します。

JMSQSEQCONSUMER の SEQQIN インスタンスの SELECTOR プロパティーに以下のステートメントを追加すると、クーロン・タスクに対して、対応する外部システムからの MXPOInterface および MXPRInterface トランザクションを処理するように指示することができます。

SENDER=’EXTSYS1’ and INTERFACE in ('MXPOInterface’, 'MXPRInterface’)

メッセージ駆動型 Bean に対して、対応する外部システムからの MXPOInterface トランザクションおよび MXPRInterface トランザクションを処理するように指示するには、以下の内容を ejb-jar.xml ファイル内のメッセージ Bean の構成に追加します。

<message-selector>SENDER=’EXTSYS1’ AND INTERFACE IN ('MXPOInterface’, 'MXPRInterface’)

</message-selector>

2 つの外部システムがデータをインバウンド用の連続キューに送信する場合、いずれかのレコードでエラーが発生すると、そのキューにあるすべてのトランザクションの処理が停止され、先入れ先出しの処理順序が維持されます。1 つのクーロン・タスクの複数のインスタンスを作成して、それぞれに異なる外部システムを処理するセレクターを指定すると、1 つのシステムでエラーが発生しても 2 つ目のシステムのトランザクションは停止されません。

セレクターの WHERE 文節が、確実に連続キュー内の相互排他的なトランザクション・セットを指定するようにしてください。キューに挿入されたすべてのトランザクションを組み込んで、すべてのメッセージが先入れ先出し順序で処理されるようにします。

JMS キュー内のメッセージの表示および削除JMS キュー内のメッセージのリストを表示し、それらのメッセージをダウンロードして内容を表示し、構成済みのキューからメッセージを削除することができます。メッセージを表示または削除するときは、セレクターを適用して処理用に返されるメッセージを制限できます。


現在、メッセージ駆動型 Bean によって継続中のキューに入れる処理、または JMS

クーロン・タスクによって連続キューに入れる処理が行われているメッセージは、表示も削除もできません。クーロン・タスクを非アクティブ化すると、連続キューに入れるメッセージの処理を停止できます。メッセージ駆動型 Bean は継続的にメッセージを処理し、処理されるメッセージの数は変化すると考えられます。メッセージ駆動型 Bean を使用不可にしない限り、一部のメッセージが表示できない、または削除できない事態が起こり得ます。メッセージ駆動型 Bean が有効なときにメッセージを表示または削除する場合、処理できないメッセージが出てくる可能性があります。


手順1. 外部システム・アプリケーションで、「キューの追加/変更」アクションを選択します。

2. キューを選択し、「キュー・データの表示」ボタンまたは「キュー・データの削除」ボタンをクリックします。

3. オプション: 「キュー・データの表示」オプションを選択する場合は、「カウント」フィールドに数値を指定して表示するレコード数を制限できます。また、現在キューに入っているメッセージ数のみを確認する場合は「カウントのみ」フィールドにチェック・マークを付けることができます。

4. オプション: 「キュー・データの表示」ウィンドウまたは「キュー・データの削除」ウィンドウで返されるレコードをフィルターに掛ける場合は、以下のいずれかのセレクターを指定します。


MEAMessageID メッセージの ID (インバウンド・メッセージおよびアウトバウンド・メッセージに適用)。

INTERFACE インバウンド・メッセージの場合はエンタープライズ・サービスの名前、アウトバウンド・メッセージの場合はパブリッシュ・チャネルの名前。

destination 外部システムの名前 (アウトバウンド・キューの場合のみ)。

SENDER 外部システムの名前 (インバウンド・メッセージの場合のみ)。

USER メッセージで指定されているユーザー。この値はオプションであり、インバウンド・メッセージの場合にのみ適用されます。

セレクターの値は大/小文字が区別され、その値は単一引用符で囲む必要があります。例えば、INTERFACE='MXPERSONInterface' のようにします。

WebSphere MQ によるキューの構成IBM WebSphere MQ を使用して、キューイング・アクティビティーを構成および管理することができます。統合フレームワークは WebSphere MQ バージョン 6 をサポートします。

関連概念:

208ページの『テキスト形式のメッセージ』統合フレームワークによってキューに書き込まれるメッセージは、デフォルトでは、バイト形式です。外部システム・アプリケーションを使用して、テキスト形式のメッセージもサポートされるようにすることができます。

JMS エンドポイントおよびハンドラーの構成:

パブリッシュ・チャネル内のアウトバウンド・メッセージはデフォルト・キューに入れられます。そのメッセージが WebSphere MQ に送信されるように JMS エンドポイントとハンドラーを構成する必要があります。


手順

1. WebSphere Application Server で WebSphere MQ プロバイダーを作成し、以下を使用してメッセージ・キュー (MQ) プロバイダーを指すように統合エンドポイントを構成します。

a. 宛先の JNDI 名 (DESTJNDINAME)

b. 接続ファクトリーの JNDI 名 (CONFACTORYJNDINAME)

2. 以下を使用して WebSphere MQ を指すようにエンドポイントを構成します。

a. 宛先の JNDI 名 (DESTJNDINAME)

b. 接続ファクトリーの JNDI 名 (CONFACTORYJNDINAME)

c. プロバイダーの URL (PROVIDERURL)

d. 初期コンテキスト・ファクトリー (CONTEXTFACTORY)

統合キューおよび WebSphere MQ プロバイダーの構成:

統合フレームワークのキューを WebSphere MQ のキューに置き換えるには、WebSphere Application Server でキューを構成し、外部システム・アプリケーションでこれらのキュー定義を追加します。

手順

1. デフォルト・プロバイダーと置き換える代替プロバイダーを定義して、JMS キューを作成します。

2. メッセージ・キュー (MQ) のサーバー・キューを指している WebSphere MQ プロバイダーを使用して、WebSphere Application Server 上でプロキシー・キューを作成します。

3. 外部システム・アプリケーションの「キューの追加/変更」ダイアログ・ウィンドウで、「キューの JNDI 名」フィールドおよび「接続ファクトリー」フィールドに値を追加して、プロキシー・キューと接続ファクトリーを指すようにします。

タスクの結果

デフォルト・キューを宛先とするアウトバウンド・メッセージはメッセージ・キュー (MQ) に配信され、インバウンド・メッセージはメッセージ・キュー (MQ) から取り出されます。

エラー管理統合フレームワークは、さまざまなメッセージ形式、メッセージ交換用のプロトコル、および同期メッセージ処理と非同期メッセージ処理の両方をサポートしています。エラーを管理するためには、選択可能なさまざまな実装構成を満たすための複数のオプションが必要です。

JMS キューは、統合フレームワークによってインバウンド・メッセージおよびアウトバウンド・メッセージのステージング・メカニズムとして使用されます。キュー・エラー管理は、エラー条件が指定されると開始され、問題のあるメッセージの表示、修正、取り消し、および再処理が可能です。


非キュー・エラー管理インバウンドまたはアウトバウンド統合メッセージの同期処理を開始すると、実行時に発生したエラーはすべて通知されます。

非キュー・エラー管理は、同期メッセージの処理中にエラーが発生した場合に必要になります。インバウンド・メッセージでは、統合フレームワークが、エラー・キューに依存するのではなく、プロセスの呼び出し元にエラー・メッセージで同期的に応答します。呼び出し元アプリケーションは、応答を受信してエラーを訂正し、トランザクションを再試行する必要があります。

同期トランザクション・エラーのトラブルシューティングを行うには、システム・ログを使用します。システム・ログには、統合フレームワークがプロセスの呼び出し元に発行する処理例外が含まれます。

キュー・ベースのエラー管理JMS キューを使用するインバウンドおよびアウトバウンド非同期統合メッセージにエラーがあった場合、メッセージ再処理アプリケーションを使用してそれらのメッセージを管理することができます。

メッセージがキューから外部システムに送信されるときに発生するエラーは、一般に、インターフェース・テーブルまたはファイルへの書き込み時の通信障害またはデータベース構成の問題が原因となっています。インバウンド処理中のエラーは、一般に、ビジネス・ルールの検証または統合フレームワークのインバウンド処理ロジックの結果として発生します。

連続キューは、メッセージを一度に 1 つずつ先入れ先出しの順序で処理します。統合フレームワークがインバウンド用またはアウトバウンド用の連続キューでメッセージの処理中にエラーを検出した場合、エラー管理メカニズムが開始され、メッセージにはエラーのフラグが立てられます。キューに入っているそれ以降のメッセージは、エラーのあるメッセージが解決されるか削除されるまで、処理されません。結果として、連続キューで発生する可能性があるエラーは 1 つだけです。

継続中のキューは、インバウンド処理のみを対象としており、マルチスレッド・モードでメッセージを処理します。継続中のキューでエラーが発生すると、エラー管理が開始され、メッセージにはエラーがあることを示すフラグが立てられます。統合フレームワークは、キュー内のそれ以降のメッセージの処理を続行します。結果として、継続中のキューでは複数のエラーが発生する可能性があります。

システム構成に応じて、統合フレームワークは、どちらのタイプのキューについても、メッセージの再処理を数回試行した後に、エラーに介入が必要であると判断します。システムはエラーを検出すると、さらに以下のアクティビティーも実行します。

v 指定された電子メール・アカウントに通知を送信して、受信者にエラーの発生を通知します。IBM WebSphere Application Server 環境では、アプリケーション・サーバーが正常に再始動されるたびに、統合フレームワークが指定の電子メール・アカウントに追加の電子メール・メッセージを送信します。

v 「メッセージ再処理」アプリケーションにレコードを作成します。「メッセージ再処理」アプリケーションで表示できるレコードを作成します。このレコードには、キューに入れられたメッセージが含まれています。


エラー管理の構成エラー管理を構成するには、システムのプロパティーを構成し、外部システムを構成する必要があります。

エラー管理プロパティーの構成:

統合フレームワークを使用する前に、システムのプロパティー・アプリケーションでプロパティーを構成します。

手順

1. mxe.int.adminfromemail プロパティーをフィルターに掛けて、[email protected] などの電子メール・アドレスを指定します。このアドレスは、統合フレームワークによって送信されるエラー通知に表示されます。SMTP サーバーの中には、このアドレスが有効な電子メール・アドレス・フォーマットでなければならないものと、どの値でも受け入れるものがあります。

2. mxe.int.admintoemail プロパティーをフィルターに掛けて、メッセージ処理エラーの通知を受け取る電子メール・アドレスを 1 つ以上指定します。複数の電子メール・アドレスを区切るにはコンマを使用します。オプションで、キュー・レベルの電子メール・アドレス・プロパティーを使用して、管理者アドレスを指定変更することができます。キューごとに異なる電子メール・アドレスを指定する場合は、このオプションを使用します。電子メール・アドレスを構成しない場合、キュー処理エラーが発生しても電子メール通知は送信されません。

3. mail.smtp.host プロパティーをフィルターに掛けて、SMTP サーバーを指定します (構成されていない場合)。このプロパティーは統合フレームワークに固有のものではなく、他のアプリケーション用に構成されている可能性もあります。

外部システムでのエラー管理の構成:

エラー管理を実施するように外部システムを構成します。

手順

1. 外部システム・アプリケーションで、「最大試行回数」フィールドに適切な値を指定します。システムがトランザクションを再試行する回数に制限はありません。トランザクションの処理試行が最初に失敗した時点で、システム管理者は通知を受け取り、メッセージがエラー・ファイルに書き込まれます。この値は、アウトバウンド用のキューでは通常 0 に設定されます。

2. キューごとに異なるアドレスにエラー通知メッセージを送信する場合、「電子メール・アドレス」フィールドに値を指定します。複数のアドレスをコンマ (,)

で区切って入力することができます。このプロパティーの値は、管理者の電子メール・アドレス・プロパティーの値を指定変更します。値が指定されない場合、電子メール通知は管理者の電子メール・アドレス・プロパティーに指定された電子メール・アドレスに送信されます。


エラー通知インバウンド・トランザクションまたはアウトバウンド・トランザクションが実行された結果、キューでエラーが発生した場合は、同じキューで別の未解決のエラーが待機していない場合にのみ、電子メール通知がシステム管理者に送信されます。


キューに複数のエラーが存在する場合、システム管理者は新しいエラーの通知が送信される前にすべてのエラーを解決する必要があります。

電子メール・エラー・メッセージには、Java エラー・スタック・トレースが記載されています。

継続中のキューの場合も連続キューの場合も、インバウンド・メッセージの場合もアウトバウンド・メッセージの場合も、さらにシステムがクラスター環境で稼動しているか非クラスター環境で稼動しているかにかかわらず、すべてのエラーについて同じ通知プロセスが使用されます。

以下の例では、インバウンド用の継続中のキューに 10 個のメッセージがある場合のエラー通知について説明します。先頭から 4 個のメッセージが正常に処理され、5 番目のメッセージでエラーが発生したとします。外部システムの最大試行回数プロパティーに設定された値に応じて、メッセージの処理が 1 回以上試行されます。メッセージによってエラーが発生し続ける場合は、電子メール通知がシステム管理者に送信され、キュー内のそれ以降のメッセージが処理されます。 7 番目のメッセージで別のエラーが発生しても、システム管理者が最初のエラーを解決していなければ、別の電子メール通知が送信されることはありません。システム管理者が最初のエラーを解決していて、保留中のエラーがない場合は、新しい電子メール通知がシステム管理者に送信されます。

エラーが連続キューで検出された場合、処理は継続中のキューと同じですが、最初にエラーが発生したメッセージが解決されるまでシステムが以降のメッセージを処理しない点のみが異なります。

複数のエラーが存在する可能性があるのは、インバウンド用の継続中のキューの場合のみです。クラスター環境では、エラーのあるトランザクションのタイミングに応じて、システム管理者がアプリケーション・サーバーごとに 1 つの電子メール・エラー通知を受け取る可能性があります。

アウトバウンド・メッセージの場合、メッセージがキューに保存されているがキューへのトランザクションのコミットが失敗した場合には、一般的でない例外条件が発生することがあります。この例外は、JMS データ・ストアへのデータベース接続が使用可能でないことが原因で発生することがあります。この例外が発生した場合は、通知が送信され、メッセージ再処理アプリケーションでエラーのあるメッセージが JMSERROR または SAVED のステータスとともに表示されます。このメッセージはキューに保存されなかったため、メッセージ・ステータスを RETRY に設定することはできませんが、アプリケーションからメッセージを処理することは可能です。

メッセージ再処理「メッセージ再処理」アプリケーションでは、エラーのフラグが立てられているメッセージを管理できます。例えば、メッセージのステータスを変更したり、メッセージを修正したり、データベースから削除したりすることができます。

メッセージ・トラッキングが有効な場合は、「メッセージ・トラッキング」アプリケーションを使用して、エラーのフラグが立てられている追跡対象メッセージを判別します。メッセージ・トラッキングが無効な場合は、トランザクション・エラーが発生したかどうかを「メッセージ再処理」アプリケーションで確認できます。


メッセージのステータス値:

メッセージのステータスを変更するには、メッセージ再処理アプリケーションの「ステータスの変更」アクションを選択します。システムは各メッセージにステータスを指定して、処理の準備ができているかどうかを示します。

メッセージのステータスは「やり直し」または「保留」です。

ステータス説明

やり直しメッセージがシステムによって再処理される準備ができています。

保留メッセージがシステムによって再処理される準備ができていません。

「やり直し」ステータスは、エラーのフラグが立てられたメッセージのデフォルトのステータスです。処理の問題が訂正されるまで、構成済みのキューの再試行回数に従ってメッセージの再処理を続けます。再試行回数の条件が満たされると、システムはメッセージのステータスを「保留」に変更します。

メッセージのステータスを「保留」に変更すると、メッセージの再処理を一時停止することができます。ステータスが「保留」の場合、システムはフラグが立てられたメッセージを再処理せず、システム・データベース表を更新しません。

エラー XML メッセージ:

エラーが発生したときに生成された XML メッセージを確認することができます。また、メッセージの内容を変更することができます。

メッセージ再処理アプリケーションでエラーを管理している場合に、以下の情報が表示されることがあります。

v 「エラー・データ」フィールドにエラー・メッセージが表示される。

v メッセージ内容に、キューに入れられてエラーの原因となっている元のメッセージが含まれている。このエレメントは編集可能です。

v 内部レコード (使用可能な場合) にエラー発生時のメッセージの XML 表現が含まれている。内部レコードは編集できませんが、エラー発生前に統合処理で元のメッセージが変更されたかどうかを内部レコードで確認することができます。

内部レコードは、エンタープライズ・サービスおよびユーザー出口の処理中に作成されたオブジェクト構造を表します。内部レコードは、エンタープライズ・サービスとユーザー出口の処理が正常に完了した場合にのみ、インバウンド・トランザクションで使用可能となります。内部レコードは情報提供のみを目的としており、変更することはできません。

エラー XML メッセージの例を以下に示します。

<?xml version="1.0" encoding="UTF-8"?><SyncMXPERSON xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"creationDateTime="2014-04-22T14:04:03-04:00"transLanguage="EN" baseLanguage="EN" messageID="11798570432187483"maximoVersion="7 6" event="1" messageid="11798570432652428">

<MXPERSONSet>


<PERSON action="Update">...</PERSON></MXPERSONSet></SyncMXPERSON>

内部レコード XML メッセージの例を以下に示します。

<?xml version="1.0" encoding="UTF-8"?><SyncMXPERSON xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"creationDateTime="2014-04-22T14:04:03-04:00"transLanguage="EN" baseLanguage="EN" messageID="11798570432187483"maximoVersion="7 6" event="1" messageid="11798570432652428">

<MXPERSONSet><PERSON action="Update">...</PERSON></MXPERSONSet></SyncMXPERSON></IR></ERROR>

クリティカル・エラー:

クリティカル・エラーは、統合フレームワークのエラー訂正プロセスが再試行できない処理例外です。

トランザクション処理の例外は、XML ファイルに特殊文字などの誤りのデータがある場合に発生します。クリティカル・エラーを訂正するには、誤ったデータをエラーのある XML メッセージから除去します。クリティカル・エラーに関連する誤りのデータは、「メッセージ再処理」アプリケーションのメインタブで表示することができます。

エラーの修正:

メッセージ再処理アプリケーションで、エラーになったメッセージを再処理することも、データベースからそのメッセージを削除することもできます。

編集したメッセージの再処理:

メッセージ再処理アプリケーションでメッセージを表示、変更、および再処理できます。エラーの XML メッセージを編集した後、メッセージを再処理せずに変更内容を保存またはキャンセルすることができます。


編集が可能なメッセージは、「保留」ステータスのメッセージのみです。「やり直し」ステータスのメッセージの場合、メッセージの内容は読み取り専用です。

手順

1. メッセージ再処理アプリケーションで、変更するメッセージを選択し、「メッセージの詳細」アイコンをクリックします。

2. 「エラー・データ」ウィンドウで、メッセージに必要な変更を加えます。


3. メッセージを再処理する場合は「プロセス」をクリックします。「保存」をクリックしてメッセージを再処理せずに変更を保存したり、「キャンセル」をクリックして変更を廃棄したりすることができます。

タスクの結果

処理に成功すると、メッセージ再処理アプリケーションは以下のタスクを実行します。

v エラー・メッセージ・テーブル内のレコードの削除

v エラー・ステータス・テーブル内の「DELETEFLAG」、「CHANGE BY」、および「CHANGE DATE」の各属性の更新

次のタスク

「メッセージの詳細」ウィンドウで、エラーのフラグが立てられたメッセージのリストを最新表示します。メッセージが正常に再処理された場合、メッセージはリストから削除されます。

メッセージの削除:

エラー・メッセージ・キューからメッセージを削除できます。メッセージを削除すると、メッセージは再処理できなくなります。

手順

1. メッセージ再処理アプリケーションで、削除するメッセージ・レコードを選択します。

2. 「メッセージの削除」アクションを選択します。


タスクの結果

メッセージが削除されると、MAXINTERRORMSG および MAXINTERROR テーブルからレコードが削除されます。アプリケーションは、結果セットをリフレッシュして、「メッセージ再処理」アプリケーションのメインタブにある削除済みメッセージのリストを除外します。

メッセージの最新表示:

メッセージ再処理アプリケーションの「リフレッシュ」アイコンを使用して、メッセージ・リストを更新できます。メッセージ・リストを最新表示すると、特定のメッセージ一覧のステータスを確認できます。

メッセージ処理が正常に実行されると、該当のメッセージ一覧が省略されます。メッセージを削除すると、削除されたメッセージ一覧が省略されます。

ファイル・ベースのデータ・インポート機能によるエラーの管理統合フレームワークは、メッセージ再処理アプリケーションによってエラー管理をサポートします。このアプリケーションにより、インバウンド・キューからの処理時にエラーになったメッセージの検討、修正、再処理、および削除を行えます。データを XML ファイルまたはフラット・ファイルからインポートする場合は、メッ


セージ再処理アプリケーションではなく、ダウンロード・ファイルを使用してエラーを管理する別のオプションが使用可能です。

ファイル・ベース・エラー管理は、多数のエラーが発生する可能性がある多数のメッセージをインポートするときに役立ちます。メッセージ再処理アプリケーションで多数のエラーを個別に管理するよりも、多数のエラーを 1 つのファイル形式で管理する方が簡単で迅速に管理できます。

関連概念:

246ページの『ファイル・ベースのデータのエクスポートとインポート』統合管理者は、外部システム・アプリケーション内からデータのエクスポートおよびインポートを開始して、ファイルによるデータの統合などをサポートすることができます。インポート処理には、ファイルからデータ・ロードをプレビューし、データベースに保存する前にデータを検証するための機能が組み込まれています。インポート処理には、ファイルのロードに起因するエラーを、インポートするファイルと同じファイル形式で管理するためのオプションも組み込まれています。

ファイル・ベースのエラー管理:

データ・インポート機能でファイル・ベースのエラー管理を使用できます。ファイル・ベースのエラー管理には、エラーのフラグが立てられたすべての統合メッセージを識別し、すべてのエラーを含む完全なファイルをダウンロードするための機能が用意されています。ダウンロードされるファイルは、インポートに使用したファイルと整合した形式になっています。

ファイル・ベースのエラー管理を構成するには、「データのインポート」ウィンドウで「ファイル・ベース・エラー管理」チェック・ボックスを選択します。

「ファイル・ベース・エラー管理」チェック・ボックスを選択した上で「インポートのプレビュー」チェック・ボックスをクリアした状態にすると、インバウンド・メッセージが正常に処理されてキューに入れられた後にシステム・メッセージが出されます。

インバウンド処理のロジックでは、ソース・ファイルにあるすべてのメッセージの処理エラーが検出され、失敗したメッセージを再処理可能ファイルでダウンロードできるようにします。「メッセージ再処理」アプリケーションに、再処理可能ファイルをダウンロードするための機能が備わっています。

「ファイル・ベース・エラー管理」チェック・ボックスを選択した場合、エラーのフラグが立てられた統合メッセージのすべては再処理可能ファイルでのみ使用可能であり、「メッセージ再処理」アプリケーションの「メッセージ」セクションには表示されません。

データ・インポート・クーロン・タスクでのエラー管理の構成:

XMLFILECONSUMER および FLATFILECONSUMER クーロン・タスクのISFILEEXTRACT パラメーターを設定して、使用するエラー管理メカニズムを指定することができます。

ISFILEEXTRACT パラメーターに指定可能な値を以下の表に示します。


値エラー管理メカニズム

0 エラー管理を「メッセージ再処理」アプリケーションで処理します。

1 ファイル・ベースのエラー管理を「データのインポート」ウィンドウおよび再処理可能ファイルで処理します。

ファイル・ベースのエラー管理は、エラーのフラグが立てられたすべての統合メッセージが再処理可能ファイル内にのみ提供され、メッセージ再処理アプリケーションのメッセージ・セクションには表示されないことを意味します。

ファイル・ベースのエラー管理によって抽出される情報:

ファイル・ベースのエラー管理には、1 つの入力ファイルから発生したすべてのエラー・メッセージが含まれた再処理可能ファイルをダウンロードするための機能が用意されています。

「メッセージ再処理」アプリケーションの「エラー抽出」セクションで得られる情報を以下の表に示します。

フィールド説明

インポート・ファイル

再処理可能ファイルを生成したソース・ファイルの名前。


ソース・ファイルのインポートに使用されたエンタープライズ・サービスの名前。

外部システム

ソース・ファイルのインポートに使用された外部システムの名前。

インポート日

データのインポート・プロセスがソース・ファイルの処理を開始した日時。

インポート済み件数

元のソース・ファイルからインポートされたメッセージの総数。

処理済み件数

正常に処理されたメッセージの数。

エラー件数エラーがあるメッセージの数。

ファイル形式

ソース・ファイルの形式。

抽出で選択可能

ソース・ファイルのインバウンド処理が完了したかどうかを示します。

「抽出」アイコン

ファイルのダウンロード処理を開始するアクション・ボタン。ソース・ファイルがインポート・メカニズムによって完全に処理されたことを保証するために、エラー件数と処理済み件数の合計がインポート済み件数に等しい場合に限ってファイルをダウンロードできます。

「削除」アイコン

選択したレコードを「エラー抽出」テーブルから削除するアクション・ボタン。テーブルのレコードを削除できるのは、エラー件数と処理済み件数の合計がインポート済み件数に等しい場合のみです。


再処理可能ファイルのダウンロード:

再処理可能ファイルをダウンロードして、そのファイルで識別されている処理エラーを修正することができます。これにより、ファイルに含まれているエラー・メッセージの説明情報を一切削除せずに再処理可能ファイルの再ロードを試行することができます。

手順

1. メッセージ再処理アプリケーションで、対応するエラーをダウンロードするソース・ファイルを指定します。

2. そのソース・ファイルがデータのインポート処理によって完全に処理されたことを確認します。エラー件数フィールドと処理済み件数フィールドの合計は、インポート済み件数フィールドと一致していなければなりません。

3. 「ダウンロード」アイコンをクリックします。

4. クライアントまたはアクセス可能なファイル・サーバー・ロケーションに再処理可能ファイルを保存します。

再処理可能ファイルの形式:

再処理可能ファイルをダウンロードした場合、そのファイルは元の入力ファイルと同じ形式で提供されます。フラット・ファイル形式を使用する場合、ファイルでは同じ区切り文字およびテキスト修飾子が使用されます。再処理可能ファイルのデフォルトのファイル名は<UniqueFileIdentifier>_<OriginalFileName>.<OriginalFileExtension>です。

XML 再処理可能ファイルの例

XML ファイルに基づく再処理可能ファイルには、元のオブジェクト構造のメインMBO に追加エレメントが組み込まれます。例えば、MXASSET 情報に基づいて生成された再処理可能ファイルには、資産エレメントの一部としてMAXINTERRORMSG エレメントが組み込まれます。

<?xml version="1.0" encoding="UTF-8"?><SyncMXASSET xmlns="http://www.ibm.com/maximo" transLanguage="EN">

<MXASSETSet><ASSET>

<ANCESTOR /><ASSETID>94</ASSETID><ASSETNUM>THREE_T2002</ASSETNUM><ASSETTAG /><ASSETTYPE />.........<WARRANTYEXPDATE>2020-12-24T00:00:00-05:00</WARRANTYEXPDATE><YTDCOST>0.0</YTDCOST><MAXINTERRORMSG>

The following error occurred while processing ASSET.BMXAA4147E -Item set error1 does not exist.

</MAXINTERRORMSG></ASSET>.........

</MXASSETSet></SyncMXASSET>


フラット形式の再処理可能ファイルの例

フラット・ファイル構造に従った再処理可能ファイルには、追加カラムが組み込まれます。例えば、MXASSET 情報に基づいて生成された再処理可能ファイルには、元のレコード構造の最後に MAXINTERROR カラムが組み込まれます。

EXTSYS1,MXASSETInterface,,ENASSETNUM,AS_DESCRIPTION,AS_DESCRIPTION_LD,HIERARCHYPATH,AS_SITEID,MAXINTERRORMSGT-SP500_error,autospray,,,TEXAS,The following error occurred while processing ASSET.BMXAA4049E -The value specified T-SP500_error exceeds the maximum field length.

再処理可能ファイルの削除:

ファイルとして再処理可能なデータを永続的に削除することができます。

手順

1. メッセージ再処理アプリケーションで、削除する再処理可能データの行を指定します。

2. 「削除」アイコンをクリックします。

インターフェース・テーブルのエラー管理インターフェース・テーブルは、インバウンドおよびアウトバウンドのデータ交換に使用することができます。インターフェース・テーブルからキューにインバウンド・データを書き込むとき、またはキューからインターフェース・テーブルにアウトバウンド・データを書き込むときに、エラーが発生することがあります。

アウトバウンド・メッセージをキューから取り出すクーロン・タスクがエラーを検出した場合、メッセージは、そのエラー状態が処理されるまでキューに残っています。エラーは以下の理由で発生することがあります。

v インターフェース・テーブルが存在しない。

v スペース不足が原因のデータベース・エラーが発生している。

v オブジェクト構造で定義されたメッセージ内容が変更されたが、その新規メッセージ形式を反映するためのインターフェース・テーブルの再作成が行われていない。

アウトバウンド・メッセージがインターフェース・テーブルに到着した場合、そのデータを取得して統合実装に基づいてエラーを管理するのは、外部アプリケーション側で行う必要があります。

インバウンド・メッセージをキューに書き込むクーロン・タスクは、以下の理由でエラーを検出することがあります。

v JMS キューが非アクティブになっているか、使用可能なフリー・スペースがありません。

v エンタープライズ・サービスまたは外部システムの名前が無効です。

v エンタープライズ・サービスが外部システム用に使用可能になっていません。

v 外部システムが使用可能になっていません。

インバウンド・インターフェース・テーブルの処理中にエラーが発生すると、ポーリング・プログラムが例外トレースを MXIN_INTER_TRANS キュー・テーブルの


IMPORTMESSAGE カラムに書き込みます。MXIN_INTER_TRANS キュー・テーブル内の最初のエラーの場合、システムは管理者に電子メール通知を送信します。エラー状態を解決するには、MXIN_INTER_TRANS のデータ行の更新 (例えば、外部システム名の値を訂正する)、またはアプリケーション内の構成データの更新 (例えば、エンタープライズ・サービスに使用可能のマークを付ける) を行います。

クーロン・タスクは、MXIN_INTER_TRANS キュー・テーブル内の後続レコードを処理すると、定義済みのクーロン・タスク処理間隔に基づいてアイドル状態に切り替わります。処理を再開すると、クーロン・タスクはエラーのあるレコードおよびMAX_INTER_TRANS キュー・テーブルに追加された新規レコードの処理を試みます。

エラー通知の送信後に、そのキュー・テーブルにエラーと示されたトランザクションが 1 つ含まれていても、クーロン・タスクは追加のエラーの通知を送信しません。最初のエラーの通知を受信した担当者が、そのキュー・テーブルを調べたときに追加のエラーを確認し、訂正するものと想定されています。すべての現行エラーが訂正された後にクーロン・タスクが新しいエラーを検出すると、通知を送信します。

クーロン・タスクがインターフェース・テーブル・メッセージをインバウンド・キューに正常に書き込んだ後に発生するエラーは、そのキューのエラー処理プロセスによって管理されます。

エラーの一般的な原因アウトバウンド用のキューにあるメッセージの処理時に発生したエラーの原因は、外部システムとして指定されたエンドポイントへのメッセージ配信の問題です。インバウンド用のキューにあるメッセージの処理時に発生するエラーは、通常、ビジネス・ルール妥当性検査に関連したエラーか、エンタープライズ・サービスのインバウンド処理でのエラーです。

アウトバウンド処理の場合は、代表的な問題として、外部システムへの通信リンクの中断、データベース表スペースに関する問題、または外部アプリケーションにおけるファイル・スペースの問題が挙げられます。アウトバウンド・エラーを解決する場合、通常は XML メッセージを修正する必要はありません。

次の表では、発生する可能性がある最も一般的なメッセージ・エラーと、推奨する修正方法について説明します。XML メッセージのエラーを修正すると、送信システムと受信システムの間でデータの不一致が生じる可能性があります。

エラー・タイプ説明アクション

シーケンス・エラーメッセージ間の順序付けの問題によって発生します。1 つのレコードが保留状態の別のレコードを参照している場合、システムはメッセージ処理を停止します。

各レコードが正しい順序で処理されるようにするために、このエラーが適用されます。メッセージ・トランザクションの方向および適用される処理ロジックによっては、保留状態にあったレコードが処理された時点で、処理によりエラーを自己修正させることができます。


エラー・タイプ説明アクション

データ・エラーデータまたはレコードがシステム・データベース内に存在せず、キュー内のインバウンド・メッセージの部分ではないときに発生します。

システム・データベースに欠落データを追加します。

通信エラーシステム障害またはネットワーク問題に起因する外部システムとの通信問題によって発生します。

外部システムとの通信をリストアします。

メッセージ・エラーメッセージ・データ値にエラーがあるために発生します。

v トランザクションのステータスを「保留」に変更します。

v エラーのある XML メッセージを訂正します。

v トランザクションのステータスを「やり直し」にして、トランザクションを再処理します。

エラーの調査エラー通知を受信したら、メッセージ再処理アプリケーションで XML メッセージを確認します。メッセージ再処理アプリケーションでは、個別のキューについて示されるキュー内のメッセージの数が、キューのタイプ (連続または継続中) に応じて、ゼロ、1 個、または複数になります。

エラーのあるメッセージが存在しない場合

メッセージ再処理アプリケーションでエラーのあるメッセージが表示されない場合は、メッセージが再試行され、エラーが発生しなかったことを示します。メッセージが正常に処理された時点でエラー・メッセージが削除されています。

例えば、誤った GL 勘定科目が原因で、インバウンド受領メッセージでエラーが発生したとします。エラーの発生後、オンライン・ユーザーがシステムに GL 勘定科目を入力します。メッセージは正常に再処理され、データが保存されます。

別の例として、アウトバウンド・トランザクションで通信エラーが発生したとします。通信の問題が解決すると、メッセージが外部システムに送信され、エラーのあるメッセージは削除されます。

エラーのあるメッセージが 1 つ以上存在する場合

連続キュー (インバウンドまたはアウトバウンド) でエラーが発生すると、キューの処理はエラーが解決されるまで停止します。

継続中のキューでエラーが発生すると、キューの処理は続行され、最初のエラーが解決する前に追加のエラーが発生することがあります。メッセージ再処理アプリケーションでエラーのあるメッセージが複数表示される可能性があります。


メッセージ・トラッキングメッセージ・トラッキング・アプリケーションは、パブリッシュ・チャネル・メッセージとキューに基づくエンタープライズ・サービス・メッセージの処理履歴を追跡して表示します。

「メッセージ・トラッキング」アプリケーションは、「メッセージ再処理」アプリケーションと連係して機能します。「メッセージ・トラッキング」アプリケーションを使用すると、エラーのフラグが立てられているメッセージを判別することができます。これにより、障害の起こったメッセージを選択して、「メッセージ再処理」アプリケーションに進み、適切なアクションを実行してエラーのあるデータを訂正することができます。

メッセージの詳細:

メッセージ・トラッキングを有効にすると、統合フレームワークがすべての処理済メッセージを MAXINTMSGTRK テーブルに書き込みます。キューに基づく処理サイクル内の現在位置を表すステータスが、各メッセージに割り当てられます。個々のメッセージ・イベントは、「メッセージの詳細」ウィンドウに表示されます。

メッセージ・トラッキングを使用可能にした場合、この機能が使用可能になる前から存在していたキュー・メッセージはメッセージ・トラッキング・ロジックによって識別されません。メッセージ・トラッキングを使用不可にした場合、この機能が使用不可になる前から存在していたメッセージ・キューは識別されますが、新規メッセージは識別されません。

メッセージには以下の属性があり、発信元のエンタープライズ・サービスまたはパブリッシュ・チャネルのデータに基づいて値が割り当てられます。

v 統合モード: メッセージの処理で使用される統合モードの名前。インバウンド・メッセージの場合、システムは MXJMS のデフォルト値を割り当てます。アウトバウンド・メッセージの場合、システムはメッセージの処理で使用されるエンドポイントの名前を割り当てます。

v 操作: システムが追跡対象メッセージに適用する処理操作で、SYNC、UPDATE、QUERY、DELETE、CREATE、および PUBLISH のいずれかです。

v システム: エンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けられた外部システムの名前。

v 統合コンポーネント: エンタープライズ・サービスまたはパブリッシュ・チャネルの名前。

v アダプター: エンタープライズ・サービスまたはパブリッシュ・チャネルに関連付けられたアダプターの名前。

v キュー名: 統合フレームワークがメッセージの処理に使用するキューの名前。

以下の属性には、トランザクション・レコードが作成される時点で値が割り当てられます。

属性値

受信日時 (Received Datetime) メッセージがキューで受信された日時。


属性値

メッセージ ID 統合フレームワークによって割り当てられた固有のメッセージ ID。

検索 ID 外部アプリケーションによって割り当てられ、メッセージの検索で使用されるメッセージ ID。

外部メッセージ ID 外部アプリケーションによって割り当てられた固有のメッセージ ID。

以下の属性には、トランザクション・イベントに基づいて変化する動的な値が割り当てられます。

属性値

現在のステータス追跡されたメッセージの最新の処理ステータス。

ステータストランザクション履歴で個々のメッセージ・イベントに関連付けられているステータス。

ステータス変更日トランザクション履歴の個々のメッセージ・イベントのステータス日付。

エラートランザクション履歴の個々のエラー・メッセージ・イベントのエラー・メッセージ。

メッセージのステータス値:

「メッセージ・トラッキング」アプリケーションに登録されたキューに基づくすべてのインバウンド・メッセージおよびアウトバウンド・メッセージには、トランザクション処理サイクル内の位置を示すステータス値があります。

メッセージ・トラッキングのステータスは、メッセージが正常に受信または処理されたかどうかを示します。さらにメッセージ・トラッキングのステータスは、メッセージが削除されたかどうか、またはエラーのフラグが立てられたかどうかも示します。

インバウンド・メッセージのステータス

インバウンド・メッセージには、以下のステータス値があります。


ERROR 検証で問題が発生したためにメッセージ処理が失敗しました。

DELETED メッセージはキューから削除されました。

PROCESSED メッセージは正常に処理されました。

RECEIVED メッセージは、インバウンド・キューに正常に書き込まれました。


アウトバウンド・メッセージのステータス

アウトバウンド・メッセージには、以下のステータス値があります。


ERROR 検証で問題が発生したためにメッセージ処理が失敗しました。

DELETED メッセージはキューから削除されました。

PROCESSED メッセージは正常に処理されました。

RECEIVED メッセージは、アウトバウンド・キューに正常に書き込まれました。

メッセージ・イベント:

「メッセージ・トラッキング」アプリケーションは、キューに基づくインバウンドおよびアウトバウンド・トランザクション処理イベントを追跡および表示します。トランザクション処理イベントは、MAXINTMSGTRK テーブルを更新するためにシステムをトリガーします。

以下のメッセージ・テーブル属性は、イベント・タイプに応じて更新されます。

v STATUS

v STATUSDATETIME

v ERRORMSGR

以下のインバウンドおよびアウトバウンドのイベントによって、MAXINTMSGTRK

テーブルが更新されます。

表 33. インバウンド・イベントおよびアウトバウンド・イベントのトラッキング

イベント詳細

キューへのメッセージの書き込み統合フレームワークが最初にメッセージをキューに書き込むときに、メッセージ・トラッキング・テーブル内にレコードが作成されます。メッセージが正常にキューに書き込まれると、メッセージ・レコードのステータスは「受信」に設定されます。

統合フレームワークはインバウンド・メッセージをキューに書き込んでいるときにエラーを検出すると、プロセスの呼び出し元に障害の原因を説明するメッセージを送信します。

メッセージ処理中のエラーメッセージ・トラッキング・テーブル内の既存レコード。資産管理システムは処理エラーを検出すると、メッセージ・レコードのステータスを「エラー」に更新します。メッセージを再送信して再び処理エラーが発生した場合、資産管理システムは「エラー」のメッセージ・ステータスを維持します。


表 33. インバウンド・イベントおよびアウトバウンド・イベントのトラッキング (続き)

イベント詳細

キュー処理の終わり以下のトランザクション処理イベントが発生すると、既存のレコードが更新されます。

v 資産管理システムはメッセージ処理を正常に完了し、メッセージ・レコード・ステータスを「PROCESSED」に更新します。処理サイクルは完了しているため、メッセージ・トラッキング・テーブルはこれ以上更新されません。

v キューからメッセージを削除すると、資産管理システムはメッセージ・レコード・ステータスを「DELETED」に設定します。メッセージ・トラッキング・テーブルは更新されなくなります。

メッセージ・トラッキングの構成:

パブリッシュ・チャネルを介して送信されるメッセージ、またはエンタープライズ・サービスから受信されるメッセージを追跡することができます。

パブリッシュ・チャネル・アプリケーションおよびエンタープライズ・サービス・アプリケーションで、以下のメッセージ・トラッキング機能を構成できます。

v メッセージ・トラッキングの有効化または無効化。

v トランザクション・メッセージおよびトラッキング詳細のデータベースへの保管

v 「メッセージ・トラッキング」アプリケーションの検索機能が使用するメッセージ・データの、XPATH 式による指定。

v XPATH 式を使用した、単一の ID 値によるメッセージの一意的な識別。

v XPATH 式を使用した、検索 ID 値によるメッセージの識別。

外部メッセージ ID 値および検索 ID 値に関連付けられた XPATH 式は、XML ファイル内の複数のノードを識別することができます。この場合、メッセージ ID と検索 ID の値は値のコンマ区切りリストとして登録されます。データベース・フィールドの長さは、外部 ID と検索 ID のフィールドに適用できます。必要な場合は、これらのフィールドの長さを「データベース構成」アプリケーションで調整することができます。

保管されるメッセージ

メッセージ・トラッキングを構成すると、メッセージとメッセージ・トラッキングの詳細がデータベースに保存され、メッセージ再処理アプリケーションで表示できるようになります。

外部メッセージ・トラッキング ID

各インバウンド・メッセージには、MAXINTMSGTRK テーブルに保管されている外部メッセージ ID があります。メッセージ・トラッキング・アプリケーションで、


この外部メッセージ ID を使用して特定のメッセージを見つけることができます。メッセージ・ノードの識別に使用する構文は、完全修飾 XPATH 式にする必要があります。

MXPERSONInterface エンタープライズ・サービスのメッセージをすべて検索するには、「外部メッセージ ID」フィールドに以下の完全修飾 XPATH 式を指定します。

/{http://www.ibm.com/maximo}SyncMXPERSON/@messageID

複数名詞のインバウンド・メッセージを受信すると、統合フレームワークは外部メッセージ ID の XPATH 式を使用してメッセージを識別します。XPATH 式がインバウンド・メッセージのそれぞれの名詞に含まれる要素を指す場合、統合フレームワークは外部 ID の複数名詞のコンマ区切りリストを作成します。

検索 ID

ノードを識別する XPATH 式を指定することによって、統合フレームワークは複数名詞検索を効率よく実行することができます。システムは、検索 ID をMAXINTMSGTRK テーブルに保管します。

MXPERSONInterface エンタープライズ・サービスのメッセージをすべて検索するには、以下の完全修飾 XPATH 式を検索 ID として作成します。

/{http://www.ibm.com/maximo}SyncMXPERSON/{http://www.ibm.com/

maximo}MXPERSONSet/{http://www.ibm.com/maximo}PERSON/{http://www.ibm.com/

maximo}PERSONID

複数名詞のインバウンド・メッセージを受信すると、統合フレームワークは検索 ID

の XPATH 式を使用してメッセージを識別します。XPATH 式がインバウンド・メッセージのそれぞれの名詞に含まれる要素を指す場合、統合フレームワークは検索ID の複数名詞のコンマ区切りリストを作成します。

メッセージ・トラッキングの有効化:

パブリッシュ・チャネル・アプリケーションでアウトバウンド・トランザクションのメッセージ・トラッキングを有効にし、エンタープライズ・サービス・アプリケーションでインバウンド・トランザクションのメッセージ・トラッキングを有効にします。

手順

1. パブリッシュ・チャネル・アプリケーションまたはエンタープライズ・サービス・アプリケーションで、統合メッセージを処理するチャネルまたはサービスを選択します。

2. 「メッセージ・トラッキング」アクションを選択します。

3. 「メッセージ・トラッキング設定」ウィンドウで、「メッセージ・トラッキングを有効にする」チェック・ボックスを選択します。

4. オプション: 「メッセージの保管」チェック・ボックスを選択して、トランザクション・メッセージを保管します。

5. オプション: 「外部メッセージ ID」フィールドで、特定のメッセージを見つけるための XPATH 式を 1 つ以上指定します。


6. オプション: 「検索 ID」フィールドで、メッセージを検索するための XPATH

式を 1 つ以上指定します。

クラスターの構成統合フレームワークは、アプリケーション・サーバーのクラスター全体にわたる統合サービスを提供できます。単一のサーバーの継続中のキューではメッセージの量にとって不十分である場合は、中央演算処理装置、ハードウェア、およびクラスター構成を追加してメッセージ処理のパフォーマンスを向上させることができます。

サーバー・クラスターを実装すると、インバウンド・メッセージの処理に複数のサーバーを同時に使用することができます。これらのメッセージは、メッセージ駆動型 Bean (MDB) を使用して継続中のキューで処理されます。クラスター構成を使用すると、大量のメッセージを処理できるようになります。

サーバー・クラスターの JMS キュークラスター構成では、JMS キューはサーバー・クラスターの 1 つのメンバーに関連付けられ、キューへのアクセスは Java Naming and Directory Interface (JNDI) サービスによって提供されます。

JDNI サービスは、クラスターのすべてのメンバーが使用できます。

XML (メッセージエンタープライズ・サービ

HTTP / EJB / SOAP

ロード・バランサー

アプリケーション・サーバー 1

JMS プロデューサー





��のキュー

JMS


JMS コンシューマー






ビジネス・オブジェクト / DB

コンシューマーとしてののアプリケーショ

ン・サーバーおよびによるマルチスレッド

!

�

MDB

コンシューマーとしてのクーロン・タスクによる

スレッド

"#

$% � (FIFO)

&� JMS キュー

すべてのクラスター・メンバーは、メッセージを連続キューに生成できます。単一スレッドのクーロン・タスクは、連続キューにあるメッセージを読み取り、先入れ先出し法による処理をサポートします。


継続中のキューはコンシューマー・サイドではマルチスレッドであり、大容量のメッセージ処理をサポートします。このキューではメッセージ処理の順序は考慮されません。

連続キューを使用するエンタープライズ・サービス・メッセージは、正確に順序どおりに処理されます。メッセージ処理は単一スレッドです。連続キューを使用する場合、クラスター化を行ってもメッセージの処理パフォーマンスに著しい影響は生じません。

アプリケーション・サーバー・クラスターの継続中のキュー:

クラスター環境では、継続中の JMS キューをクラスターの 1 つのメンバーにピンすることができます。

次の図に、アプリケーション・サーバーのクラスター構成の例を示します。継続中のキューは JMS プロデューサー・メッセージを受信して、JMS コンシューマー・メッセージを処理します。

XML ファイルフラッ

ト・ファイルインターフェース・テーブルのロード

、

、

XML(

)

トランザクションエンタープライズ・サ

ービス

HTTP / EJB / SOAP




クーロン・

タスク





JMS( )キュー��

JMS サーバー









JMS server2キューがにピンされるをすクラス

ターのどのサーバーにで

もピンできる

( 。

*

。

メッセージによるマルチスレッ

ド

+�,

�

Bean(MDB)

クーロン・タスクがでのを

すクラスターのどのサ

ーバーでもできる

server1 -.� (

。 *

-. 。

この例では、クラスター環境内に 3 つのアプリケーション・サーバーが存在します。継続中の JMS キューがクラスターの 1 つのメンバーにピンされます。

統合フレームワークが HTTP、Enterprise Beans、および SOAP アクションを使用してエンタープライズ・サービス・メッセージを受信するときに、処理が行われます。ロード・バランサーはアプリケーション・サーバーに対して、エンタープライ


ズ・サービス・メッセージを継続中のキュー内にドロップするよう指示します。クラスターの各メンバーはメッセージをキューに入れます。キューはクラスターの各メンバーにあります。

統合クーロン・タスクは、フラット・ファイルまたは XML ファイルおよびインターフェース・テーブルからエンタープライズ・サービス・メッセージを配信します。メッセージをキューに入れるクーロン・タスクは、クラスター内のどのサーバーでも実行できます。

メッセージがキューに入れられた後、すべてのアプリケーション・サーバーがそのキューから同時にメッセージをプルし、それらをシステムに取り込んで処理することができます。クラスター内の各アプリケーション・サーバーで、必ずメッセージ駆動型 Bean を使用可能にしてください。

アプリケーション・サーバー・クラスターの連続キュー:

連続キューは JMS プロデューサー・メッセージを受信して、JMS コンシューマー・メッセージを処理します。

次の図に、アプリケーション・サーバーのクラスター構成の一例を示します。

XML ファイルフラッ

ト・ファイルインターフェース・テーブルのロード

、

、

XML(

)

トランザクションエンタープライズ・サービス

HTTP / EJB / SOAP




クーロン・

タスク





JMS( )キュー&�

JMS サーバー

JMS クーロン・タスクはクラスターのどのサーバー

でもできる

*

-. 。アプリケーション・サーバー 1

JMS コンシューマー・クーロン・タスク





JMS server2キューがにピンされるをすクラス

ターのどのサーバーにで

もピンできる

( 。

*

。

クーロン・タスクによる

スレッド

"

# $% �

クーロン・タスクがでのを

すクラスターのどのサ

ーバーでもできる

server1 -.� (

。 *

-. 。

この例では、クラスター環境内に 3 つのアプリケーション・サーバーが存在します。連続 JMS キューがクラスターの 1 つのメンバーにピンされます。


統合フレームワークが HTTP、Enterprise Beans、および SOAP アクションを使用してエンタープライズ・サービス・メッセージを受信するときに、処理が行われます。ロード・バランサーはアプリケーション・サーバーに対して、エンタープライズ・サービス・メッセージを連続キュー内にドロップするよう指示します。クラスターの各メンバーはメッセージをキューに入れます。キューはクラスターの各メンバーにあります。

統合クーロン・タスクは、フラット・ファイルまたは XML ファイルおよびインターフェース・テーブルからエンタープライズ・サービス・メッセージを配信します。メッセージをキューに入れるクーロン・タスクは、クラスター内のどのサーバーでも実行できます。メッセージがキューに入れられると、JMS コンシューマー・クーロン・タスクを実行しているアプリケーション・サーバーがメッセージを順序に従って処理します。

継続中のキューとは異なり、設計上、メッセージのマルチスレッド化は行われません。クラスターを実装しても、連続キューによって処理されるメッセージの処理パフォーマンスに著しい影響は生じません。

クーロン・タスクの構成インターフェース・テーブル・クーロン・タスク、データのインポート・クーロン・タスク、および JMS キュー・クーロン・タスクは、クラスター対応の機能です。デフォルトで、クーロン・タスクのフレームワークは、ランダムに選択されたサーバーでタスクを実行します。サーバー・クラスター内の特定のアプリケーション・サーバーで実行されるようにクーロン・タスクを構成することができます。クーロン・タスク・フレームワークの donotrun パラメーターを使用して、クーロン・タスクの実行先のサーバーを制御します。

メッセージ処理サーバーの構成インバウンド・メッセージの量が多い場合、インバウンド・メッセージ処理を別のアプリケーション・サーバーまたはサーバー・クラスターに移動することで、サーバーの効率を向上することができます。

手順1. メッセージ処理サーバーまたはサーバー・クラスターに別のアプリケーション

EAR ファイルをデプロイします。

2. メッセージ処理アプリケーション・サーバーまたはサーバー・クラスターで、クーロン・タスク・フレームワークの donotrun パラメーターを使用して、クーロン・タスクの実行先のサーバーを制御します。

3. オプション: インバウンド用の継続中のキューからデータをプルするようにメッセージ駆動型 Bean を構成します。オンライン・ユーザー専用のサーバーまたはサーバー・クラスター内でメッセージ駆動型 Bean をインバウンド処理用に使用可能に設定しないでください。このサーバーまたはサーバー・クラスターでは他のバックグラウンド処理のクーロン・タスクを実行することができます。

4. オプション: データのインポート機能を使用するユーザーに対して、ユーザー・インターフェースへのアクセスを認可します。


グローバル・ディレクトリーの構成クラスター環境では、統合ファイルの管理のためにグローバル・ディレクトリーを構成する場合、グローバル・ディレクトリーはクラスターのすべてのメンバーからアクセス可能でなければなりません。

統合フレームワーク・コンポーネントの使用状況によっては、グローバル・ディレクトリーへのファイルの書き込みが可能であったり不可能であったりする場合があります。グローバル・ディレクトリーを構成する主要な理由の 1 つは、ファイル・ベースのエンドポイントの使用をサポートするためです。呼び出しチャネル用にファイル・ベースのエンドポイントの使用を予定しており、UI クラスターで構成されているアプリケーション・ユーザーがメッセージを開始する場合は、クラスターのすべてのメンバーがグローバル・ディレクトリーを表示できる必要があります。

グローバル・ディレクトリーを定義するには、「システムのプロパティー」アプリケーションで mxe.int.globaldir システム・プロパティーを更新します。

インバウンド・メッセージによるサービスへのアクセスエンタープライズ・サービス、オブジェクト構造サービス、および標準サービスは、いずれもサーバー・クラスターで機能することができます。

インバウンド・トランザクションは、以下のいずれの通信方式でも関連したサービスにアクセスできます。

v Java リモート・メソッド呼び出し (RMI)、Internet Inter-ORB Protocol (IIOP)、および Enterprise Bean

v HTTP および HTTPS サーブレット

v SOAP、HTTP、および HTTPS サーブレット

Enterprise Bean

単一のサーバーでは、JNDI ツリーにアクセスするためのプロバイダーの URL は単一サーバーの URL です。サーバー・クラスターでは、プロバイダーの URL はEnterprise Bean が導入されたいずれかのサーバーの URL にすることができます。クラスターのすべてのメンバーは JNDI ツリーを共有し、クラスターのどのメンバーもクラスターを探索および取得することができます。

クラスターがルックアップされると、クライアントは Enterprise Bean のクラスター対応プロキシーを取得します。それにより、そのプロキシーを使用する後続のすべての呼び出しのロード・バランシングが行われます。ロード・バランシングはクライアント・コードに対して透過的に行われます。単一サーバーのセットアップ用コードとクラスターのセットアップ用コードに違いはありません。各サービス・タイプ (オブジェクト構造サービス、エンタープライズ・サービス、および標準サービス) ごとに別々の Enterprise Bean が導入されます。

HTTP サーブレット

統合サーブレットは、クラスターのすべてのメンバーに対して導入されます。単一サーバー構成では、URL はそのサーバーの HTTP および HTTPS の URL です。クラスター構成では、URL はクラスターのロード・バランサーの HTTP および


HTTPS の URL です。各サービス・タイプ (オブジェクト構造、エンタープライズ、および標準) ごとに別々のサーブレットが導入されます。

次の表に、各サービスの URL フォーマットを示します。URL 内の meaweb 変数は、システムのプロパティー・アプリケーションで mxe.int.webappurl に指定した値を表します。

サービス URL

オブジェクト構造サービス http://hostname:port/meaweb/os/object structure

name

エンタープライズ・サービス (キューのバイパス)

http://hostname:port/meaweb/es/extsysname/

enterprise service name

エンタープライズ・サービス (キューを使用する場合)

http://hostname:port/meaweb/esqueue/extsysname/

enterprise service name

標準サービス http://hostname:port/meaweb/ss/standard service

name

Web サービス

統合 Web サービスは、クラスターのすべてのサーバー・メンバーに対して均一に導入されます。クラスターの Web サービス・アクセスは単一サーバーの場合と同じですが、Web サービスの URL および Web サービス記述言語 (WSDL) の URL

がクラスター内の特定のサーバーではなくクラスターを指す点が異なります。

次のプロパティーはクラスターの URL を指している必要があります。

v Web アプリケーション URL mxe.int.webappurl

v UDDI レジストリー照会 URL mxe.int.uddiinurl

v UDDI レジストリー公開 URL mxe.int.uddipuburl

Web サービスにアクセスするための URL は、http://hostname:port/meaweb/

services/web service name になります。URL 内の meaweb 変数は、システムのプロパティー・アプリケーションで mxe.int.webappurl に指定した値を表します。

統合セキュリティー統合フレームワークには、J2EE 認証およびコンポーネント・レベルの許可のためのサポートが組み込まれています。

認証セキュリティーJMS キュー、EJB、HTTP、および Web サービスを対象として J2EE 認証セキュリティーを構成することができます。また、リモート統合 API およびアウトバウンド・ルーティング用の Java ハンドラー・クラスを対象として認証セキュリティーを構成することもできます。

J2EE セキュリティーの構成:

統合フレームワークは、認証および許可に基づいてアクセスを制限するために、基本の J2EE セキュリティーをサポートします。


JMS キューの J2EE 制限の構成:

統合処理で使用される JMS キューでは、ユーザー ID とパスワードに基づく認証および許可をベースとした、J2EE セキュリティーがサポートされます。キューのJava Naming and Directory Interface (JNDI) 名が知られている場合でも、この JNDI

名にユーザー ID とパスワードを割り当てることにより、キューへの無許可アクセスを防ぐことができます。


複数のキューには同じまたは異なるユーザー ID を使用できます。

手順

1. サーバーの管理者コンソールで、以下のプロパティーにユーザー ID とパスワードの値を指定して、J2EE 制限を有効にします。

v java.naming.security.principal (ユーザー ID)

v java.naming.security.credentials (パスワード)

2. 外部システム・アプリケーションで、「キューの追加/変更」アクションを選択し、ステップ 1 で指定したものと同じユーザー ID およびパスワードを指定します。このステップにより、統合のプロデューサー・プログラムおよびコンシューマー・プログラムにキューへのアクセス権限が付与されます。

3. 継続中のキューへのアクセス権限を付与するには、ejb-jar.xml ファイルの<enterprise-beans> セクションの下に、太字のテキストで示されている <security

identify> 要素を追加します。

<enterprise-beans><message-driven id="MessageDriven_JMSContQueueProcessor_1">

<ejb-name>JMSContQueueProcessor-1</ejb-name><ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class><transaction-type>Container</transaction-type><message-driven-destination>

<destination-type>javax.jms.Queue</destination-type></message-driven-destination><env-entry>

<env-entry-name>MESSAGEPROCESSOR</env-entry-name><env-entry-type>java.lang.String </env-entry-type><env-entry-value>

psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>

</env-entry><security-identity>

<run-as><role-name>maximouser</role-name>

</run-as></security-identity>

</message-driven>

4. ejb-jar.xml ファイルの <assembly-descriptor> セクションの下に、太字のテキストで示されている <security-role> 要素を追加します。

<assembly-descriptor><security-role>

<role-name>maximouser</role-name></security-role><container-transaction>

<method><ejb-name>JMSContQueueProcessor-1</ejb-name><method-name>*</method-name>


</method><trans-attribute>Required</trans-attribute>

</container-transaction></assembly-descriptor>

Enterprise Bean へのアクセスの保護:

システムで J2EE 認証を使用可能に設定している場合は、デプロイメント記述子内の各 Enterprise Bean ごとにセキュリティーを有効にする必要があります。


ejb-jar.xml ファイルの <enterprise-beans> セクションの下に、3 つの統合 EJB がデプロイされ、(認証が不要であることを示す) デフォルト値の 1 が指定されています。

<ejg-name> とサービスのマッピングは次のとおりです。

<ejb-name> サービス

enterpriseservice エンタープライズ・サービス

mosservice オブジェクト構造サービス

actionservice 標準サービス

手順

1. 認証を強制的に行うには、3 つのサービスのそれぞれで、以下のコード例に太字で示されている ALLOWDFLTLOGIN 値を 0 (False) に変更します。

<enterprise-beans><session id="Session_enterpriseservice">

<ejb-name>enterpriseservice</ejb-name><home>psdi.iface.gateway.MEAGatewayHome</home><remote>psdi.iface.gateway.MEAGateway</remote><local-home>psdi.iface.gateway.MEAGatewayHomeLocal</local-home><local>psdi.iface.gateway.MEAGatewayLocal</local><ejb-class>psdi.iface.gateway.MEAGatewayBean</ejb-class><session-type>Stateless</session-type>

<transaction-type>Container</transaction-type><env-entry>

<env-entry-name>ALLOWDFLTLOGIN</env-entry-name><env-entry-type>java.lang.String</env-entry-type><env-entry-value>0</env-entry-value>

</env-entry><security-role-ref>

<description>Application Users

</description><role-name>maximouser</role-name><role-link>maximouser</role-link>

</security-role-ref></session><session id="Session_mosservice">

<ejb-name>mosservice</ejb-name><home>psdi.iface.mos.MOSServiceHome</home><remote>psdi.iface.mos.MOSServiceRemote</remote><local-home>psdi.iface.mos.MOSServiceHomeLocal</local-home><local>psdi.iface.mos.MOSServiceLocal</local><ejb-class>psdi.iface.mos.MOSServiceBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type><env-entry>





</description><role-name>maximouser</role-name><role-link>maximouser</role-link></security-role-ref></session>

<session id="Session_actionservice"><ejb-name>actionservice</ejb-name><home>psdi.iface.action.MAXActionServiceHome</home><remote>psdi.iface.action.MAXActionServiceRemote</remote><local-home>psdi.iface.action.MAXActionServiceHomeLocal</local-home><local>psdi.iface.action.MAXActionServiceLocal</local><ejb-class>psdi.iface.action.MAXActionServiceBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type><env-entry>




</description><role-name>maximouser</role-name><role-link>maximouser</role-link>

</security-role-ref></session>

クライアント・プログラムは、以下のサービス・タイプごとに Enterprise Bean

メソッドのセキュア・バージョンを呼び出します。

v エンタープライズ・サービス: secureProcessExtnernalDataAsync(..) ,

secureProcessExtnernalDataSync(..)

v オブジェクト構造サービス: secureProcessMOS(..)

v 標準サービス: secureAction(..)

2. Enterprise Bean を呼び出すセキュア・コンテキストを作成するには、以下のいずれかのタスクを実行します。

v クライアント・コードに次のコードを追加します。

Properties env = new Properties();...if(userid != null && password != null){env.put(Context.SECURITY_CREDENTIALS, password);env.put(Context.SECURITY_PRINCIPAL, userid);}

Context ctx = new IntialContext(env);//instead of using the default IntialContext() constructor

v デフォルトの InitalContext コンストラクターを使用して、クライアントを起動する .bat/.sh スクリプトの –D パラメーターによってセキュリティー情報を渡します。


–Djava.naming.security.principal=<username>–Djava.naming.security.credentials=<password>

SSL バージョンの Internet Inter-ORB Protocol は、プロバイダーの URL のデータの暗号化を実行し、システムは Enterprise Bean と通信します。

HTTP サーブレットの保護:

HTTP サーブレットは、インバウンド HTTP ポストを処理する J2EE コンポーネントです。HTTP サーブレットを保護するには、最初に Enterprise Bean を保護する必要があります。HTTP サーブレットを保護するには、HTTP 基本認証を使用することができます。有効なユーザー名とパスワードを持つ許可ユーザーが、XML トランザクションをシステムに送ることができます。


HTTP 基本認証を有効にするには、Web アプリケーションの web.xml ファイルを変更します。

v 統合サーブレットの <security-constraint> セクションからコメントを除去します。<security-constraint> セクションは、サービス・タイプ (エンタープライズ・サービス、オブジェクト構造サービス、および標準サービス) ごとに 1 つずつ、合計3 つあります。

<web-resource-name> とサービスのマッピングは次のとおりです。

<web-resource-name> サービス

Enterprise Service Servlet エンタープライズ・サービス

App Service Servlet 標準サービス

Object Structure Service Servlet オブジェクト構造サービス

手順

1. 次のコード例に示すように、web.xml ファイルで、各サービス・タイプのセキュリティー制約セクションをアンコメントします。



2. 次のコード例に示すように、web.xml ファイルの <security-role> セクションがコメント化されていないことを確認します。

<security-role><description>An Integration User</description><role-name>maximouser</role-name>

</security-role>

3. 次の例に示すように、useAppServerSecurity <env-entry-name> セクションで値を0 から 1 に変更します。

<description>Indicates whether to use Application Server security or not

</description><env-entry-name>useAppServerSecurity</env-entry-name><env-entry-type>java.lang.String</env-entry-type><env-entry-value>1</env-entry-value></env-entry>


次のタスク

HTTPS ポストに Secure Sockets Layer (SSL) を使用すると、Web サービスを安全にデプロイすることができます。アプリケーション・サーバーで、適切なデジタル証明書を指定して SSL を構成します。

Web サービスの保護:

標準 J2EE セキュリティーで HTTP 基本認証を使用することにより、統合 Web サービスを保護することができます。これらのセキュリティー設定により、有効なユーザー名およびパスワードを持つ許可ユーザーが Web サービスにアクセスできるようになります。

手順

1. HTTP サーブレットを保護する手順と同様に、次の例に示すように、web.xml ファイルで Web サービスの呼び出しの <security-constraint> セクションをアンコメントします。

<security-constraint><web-resource-collection>

<web-resource-name>Integration Web Services</web-resource-name><description>

Integration Web Services accessible by authorized users</description><url-pattern>/services/*</url-pattern><http-method>GET</http-method><http-method>POST</http-method>

</web-resource-collection><auth-constraint>

<description>Roles that have access to Integration Web Services

</description><role-name>maximouser</role-name>

</auth-constraint><user-data-constraint>

<description>data transmission gaurantee</description><transport-guarantee>NONE</transport-guarantee>

</user-data-constraint></security-constraint>

2. 次のコード例に示すように、web.xml ファイルの <security-role> セクションがコメント化されていないことを確認します。

<security-role><description>An Integration User</description><role-name>maximouser</role-name>

</security-role>

3. 次の例に示すように、useAppServerSecurity <env-entry-name> セクションで値を0 から 1 に変更します。

<description>Indicates whether to use Application Server security or not

</description><env-entry-name>useAppServerSecurity</env-entry-name><env-entry-type>java.lang.String</env-entry-type><env-entry-value>1</env-entry-value></env-entry>

4. Web サービスの呼び出しの場合、クライアント・プログラムが JAX-RPC Call

オブジェクトで次のユーザー名とパスワード呼び出しを使用していることを確認します。


call.setProperty(Call.USERNAME_PROPERTY, username);call.setProperty(Call.PASSWORD_PROPERTY, password);

次のタスク

HTTPS ポストに Secure Sockets Layer (SSL) を使用すると、Web サービスを安全にデプロイすることができます。アプリケーション・サーバーで、適切なデジタル証明書を指定して SSL を構成します。

インターフェース・テーブルのセキュリティー:

インターフェース・テーブルでは、デフォルトのデータベース認証および許可が使用されます。認証と許可が有効になっている場合、インターフェース・テーブルの読み取りおよび書き込みを行う外部プログラムは適切な許可を提示する必要があります。インターフェース・テーブルで読み取りおよび書き込みを行うために、USERNAME および PASSWORD の値がインターフェース・テーブル・ハンドラーを実装するエンドポイント用に構成されています。

リモート統合 API の保護:

MIC サービス・リモート API の中には、これらのメソッドのユーザーに強制的にUserInfo オブジェクトを提供させることによって、セキュア・アクセスを実現しているものがあります。有効な UserInfo オブジェクトが提供されない場合は、エラーが発生し、呼び出しは完了しません。

以下のリモート・メソッドは、機密情報を提供するか機密データ・トランザクション処理を実行するため、保護されています。

v exportData(..)

v deleteQueueData(..)

v processExternalData(..) (both versions)

v query(..)

v viewQueueData(..)

v loadData(..)

v loadSystemData(..)

v processObjectStructure(..)

v routeData(..)

上記のメソッドを実行するには、呼び出し元が有効な UserInfo オブジェクトを取得してメソッドに渡し、セキュア層にアクセスできるようにする必要があります。

UserInfo オブジェクトは、セキュリティー目的で使用されるユーザーの詳細 (ユーザー、パスワード、ロケール、言語、およびタイム・ゾーンなどの情報) が含まれている直列化オブジェクトです。

システムは、Java Remote Method Invocation (RMI) および Java Remote Method

Protocol (JRMP) を使用します。システム・サービスと通信するには、SSL を使用する JRMP プロトコルのセキュア・バージョンを使用します。


アウトバウンド・ルーター・ハンドラーのセキュリティー:

アウトバウンド・ルーター・ハンドラーには、許可と機密性を維持するためのサポートが用意されています。Enterprise Bean、HTTP、JMS、Web サービス、およびインターフェース・テーブル・ハンドラーには、セキュリティーのためのサポートが用意されています。

許可セキュリティー許可セキュリティーは、アプリケーション・レベル、オブジェクト・レベル、または標準サービスで定義されたメソッドのレベルで構成することができます。ユーザー認証が完了すると、統合フレームワークは、ターゲットのアプリケーション、オブジェクト、またはメソッドにメッセージを送信する権限がそのユーザーに付与されているかどうかを検査します。

オブジェクト・レベルの許可

オブジェクト・レベルの許可は、セキュリティー・グループ・アプリケーションの「データ制限」タブで設定されたセキュリティー構成に基づいています。オブジェクトまたは属性が読み取り専用または非表示となっている場合、インバウンド・メッセージ・データの処理はクエリーに限定されます。該当のオブジェクトまたは属性に対するデータの挿入、更新、または削除はできません。

アプリケーション・レベルの許可

アプリケーション・レベルの許可はオブジェクト構造アプリケーションで構成します。「認証済みアプリケーション」フィールドで、許可するアプリケーションを指定してください。指定したアプリケーションと統合メッセージ・ユーザーのユーザー・グループが連携して、オブジェクト構造とエンタープライズ・サービスの両方のインバウンド統合メッセージに対する許可を提供します。アプリケーションとユーザー・グループの組み合わせも、このオブジェクト構造に関連したデータのエクスポートに関する許可を提供します。

REST API を使用する場合は、ビジネス・オブジェクト・リソースにアクセスするために、アプリケーション・レベルの許可を構成する必要が生じる場合があります。

標準サービスの許可

標準サービスの許可では、シグニチャー・オプションに関連付けられた条件の使用はサポートされません。条件を割り当ててもすべて無視されます。

標準サービス・トランザクションを構成して、統合ユーザーに対して、そのユーザーがアプリケーションを介してトランザクションを入力した場合と同様のセキュリティー・プロファイルを実行することができます。このレベルの許可には、手動構成が必要です。アプリケーション・サービスには適切に注釈を付けたメソッドを含め、サービスをデータベースの構成アプリケーションで登録する必要があります。標準サービスに署名オプションを割り当てて、選択されたオプションの許可を持つユーザーまたはグループのみがアクセスできるように制限します。


許可する標準サービスの詳細を指定して、MAXSERVSECURITY テーブルを更新する SQL スクリプトを実行します。MAXSERVSECURITY の挿入ステートメントには、以下の表にリストするフィールドを組み込む必要があります。

フィールド説明

MAXSERVSECURITYID 固有 ID (数値)。例えば、max(MAXSERVSECURITYID) をMAXSERVSECURITY からクエリーして、次の連続値を使用することができます。

ROWSTAMP 固有 ID (数値)。例えば、max(ROWSTAMP)

を MAXSERVSECURITY からクエリーして、次の連続値を使用することができます。

SERVICENAME データベースの構成アプリケーションで登録されるサービス名(MAXSERVICE.SERVICENAME)。

APP 署名オプションの構成先のアプリケーション名 (MAXAPPS.APP)。

METHODNAME アプリケーション・サービス内で注釈が付けられたメソッドの名前。

OPTIONNAME この値はアプリケーションの署名オプション・テーブルと署名オプションの組み合わせ(SIGOPTION.OPTIONNAME) です。

関連概念:


言語サポートデータベースには、説明や詳細説明などの一部の要素を複数の言語で含めることができます。パブリッシュ・チャネルおよびエンタープライズ・サービスは、これらの翻訳済みカラムを組み込むことができます。統合フレームワークは、双方向言語の形式の使用もサポートしています。

単一のデータベースに複数の言語のデータを含めることもできます。基本言語はアプリケーションをインストールする際に指定します。システムで基本言語とは異なる言語を使用する場合、統合フレームワークでは基本言語のデータにないデータを送受信できます。

複数言語のデフォルトの処理ログイン時に、そのシステムの基本言語以外の言語コードを選択することができます。これにより、任意のアプリケーションで、翻訳可能として指定されたカラムに言語固有の値を入力することができます。

デフォルトでは、アウトバウンド・トランザクションに、ログイン・セッションに関連付けられた言語に該当するカラム値が含まれます。言語値は、そのトランザクションがアプリケーションまたはデータのエクスポート機能のどちらによって開始


されたかを表示します。例えば、システムの基本言語が英語の場合に、フランス語ユーザーとしてログインし、フランス語の説明が使用されるように部品レコードを更新することができます。英語または第 3 の言語の説明が存在する場合でも、アウトバウンド・メッセージにはフランス語の部品説明が含まれます。

データベース表に翻訳可能カラムが含まれる場合、そのデータベースにはL_tablename (例えば、ITEM の場合は L_ITEM) という対応するテーブルが含まれます。L_tablename テーブルには、詳細説明を除くすべての翻訳可能カラムの非基本言語値が保管されます。すべての言語の詳細説明は LONGDESCRIPTION テーブルにあります。

出力の XML に翻訳可能値を組み込むには、該当するオブジェクト構造にL_tablename と LONGDESCRIPTION オブジェクトを組み込みます。基本言語値は、L_tablename がオブジェクト定義の一部として使用されているオブジェクト構造へのサービス入力として指定します。サービス入力はコア・オブジェクト内になければならず、他の言語はすべて追加言語対応オブジェクト内になければなりません。

例えば、英語が基本言語の場合、ITEM テーブルには部品の英語の説明が含まれ、L_ITEM テーブルにはその部品のフランス語とドイツ語の説明が含まれる、ということになります。LONGDESCRIPTION テーブルには、英語、フランス語、およびドイツ語の詳細説明が含まれています。

L_tablename オブジェクトをオブジェクト構造に追加する場合は、transLanguage 属性と baseLanguage 属性に同じ値を割り当てます。これを行わないと、基本言語値が使用可能にならず、複数言語対応フィールド用に処理されません。

複数言語属性サービスおよびチャネル用の XML 構造のルート・エレメントには、レコードの言語属性を指定する言語属性が含まれています。

以下の言語属性が使用されます。

v baseLanguage 属性は、アウトバウンド XML を生成するシステムまたはアプリケーションの基本言語を識別します。インバウンド・トランザクション (入力XML) の場合、この属性は検証されません。

v 出力の XML には、以下の例に示すように、すべての翻訳可能カラムにlangenabled 属性が組み込まれます。

<DESCRIPTION langenabled="1">Item 1 description</DESCRIPTION>

v transLanguage 属性は、該当の複数言語フィールドの値が指定されている言語を識別します。この属性がない場合、または値を含んでいない場合、すべてのデータは基本言語であると想定されます。transLanguage 値が解釈不能な場合、またはその値が有効な言語を識別していない場合は、サービス要求元にエラーが返されます。

双方向言語サポート統合フレームワークは、アラビア語やヘブライ語などの双方向言語をサポートしており、別の双方向言語の形式を使用する外部システムとデータを交換できるようになっています。双方向言語は、右から左に読むように文字を書き連ねると同時に、一部の文字 (数字や日付など) を左から右に読むように書きます。


統合フレームワークは、すべてのインバウンド・データおよびアウトバウンド・データの双方向形式を、外部システムに指定された双方向形式との間で相互に変換できます。変換は、エンタープライズ・サービス、オブジェクト構造サービス、および標準サービスの同期通信および非同期通信に適用されます。クーロン・タスクまたはデータ・インポート機能の使用時にインポートする双方向形式のファイルを変換することもできます。

双方向言語の形式統合フレームワークによって使用されるデフォルトの双方向形式は Unicode 規格に基づいています。これらの形式は、外部システムによって使用される形式と異なることがあります。

双方向形式には 5 つのパラメーターがあります。

パラメーター値フラグデフォルト詳細

テキスト・タイプ v Implicit

v Visual

v I

v V

I: Implicit (論理)

テキスト方向 v LeftToRight

v RightToRight

v ContextualLeftToRight

v ContextualRightToLeft

v L

v R

v C

v D

L: LeftToRight

テキスト対称スワッピング

v On

v Off

v Y

v N

Y: On

テキスト・シェーピング v Not Shaped

v Shaped

v Isolated

v N

v S

v B

N: Not Shaped アラビア語のみ

数表示形状 v National

v Nominal

v ContextualNational

v ContextualNominal

v H

v N

v C

v T

N: Nominal アラビア語のみ

外部システムの双方向言語サポートの構成デフォルト・フォーマットに (またはデフォルト・フォーマットから) データを正しく変換できるように、外部システムが使用する双方向言語形式を指定します。

手順1. オプション: エンタープライズ・サービスの外部システム・アプリケーションまたはオブジェクト構造サービスの呼び出しチャネル・アプリケーションで、「双方向形式」アクションを選択します。

2. 外部システムが使用する双方向言語形式をオプションのリストから選択し、「OK」をクリックします。


タスクの結果

外部システムが使用する双方向言語形式を設定した後は、統合処理中に、適切な形式への変換が自動的に行われます。

ファイル・ベースのデータのエクスポートとインポート統合管理者は、外部システム・アプリケーション内からデータのエクスポートおよびインポートを開始して、ファイルによるデータの統合などをサポートすることができます。インポート処理には、ファイルからデータ・ロードをプレビューし、データベースに保存する前にデータを検証するための機能が組み込まれています。インポート処理には、ファイルのロードに起因するエラーを、インポートするファイルと同じファイル形式で管理するためのオプションも組み込まれています。

ファイル・ベースのエラー管理は、「メッセージ再処理」アプリケーションによるエラー管理の代わりとして使用できます。フラット・ファイルまたは XML 形式のファイルからのデータのインポートは、事前定義したクーロン・タスクを使用してスケジュール・ベースで実行できます。さらに、管理者がエクスポートおよびインポート用のアプリケーションを使用可能にすると、使用可能にされたアプリケーション内からユーザーが直接データをエクスポートおよびインポートできるようになります。

関連概念:

217ページの『ファイル・ベースのデータ・インポート機能によるエラーの管理』統合フレームワークは、メッセージ再処理アプリケーションによってエラー管理をサポートします。このアプリケーションにより、インバウンド・キューからの処理時にエラーになったメッセージの検討、修正、再処理、および削除を行えます。データを XML ファイルまたはフラット・ファイルからインポートする場合は、メッセージ再処理アプリケーションではなく、ダウンロード・ファイルを使用してエラーを管理する別のオプションが使用可能です。

外部システム・アプリケーションでのデータのエクスポートおよびインポート

データのエクスポートは、外部システム・アプリケーションの「パブリッシュ・チャネル」タブで開始できます。データのインポートは、外部システム・アプリケーションの「エンタープライズ・サービス」タブで開始できます。

ファイル・ベースのデータのエクスポートデータのエクスポート機能により、ファイルから外部システムへのメッセージ・データの一括エクスポートを実行できます。外部システムに関連付けられたパブリッシュ・チャネルごとに、エクスポート・プロセスを開始できます。

始める前に

マルチテナンシー環境では、アプリケーション・サーバーからアクセス可能なファイル・サーバーへのアクセス権限がシステム・プロバイダーによってユーザーに提供される場合にのみ、データのエクスポート機能を使用することができます。そして、このファイル・サーバーのロケーションを指すようにファイル・ベースのエンドポイントを構成する必要があります。


データをエクスポートできるようにするには、外部システムとパブリッシュ・チャネルの両方を有効にする必要があります。エクスポートするデータは、オブジェクト構造スキーマに従った XML ファイルの形式、あるいはコンマ区切りなどの区切り文字で区切られたフラット・ファイルの形式 (オブジェクト構造スキーマ形式をフラット化したもの) である必要があります。


「条件のエクスポート」フィールドに入力するオプションの SQL クエリーは、エクスポートされる XML メッセージのサイズに影響を与えます。この内容をフィルターに掛けると、エクスポートするデータ量を制限できます。エクスポート・プロセスでは、選択されたパブリッシュ・チャネルのクエリー結果セットに対し、標準のアウトバウンド処理が実行されます。

手順1. 外部システム・アプリケーションで「パブリッシュ・チャネル」タブをクリックし、エクスポートするパブリッシュ・チャネルを選択します。

2. 「エンドポイント」フィールドに、XML ファイル形式またはフラット・ファイル形式のいずれかについてのファイル・ベースのエンドポイント・ハンドラーを指定します。


4. オプション: 「条件のエクスポート」フィールドに SQL クエリーを入力します。クエリーは、パブリッシュ・チャネル・オブジェクト構造内の主または最上位のオブジェクトに対して行う必要があります。

5. オプション: 「エクスポート・カウント」フィールドに整数値を指定して、エクスポートされるファイル内のレコード数を制限します。クエリーの結果に、指定した数より多くのレコードが含まれる場合、超過した分のレコードはエクスポートされるファイルに組み込まれません。

6. 「OK 」をクリックして、データのエクスポート・プロセスを開始します。

次のタスク

データのエクスポートが実行されると、選択したデータがメッセージに変換されて、パブリッシュ・チャネルとそれに対応する外部システム用に構成されたアウトバウンド・キューに入れられます。アウトバウンド・キューに入れられたメッセージが処理されると、構成済みエンドポイントに配信されます。エンドポイントへのメッセージ配信時にエラーが発生した場合は、メッセージ再処理アプリケーションで、エラーのフラグが立てられたデータ・エクスポート・メッセージを管理および表示できます。

ファイル・ベースのデータのインポートデータのインポート機能を使用して、XML ファイルまたは区切り文字で区切られたフラット・ファイルからデータをロードし、Maximo データベースを更新することができます。データをロードしてデータベースにコミットする前に、データをプレビューして確認できます。エラーは、メッセージ再処理アプリケーションで管理することも、インポートされたファイル形式と同じファイル形式に抽出して管理することもできます。


始める前に

データをフラット・ファイル (.csv ファイルなど) からインポートする予定の場合、データをインポートするには、エンタープライズ・サービス・オブジェクト構造がフラット・ファイル構造をサポートしていなければなりません。オブジェクト構造アプリケーションで、関連付けられたオブジェクト構造レコードに対して「フラット・ファイル構造のサポート (Support Flat File Structure)」チェック・ボックスが選択されていることを確認してください。また、データをインポートするには、外部システムとエンタープライズ・サービスの両方が有効になっている必要もあります。


インポートするデータは、コンマ区切りなどの区切り文字で区切られたフラット・ファイルまたは XML ファイルの形式である必要があります。データのインポート・プロセスでは、定義済みまたはユーザー定義のエンタープライズ・サービスを使用できます。

手順1. 外部システム・アプリケーションで、データのインポート元となるエンタープライズ・サービスが含まれる外部システムを表示します。

2. 「エンタープライズ・サービス」タブで、データのインポート元となるエンタープライズ・サービスを選択します。

3. 「データのインポート」をクリックします。

4. オプション: 「インポートのプレビュー」チェック・ボックスを選択して、データをデータベースにインポートしてコミットする前に、データを確認します。データ・レコードをサンプリングするには、プレビュー・オプションを使用します。この機能は、数百のレコードが含まれる大きなサイズのファイルをサポートすることは意図していません。同期処理により、更新内容をデータベースにコミットせずにファイルをビジネス・オブジェクトに処理して、エラー・メッセージが検出された場合にはそのメッセージを返します。

5. ファイルのインポートに使用するファイルのタイプを指定します。


XML ファイルデータは XML 形式でインポートされます。

フラット・ファイルデータは区切り文字で区切られたフラット・ファイルでインポートされます。必要に応じて、「区切り文字」および「テキスト修飾子」の値を変更します。

6. 「インポート・ファイルの指定」フィールドに、インポートされるファイルを識別および保管するためのファイル名パスを入力します。

7. ファイルで検出されたエラーを、インポートされたファイルと同じ形式で管理するには、「ファイル・ベース・エラー管理」チェック・ボックスを選択します。このオプションは、エラーをメッセージ再処理アプリケーションで管理する代わりの手段となります。

8. 「OK」をクリックして、データのインポート・プロセスを開始します。


次のタスク

データのインポートが実行されると、インポート対象として選択されたファイルが複数のメッセージに変換されて、エンタープライズ・サービスとそれに対応する外部システム用に構成されたインバウンド・キューに入れられます。インバウンド・キューに入れられたメッセージが処理されると、更新対象のアプリケーション・オブジェクトに配信されます。インバウンド・キューからのメッセージを処理するためには、連続キューの使用時には JMS クーロン・タスクを有効にし、継続中のキューの使用時にはメッセージ駆動型 Bean を有効にする必要があります。ファイルの処理中にエラーが発生した場合は、メッセージ再処理アプリケーションで、エラーのフラグが立てられたデータ・インポート・メッセージを管理および表示できます。

インバウンド・データ処理用のクーロン・タスクデータのインポート・ウィンドウを使用せずにファイルのロードをスケジュールに入れるには、クーロン・タスク・メッセージ処理が発生する前にXMLFILECONSUMER クーロン・タスクおよび FLATFILECONSUMER クーロン・タスクを作成および構成し、使用可能にする必要があります。

XMLFILECONSUMER クーロン・タスクXMLFILECONSUMER クーロン・タスクは、アプリケーション・ユーザーの介入なしで XML ファイルをロードするときに使用するメカニズムです。

XMLFILECONSUMER クーロン・タスクには以下の定義済みパラメーターがあります。


EXTERNALSYSTEM クーロン・タスクのデータ・ロード・プロセスで使用される外部システム値を指定する必須パラメーター値。

SOURCEDIRECTORY ソース・ファイルをロードするディレクトリーを定義する必須パラメーター値。このディレクトリーはアプリケーション・サーバー上に存在するものでなければなりません。

ENTERPRISESERVICE ソース・ディレクトリー内にあるすべてのファイルを処理するためにクーロン・タスクが使用するエンタープライズ・サービス名を指定する必須パラメーター値。

FILENAME クーロン・タスクのデータ・ロード・プロセスでファイル名に基づいてソース・ファイルが選択されるようにするかどうかを決定するオプションのパラメーター値。

USEREXITCLASS クーロン・タスクの追加機能 (ファイルのロード順など) を定義するオプションのカスタム処理クラス値。




ISFILEEXTRACT 1 (True) に設定すると、このパラメーターは、ファイル・ベース・エラー管理を使用してインバウンド・メッセージが処理されることを示します。

ソース・ディレクトリー内の使用可能な XML ファイルはすべて、特定の外部システム (EXTERNALSYSTEM、SOURCEDIRECTORY、および ENTERPRISESERVICE

パラメーターに値を追加した場合はエンタープライズ・サービス) に関連付けられます。これらの XML ファイルは統合フレームワークにもロードされます。

クーロン・タスクのファイル名プロパティーと一致するファイルは特定の外部システムに関連付けられます。EXTERNALSYSTEM、SOURCEDIRECTORY、ENTERPRISESERVICE、およびFILENAME パラメーターに値を追加する場合、外部システムはエンタープライズ・サービスであり、これらのファイルはこのシステムにロードされます。

FLATFILECONSUMER クーロン・タスクFLATFILECONSUMER クーロン・タスクは、アプリケーション・ユーザーの介入なしでフラット・ファイルをロードするときに使用するメカニズムです。

クーロン・タスク・パラメーター

FLATFILECONSUMER クーロン・タスクには以下の定義済みパラメーターがあります。

表 34. FLATFILECONSUMER クーロン・タスク・パラメーター


SOURCEDIRECTORY ソース・ファイルをロードするディレクトリーを定義する必須パラメーター値。このディレクトリーはアプリケーション・サーバー上に存在するものでなければなりません。

DELIMITER フラット・ファイルのフィールド区切り文字として使用される文字を示す必須パラメーター。デフォルト値は , (コンマ) です。

USEREXITCLASS クーロン・タスクの追加機能 (ファイルのロード順など) を使用可能にするカスタム処理クラス値。

TEXTQUALIFIER フラット・ファイルのテキスト修飾子として使用される文字を定義する必須パラメーター値。デフォルト値は“ (二重引用符) です。


表 34. FLATFILECONSUMER クーロン・タスク・パラメーター (続き)


TARGETENENABLED 値がデフォルトの 0 (false) であることを確認してください。このフラグの機能は、donotrun 機能に置き換えられました。クーロン・タスク・フレームワークの donotrun パラメーターを使用して、クーロン・タスクの実行先のサーバーを制御します。

ISFILEEXTRACT 1 (True) に設定すると、このパラメーターは、ファイル・ベース・エラー管理を使用してインバウンド・メッセージが処理されることを示します。

ソース・ディレクトリーで使用可能なすべてのファイルは、SOURCEDIRECTORY

パラメーターに値を追加した場合に FLATFILECONSUMER クーロン・タスクによって処理されます。外部システムおよびエンタープライズ・サービスは、インポートされるフラット・ファイル内の最初のレコード (フラット・ファイル定義に含まるもの) から識別されます。

クーロン・タスク処理プロパティー

FLATFILECONSUMER クーロン・タスクは、インバウンド・メッセージに以下の処理プロパティーを使用します。

v ファイル処理順序 - XML ファイルのタイム・スタンプによって決定される、ファイルがサーバー上にロードされる順序。クーロン・タスクのユーザー出口クラスを使用すると、インバウンド・メッセージの処理ロジックを上書きすることができます。

v ファイルの分割 - FLATFILECONSUMER クーロン・タスクによって処理される複数名詞ファイルは、キューに書き込まれる前に分割されます。このクーロン・タスクは、ロードされるファイルが複数名詞 XML ファイルかどうかを指定します。XML ファイルが複数名詞ファイルの場合、統合フレームワークはエンタープライズ・サービスのキー・カラムを使用してファイルの分割が行われる場所を指定します。例えば、MXPOInterface エンタープライズ・サービスの PONUM および SITE がこれに該当します。

v キュー処理 - FLATFILECONSUMER クーロン・タスクはフラット・ファイルがロードされるキューを指定します。このロケーションは、外部システムおよびエンタープライズ・サービス・レベルで指定されたキュー (継続中または連続) に基づきます。

このクーロン・タスクは、複数名詞ファイルの処理時に最後に正常に処理された名詞への参照を含むインデックス・ファイル (recovery_filename.txt) を作成します。このインデックス・ファイルのエントリーは、名詞が正常にキューにコミットされたときに更新されます。インデックス・ファイルは、クーロン・タスクのソース・ディレクトリーで作成される RECOVERY フォルダー内にあります。

FLATFILECONSUMER クーロン・タスクはインデックス・ファイルの名前を使用して、サーバーまたはキューの問題が検出される前に処理されたファイルを指定します。このクーロン・タスクは、インデックス・ファイル内で最後に正常にコミット


された名詞から XML ファイルの処理を続行します。メッセージが正常にインバウンド用キューに書き込まれた後に識別されたエラーは、「メッセージ再処理」アプリケーションで解決する必要があります。

データのエクスポートおよびインポート用のアプリケーションの構成

アプリケーション・ベースのデータのインポートおよびエクスポートを有効にするには、オブジェクト構造の内容を定義して、このオブジェクト構造をインポートおよびエクスポート用に有効にする必要があります。

オブジェクト構造の内容の定義アプリケーション・ユーザーには、アプリケーションから直接データをエクスポートまたはインポートするためのアクセス権限を認可できます。管理者は、アプリケーションに適したオブジェクト構造を特定して、ユーザーに対してエクスポートまたはインポート (あるいはその両方の) 機能を認可して、スプレッドシートに維持できる .csv ファイルなどのファイルでアプリケーション・データを管理できます。


統合トランザクションに使用するオブジェクト構造を判別してから、データ交換を必要な内容に制限するように、オブジェクト構造の内容を変更します。

手順1. アプリケーション・デザイナーで、有効にするアプリケーションを開き、ヘッダー領域の「メイン・オブジェクト」フィールドの値を確認します。この値は、オブジェクト構造に使用するメイン・オブジェクトでなければなりません。

2. オブジェクト構造アプリケーションで、「オブジェクト構造」フィールドにメイン・オブジェクトの名前を指定し、このオブジェクトに基づいてオブジェクト構造をフィルターに掛けます。メイン・オブジェクトに基づく検索でオブジェクト構造が 1 つも返されない場合は、オブジェクト構造を作成する必要があり、以下のステップは適用されません。

3. 検索で複数のオブジェクト構造が返された場合は、「適用先」フィールドの値が「統合」に設定されているオブジェクト構造を選択します。

4. オブジェクト構造の内容を検討し、以下の質問について確認します。

a. オブジェクト構造のメイン・オブジェクトは、データのエクスポートおよびインポート用に有効にするアプリケーションのメイン・オブジェクトと同じですか。

b. オブジェクト構造に、ユーザーがインポートもエクスポートもする必要のないデータを含む下位階層オブジェクトが含まれていますか。例えば、MXPERSON オブジェクトに PHONE、EMAIL、および SMS という下位階層オブジェクトが含まれているとします。ユーザーは、PERSON オブジェクトと PHONE オブジェクトのデータのみをインポートおよびエクスポートすることができます。

5. オブジェクト構造の内容を検討したら、定義済みオブジェクト構造を既存のすべての内容とともに使用することも、このオブジェクト構造を複製したうえで内容を変更することもできます。定義済みオブジェクト構造に変更を加えた場


合、このオブジェクト構造を使用する他の統合シナリオにも影響する可能性があります。オブジェクト構造を複製し、テンプレートとして使用しても、他の統合ユーザーで予期しない動作が発生することはありません。

6. オブジェクト構造を複製して、このシナリオ用の新しいオブジェクト構造を作成すると想定した場合、統合ユーザーに必要のない下位階層オブジェクトはすべて削除します。

7. オブジェクト構造に残っている各オブジェクトで、「アクションの選択」メニューで「フィールドの選択」オプションを選択し、ユーザーがインポートもエクスポートもする必要のないすべてのフィールドを選択解除します。このステップにより、データ・フィールドがアプリケーション・ユーザーに必要なフィールドのみに制限されます。

8. (スプレッドシートで使用するために) 区切り文字で区切られたフラット・ファイルが必要な場合は、「フラット構造をサポート」チェック・ボックスを選択します。このステップにより、オブジェクト構造内のすべてのオブジェクトのすべてのカラムに固有の名前が付いていることを確認する、検証がアクティブ化されます。検証に失敗すると、「別名の競合」標識が設定されます。

9. オブジェクト構造に別名の競合が含まれる場合は、「アクションの選択」メニューの「別名の追加/修正」オプションを選択して、重複が存在するすべてのフィールド名に固有の別名を割り当てます。別名の競合は、どの定義済みオブジェクト構造にも存在しません。

10. オブジェクト構造を保存します。

次のタスク

これでオブジェクト構造の内容が構成され、オブジェクト構造アプリケーションで、そのオブジェクト構造へのアプリケーション・アクセスを認可することができます。

アプリケーションでのデータのインポートおよびエクスポートの有効化オブジェクト構造の内容を定義したら、データのインポートおよびエクスポート用にアプリケーションを有効にする必要があります。データのインポートを可能にする手順は、データのエクスポートを可能にする手順とは別個です。これらの手順が別個であるため、一部のユーザーがデータをエクスポートでき、別のユーザーがデータをインポートできる、というように設定したり、データをインポートできるユーザー群とエクスポートできるユーザー群をそれぞれ別個に設定したりすることができます。

手順1. オブジェクト構造アプリケーションで、有効にするオブジェクト構造を選択します。

2. 「アプリケーション・エクスポート・サポートの追加/変更」アクションを選択します。

3. 「アプリケーション・エクスポート・サポートの追加/変更」ウィンドウで、「新規行」をクリックします。「詳細」セクションでは、「アプリケーション」フィールドの値に、オブジェクト構造のメイン・オブジェクトと同じメイン・オブジェクトを持つアプリケーションがデフォルトとして設定されています。


4. データ・エクスポート・ファイルのフォーマットとして「XML ファイル」または「フラット・ファイル」を指定します。

5. 「最大数」フィールドで、1 回の実行でエクスポートできる行数を制限する値を指定できます。ユーザーが 1000 件のレコードを選択した場合でも、制限が100 件に設定されているときは、100 行のみがエクスポートされます。値が 0

または NULL の場合、処理できる行数は無制限になります。

6. アプリケーション・エクスポート用に複数のオブジェクト構造を有効にし、このオブジェクト構造をデフォルトにする場合は、「デフォルト」チェック・ボックスを選択します。

7. 「OK」をクリックしてエクスポート構成を保存します。

8. 「アプリケーション・インポート・サポートの追加/変更」アクションを選択し、同じ手順を繰り返して、アプリケーションでデータのインポートを構成します。

9. セキュリティー・グループ・アプリケーションでアプリケーション・ユーザーのユーザー・グループを選択し、「アプリケーション・エクスポート」オプション、「アプリケーション・インポート」オプション、または両方のオプションへのアクセス権限を認可します。

アプリケーションでのデータのエクスポートおよびインポートの開始アプリケーションでデータのエクスポートおよびインポートを有効にすると、アプリケーションのツールバーに、トランザクションを開始するためのアイコンが追加されます。

アプリケーションでのデータのエクスポートの開始:

アプリケーションでデータのエクスポートを有効にしたら、ユーザーはアプリケーション・ユーザー・インターフェース内からエクスポート・トランザクションを開始できます。

手順

1. アプリケーションの「一覧」タブで、以下のいずれかの方法を使用してエクスポートするデータを選択します。

v フィルター・オプションを使用してエクスポートするレコード・セットをフィルターに掛け、ツールバーの「アプリケーション・エクスポート」アイコンをクリックします。

v 特定のレコードをエクスポート対象として選択し、「アプリケーション・エクスポート」アイコンをクリックします。このオプションでは、単一のレコードのデータのみがエクスポートされます。

2. 「データのエクスポート」ウィンドウで、エクスポート設定を検討し、必要に応じて調整を行います。

a. オプション: エクスポートでデフォルトのオブジェクト構造を使用しない場合は、「オブジェクト構造」フィールドに別の値を指定します。代替オブジェクト構造を指定できるのは、このアプリケーション用に別のオブジェクト構造が有効になっている場合のみです。代替オブジェクト構造を指定すると、ウィンドウが最新表示され、「エクスポートの構成」セクションが表示されるようになります。ここで、追加の設定を構成できます。

b. オプション: 「エクスポート用に選択済み」フィールドの値が「エクスポートの制限」フィールドの値を超えている場合は、エクスポートを取り消し、別


のフィルターを使用してエクスポートするレコード数を減らすことができます。「エクスポートの制限」フィールドの値は管理者が設定し、選択されたレコード数に関係なく、この値を超過することはできません。

3. オプション: 「エクスポートの構成」セクション (デフォルト以外のオブジェクト構造を指定した場合にのみ展開されます) で、データ・フォーマットを指定します。

a. 「XML」フォーマットを選択した場合は、エクスポートに関する操作 (「同期」など) を指定します。

b. 「フラット・ファイル」フォーマットを選択した場合は、「区切り文字」および「テキスト修飾子」フィールドに値を指定します。

4. 「OK」をクリックしてエクスポートを開始します。「保存」ダイアログ・ボックスが開き、ファイルを保存する場所を指定できます。フラット・ファイルをスプレッドシート・アプリケーションで開くには、接尾部として .csv を使用するようにファイル名を変更できます。「保存」ダイアログ・ボックスが開かない場合は、ブラウザーのセキュリティー設定を変更して、ダウンロードの自動プロンプトを有効にします。

アプリケーションでのデータのインポートの開始:

アプリケーションでデータのインポートを有効にしたら、ユーザーはアプリケーション・ユーザー・インターフェース内からインポート・トランザクションを開始できます。

手順

1. アプリケーション内の任意の場所で、ツールバーの「データのインポート」アイコンをクリックします。

2. オプション: インポートでデフォルトのオブジェクト構造を使用しない場合は、「データのインポート」ウィンドウで「オブジェクト構造」フィールドに別の値を指定します。代替オブジェクト構造を指定すると、「インポートの構成」セクションが展開し、ここで、追加の構成を行う必要があります。

3. オプション: 代替オブジェクト構造を指定した場合は、展開された「インポートの構成」セクションで、以下の値を指定します。

a. 「XML」フォーマットを指定した場合、送られてきた XML ファイルが操作、言語コード、およびアクション・コードを指定するため、追加の設定は必要ありません。

b. 「フラット・ファイル」フォーマットを指定した場合は、「区切り文字」、「テキスト修飾子」、「アクション」、および「言語コード」の各フィールドに値を指定することも、デフォルト値を使用することもできます。

4. オプション: 「インポート制限」フィールドの値を検討します。この値は変更できません。例えば、レコード数の制限が 100 件に設定され、インポート・ファイルに 200 件のレコードが含まれる場合、最初の 100 件のレコードのみがインポートされます。

5. 「参照」をクリックしてインポート・ファイルにナビゲートし、そのファイルを選択します。

6. オプション: 「インポートのプレビュー」を選択した場合、インポートの実行時に、ファイルはビジネス・オブジェクトによって処理されますがデータはデータ


ベースに保存されません。このオプションは、データ・ロードの実行前にデータ・ロードをテストし、エラーがないことを確認するために使用できます。エラーがある場合はすべて表示され、入力ファイルに修正を適用して、インポートを再試行できます。

7. 「OK」をクリックしてインポートを開始します。データのインポートは同期処理であるため、ロードが完了し、確認メッセージが表示されるまでユーザー・インターフェースで待機する必要があります。ロードでエラーが検出されると、データはロードされません。ファイルはコミットを 1 回行う単一トランザクションとして処理されるためです。

REST APIRepresentational State Transfer (REST) アプリケーション・プログラミング・インターフェース (API) は、外部アプリケーションが共通基盤のアプリケーション・データをクエリーおよび更新できるようにします。

REST API は統合フレームワークの一部であり、この API を使用して外部アプリケーションを共通基盤アプリケーションと統合することができます。 REST API は、ビジネス・オブジェクトおよび統合オブジェクトの構造を REST リソースとして公開します。 REST API はリソース・データを、XML または JavaScript Object

Notation (JSON) のいずれかのフォーマットで提供できます。外部アプリケーションは REST API を使用して、アプリケーション・データをクエリーおよび更新できます。

REST API リソースは構成を行わずに使用できます。REST API がクエリーおよび更新できるオブジェクト構造は、オブジェクト構造アプリケーション内の「適用先」フィールドの値が「統合」になっています。

REST API は、標準の HTTP GET、POST、PUT、および DELETE メソッドを使用して、リソースに対する作成、クエリー、更新、および削除の各操作をサポートします。

関連情報:

Using REST Api Details (新しいブラウザー・ウィンドウまたはタブで開きます)

RESTing with Maximo (新しいブラウザー・ウィンドウまたはタブで開きます)

REST API フレームワークREST API は統合フレームワークの一部であり、外部コンシューマーからの要求を処理します。

以下の図に、REST API が要求を処理する方法の概要を示します。


https://www.ibm.com/developerworks/mydeveloperworks/blogs/a9ba1efe-b731-4317-9724-a181d6155e3a/entry/using_rest_api_details2?lang=en

https://www.ibm.com/developerworks/mydeveloperworks/blogs/a9ba1efe-b731-4317-9724-a181d6155e3a/entry/resting_with_maximo1?lang=en

外部コンシューマーが要求を開始すると、REST API コントローラーはリソース要求を該当するリソース・ハンドラーに送信します。リソース・ハンドラーはリソースと対話して、要求を実行します。要求が完了すると、結果のリソースまたはリソース・コレクションがリソース・シリアライザーによって処理されます。リソース・シリアライザーは表現をリソース応答として返します。XML および JSON 用のシリアライザーが用意されています。

REST API は統合フレームワークの一部なので、共通基盤認証、許可、およびシステム・プロパティーを使用できます。

REST API コントローラーはサーブレットです。負荷およびスケーラビリティーのパフォーマンスと調整は、他の Web コンポーネント用であるため、アプリケーション・サーバー・レベルで実行されます。

サポートされる表現REST API は表現として XML および JSON をサポートします。表現は、システム・プロパティーに登録されているシリアライザー・クラスの実装によってサポートされます。

XML および JSON の表現は、以下の REST API システム・プロパティーに登録されています。

v mxe.rest.serializer.mbo.xml

v mxe.rest.serializer.os.xml

v mxe.rest.serializer.mbo.json

v mxe.rest.serializer.os.json

シリアライザーはカスタム処理用に拡張できます。既存のリソース・タイプ用、およびビジネス・オブジェクト・リソースまたはオブジェクト構造リソースの個々のインスタンス用にシリアライザーを作成できます。

オブジェクト構造リソースの場合、REST API の XML フォーマットは統合フレームワークによってサポートされているフォーマットに類似しています。

関連資料:

lpコンシューマー

リソースqu

リソースwy

REST APIコントローラー

リソース・ハンドラー

REST API フレームワーク

{|}~フレームワーク

リソースビジネス・オブジェク

ト (MBO)オブジェクト�� (OS)

リソース・シリアライザー

リソース��(XML、JSON) リソース/リソース・コレクション


289ページの『REST システム・プロパティー』特定の要件に合わせた REST API の動作方法を構成するために、システム・プロパティーを使用できます。

リソース・ハンドラーおよび URIREST API は、ビジネス・オブジェクトおよび統合オブジェクトの構造へのアクセスを可能にします。各リソースのハンドラー・クラスはシステム・プロパティーに登録されます。

ビジネス・オブジェクト・リソースおよびオブジェクト構造リソースのハンドラー・クラスは、mxe.rest.handler.mbo システム・プロパティーおよびmxe.rest.handler.os システム・プロパティーに登録されます。

ハンドラーはカスタム処理用に拡張できます。他のリソース・タイプ用、およびビジネス・オブジェクト・リソースまたはオブジェクト構造リソースの個々のインスタンス用にハンドラーを作成できます。

REST API リソースは、Uniform Resource Identifier (URI) に含まれるリソース ID

を使用してアドレス指定されます。URI は、REST リソースとして表現されるエンティティーをアドレス指定する場合に使用します。

例えば、以下の URI は担当者ビジネス・オブジェクトのコレクションにアクセスします。mbo はビジネス・オブジェクト・リソース・タイプを示し、person はリソースです。

.../maxrest/rest/mbo/person

別の例として、以下の URI は担当者オブジェクト構造のデータのコレクションにアクセスします。 os はオブジェクト構造リソース・タイプを示し、mxperson はリソースです。

.../maxrest/rest/os/mxperson

GET メソッドGET メソッドを使用して、ビジネス・オブジェクト・リソースおよびオブジェクト構造リソースを取得します。

構文GET uri?parameter=value?parameter=value&...

uri は URI です。URI パスの長さは、システムで指定されている制限を超えることはできません。

parameter はクエリー・パラメーターです。

value はクエリー・パラメーターの値です。

例: ビジネス・オブジェクト・リソースの取得

以下のメソッドは、ビジネス・オブジェクト・リソースを取得します。

GET /maxrest/rest/mbo/asset/123


以下の XML が返されます。

<?xml version="1.0" encoding="UTF-8" ?><ASSET xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>11200</ASSETNUM><SERIALNUM>3481-52</SERIALNUM><ASSETTAG>3751</ASSETTAG><LOCATION>BR200</LOCATION><DESCRIPTION>HVAC System- 50 Ton Cool Cap/ 450000 Btu Heat Cap</DESCRIPTION><ASSETUID>123</ASSETUID>..

</ASSET>

リソース応答は XML で表示されます。デフォルトのフォーマット設定は、mxe.rest.mbo.defaultformat システム・プロパティーで構成できます。

例: オブジェクト構造リソースの取得

以下のメソッドは、オブジェクト構造リソースを取得します。

GET /maxrest/rest/mbo/mxasset/123


<?xml version="1.0" encoding="UTF-8" ?><QueryMXASSETResponse xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"creationDateTime="2011-04-07T11:43:59-04:00"transLanguage="EN" baseLanguage="EN" messageID="1302195161355515345"maximoVersion="7 5 20110405-0030 V7500-718" rsStart="0" rsTotal="1"rsCount="1"><MXASSETSet>

<ASSET><ASSETNUM>11200</ASSETNUM><SERIALNUM>3481-52</SERIALNUM><ASSETTAG>3751</ASSETTAG><LOCATION>BR200</LOCATION><DESCRIPTION>HVAC System- 50 Ton Cool Cap/ 450000 Btu Heat Cap</DESCRIPTION><ASSETUID>123</ASSETUID>..<ASSETMETER>

<ACTIVE>1</ACTIVE><ASSETMETERID>63</ASSETMETERID><LASTREADING>0</LASTREADING><METERNAME>PRESSURE</METERNAME>..

</ASSETMETER><ASSETSPEC>

<ASSETATTRID>SPEED</ASSETATTRID><ASSETSPECID>2138</ASSETSPECID>..

</ASSETSPEC><ASSETSPEC>

<ASSETATTRID>SHAFTDIA</ASSETATTRID><ASSETSPECID>2139</ASSETSPECID>..

</ASSETSPEC></ASSET>

</MXASSETSet></QueryMXASSETResponse>


オブジェクト構造リソース・データには、MXASSET オブジェクト構造内のオブジェクトの構成に基づいて、資産、資産計測値、および資産仕様のデータが含まれています。包含または除外されるように構成されたフィールドはすべて、このデータに実装されます。

URI パスには、特定のリソースを選択するための方法としてリソースの ID を含めることができます。前述の例では、ID は 123 です。 ID 値は、MAXATTRIBUTE

テーブルに登録されているオブジェクトの固有 ID です。ID を指定しない場合、ユーザーに対するセキュリティー制限に応じて、リソースのすべてのオカレンスが応答に含まれます。 ID は、選択基準として URI パスに含めることができる唯一のビジネス・オブジェクト・フィールドです。その他のフィールドはすべて、選択のフィルタリング用に URI 内でクエリー・パラメーターとして使用できます。

例: 関連する下位階層リソースの選択

以下のメソッドは、ビジネス・オブジェクト・リソースとして注文書リソースを要求します。

GET /maxrest/rest/mbo/po/13


<?xml version="1.0" encoding="UTF-8" ?><PO xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><PONUM>1005</PONUM><DESCRIPTION>Electrical Supplies</DESCRIPTION>..

</PO>

例: 注文書の関連する注文書明細の選択

以下のメソッドは、前述の例で選択した注文書に関連する、すべての注文書明細を要求します。

GET /maxrest/rest/mbo/po/13/poline


<?xml version="1.0" encoding="UTF-8" ?><POLINEMboSet rsStart="0" rsTotal="2" rsCount="2"

xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><POLINE xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><PONUM>1005</PONUM><ITEMNUM>11241</ITEMNUM><STORELOC>CENTRAL</STORELOC><ORDERQTY>3.0</ORDERQTY><POLINENUM>1</POLINENUM><POLINEID>10051</POLINEID>..

</POLINE><POLINE xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><PONUM>1005</PONUM><ITEMNUM>29331</ITEMNUM><STORELOC>PKG</STORELOC><ORDERQTY>2.0</ORDERQTY>


<POLINENUM>2</POLINENUM><POLINEID>10052</POLINEID>..

</POLINE></POLINEMboSet>

注文書明細を選択する場合、URI に指定されている関係名 (POLINE) に、ビジネス・オブジェクト (注文書) から関連するビジネス・オブジェクト (注文書明細) へのパスが示されます。この例では、ビジネス・オブジェクトと関係が同じ名前になっています。オブジェクトは 2 つのオブジェクト間の関係を多数持っている場合があり、それにより、それぞれの関連オブジェクトに関して異なるデータが選択される可能性が生じます。関係は MAXRELATIONSHIP テーブルで定義されます。

特定の注文書明細ビジネス・オブジェクトの明細のみを取得するには、URI にその注文書明細ビジネス・オブジェクトの ID を含めます。

GET /maxrest/rest/mbo/po13/poline/10052

この例では、poline は関係名を表し、10052 はその関係で取得する注文書明細ビジネス・オブジェクトの ID です。注文書明細から部品または注文価格へのパスを指定する場合にも同じ方法を使用できます。

GET /maxrest/rest/mbo/po/13/poline/10052/item

GET /maxrest/rest/mbo/po/13/poline/10052/pocost

オブジェクト構造リソースを使用する場合、下位階層オブジェクトが関係を持つことはできません。オブジェクト構造は、関連するビジネス・オブジェクトのグラフをサポートします。関係はオブジェクト構造定義に含まれています。

ソース・オブジェクトとターゲット・オブジェクトの間に有効な関係が存在する場合、関連するビジネス・オブジェクトを通って 1 つのリソースから別のリソースに移動することができます。

関連資料:

280ページの『HTTP ヘッダー・プロパティー』REST API に関連する HTTP ヘッダー・プロパティーがいくつか存在します。

クエリーのパラメーターおよび演算子固有 ID が分かっているリソースをフェッチするために、リソースの ID を URI

パスの一部として指定できます。また、クエリー・パラメーターを使用して、リソース・コレクションをフィルターに掛けてフェッチできます。

リソース・コレクションでは、表現に各リソースの固有 ID へのポインターが含まれています。この ID は、コンシューム側のソフトウェアがリソースへのリンクを作成する際に使用されます。このリンクは、リソースに対する更新、削除、およびクエリーの実行に使用されます。

多くの場合、RESTful 相互作用は、リソース・コレクションをフェッチして、コレクション内の特定のリソースにドリルダウンすることから開始します。

ビジネス・オブジェクト・リソースまたは関連ビジネス・オブジェクト・リソースの任意のフィールドをクエリー・パラメーターとして使用できます。ビジネス・オブジェクトの例示照会プログラム (QBE) フレームワークでは、ビジネス・オブジェ


クト間の関係の深さは 1 レベルまでに制限されます。オブジェクト構造リソースの任意のフィールドがオブジェクト構造の上位 2 レベル内に存在するオブジェクトに属している場合は、そのフィールドをクエリー・パラメーターとして使用できます。

ビジネス・オブジェクト属性をクエリー・パラメーターとして使用する場合は、以下の演算子をパラメーターの一部として使用できます。

演算子表記例

等しい ~eq~ status=~eq~APPR 「等しい」演算子は、完全一致突き合わせを実行する場合に使用します。status=APPR クエリーは、「一致する」演算子の比較を暗黙指定します。status=APPR&_exactmatch=1

を使用した場合は、プロセッサーは強制的に完全一致突き合わせを実行します。この表記では、status=~eq~APPR と同じ結果が得られます。

等しくない ~neq~ status=~neq~APPR

より大きい ~gt~ quantity=~gt~2.5

以上 ~gteq~ quantity=~gteq~2.5

未満 ~lt~ quantity=~lt~2.5

以下 ~lteq~ quantity=~lteq~2.5

末尾の文字 ~ew~ description=~ew~APPR

先頭の文字 ~sw~ description=~sw~APPR

一致する表記は不要 description=APPR

例: ロケーションによるクエリー実行

以下の例では、演算子なしでロケーション番号をクエリー・パラメーターとして使用して、ロケーションについてのクエリーを実行しています。

GET maxrest/rest/mbo/locations?location=PT100

このクエリーによって、以下の XML が返されます。

<?xml version="1.0" encoding="UTF-8" ?><LOCATIONSMboSet rsStart="0" rsTotal="2" rsCount="2"

xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><LOCATIONS>

<LOCATION>PT100</LOCATION><DESCRIPTION>PT100</DESCRIPTION>..

</LOCATIONS><LOCATIONS>

<LOCATION>PT1001</LOCATION><DESCRIPTION>1001</DESCRIPTION>


.

.</LOCATIONS>

</LOCATIONSMboSet>

演算子が指定されていないため、「一致する」比較が使用され、結果には 2 つのロケーションが含まれています。以下のように要求で「等しい」演算子を使用した場合は、この演算子によって完全一致突き合せが強制されるため、クエリー要求に対してロケーション PT100 のみが返されます。

GET /maxrest/rest/mbo/locations?location=~eq~PT100

例: 複数のパラメーターの使用

以下の例では、複数のパラメーターを使用して、1 を超える年間累計出庫数量かつ5 を超える発注数量についてのクエリーを実行しています。

GET /maxrest/rest/mbo/inventory?issueytd=~gt~1&orderqty=~gt~5

例: ormode 条件の使用

ormode 条件を使用することで、単一フィールドについて複数の値を要求できます。以下の例では、年間累計出庫数量が 7 であるか 4 未満のレコードを選択しています。

GET /maxrest/rest/mbo/inventory?issueytd.ormode=~eq~7&issueytd.ormode=~lt~4

例: 選択レコードなし

クエリー要求の結果としてレコードが 1 つも選択されなかった場合に、空の結果セット (例外条件ではなく) が返されます。

例えば、以下の要求では、年間累計出庫数量が 99 のレコードを求めています。

GET /maxrest/rest/mbo/inventory?issueytd=~eq~99

要求の結果として 1 つもレコードが選択されなかったため、以下の空の結果が返されます。

<?xml version="1.0" encoding="UTF-8" ?><INVENTORYMboSet rsStart="0" rsTotal="0" rsCount="0"

xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />

_opmodeor パラメーター_opmodeor パラメーターを使用して、値と値の間にデフォルトの AND 条件ではなく OR 条件を使用することにより、複数のフィールドを評価します。

例えば、以下の要求では、年間累計出庫数量が 1 を超え、かつ発注数量が 5 を超えるレコードが返されます。

GET /maxrest/rest/mbo/inventory?issueytd=~gt~1&orderqty=~gt~5

rsTotal 属性に示すように、このクエリーでは 6 つのレコードを選択します。


xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><INVENTORY xmlns="http://www.ibm.com/maximo"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ITEMSETID>SET1</ITEMSETID><MANUFACTURER>WES</MANUFACTURER><SHRINKAGEACC>

<VALUE>6600-810-800</VALUE></INVENTORY>..

<INVENTORY xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

.

.

以下の変更された要求では、_opmodeor パラメーターを true に設定して、年間累計出庫数量が 1 を超えるか、または発注数量が 5 を超えるレコードが返されるようにします。

GET /maxrest/rest/mbo/inventory?issueytd=~gt~1&orderqty=~gt~5&_opmodeor=1

変更されたクエリーでは、以下のように 54 のレコードを選択します。


xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><INVENTORY xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">..

_rsStart パラメーターおよび _maxItems パラメーター_rsStart パラメーターおよび _maxItems パラメーターを一緒に使用することで、1

つの要求に対して返されるレコード数を制御し、大量のレコードをページングできるようにします。

例: すべての資産リソースの選択

以下の要求では、システム内のすべての資産リソースを選択します。

GET maxrest/rest/mbo/asset?&_opmodeor=1

この例では、757 件の資産が選択されています。

<?xml version="1.0" encoding="UTF-8" ?><ASSETMboSet rsStart="0" rsTotal="757" rsCount="757"

xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSET xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>CAL100</ASSETNUM>

以下の要求では、選択される行数を _maxItems パラメーターによって制限します。rsCount 値に示すように、行数は 20 に制限されます。

GET /maxrest/rest/mbo/asset?_maxItems=20



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

次の 20 行を取得するには、以下の要求で _rsStart パラメーターを追加します。


GET /maxrest/rest/mbo/asset?_maxItems=20&_rsStart=20



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

行 20 で始まり行 39 で終わる、次の 20 行が取得されます。

関連概念:

270ページの『セッション内スクロール』リソース・コレクションをメモリー内に保持することで、データのページをスクロールする際のパフォーマンスを改善することができます。

_orderbyasc パラメーター_orderbyasc パラメーターは、返されるデータのソート順を制御します。

順序文節に使用される属性は昇順で示されます。結果をソートするリソース・オブジェクトのフィールド名のコンマ区切りリストを表示します。

_orderbydesc パラメーターは、降順でソートする場合と類似の方法で使用します。

例: 応答のソート

以下の要求には _orderbyasc パラメーターは含まれていません。

GET /maxrest/rest/mbo/asset?_maxItems=20&_rsStart=20

以下の資産が返されます。



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>7400</ASSETNUM><SERIALNUM>A5252525555</SERIALNUM><LOCATION>HWSTOCK</LOCATION>..

<ASSET xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>7300</ASSETNUM><SERIALNUM>A6687688888</SERIALNUM><LOCATION>HWSTOCK</LOCATION>..

<ASSET xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>7200</ASSETNUM><SERIALNUM>A6387683888</SERIALNUM><LOCATION>HARDWARE</LOCATION>..

以下の要求には、_orderbyasc パラメーターが含まれ、資産ビジネス・オブジェクトのロケーション・フィールドを指定しています。

GET /maxrest/rest/mbo/asset?_maxItems=20&_rsStart=20&_orderbyasc=location


変更された要求では、要求されたソート順で以下の資産が返されます。



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>2045</ASSETNUM><PARENT>19998</PARENT><LOCATION>5THFLSWSTOCK</LOCATION>..

<ASSET xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>2002</ASSETNUM><SERIALNUM>K6LQI</SERIALNUM><LOCATION>6THFLOOR</LOCATION>..

<ASSET xmlns="http://www.ibm.com/maximo"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ASSETNUM>2074</ASSETNUM><PARENT>2002</PARENT><LOCATION>6THFLOOR</LOCATION>..

_includecols パラメーターおよび _excludecols パラメーター_includecols パラメーターおよび _excludecols パラメーターを使用して、クエリーに対して返される属性の内容を制御します。

いずれのパラメーターも指定しないと、ビジネス・オブジェクト・リソースのすべての属性が返されます。_includecols パラメーターおよび _excludecols パラメーターは、ビジネス・オブジェクト・リソースに対してのみ有効です。

例: 特定のフィールドの取得

以下のように _includecols パラメーターを使用した場合は、そのパラメーターに一覧を示した属性のみが返されます。

GET /maxrest/rest/mbo/asset?_includecols=assetnum,serialnum

以下のように、要求は資産番号とシリアル番号のみを返します。



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SERIALNUM>32R5G</SERIALNUM><ASSETNUM>13150</ASSETNUM>

</ASSET><ASSET xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SERIALNUM>2342VV</SERIALNUM><ASSETNUM>13160</ASSETNUM>

</ASSET>


例: フィールドの除外

以下のように、 _excludecols パラメーターは、クエリー応答から除外するビジネス・オブジェクト・フィールドの一覧を指定します。

GET /maxrest/rest/mbo/asset?_excludecols=serialnum

この例では、要求は、シリアル番号を除いて、資産リソースのすべてのフィールドを返します。

_dropnulls パラメーター_dropnulls パラメーターを False に設定して、NULL 値を持つフィールドをクエリー応答に組み込みます。

他のパラメーターまたはオブジェクト構造構成によって制限されていない限り、クエリーによってすべてのリソース・フィールドが返されます。_dropnulls パラメーターを指定しないと、NULL のフィールドはクエリー応答からドロップされます。

例: NULL 値のフィールドの組み込み

以下のクエリーにはこのパラメーターが含まれています。

GET /maxrest/rest/os/mxasset?_dropnulls=0&_maxItems=1

クエリーは、以下の XML に示すように、NULL 値を返します。

<?xml version="1.0" encoding="UTF-8" ?><QueryMXASSETResponse xmlns="http://www.ibm.com/maximo"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"creationDateTime="2011-04-08T09:25:11-04:00" transLanguage="EN"baseLanguage="EN" messageID="1302273234298496774"maximoVersion="7 5 20110405-0030 V7500-718" rsStart="0"rsTotal="757" rsCount="1"><MXASSETSet><ASSET>

<ANCESTOR /><ASSETID>1579</ASSETID><ASSETNUM>CAL100</ASSETNUM><ASSETTAG /><ASSETTYPE /><AUTOWOGEN>0</AUTOWOGEN><BINNUM /><BUDGETCOST>0.0</BUDGETCOST><CALNUM /><CHANGEBY>WILSON</CHANGEBY>..

_format パラメーターおよび _compact パラメーターREST API は XML と JSON の表現 (フォーマット) をサポートします。 _formatパラメーターまたはコンテンツ・ネゴシエーションを使用すると、リソース表現を指定できます。 _compact パラメーターを使用すると、コンパクト JSON フォーマットを指定できます。

要求でフォーマットが指定されていない場合、デフォルトの表現が使用されます。デフォルトは mxe.rest.mbo.defaultformat システム・プロパティーによって定義されています。


要求で _format パラメーターが指定されている場合、その値は、mxe.rest.supportedformats システム・プロパティー内のサポートされているフォーマットのリストと照合して検証されます。要求されたフォーマットがサポートされているフォーマットのいずれかと一致した場合、要求されたフォーマットが応答のフォーマットとして使用されます。要求されたフォーマットがリスト内のサポートされているフォーマットと一致しない場合、HTTP 406 エラー・コードが生成されます。

_compact ブール型クエリー・パラメーターは、フォーマットされた応答をコンパクト・スタイルで返すことができる場合に JSON フォーマットに適用されます。応答データの構造は単純化され、個々のフィールド値に関するメタデータは返されません。

例: JSON 表現の指定

以下の要求は、JSON 表現での資産オブジェクトを対象としたものです。

GET /maxrest/rest/mbo/asset/123?_format=json

以下の応答が返されます。

{

ASSET: {

Attributes: {

ASSETNUM: {content: "11200"}

SERIALNUM: {content: "3481-52"}

ASSETTAG: {content: "3751"}

LOCATION: {content: "BR200"}

DESCRIPTION: {content: "HVAC System- 50 Ton Cool Cap/ 450000 Btu Heat Cap"}

例: コンパクト・フォーマットの指定

以下の要求はコンパクト・フォーマットを指定しています。

GET /maxrest/rest/mbo/asset/123?_format=json&_compact=1

以下の応答が返されます。

{

ASSET: {ASSETNUM: "11200"SERIALNUM: "3481-52"ASSETTAG: "3751"LOCATION: "BR200"


DESCRIPTION: "HVAC System- 50 Ton Cool Cap/ 450000 Btu Heat Cap"VENDOR: "TRN"MANUFACTURER: "TRN"..

関連概念:

『表現のコンテンツ・ネゴシエーション』REST API では、_format クエリー・パラメーターを使用する代わりにコンテンツ・ネゴシエーションを使用した表現形式の特定がサポートされます。

表現のコンテンツ・ネゴシエーションREST API では、_format クエリー・パラメーターを使用する代わりにコンテンツ・ネゴシエーションを使用した表現形式の特定がサポートされます。

XML 形式および JSON 形式の場合は、サポートされる MIME タイプ値は、以下のシステム・プロパティーで定義されます。


mxe.rest.format.json.mimetypes application/json

mxe.rest.format.xml.mimetypes application/xml,text/xml

形式は 1 つ以上の MIME タイプの別名であり、要求された MIME タイプのシリアライザーを特定するために使用されます。REST API は、コンテンツ・ネゴシエーションに Accept HTTP ヘッダー値を使用します。 REST API は、システム・プロパティーに定義された指定 MIME タイプの 1 つに対してヘッダー値を突き合わせます。一致するものがあった場合、REST API は、応答形式で対応する形式としてその値を使用します。サポートされる形式一覧で一致するものがない場合は、HTTP 406 エラー・コードが生成されます。

XML シリアライザーおよび JSON シリアライザーは常に、Content-Type ヘッダー・プロパティーに値 application/xml (XML 表現の場合) およびapplication/json (JSON 表現の場合) を設定して応答します。別の形式をサポートするシリアライザーを作成した場合は、mxe.rest.supportedformats システム・プロパティーの一覧にその形式を追加します。

mxe.rest.supportedformats システム・プロパティーの値は、対応するサポートされる MIME タイプ値の個別プロパティー (mxe.rest.format.NEW.mimetypes など)

で指定される値に関連しています。要求で、MIME タイプ値は Accept ヘッダー・プロパティーを介して指定されます。

例えば、以下のシステム・プロパティーを使用して、HTML をリソース表現形式として追加します。


mxe.rest.supportedformats html,xml,json,image

mxe.rest.format.html.mimetypes text/html

mxe.rest.mbo.serializer com.ibm.tivoli.maximo.rest.MboHTMLSerializer

mxe.rest.os.serializer com.ibm.tivoli.maximo.rest.OSHTMLSerializer


_format パラメーターおよび Accept ヘッダー・プロパティーの両方をクエリーで指定した場合は、クエリー・パラメーターが優先されます。

関連概念:

267ページの『_format パラメーターおよび _compact パラメーター』REST API は XML と JSON の表現 (フォーマット) をサポートします。 _formatパラメーターまたはコンテンツ・ネゴシエーションを使用すると、リソース表現を指定できます。 _compact パラメーターを使用すると、コンパクト JSON フォーマットを指定できます。

セッション内スクロールリソース・コレクションをメモリー内に保持することで、データのページをスクロールする際のパフォーマンスを改善することができます。

クエリーで _usc パラメーターに値 1 を指定すると、サーバーはリソース・コレクションをメモリー内に保持します。ブラウザーは、ビジネス・オブジェクトからデータを再選択する代わりに、メモリーにあるデータの追加ページを要求できます。HTTP 応答の RLID ヘッダー・プロパティーに、リソース・コレクションの ID が含まれます。

データの追加ページに関する以降の要求では、_maxitem パラメーター、_rsStartパラメーター、および _rlid パラメーター (リソース・コレクションの ID を保持)

を指定できます。サーバーは、指定された ID について、メモリー内に保持されたデータから次のページを取得します。

サーバー・キャッシュ・データは、ブラウザー・セッションが終了するか、ブラウザーがデータを解放するまで保持されます。例えば、リソースの ID が _rlid パラメーターで指定され、_rlrq パラメーターが True に設定されている場合に、データが解放されます。

セッション内スクロールに _maxitems パラメーターおよび _rsStart パラメーターを使用する代わりに、mxe.rest.handler.resource.pagesize システム・プロパティーを作成して、データの各ページのリソース数を割り当てることができます。その後、要求で _page クエリー・パラメーターを使用して、データの特定のページ (例えば、3 ページ目) を選択できます。

例えば、mxe.rest.mbo.asset.pagesize システム・プロパティーを作成して、値 35

を割り当てた場合は、データの 1 ページにつき 35 個の資産が返されます。

関連概念:

264ページの『_rsStart パラメーターおよび _maxItems パラメーター』_rsStart パラメーターおよび _maxItems パラメーターを一緒に使用することで、1


関連資料:


285ページの『REST クエリー・パラメーター』クエリー・パラメーターを使用することにより、応答を調整およびフィルタリングすることができます。


GET 要求のキャッシングGET 要求のキャッシングを有効にすることで、同じユーザーによって前に実行依頼されたリソース・データの要求の応答時間を改善することができます。

キャッシングが有効になっている場合は、データはサーバー上のビジネス・オブジェクトからではなく、ブラウザーのキャッシュから取得されます。キャッシングが要求で使用されるのは、要求のエンティティー・タグ (ETag) 値が前の要求の値に一致している場合です。キャッシングは各ユーザーに固有であり、Cache-ControlHTTP ヘッダー・プロパティーによって制御されます。

キャッシングの有効化

個別リソースのキャッシングを有効にするには、システム・プロパティーを作成します。システム・プロパティーの形式は、mxe.rest.handler.resource.cache です。ここで、handler は mbo または os で、resource はビジネス・オブジェクトまたはオブジェクト構造の名前です。システム・プロパティーには、ブール値 1 を設定する必要があります。

例えば、システム・プロパティー mxe.rest.mbo.workorder.cache を値 1 に設定すると、作業指示書ビジネス・オブジェクトのキャッシングが有効になります。

エンティティー・タグの計算および比較

初期要求がリソースに対して行われ、そのリソースのキャッシングが有効になっている場合は、フレームワークはリソース応答用の ETag 値を生成します。ETag はMBO rowstamp 属性に基づいて計算され、MBO が変更されるたびに変更されます。リソース・コレクションでは、ETag は、コレクション内の MBO から取得した rowstamp 値のコレクションのハッシュに基づいて計算されます。

例えば、応答の HTTP ヘッダーには以下が含まれます。

HTTP/1.1 200 OKETag: "123456789"Cache-control: privateContent-Length: 12195

Cache-control は private のマークが付けられ、現在のユーザーのみがキャッシュのコンテンツを再使用できるようにします。

ユーザーが同じリソースまたはコレクションに対する要求を繰り返した場合は、要求は以下のようなものになります。

GET maxrest/rest/mbo/po HTTP/1.1Host: x.yIf-None-Match: "123456789"

If-None-Match 値は、前の要求の ETag 値です。フレームワークは If-None-Matchヘッダー値を読み取って、2 回目の要求でリソースまたはコレクションについて新たに計算された ETag 値とその値を比較します。値が一致している場合は、サーバーは HTTP 304 で応答し、クライアント・キャッシュ・コンテンツが有効で使用可能であることを示します。応答には、以下の行が含まれています。

HTTP/1.1 304 Not Modified


ETag 値が要求の If-None-Match ヘッダー値に一致しない場合は、以下のように、リソース表現が構成されて、リソースまたはコレクションの今後の要求でクライアントが使用する新しい ETag 値とともにクライアントに送信されます。

HTTP/1.1 200 OKETag: "98999999"Cache-control: privateContent-Length: 50004

ペシミスティック・キャッシング・モード

デフォルトのキャッシング・モードはペシミスティック・キャッシングです。ペシミスティック・キャッシング・モードでは、要求はシリアライズされますが、要求の ETag 値が前の要求の値と一致している場合に、データはサーバーからクライアントに送信されません。

オプティミスティック・キャッシング・モード

オプティミスティック・キャッシングを有効にするには、mxe.rest.handler.resource.optimistic システム・プロパティーを 1 に設定します。オプティミスティック・キャッシング・モードでは、データのシリアライゼーションが行われる前に ETag 値が計算されます。オプティミスティック・キャッシングではシリアライゼーションが行われないため、大幅に応答時間を改善させることができますが、より多くのメモリーが必要になります (特に多数のレコードを要求するクエリーで)。

デフォルトでは、オプティミスティック・キャッシングは、オブジェクト構造のルート・オブジェクトから ETag 値を求めます。そのため、ルート・オブジェクトを更新しない関連オブジェクトをオブジェクト構造が持つ場合は、ETag 値が正しくない可能性があります。関連オブジェクトを含む、オブジェクト構造内のすべてのオブジェクトから ETag 値を求めるようにするには、mxe.rest.handler.resource.deepetag システム・プロパティーを 1 に設定します。ただし、このシステム・プロパティーを使用することで、パフォーマンスの改善の効果が低下し、より多くのメモリーが使用されるようになります。

キャッシュ時間制限

mxe.rest.handler.resource.maxage システム・プロパティーを秒単位の値に設定することにより、キャッシュの有効期間を構成できます。

関連資料:



PUT、POST、および DELETE の各メソッドHTTP PUT、POST、および DELETE の各メソッドを使用して、リソースを変更できます。


PUT、POST、および DELETE の各メソッドを使用して、ビジネス・オブジェクト・リソースおよびオブジェクト構造リソースを変更できます。ただし、オブジェクトのビジネス・ルールが原因で、REST API 要求によって更新できない場合があります。例えば、作業指示書の現在の状態が原因でビジネス・オブジェクトの有効性チェックで削除が許可されない場合に、作業指示書リソースに対する DELETE 要求が失敗することがあります。

構文method uri HTTP/1.1parameter=value&parameter=value&...

method は PUT、POST、または DELETE

uri は URI および関連するクエリー・パラメーター

parameter は更新されるリソースのパラメーター

value はパラメーターの値

PUT メソッドPUT メソッドを使用してリソースを更新または挿入します。更新要求では、リソースの固有 ID を指定する必要があります。オブジェクト構造リソースを更新するには、メイン・オブジェクトの ID が必要です。

オブジェクト構造リソースを更新または挿入する場合、_action パラメーターを指定して、統合フレームワークが提供するアクション (変更アクションや追加変更アクションなど) を識別することができます。

例: 資産の更新

以下のメソッドは、ID が 1234 の資産を更新します。資産の説明をmy_new_description に変更し、タイプを OPERATING に変更します。

PUT maxrest/rest/mbo/asset/1234 HTTP/1.1description=my_new_description&type=OPERATING

例: 下位階層オブジェクトの更新

以下のメソッドは、asset の下位階層である assetspec ビジネス・オブジェクトを更新します。値を new_value に変更し、説明を my_new_description に変更します。

PUT maxrest/rest/mbo/assetspec/5678 HTTP/1.1value=my_new_value&description=my_new_description

例: 上位階層オブジェクトのコンテキストの設定

下位階層ビジネス・オブジェクトを挿入または更新するには、上位階層ビジネス・オブジェクトのコンテキストを設定することが必要になる場合があります。例えば、以下の例では、コンテキストに合わせて注文書明細の説明を更新し、注文書のID を指定しています。

PUT maxrest/rest/mbo/po/1234/poline/5678 HTTP/1.1description=my_new_description


POST メソッドPOST メソッドを使用してリソースを更新または挿入します。

リソースを更新するには、リソースの ID を指定する必要があります。リソースを作成するには、プライマリー・キー、およびデフォルト値のないすべての必須フィールドを指定する必要がありますが、ID は必要ありません。

オブジェクト構造リソースを更新または挿入する場合、_action パラメーターを指定して、統合フレームワークが提供するアクション (変更や追加変更など) を識別することができます。

オブジェクト構造リソースの下位階層オブジェクトを更新または挿入するには、フォーム・データがその下位階層オブジェクトの各オカレンスを識別する必要があります。

POST メソッドを使用してリソースを作成する場合、値を 1 にして _ulcr クエリー・パラメーターを指定し、クライアントが新しいリソースにアクセスするためのリンクが応答に含まれるようにします。それ以外の場合、リソースの内容は応答に含まれます。リンクは Location ヘッダー・プロパティーに組み込まれ、HTTP 応答コードは、データの代わりにリンクが提供されていることを示す 201 です。

例: 資産の挿入

以下のメソッドは、ビジネス・オブジェクト・リソースを使用して、BEDFORD サイト内に資産 127 を挿入します。この資産とサイトがプライマリー・キーを構成します。

POST maxrest/rest/mbo/asset HTTP/1.1assetnum=127&siteid=BEDFORD&description=my_new_description&type=OPERATING

例: ID を指定することによる資産の更新

以下のメソッドは、URI の一部として ID を指定することによって資産を更新します。

POST maxrest/rest/mbo/asset/1234 HTTP/1.1description=my_new_description&type=OPERATING

例: アクションの指定

以下のメソッドは、_action パラメーターを使用して変更アクションを指定します。

POST maxrest/rest/mbo/asset/968 HTTP/1.1_action=Change&description=my_new_description

例: 複数の下位階層オブジェクトを持つレコードの更新

以下のメソッドは、2 つの注文書明細を注文書に追加し、各明細には 2 つの注文書コストがあります。

POST maxrest/rest/os/mxpo/1234 HTTP/1.1description=new_po_desc&poline.id1.polinenum=1&poline.id1.item=ABC&poline.id1.description=new_description&poline.id1.pocost.id1-1.costlinenum=1&poline.id1.pocost.id1-1.gldebitacct=new_gl_acct_a&poline.id1.pocost.id1-2.costlinenum=2&poline.id1.pocost.id1-2.gldebitacct=new_gl_acct_b&


poline.id2.polinenum=2&poline.id2.item=XYZ&poline.id2.description=new_description&poline.id2.pocost.id2-1.costlinenum=1&poline.id2.pocost.id2-1.gldebitacct=new_gl_acct_c&poline.id2.pocost.id2-2.costlinenum=2&poline.id2.pocost.id2-2.gldebitacct=new_gl_acct_d&

この例では、それぞれの ID は以下のパラメーターを識別します。

グループ ID 識別されるパラメーター

id1 注文書明細 1 に属するパラメーター

id1-1 注文書明細 1 の注文価格 1 に属するパラメーター


id2 注文書明細 2 に属するパラメーター



関連資料:


DELETE メソッドDELETE メソッドを使用するには、リソースの固有 ID が必要です。

オブジェクト構造リソースを削除するには、メイン・オブジェクトの ID が必要です。

例: 資産の削除

以下のメソッドは資産 1234 を削除します。

DELETE maxrest/rest/mbo/asset/1234 HTTP/1.1

リソースの並行更新初期クエリー後に別のユーザーまたはアプリケーションによってリソースが変更されていない場合にのみリソースを更新または削除するように、処理を制御できます。

_urs パラメーターを値 1 に設定すると、クエリー応答には、リソースの rowstamp

値が含まれます。

XML の例:

<PO rowstamp=1234567890>

JSON の例:

{"ASSET":{"rowstamp":"1234567890","Attributes":{"ASSETNUM":{"content":"1001"}

JSON の例 (コンパクト形式):

{"ASSET":{"rowstamp":"1234567890","ASSETNUM":"1001",

オブジェクト構造リソースの場合は、オブジェクト構造内にあるオブジェクトごとに rowstamp 値が提供されます。


リソースの更新以降の要求では、ビジネス・オブジェクトおよびオブジェクト構造リソースに対して _rowstamp パラメーターを使用するか、ビジネス・オブジェクトに対して If-Match ヘッダー・プロパティーを指定することで、rowstamp 値を提供できます。

処理中に、rowstamp 値は初期 rowstamp と比較されます。値が一致しない場合は、更新または削除の操作は失敗し、HTTP 戻りコード 412 が応答で返されます。

サービス・メソッドのクエリーおよび更新REST API は、アプリケーション・サービスによって公開されているメソッドの呼び出しに使用できます。

アプリケーション・サービスによって公開されているメソッドには、通常 Java

Specification Request (JSR) 181 @WebMethod 注釈のマークが付いています。これにより、これらのメソッドはサービス・メソッドとして公開されます。 REST API

は、これらのサービス・メソッド内にリソース指向ビューを提供します。

サービス・メソッドは以下のカテゴリーに分かれます。

v HTTP POST メソッドを使用してリソースを作成、更新、または削除し、それを行うことでシステムの状態を変更するメソッド。

v HTTP GET メソッドを使用してリソースまたはリソース・コレクションを取り出し、システムの状態を変更しないメソッド。

v HTTP GET メソッドを使用して日付やバージョン情報などのシステム情報を返し、リソースにはアクセスしないメソッド。

HTTP POST を使用してリソースを更新するサービス・メソッドメソッドは、HTTP POST メソッドを使用してリソースを作成、更新、または削除することができます。

リソースを更新するメソッドは、システムの状態を変更します。

X-HTTP-Method-Override (XMO) ヘッダーは HTTP POST を修飾します。 XMO ヘッダーには、JSR 181 注釈によって公開されるメソッドの名前が含まれます。

REST フレームワークは、リソースを所有するサービスを検索し、XMO ヘッダーに示されているメソッドを見つけ、POST フォーム・パラメーターをデシリアライズし、メソッドを呼び出し、変更されたリソースのシリアライズされた表現を返します。

例: メソッドへの注釈の付加

例えば、ASSET サービスに、注釈が付けられた moveSingleAsset ビジネス・メソッドがあるとします。

@WebMethodpublic void moveSingleAsset(@WSMboKey("ASSET") MboRemote asset, String newLocation,

String newSite, String newParent) throws MXException, RemoteException

このメソッドは資産を現在のロケーションから新規ロケーションに移動するので、システムの状態を変更します。以下の要求はこのメソッドを呼び出すために使用されます。


POST maxrest/rest/mbo/asset/1234 HTTP/1.1x-http-method-override: "moveSingleAsset"

以下が、フォーム・データ要求です。

~asset=this&~newLocation=Some_where&~newSite=some_site&~newParent=Some_one

この要求が行われると、以下のことが行われます。

1. ID が 1234 の資産ビジネス・オブジェクトがロードされます。

2. 所有サービス (ASSET) が検索されます。

3. moveSingleAsset というメソッドが検出されます。

4. URI にある asset は、@WSMboKey 注釈で資産ビジネス・オブジェクトとして参照され、このビジネス・オブジェクトは、フォーム・データ要求の最初のパラメーター値として指定されます。

5. 残りの値は、それぞれの名前に基づいてデシリアライズされ、割り当てられます。

6. 変更された資産 1234 は、要求された表現でクライアントに返されます。

例: メソッド・パラメーター名のオーバーライド

@WebParam(name="...") 注釈が付けられている場合を除いて、フォーム・パラメーター名はメソッド・パラメーター名と同じで、~ (チルド) 文字の接頭部が付いています。

例えば、注釈内に操作名が定義されたメソッド定義の場合を考えてみます。

@WebMethod(operationName="moveAssetLocation")public void moveSingleAsset(...)

この場合、このメソッドの呼び出しに以下の要求が使用されます。

POST maxrest/rest/mbo/asset/1234 HTTP/1.1x-method-override: "moveAssetLocation"

以下が、フォーム・データ要求です。

~asset=this&~newLocation=Some_where&~newSite=some_site&~newParent=Some_one

XMO ヘッダー値は、@WebMethod 注釈に指定されている属性値(moveAssetLocation) を使用する必要があります。

HTTP GET を使用してリソースをクエリーするサービス・メソッドキーワード get で始まるメソッド名または注釈が付けられた操作名には、HTTP

GET メソッドによってアクセスできます。

例えば、LOGGING サービスの以下のメソッドは、MAXLOGGER ビジネス・オブジェクトのリストを 1 つのビジネス・オブジェクト・セットとして返します。

@WebMethod@WSMboSet(name="MAXLOGGER")public MboSetRemote getLoggerList()

以下の要求はこのメソッドを呼び出すために使用され、ビジネス・オブジェクトのコレクションを構成された表現で返します。

GET maxrest/rest/mbo/maxlogger?_qop=getLoggerList HTTP/1.1


このメソッドを以下のように変化させた場合、操作名が提供されます。

@WebMethod(operationName=”getFilteredLoggers”)@WSMboSet(name="MAXLOGGER")public MboSetRemote getLoggerList(String someFilter)

以下の要求はこのメソッドを呼び出すために使用されます。

GET maxrest/rest/mbo/maxlogger?_qop=getFilteredLoggers&~someFilter=... HTTP/1.1

_qop 値は、注釈が付けられた名前を指定します。someFilter パラメーターには、この要求の一部として ~ 文字の接頭部が付きます。

仮想メソッド

メソッド名がキーワード get で始まっていない場合、それを直接呼び出すことはできません。例えば、クライアントが HTTP GET を使用して moveSingleAsset 操作を呼び出そうとすると、HTTP 405 エラーがスローされます。ただし、システム・プロパティーを使用することで、仮想メソッドを定義できます。

例えば、プロパティー mxe.rest.mbo.maxqueue.action.getQueueData を作成し、それに値 _operation=viewQueue|~queueName=this.queuename を割り当てるとします。

maxqueue リソースの場合、仮想メソッド getQueueData が maxqueue の所有サービス (MIC サービス) 内の viewQueue 操作にマップされます。属性は | (パイプ) 文字で区切ります。これにより、以下の HTTP GET 呼び出しを使用して、viewQueue

操作にアクセスすることができます。

GET /maxrest/rest/mbo/maxqueue/4567?_qop=getQueueData&~selector=...&~count=-1

メソッド・パラメーターにはリテラル値または派生値を指定できます。

例えば、viewQueue メソッドにパラメーター queueName があり、このパラメーターが maxqueue.queuename 属性にマップされるとします。maxqueue は GET URI によって指定される現行コンテキスト内のビジネス・オブジェクトです。したがって、フレームワークは派生値 this.queuename を current_mbo_in_context.queuename として評価します。これは、固有 ID 4567 によって識別される maxqueue の queuename

属性の値です。

第 2 の例として、mxe.rest.mbo.po.action.approve システム・プロパティーを作成し、それに値 _operation=changeStatus|~status=APPR を割り当てるとします。

approve という仮想操作が作成され、注文書上の changeStatus という操作にマップされます。この操作は、注文書ビジネス・オブジェクトの所有者サービスです。例を簡単に示すため、status パラメーターの値が APPR (承認済) にハードコーディングされています。 status パラメーターの値は変換可能でなければならないため、このハードコーディングされた値は実用に向きません。

仮想メソッドを使用する場合、システムの状態を変更したり、他の副次作用を生じたりするような操作に HTTP GET メソッドをマップしないようにする必要があります。


事前定義の initiateWorkflow 操作

事前定義の initiateWorkflow 操作は、ビジネス・オブジェクト・リソースのワークフローを開始します。以下の 2 つの例ではこの操作が使用されています。

POST /maxrest/rest/mbo/po/6789 HTTP/1.1x-http-method-override: "initiateWorkflow"

wfname=SOMEWF

POST /maxrest/rest/mbo/po/6789?wfname=SOMEWF HTTP/1.1x-http-method-override: "initiateWorkflow"

このメソッドは、固有 ID 6789 を持つ注文書ビジネス・オブジェクト用のSOMEWF という名前のワークフローのアクティブな改訂を開始します。ワークフローに待機ノードまたはタスク・ノードがある場合、他の手順またはバックグラウンド・イベントによってその再始動が必要になる可能性がありますが、それについては REST API の対象範囲外となります。

HTTP GET を使用してシステム・データをクエリーするサービス・メソッドサービス操作の中には、システム・データを取得し、リソース指向でないものがあります。

例えば、以下の HTTP GET は日時を取得します。

GET /maxrest/rest/ss/system/getDate


<getDateResponse xmlns=....><result>some ISO 8601 date</result></getDateResponse>

別の例として、以下の HTTP GET はバージョン情報を返します。

GET /maxrest/rest/ssm/system/getMXServerVersion


<getMXServerVersionResponse xmlns=...><return>Tivoli’s process automation engine 7.5.0.0 Build 20110127-1121DB Build V7500-673</return><return>...</return></getMXServerVersionResponse>

すべてのサービスのリストを取得する場合、以下の GET メソッドを使用できます。

GET /maxrest/rest/ss

この後に、リスト内の各サービスをドリルダウンして、呼び出し可能な操作のリストを取得できます。例えば、以下のメソッドは、system というサービスの操作を返します。

GET /maxrest/rest/ss/system


HTTP ヘッダー・プロパティーREST API に関連する HTTP ヘッダー・プロパティーがいくつか存在します。

表 35. REST API の HTTP ヘッダー・プロパティー


Accept 要求者によって指定され、要求の応答フォーマットを判別するためのコンテンツ・ネゴシエーションに使用されます。

Accept-Language 要求された言語でデータを提供します。このプロパティーは、複数の言語をサポートするアプリケーション・フィールドのみに適用されます。指定する値 (EN や FR など) は、アプリケーションがサポートするものでなければなりません。

クエリー・パラメーター _lang で言語コードを指定することができ、これは Accept-Language ヘッダー・プロパティーと同じ機能を提供します。

クエリー・パラメーター _locale を使用すると、要求者のロケールで返される数値および日付が有効になります。

Cache-Control キャッシングが使用可能かどうかを要求者に通知します。

キャッシングが使用可能な場合、Cache-Control プロパティーの値はprivate であり、現在のユーザーのみがキャッシュの内容を再利用できるようにします。

キャッシングが使用可能でない場合、Cache-Control プロパティーの値は no-cache です。

クライアント要求にヘッダー Cache-Control: no-cache を含めると、リソースでキャッシングが使用可能になっている場合でも、特定の要求に対してキャッシングを使用不可にすることができます。

Content-Length 応答の長さを含みます。

Content-Type 送信される表現のフォーマットを要求者に通知します。例えば、値として application/xml (XML 応答フォーマットの場合) またはapplication/json (JSON 応答フォーマットの場合) を指定できます。

ETag キャッシングが使用可能な場合、要求されているリソースに対してEtag 値を含みます。この値は、同じリソースを求める後続の要求のために、要求者のブラウザー・キャッシュによって保持されます。

If-None-Match キャッシングが使用可能な場合、前に要求されたリソースに対してEtag 値を含み、キャッシュの内容を再利用できるかどうかを API が判別できるようにします。

Last-Modified リソースが最後に変更された日時を要求者に通知します。

Location HTTP POST によって作成されたリソースへのリンク (HTTP コード201) を含みます。

_rlid リソース・コレクションの ID を含み、セッション内スクロールに使用されます。

関連概念:

271ページの『GET 要求のキャッシング』GET 要求のキャッシングを有効にすることで、同じユーザーによって前に実行依頼


されたリソース・データの要求の応答時間を改善することができます。


関連資料:

258ページの『GET メソッド』GET メソッドを使用して、ビジネス・オブジェクト・リソースおよびオブジェクト構造リソースを取得します。


274ページの『POST メソッド』POST メソッドを使用してリソースを更新または挿入します。


応答コードREST リソースからのメッセージは、そのリソース・インスタンスから応答に伝搬されます。

以下の HTTP 応答コードが REST API によって実装されています。

表 36. HTTP 応答コード

HTTP コード原因

200 成功。

201 成功。応答にリンクが含まれています。

304 成功。データはキャッシュから取得されます。

400 URI が無効であるなどの原因で、要求を受け取ることができません。

401 構成が原因で、許可違反が発生しました。

403 リソースが mxe.rest.resourcetype.blockaccess システム・プロパティーによってブロックされているため、許可違反が発生しました。

404 リソースが見つからないか、無効なリソース・タイプが指定されました。

405 その HTTP メソッドはリソースに使用できません。例えば、ビジネス・オブジェクト・セットでは DELETE メソッドは使用できません。

406 要求された表現はサポートされていません。

412 リソースは別のユーザーによって更新中です。

500 他のすべてのエラー。

これらのメッセージは、共通基盤によってサポートされる言語をサポートします。

REST API のセキュリティー共通基盤は、REST API に対して認証層および権限サポートを提供します。

REST API フレームワーク内では特定の認証関連処理は行われません。


認証層が REST API に対して J2EE 認証またはネイティブ認証を提供することができ、アプリケーション・サーバーが HTTPS サポートを提供します。

J2EE 認証

HTTP 基本認証を使用するには、以下の行をアンコメントして、maxrest Web モジュールの web.xml ファイルを変更します。



上記の <security-constraint> セクションは単一のロール、maximouser を示しています。これはこのファイルの <security-role> セクションで定義します。デフォルトでは、<security-role> セクションはコメント化されていません。

<security-role><description>MAXIMO Application Users</description><role-name>maximouser</role-name></security-role>

さらに、useAppServerSecurity の値を 0 から 1 に変更します。

<description>Indicates whether to use Application Serversecurity or not</description>

<env-entry-name>useAppServerSecurity</env-entry-name><env-entry-type>java.lang.String</env-entry-type><env-entry-value>0</env-entry-value></env-entry>

ネイティブ認証

ネイティブ認証を使用する場合、要求が、Base64 でエンコードされたユーザーとパスワードを含む MAXAUTH ヘッダー・プロパティーを指定することによって資格情報を指定できます。

明示的なログインまたはログアウト要求が必要な場合は、以下の要求を使用します。

GET /maxrest/rest/login


GET /maxrest/rest/logout

モジュール間通信

REST API との通信は、maximo および maxrest Web モジュールから行うことができます。

モジュール間通信では、通常、ユーザーが資格情報を再入力することは望ましくありません。アプリケーション・サーバーの認証を使用する場合、この問題は生じません。ブラウザーが、要求ごとに認証トークンを Web モジュールに伝搬するためです。ネイティブ認証では、REST API はどの Web モジュールでもアクセスできるライブラリー (commonweb) として使用できます。

例えば、URI http://site.example.com:9999/maxrest/rest/mbo/asset/46 は、maxrest Web モジュールを使用して資産をクエリーします。

対照的に、URI http://site.example.com:9999/maximo/rest/mbo/asset/46 は、ユーザー・インターフェース Web モジュールを使用して資産をクエリーします。

権限

オブジェクト構造の場合、オブジェクト構造アプリケーションの「オブジェクト構造」タブで、アプリケーション権限にリソースを接続できます。アプリケーション権限を指定すると、そのオブジェクト構造を使用するすべての統合処理がその影響を受けます。

ビジネス・オブジェクトの場合、オブジェクト構造アプリケーションの「オブジェクトに対するアプリケーションの権限」ウィンドウでアプリケーション権限にリソースを接続できます。このアプリケーションは、特定の MBO リソースに対するすべての REST API 要求に権限を与えます。

リソース・アクセスを制限するには、mxe.rest.mbo.blockaccess システム・プロパティーおよび mxe.rest.os.blockaccess システム・プロパティーでリソース名のリストを指定します。

関連資料:


REST API のカスタマイズREST API をカスタマイズして、XHTML 形式や Atom 形式などの各種リソース表現をサポートすることができます。また、REST API は、属性をビジネス・オブジェクト・リソースの表現に追加したり、表現の構造を変更したりしてカスタマイズすることもできます。

新しいリソース表現をサポートするには、新しい形式をサポートするカスタム・シリアライザーを指定する必要があります。


JSON 表現での作業指示書 MBO リソースの属性など、属性を追加する場合は、リソース用のカスタム JSON シリアライザーを追加する必要があります。追加クエリー・パラメーターをサポートするためには、MBO または OS ハンドラーを継承する必要があります。

カスタマイズによって既存のビジネス・プロセスまたはユーザーに影響が出ないようにしてください。リソース・タイプ用に REST API の別個のインスタンスを作成することで、悪影響を回避できます。

カスタマイズでは必ず、commonweb ライブラリーの一部としてアプリケーションEAR ファイルにクラス・ファイルを組み込む必要があります。

例

以下の手順で、REST API をカスタマイズします。

1. mxe.rest.handler.mbo プロパティーをコピーし、プロパティーの名前をmxe.rest.handler.abcmbo にし、値com.ibm.tivoli.maximo.rest.ABCMboResourceRequestHandler を割り当てることで、システム・プロパティーを作成します。

カスタマイズがすべての MBO に対する汎用的なものである場合は、カスタム・クラスは基本 MBO ハンドラーを継承します。URI コンテキストは abcmbo であるため、URL の形式は /maxrest/rest/abcmbo/workorder?... のようになります。

この手順では、MBO リソース用の REST API のインスタンスを作成します。

2. 作業指示書 MBO に固有のクエリー・パラメーターを処理するために、mxe.rest.handler.abcmbo.workorder システム・プロパティーを作成し、値com.ibm.tivoli.maximo.rest.WOMboResourceRequestHandler を割り当てることで、カスタム・ハンドラーを指定します。

クラスはデフォルトの MBO ハンドラーを継承できます (例えば、MboResourceRequestHandler に ABCMboResourceRequestHandler を使用します)。

3. 作業指示書 MBO 用に JSON シリアライザーをカスタマイズするために、mxe.rest.serializer.abcmbo.workorder.json システム・プロパティーを作成し、値 com.ibm.tivoli.maximo.rest.WOMboJSONSerializer を割り当てることで、シリアライザーを登録します。

4. Atom などの新しい形式をサポートするために、値 atom をmxe.rest.supported.formats システム・プロパティーに追加します。名前 atom

は、その形式のシリアライザーを一意的に識別します。その名前のシリアライザーが存在しない限り、任意の名前を指定できます。

5. mxe.rest.serializer.abcmbo.atom システム・プロパティーを作成して、値com.ibm.tivoli.maximo.rest.MboATOMSerializer を割り当てることで、シリアライザー・クラスを追加します。

6. HTTP Accept ヘッダーを使用して新しい形式を特定するために、mxe.rest.format.atom.mimetypes システム・プロパティーを作成し、値application/atom+xml を割り当てることで、MIME タイプ・マッピングを指定します。


7. 値 atom を mxe.rest.abcmbo.defaultformat システム・プロパティーに割り当てることで、デフォルト形式を設定します。

このような手順を実行することで、abcmbo ハンドラーのコンテキスト内にあることが原因で、カスタマイズが他の MBO や OS リソース・ハンドラーに影響することがなくなります。

REST クエリー・パラメータークエリー・パラメーターを使用することにより、応答を調整およびフィルタリングすることができます。

以下の 1 つ以上のクエリー・パラメーターを指定して、選択されるデータを制御することができます。ブール値は、true の場合は 1 に設定し、false の場合は 0 に設定する必要があります。

表 37. REST クエリー・パラメーター

名前タイプまたは値説明デフォルト

_compact ブール型 true の場合、JSON データはコンパクト表現で表示されます。

False

_dropnulls ブール型 true の場合、ビジネス・オブジェクト・リソースまたはオブジェクト構造リソースに値が含まれる場合にのみ、属性がシリアライズされます。 false

の場合、属性は NULL の場合でもすべてシリアライズされます。

True

_exactmatch ブール型 true の場合、完全に一致するかどうかについてパラメーター値が評価されます。 false の場合、LIKE 評価が行われます。

False

_excludecols MBO 属性のコンマ区切りリスト

リストされた属性をリソース応答から除外します。ビジネス・オブジェクト・リソース・タイプの場合にのみ有効です。

_fd クエリーの実行時にフィルターとして適用するアプリケーション・テーブル・ドメインを指定します。 _fdorg パラメーターおよび _fdsite パラメーターと一緒に使用できます。

_fdorg クエリーの実行時にフィルターとして適用する組織 ID を指定します。 _fd パラメーターと一緒に使用する必要があります。

_fdsite クエリーの実行時にフィルターとして適用するサイト ID を指定します。 _fd パラメーターと一緒に使用する必要があります。

_format json または xml リソース応答の表現を指定します。 xml

_generic ブール型 true の場合、リソース応答フィールドのデータは汎用フォーマットで返されます。 JSON データのみに適用されます。

False


表 37. REST クエリー・パラメーター (続き)


_glc ブール型 true の場合、ビジネス・オブジェクトの勘定科目一覧アプリケーションのすべてのフィールドに、総勘定元帳 (GL) コンポーネント・データが含まれます。

勘定科目一覧のほとんどのフィールドには、個々のコンポーネント・データが含まれます。デフォルトでは、このパラメーターはコンポーネント・データを省略するため、パフォーマンスが向上する可能性があります。

False

_includecols MBO 属性のコンマ区切りリスト

リソース応答の一部として含まれる属性を指定します。ビジネス・オブジェクト・リソース・タイプの場合にのみ有効です。

_keys ブール型 true の場合、ビジネス・オブジェクトのキー属性のみがシリアライズされます。他のすべての属性は、リソース応答から除去されます。

False

_lang 要求者の言語コードを指定します。

このパラメーターを指定しない場合、HTTP ヘッダーの accept-language パラメーターを使用して要求者の言語設定が決定されます。 HTTP ヘッダーにこのパラメーターを指定しない場合、デフォルトの統合ユーザーの値が使用されます。

_lid および _lpwd ログイン・ユーザー ID とパスワードを指定します。開発およびテスト専用です。ネイティブ認証が構成されている場合にのみ有効です。

_locale ブール型 true の場合、強い型定義の値に加え、ビジネス・オブジェクト属性値のロケール固有のテキスト・バージョンが返されます。

False

_maxItems 数字リソース・コレクション内のシリアライズされるビジネス・オブジェクトの最大数を指定します。このパラメーターを _rsStart パラメーターと一緒に使用して、大規模なリソース・コレクションの応答をページングします。このパラメーター名には大/小文字の区別があります。

_md ブール型 true の場合、メタデータ情報 (非表示、読み取り専用、必須値など) が返されます。

False

_opmodeor ブール型 true の場合、複数の属性パラメーターの間に OR

演算子が適用されます。 false の場合、AND 演算子が適用されます。

False

_orderby リソースのフィールドの順序付け方法を指定します。値として asc (昇順) または desc (降順) を指定できます。オブジェクト構造リソースの場合、このパラメーターは、オブジェクト構造の第1 レベルまたは第 2 レベルにあるビジネス・オブジェクトのフィールドにのみ使用できます。




_orderbyasc MBO 属性のコンマ区切りリスト

順序文節に使用される属性を昇順で指定します。

_orderbydesc MBO 属性のコンマ区切りリスト

順序文節に使用される属性を降順で指定します。

_page 要求で返す必要のあるページ番号を指定します。このパラメーターは、クエリー対象のリソースのpagesize システム・プロパティーが作成されている場合にのみ使用できます。

_qop GET 操作のクエリー・メソッドを指定します。MBO リソースでのみ有効です。

_rcol.alias クエリー応答の一部として返される関係名フィールドを指定します。 alias は、関連する属性の別名です。

このパラメーターを指定すると、クエリー対象のMBO リソースに関連するフィールドをクエリーできます。例えば、パラメーター_rcol.polinecost=poline.linecost では、polinecost が別名で、poline.linecost が関連する属性です。

_retainmbos ブール型内部使用のみ。

_rlid ブール型リソース・コレクションの ID を指定します。このパラメーターは、セッション内スクロールにのみ使用します。

_rlrq ブール型 true の場合、_rlid パラメーターによって指定されたリソース・コレクション用にキャッシュが解放されます。

False

_rootonly ブール型 true の場合、オブジェクト構造のメイン・オブジェクトのみがシリアライズされます。オブジェクト構造リソース・タイプの場合にのみ有効です。

False

_rowstamp 更新要求の場合、rowstamp ビジネス・オブジェクトを指定して、更新対象のオブジェクトが、最初にクエリーされた後に更新されていないか確認することができます。

_rsStart 数字リソース応答によってシリアライズされる、リソース・コレクション内の MBO の開始インデックスを指定します。このパラメーター名には大/小文字の区別があります。

0

_tc ブール型 true の場合、レコードの総数が計算され、その数が rsTotal 属性に割り当てられます。この計算では、リソース・コレクションのサイズに応じて、処理時間が増加します。

False

_tz 要求のタイム・ゾーンを指定します。要求のタイム・ゾーンがアプリケーションのタイム・ゾーンと異なる場合、このパラメーターを使用して日付関連のクエリーを正しく実行します。




_ulcr ブール型 true の場合、POST メソッドが、新しいリソースへのリンクを HTTP ヘッダーの Location プロパティー内に返します。

False

_urs ブール型 true の場合、クエリー応答に、リソースのrowstamp 値が含まれます。

_usc ブール型 true の場合、セッション内スクロールが使用され、_rlid プロパティーを使用して HTTP 応答にリソース・コレクション ID が組み込まれます。

False

_uw 選択基準として使用する SQL WHERE 文節を指定します。この文節は、アプリケーション内の詳細検索で動作する文節と互換性があるものでなければなりません。mxe.rest.whereclause.usepolicy システム・プロパティーと一緒に使用します。

_verbose ブール型 true の場合、JSON 表現のリソース応答はフォーマット済みとして返されます。

False

_vt ブール型 true の場合、有効な XML 文字に関して XML の検証が行われます。このパラメーターを false に設定すると検証が実行されないため、パフォーマンスが向上する可能性があります。

このパラメーターを指定しない場合、mxe.int.validatexml システム・プロパティーがXML を検証するかどうかを決定します。

True

関連概念:


267ページの『_format パラメーターおよび _compact パラメーター』REST API は XML と JSON の表現 (フォーマット) をサポートします。 _formatパラメーターまたはコンテンツ・ネゴシエーションを使用すると、リソース表現を指定できます。 _compact パラメーターを使用すると、コンパクト JSON フォーマットを指定できます。

267ページの『_dropnulls パラメーター』_dropnulls パラメーターを False に設定して、NULL 値を持つフィールドをクエリー応答に組み込みます。

266ページの『_includecols パラメーターおよび _excludecols パラメーター』_includecols パラメーターおよび _excludecols パラメーターを使用して、クエリーに対して返される属性の内容を制御します。

264ページの『_rsStart パラメーターおよび _maxItems パラメーター』_rsStart パラメーターおよび _maxItems パラメーターを一緒に使用することで、1



263ページの『_opmodeor パラメーター』_opmodeor パラメーターを使用して、値と値の間にデフォルトの AND 条件ではなく OR 条件を使用することにより、複数のフィールドを評価します。

265ページの『_orderbyasc パラメーター』_orderbyasc パラメーターは、返されるデータのソート順を制御します。

関連資料:


『REST システム・プロパティー』特定の要件に合わせた REST API の動作方法を構成するために、システム・プロパティーを使用できます。

REST システム・プロパティー特定の要件に合わせた REST API の動作方法を構成するために、システム・プロパティーを使用できます。

事前定義のシステム・プロパティー

以下のシステム・プロパティーを使用して、REST API の動作方法を構成します。プロパティーはすべて、mxe.rest で始まります。例えば、mxe.rest.format.json.mimetypes です。

表 38. 事前定義の REST システム・プロパティー

mxe.rest.property 名説明デフォルト値

format.json.mimetypes HTTP の Accept ヘッダー・プロパティーに含まれている、JSON でサポートされる MIME タイプのコンマ区切りリスト。この値はコンテンツ・ネゴシエーションの場合にのみ使用され、フォーマットを指定するクエリー・パラメーターがこれに優先します。

application/json

format.xml.mimetypes HTTP の Accept ヘッダー・プロパティーに含まれている、XML でサポートされる MIME タイプのコンマ区切りリスト。この値はコンテンツ・ネゴシエーションの場合にのみ使用され、フォーマットを指定するクエリー・パラメーターがこれに優先します。

application/xml、text/xml

handler.mbo ビジネス・オブジェクトのリソースのハンドラー・クラス・ファイル。



handler.os オブジェクト構造のリソース・ハンドラー・クラス・ファイル。



handler.ss システム・データへのアクセスをサポートする、標準サービスのハンドラー・クラス・ファイル。




表 38. 事前定義の REST システム・プロパティー (続き)


mbo.blockaccess REST API がアクセスできないビジネス・オブジェクトのコンマ区切りリスト。このプロパティーは、構成されている権限制限をすべてオーバーライドします。

mbo.defaultformat すべてのビジネス・オブジェクトのデフォルト表現。コンテンツ・ネゴシエーションに使用される Accept

ヘッダーの値、および表現を指定するクエリー・パラメーターが、このプロパティーに優先します。

xml

mbo.imglib.defaultformat IMGLIB ビジネス・オブジェクトの REST デフォルト表現。

image

os.blockaccess REST API がアクセスできないオブジェクト構造のコンマ区切りリスト。このプロパティーは、構成されている権限制限をすべてオーバーライドします。

os.defaultformat すべてのオブジェクト構造のデフォルト表現。コンテンツ・ネゴシエーションに使用される Accept ヘッダー・プロパティーの値、および表現を指定するクエリー・パラメーターが、このプロパティーに優先します。

xml

serializer.mbo.imglib.image イメージ・フォーマットになっている IMGLIB ビジネス・オブジェクトのシリアライザー・クラス。


ImageLibSerializer

serializer.mbo.json JSON フォーマットになっているビジネス・オブジェクトのシリアライザー・クラス。


MboJSONSerializer

serializer.mbo.xml XML フォーマットになっているビジネス・オブジェクトのシリアライザー・クラス。


MboXMLSerializer

serializer.os.json JSON フォーマットになっているオブジェクト構造のシリアライザー・クラス。


OSJSONSerializer

serializer.os.xml XML フォーマットになっているオブジェクト構造のシリアライザー・クラス。


OSXMLSerializer

serializer.ss.json JSON フォーマットになっている標準サービス・システム・データのシリアライザー・クラス。



serializer.ss.xml XML フォーマットになっている標準サービス・システム・データのシリアライザー・クラス。




表 38. 事前定義の REST システム・プロパティー (続き)


ss.defaultformat すべての標準サービス・システム・データのデフォルト表現。コンテンツ・ネゴシエーションに使用されるAccept ヘッダー・プロパティーの値、および表現を指定するクエリー・パラメーターが、このプロパティーに優先します。

xml

supportedformats サポートされている表現のリスト。 xml、json、image

webappurl トークン認証 Web アプリケーションの URL。このプロパティーは、内部使用のみです。

whereclause.usepolicy _uw クエリー・パラメーターの使用方法を指定します。値が parse の場合、クロスサイト・スクリプティングおよび SQL インジェクション攻撃を防ぐために、SQL WHERE

文節が検査されます。値が noparse

の場合、この文節は検査されません。それ以外の値の場合、WHERE

文節は無視されます。

parse

キャッシングに関するオプションのシステム・プロパティー

以下のプロパティーを作成して、REST API でのキャッシングを構成することができます。プロパティーはすべて、mxe.rest で始まります。例えば、mxe.rest.mbo.wo.cache です。

表 39. キャッシングに関するオプションの REST システム・プロパティー

mxe.rest.property 名タイプ説明例

handler.resource.cache ブール型指定されたハンドラーおよびリソースに対してペシミスティック・キャッシングを使用可能にします。

デフォルトは false です。

mxe.rest.mbo.wo.cache は 1 に設定されます。

mxe.rest.os.mxwo.cache は 1

に設定されます。

handler.resource.deepetag ブール型オプティミスティック・キャッシングが使用可能な場合、ルート・オブジェクトだけでなく、オブジェクト構造内のすべてのオブジェクトを評価することを指定します。



表 39. キャッシングに関するオプションの REST システム・プロパティー (続き)

mxe.rest.property 名タイプ説明例

handler.resource.optimistic ブール型指定されたハンドラーおよびリソースに対してオプティミスティック・キャッシングを使用可能にします。 1 つ以上のリソースのコレクションに適用されます。

オブジェクト構造の場合、メイン・ビジネス・オブジェクトのみに対して状態変更の評価が行われます。下位階層ビジネス・オブジェクトは評価されません。ビジネス・オブジェクトの非永続属性は、状態変更の評価から除外されます。

オプティミスティック・キャッシングを使用可能にする場合、handler.resource.deepetag システム・プロパティーも指定できます。


mxe.rest.mbo.wo.optimistic は1 に設定されます。

mxe.rest.os.mxwo.optimistic

は 1 に設定されます。

handler.resource.maxage 整数 (秒単位) リソース・コレクションがキャッシュ内に保持される最長時間を秒単位で指定します。

mxe.rest.mbo.wo.maxage は 60


mxe.rest.os.mxwo.maxage は 60


関連概念:

271ページの『GET 要求のキャッシング』GET 要求のキャッシングを有効にすることで、同じユーザーによって前に実行依頼されたリソース・データの要求の応答時間を改善することができます。

257ページの『サポートされる表現』REST API は表現として XML および JSON をサポートします。表現は、システム・プロパティーに登録されているシリアライザー・クラスの実装によってサポートされます。

関連資料:



外部サービス呼び出し構成された HTTP エンドポイントを使用して、外部 REST API を呼び出すことができます。


任意の構成された HTTP エンドポイントをサポートする HTTP ハンドラーにより、XML ペイロードを使用し、かつ POST メソッドおよび GET メソッドを使用する REST ベースのサービスを使用できます。エンドポイントは、パブリッシュ・チャネルまたは呼び出しチャネルを介してメッセージを送信するように構成できます。

OSLC 統合Maximo Integration Framework は、Open Services for Lifecycle Collaboration (OSLC)

統合に基づいて、アプリケーション間でのライフサイクル・データの共有をサポートします。OSLC 統合により、コンシューマー・アプリケーションは、プロバイダー・アプリケーションが OSLC サービス・プロバイダー経由で統合用に使用可能にするデータ・リソースに対して、作成、要求、更新、削除操作を実行できるようになります。

OSLC プロバイダー・アプリケーションは、サービス・プロバイダー経由で統合用に使用可能な関連データ・リソースのコンテナーを作成します。コンシューマー・アプリケーションはこれらのサービス・プロバイダーを使用して、リソースの照会、リソース・データの作成、更新、削除を行います。以下の図は、OSLC 統合での標準的な相互作用を示しています。コンシューマー・アプリケーションは、リソース・データに対するクエリーをサービス・プロバイダーに送信します。サービス・プロバイダーは、応答としてリソース・データへのリンクを提供します。コンシューマー・アプリケーションは、このリンクを使用して、リソース・データの作成、更新、削除を行います。

サービス・プロバイダー

OSLC プロバイダー・アプリケーション

クエリー��

リソース・リンク

OSLC コンシューマー・アプリケーション

�� /の

0されるリソース・リンク

コンシューマー・アプリケーションはリソース・リンクをして

リソースをまたはする

1

23 45


リソース・データ

関連情報:

Open Services for Lifecycle Collaboration コミュニティー

OASIS Open Standards Network の OSLC

OSLC Platform コミュニティー (IBM)


http://www.open-services.net

http://www.oasis-oslc.org/

https://www.ibm.com/developerworks/servicemanagement/oslcp/index.html

Maximo Asset Management での OSLC の実装複数のアプリケーション間でリンクされたデータの表現方法と交換方法を規定するOSLC 仕様は、OASIS コンソーシアムが開発と保守を行っています。Maximo Asset

Management は、バージョン2.0 の OSLC のコア仕様をサポートしています。このバージョンは、Maximo Integration Framework で有効にして拡張することができます。

OSLC の仕様は、REST (Representational State Transfer) アーキテクチャー、RDF

(Resource Description Framework) 仕様、HTTP (Hyper-Text Transfer Protocol) メソッドなど、確立されたインターネット標準とリンク・データの標準に基づいて、ライフサイクル・アプリケーションによるリソースの表現方法、リソースへのリンク方法、リソースへのアクセス方法を定義します。それぞれの仕様は、共通する統合ユース・ケースに対応するために、実質的に最小限の仕様になるよう設計されています。インテグレーターは、これらの仕様を拡張することも、特定の統合のシナリオに対応するために新しい仕様を追加することもできます。

Maximo Asset Management は、以下のコンポーネントを持つ OSLC プロバイダーとして構成されています。

v OSLC リソース・アプリケーションでは、統合のデータ・リソースを構成します。各 OSLC リソースは、統合可能なプライマリー・ビジネス・オブジェクトと関連する子ビジネス・オブジェクトを指定するオブジェクト構造に基づいています。

v OSLC のリソースは、リソース・オブジェクトを RDF/XML 形式で表す Shape

Document として生成されます。Shape Document は、リソースの必須特性を指定します。また、依存関係、属性、プロパティーなど、リソース・オブジェクトのさまざまな側面を記述することもできます。リソースの Shape Document には、リソースの子オブジェクトの Shape Document へのリンクを含めることができます。

v リソースは、機能ドメインによってグループ化されます。機能グループは、OASIS OSLC グループが開発と保守を行う既存のドメイン仕様を基にすることができます。インテグレーターは、ビジネス要件をサポートするために、これらの既存のドメイン仕様を拡張することも、追加のドメイン仕様を作成することもできます。

v ドメイン内のリソースは、サービス・プロバイダー経由で、OSLC コンシューマーに対して使用可能になります。

v ドメインごとに 1 つのサービス・プロバイダーがサポートされます。サービス・プロバイダーは、サポートされるリソースの作成や検索を行うための URI をOSLC コンシューマーに提供する OSLC 作成ファクトリーとクエリー機能の操作をサポートします。

v セキュリティー・フレームワークは、OSLC サービスの認証と許可をサポートします。 Maximo Asset Management のネイティブ認証と J2EE 認証がサポートされます。権限は、リソースのオブジェクト構造レベルによって制御され、アプリケーション・レベルとユーザー・ベースの権限が適用されます。

OSLC のコンシューマーは、以下の HTTP メソッドとヘッダー情報を使用して、OSLC プロバイダーとの対話を行います。


v 明示的なログインが必要な場合は、GET 要求を送信してログインを実行します。ネイティブ認証を使用する場合は、HTTP ヘッダーに権限プロパティーを組み込みます。明示的なログアウトが必要な場合も、GET 要求が使用されます。

v OSLC のクエリー・パラメーターが指定された GET 要求をサービス・プロバイダー URI に送信して、OSLC のリソースに対してクエリーを実行します。

v POST 要求を送信して、OSLC のリソースのインスタンスを作成します。この要求には、OSLC リソースのパブリッシュ済み Shape Document に準拠する JSON

ドキュメントが含まれています。リソース・インスタンスが作成されると、OSLC

プロバイダーは新しいリソースの URI が含まれた HTTP 応答を送信します。

v PUT 要求または PATCH 要求を送信して、OSLC のリソースを更新します。PUT 要求は、リソース全体を更新します。PATCH 要求は、リソースの一部を更新します。

v HTTP ヘッダーでエンティティー・タグ (ETag) を使用して、リソース・エンティティーが最新であることを確認します。また、PUT 要求と PATCH 要求でETag と If-Match ヘッダーを組み合わせることにより、条件付きの更新を有効にすることができます。

v コレクション・リソースの GET 要求で、安定ページングを要求することができます。その結果、応答により、複数のページがロードされる URI にコンシューマー・アプリケーションがリダイレクトされます。コレクション・リソースの場合、OSLC コンシューマーがページごとにデータベースにアクセスすることなく安定したページをロードできるため、パフォーマンスが向上します。

OSLC の構成Maximo Asset Management を OSLC プロバイダーとして構成するためには、ドメイン内のリソースを指定し、これらのドメインのサービス・プロバイダーのプロビジョニングを行い、セキュリティーを構成し、トラブルシューティングを支援する情報を収集するためのロギングをセットアップする必要があります。

OSLC のリソースの仕様OSLC のリソースは、OSLC で使用されるように構成された統合オブジェクト構造に基づいています。各オブジェクト構造には、アプリケーションで使用されるプライマリー・ビジネス・オブジェクトとすべての子ビジネス・オブジェクトが含まれています。オブジェクト構造内のオブジェクトの属性は、リソースの RDF タイプと述部にマップされ、リソース・タイプの名前空間を指定します。

OSLC の各リソース・タイプは、RDF 述部であるプロパティーを持っています。これらのプロパティーは、プロパティーの名前空間に対応する語彙仕様に属している場合があります。各属性は、DCMI (Dublin Core Metadata Initiative) などの語彙仕様に定義されているプロパティーにマップすることができます。

各リソースは、名前、OSLC が使用する関連オブジェクト構造、リソースのデフォルト名前空間の URI を持っています。統合する各属性には、デフォルトの RDF 値を使用するか、独自の値を指定できます。

v タイプ値と名前空間値は、リソースの RDF タイプとして機能します。

v 名前と名前空間の値は、リソースの RDF 述部として機能します。


リソースの Shape Document は、リソースのすべてのプロパティー、属性、依存関係など、リソースの情報を記述する RDF/XML 文書です。 OSLC の Shape

Document は、リソースのすべての依存関係、属性、プロパティーなど、リソースの情報を電子的に確認するための手段を提供します。例えば、作業指示書の Shape

Document には、資産、タスク、作業員、作業ログなど、サポートされるリソースを記述するプロパティーが含まれています。Shape Document では、資産、企業、注文書、および作業指示書など、さまざまな分野を対象にすることができます。Shape

Document には、要求内容も表示されます。リソースの Shape Document には、子オブジェクトの Shape Document へのリンクを含めることができます。

例: 作業指示書のリソースの Shape Document

作業指示書のリソースの Shape Document には、作業指示書のすべてのプロパティー、属性、依存関係がリストされます。以下のコードは、oslcwodetail という名前の作業指示書の Shape Document からの抜粋です。リソースの Shape Document のこの部分には 3 つのプロパティーが含まれていますが、このドキュメントにはさらに多くのプロパティーがリストされている可能性があります。Shape Document のこの部分に含まれる 3 つのプロパティーは、RDF ドキュメントに含まれるノードの3 つのタイプを表します。最初のプロパティー (genforporevision) は、ローカル・ノードです。2 番目のプロパティー (multiassetlocci) は、ブランクのノードです。これは、このプロパティーの URI またはリテラルは、いずれも RDF にリストされないことを意味します。3 番目のプロパティー (asset) は、URI ノードです。<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:oslc="http://open-services.net/ns/core#"xmlns:dcterms="http://purl.org/dc/terms/>"

<oslc:ResourceShape rdf:about="http://host/maximo/oslc/shapes/oslcwodetail"><oslc:describes rdf:resource="http://jazz.net/ns/ism/work/smarter_physical_

infrastructure#WorkOrder"/><oslc:property><oslc:Property>

<oslc:name>genforporevision</oslc:name><oslc:occurs rdf:resource="http://open-services.net/ns/core#Zero-or-one"/><oslc:propertyDefinition rdf:resource="http://jazz.net/ns/ism/asset/smarter_physical_

infrastructure#genforporevision"/><oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/><dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">

PO Revision</dcterms:title></oslc:Property>

</oslc:property><oslc:property>

<oslc:Property><oslc:name>multiassetlocci</oslc:name><oslc:occurs rdf:resource="http://open-services.net/ns/core#Zero-or-many"/><oslc:propertyDefinition rdf:resource="http://jazz.net/ns/ism/asset/smarter_physical_

infrastructure#multiassetlocci"/><oslc:valueType rdf:resource="http://open-services.net/ns/core#LocalResource"/><oslc:representation rdf:resource="http://open-services.net/ns/core#Inline"/><oslc:valueShape rdf:resource="http://host/maximo/oslc/shapes/oslcwodetail/multiassetlocci"/><oslc:range rdf:resource="http://jazz.net/ns/ism/asset/smarter_physical_

infrastructure#MultuAssetLocationCI"/></oslc:Property>

</oslc:property><oslc:property>

<oslc:Property><oslc:name>asset</oslc:name><oslc:occurs rdf:resource="http://open-services.net/ns/core#Zero-or-one"/><oslc:propertyDefinition rdf:resource="http://jazz.net/ns/ism/work/smarter_physical_

infrastructure#asset"/><oslc:valueType rdf:resource="http://open-services.net/ns/core#Resource"/><oslc:representation rdf:resource="http://open-services.net/ns/core#Reference"/><oslc:valueShape rdf:resource="http://host/maximo/oslc/shapes/oslcasset"/><oslc:range rdf:resource="http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#asset"/><dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">

Asset</dcterms:title></oslc:Property>

</oslc:property>


ドメインのサービス・プロバイダーOSLC のリソースはドメイン内で使用可能になり、そのドメインの OSLC サービス・プロバイダーを介して OSLC コンシューマーで使用することができます。ドメインごとに単一のサービス・プロバイダーがサポートされます。

Maximo Asset Management では、ブラウザーで http:/host:port/maximo/oslc/sp

という URI を入力することにより、使用可能なサービス・プロバイダーを検出することができます。応答として、OSLC 統合用に構成された各ドメインのサービス・プロバイダー文書の URI が返されます。

例えば、作業管理ドメインのサービス・プロバイダー文書の URI はhttp://host:port/maximo/oslc/sp/WorkManagment です。サービス・プロバイダー文書は、RDF/XML 形式です。この文書には、使用可能なリソースと名前空間のマッピング、保存されたクエリー、サービス・プロバイダーがサポートするリソースに対してサポートされる操作が記述されています。OSLC のコンシューマーは、サービス・プロバイダー文書を使用して、使用可能なリソースと、コンシューマーがサポートするサービス (クエリーや作成サービスなど) を判別することができます。現在の実装では、作成、要求、更新、および削除の操作がデータ・レベルでサポートされていますが、委任ユーザー・インターフェース・シナリオでのリソースはサポートされていません。

以下のサンプル応答では、OSLC サービス・プロバイダーが rdfs:member プロパティーから参照されています。ドメインのサービス・プロバイダー文書に、作業管理用の URI が示されます。

<rdfs:member rdf:resource="http://host/maximo/oslc/sp/WorkManagement">

<rdf:RDF><rdf:Description rdf:about="http://host/maximo/oslc/sp"><rdfs:member rdf:resource="http://host/maximo/oslc/sp/WorkManagement"></rdf:Description></rdf:RDF>

名前空間

OSLC では、共通の名前空間を定義しています。prefixDefinition プロパティーは、サービス・プロバイダーが管理対象のリソースを記述するために使用する、名前空間接頭辞のマッピングをすべて公開します。以下の表に、使用可能な名前空間のサンプルを示します。

Prefix 名前空間

rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#

oslc http://open-services.net/ns/core#

dcterms http://purl.org/dc/terms/

asset http://open-services.net/ns/asset#

foaf http://xmlns.com/foaf/0.1/

rdfs http://www.w3.org/2000/01/rdf-schema#

rr http://jazz.net/ns/ism/registry#

spi http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#


以下のサービス・プロバイダー文書のサービス・セクションからの抜粋に、OSLC

名前空間と RDF 名前空間が示されています。<oslc:ServiceProvider rdf:about="http://host:7001/maximo/oslc/sp/WorkManagement"><oslc:prefixDefinition><oslc:PrefixDefinition><oslc:prefixBase rdf:resource="http://open-services.net/ns/core#"/><oslc:prefix>oslc</oslc:prefix>

</oslc:PrefixDefinition></oslc:prefixDefinition>

<oslc:prefixDefinition><oslc:PrefixDefinition><oslc:prefixBase rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/><oslc:prefix>rdf</oslc:prefix>

</oslc:PrefixDefinition></oslc:prefixDefinition>

以下の表に、共通名前空間を使用する作業指示書のサンプル・マッピングを示します。

OSLC 接頭辞既存の接頭辞

oslc:shortTitle wonum

dcterms:title 説明

dcterms:description description_longdescription

dcterms:creator reportedby

dcterms:created reportdate

dcterms:identifier workorderid

以下の表に、作業指示書の dcterms:creator から参照される担当者オブジェクトのマッピングを示します。

OSLC 接頭辞既存の接頭辞

foaf:name displayname

foaf:givenName firstname

foaf:familyName lastname

作成ファクトリーとクエリーの操作

OSLC サービス・プロバイダーは、サービス・プロバイダー文書で使用可能なリソースに対する作成ファクトリーとクエリー機能の操作をサポートします。作成ファクトリーは、oslc:creation という作成 URI を提供します。この URI を HTTP

POST 要求で使用して、新しいリソースを作成します。oslc:queryBase というクエリー URI を使用すると、サービス・プロバイダーによって管理されるリソース・コレクションを選択することができます。クエリーまたは作成の操作で取得したリソースは、更新または削除することができます。

リソースで作成がサポートされる場合は、作成ファクトリーの操作が 1 つ存在する可能性があります。以下に、サービス・プロバイダー文書の抜粋を示します。この抜粋は、作成ファクトリーの操作、リソースの形状の URI、その形状を作成するリソース作成操作の URI を示しています。<oslc:creationFactory><oslc:CreationFactory><oslc:resourceType rdf:resource="http://jazz.net/ns/ism/work

/smarter_physical_infrastructure#WorkOrder"/>


<oslc:resourceShape rdf:resource="http://host:port/maximo/oslc/shapes/oslcwodetail"/><oslc:creation rdf:resource="http://host:port/maximo/oslc/os/oslcwodetail"/><oslc:label>Create WorkOrder</oslc:label><dcterms:title>OSLC creation factory for WorkOrder</dcterms:title>

</oslc:CreationFactory></oslc:creationFactory>

......

クエリー URI は oslc:queryBase です。以下の例は、要求

<oslc:queryBase rdf:resource="http://host/maximo/oslc/os/oslcwodetail"/>

による作業指示書の検索を示しています。<oslc:queryCapability>

<oslc:QueryCapability><oslc:resourceType rdf:resource="http://jazz.net/ns/ism/work/smarter_physical_

infrastructure#WorkOrder"/><oslc:queryBase rdf:resource="http://host/maximo/oslc/os/oslcwodetail"/><oslc:labelQuery> WorkOrder</oslc:label><dcterms:title>OSLC query capability for WorkOrder</dcterms:title>

</oslc:QueryCapability></oslc:queryCapability>

保存されたクエリーOSLC リソースが、あるアプリケーションを参照するオブジェクト構造に基づいて定義されている場合、そのアプリケーションから保存されているパブリック・クエリーはすべて、サービス・プロバイダーを介して使用可能になります。これらのクエリーは、その OSLC リソースのサービス・プロバイダー文書で、OSLC クエリー機能として公開されます。

オブジェクト構造は、オプションでアプリケーションに接続することができます。オブジェクト構造がアプリケーションに接続されている場合、アプリケーションは、そのオブジェクト構造に関連付けられているリソースに対して、セキュリティー許可と保存されたパブリック・クエリーを提供します。ユーザーは、アプリケーションでカスタム・クエリーを作成して、それをパブリックにすることができます。これにより、リソースのクエリーを実行するときに、それらのクエリーを使用できるようになります。保存されているクエリーをリソースに対して実行するには、その保存されているクエリーのクエリー機能で提供されているクエリー・ベース URI で HTTP GET 要求を実行します。保存されているクエリーに一致するOSLC リソースのリストが返されます。

クエリー機能のプロパティーのそれぞれは、oslc:queryBase プロパティーと呼ばれるURI を公開しています。このプロパティーにより、コンシューマーは、サービス・プロバイダーによって管理されるリソースを検索することができます。それぞれのクエリー機能は、oslc:resourceType という 1 つのリソース・タイプのみをサポートします。OSLC 仕様では、クエリー機能が複数のリソース・タイプをサポートすることを許可しています。クエリー機能は、OSLC リソースを実装するオブジェクト構造に登録されているアプリケーションに対してパブリック・クエリーとして保存されたすべてのクエリーをリストします。登録されたアプリケーションに対してパブリック・クエリーとして保存されたクエリーがない場合や、登録されたアプリケーションがない場合、1 つのクエリー機能だけが、汎用のクエリー・コレクションURI を提供します。サービス・プロバイダーによってサポートされるリソース・タイプごとに、最低 1 つのクエリー機能が必ず存在します。


例: 作業指示書アプリケーションに保存されたクエリー

作業指示書アプリケーションに、自分が所有する作業指示書を検索するためのクエリーを作成します。クエリーをパブリック・クエリーにして、クエリーがサービス・プロバイダー文書に savedQuery=OWNER+IS+ME として表示されるようにします。OSLC の最上位オブジェクト構造も作業指示書にする必要があります。<oslc:service>

<oslc:Service><oslc:queryCapability><oslc:QueryCapability><oslc:resourceType rdf:resource="http://jazz.net/ns/ism/work/smarter_physical_

infrastructure#WorkOrder"/><oslc:queryBase rdf:resource="http://host/maximo/oslc/os/oslcwodetail?

savedQuery=OWNER+IS+ME"/><oslc:label>Query OWNER IS ME</oslc:label><dcterms:title>OSLC query capability for My Work Orders</dcterms:title>

</oslc:QueryCapability></oslc:queryCapability><oslc:queryCapability><oslc:QueryCapability><oslc:resourceType rdf:resource="http://jazz.net/ns/ism/work/smarter_physical_

infrastructure#WorkOrder"/><oslc:queryBase rdf:resource="http://host/maximo/oslc/os/oslcwodetail"/><oslc:label>Query WorkOrder</oslc:label><dcterms:title>OSLC query capability for WorkOrder</dcterms:title>

</oslc:QueryCapability></oslc:queryCapability>......

OSLC セキュリティーOSLC サービスの認証と権限のサポートは、Maximo Asset Management セキュリティー・フレームワークによって提供されます。LDAP などの J2EE ベースの認証は、アプリケーション・サーバーによってサポートされます。アプリケーション・サーバーは、HTTPS のサポートも提供します。

Maximo Asset Management に対するネイティブ認証

コンシューマー要求では、base64 エンコードされて MAXAUTH HTTP ヘッダー・プロパティーに格納される user:password 値を指定できます。

J2EE 認証

J2EE 認証を構成するには、web.xml ファイルを変更し、セキュリティー制約を設定して、useAppServerSecurity プロパティーを true に設定します。

maximouiweb Web モジュールの web.xml ファイルを変更するには、以下の行をアンコメントします。




"},-{"oslc:shortTitle": "2004","rdf:about": "http://host/maximo/oslc/os/oslcwodetail/58","spi_wm:status": "INPRG","dcterms:description": "all the database and stuff"},-{"oslc:shortTitle": "6003","rdf:about": "http://host/maximo/oslc/os/oslcwodetail/8","spi_wm:status": "APPR"},-{"oslc:shortTitle": "1004","rdf:about": "http://host/maximo/oslc/os/oslcwodetail/155","spi_wm:status": "INPRG","dcterms:description": "Performance is key"},-{"oslc:shortTitle": "1006","rdf:about": "http://host/maximo/oslc/os/oslcwodetail/73","spi_wm:status": "APPR"}],"rdf:about": "http://host/maximo/oslc/os/oslcwodetail"-"prefixes":{"rdfs": "http://www.w3.org/2000/01/rdf-schema#",


"oslc": "http://open-services.net/ns/core#","rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#","spi_wm": "http://jazz.net/ns/ism/work/smarter_physical_infrastructure#","dcterms": "http://purl.org/dc/terms/"}}

クエリー並べ替えパラメーター:

oslc.orderBy クエリー・パラメーターは、クエリーの結果が並べられる順序を定義します。例えば、作業指示書のリストを日付順に並べたり、ID 順に並べたりします。

例: ソート順の指定

以下の oslc.orderBy クエリーは、作成日の昇順および所要時間見積の降順に基づいて作業指示書を返します。

+dcterms:created,-m:estimatedDuration

このクエリーでは、+ は昇順のソート順を意味し、- は降順のソート順を意味します。OSLC クエリー構文にデフォルトのソート順はないため、dcterms:created,-m:estimatedDuration という oslc.orderBy パラメーターは無効です。プロパティー名とともに、+ または - を明示的に指定する必要があります。oslc.orderBy パラメーターは、ネストされたプロパティーに対してはサポートされません。例えば、dcterms:creator{+foaf:name} はサポートされません。

クエリー選択パラメーター:

oslc.select クエリー・パラメーターは、コレクション・リソース内のリソースのリソース表現の一部を要求します。oslc.select パラメーターは、常にコレクション・リソースに適用されます。要求には、含めるプロパティーのリストを指定します。

例: リソースの一部の要求

oslc.select パラメーターは、修飾プロパティー名のコンマ区切りリストを指定します。oslc.prefix パラメーターはサポートされていません。以下のクエリーは、リソースの一部を要求します。

oslc.select=oslc:shortTitle, dcterms:creator


{"rdf:about": "some uri","rdfs:member": [{"oslc:shortTitle": "1022","rdf:about": "some workorder uri","dcterms:creator":{

"rdf:about": "some person uri"}


例: 参照されるリソースのプロパティーの選択

oslc.select パラメーターを使用して、参照されるリソースからプロパティーを選択することができます。以下のクエリーは、作成者の名前を要求します。

oslc.select= oslc:shortTitle, dcterms:creator{foaf:name}


{"rdf:about": "some uri","rdfs:member": [{"oslc:shortTitle": "1022","rdf:about": "some workorder uri","dcterms:creator":{

"rdf:about": "some person uri","foaf:name": "Todd Winston"

}

この例では、foaf:Person リソースは、creator プロパティー値に指定された担当者の名前です。リソースのすべてのプロパティーを取得するには、oslc.select=* を使用します。OSLC リソースを検索する場合には、これと同じ構文をoslc.properties パラメーターに適用できます。

リソース・インスタンスの作成コンシューマー・アプリケーションは、HTTP POST メソッドを使用して、OSLC

リソースのインスタンスを作成します。このリソースは、他のアプリケーションで共有することができます。

コンシューマー・アプリケーションは、HTTP POST メソッドを使用して、パブリッシュ済みのリソース形状に準拠した JSON ドキュメントを送信します。 OSLC

の JSON フォーマットには、application/json MIME タイプが関連付けられています。要求が正常に処理されると、プロバイダー・アプリケーションの HTTP 応答のヘッダーに、新しく作成されたリソースの URI が組み込まれます。

例: リソースのインスタンスの作成

以下のメソッドは、oslcwodetail リソースを作成します。POST /maximo/oslc/os/oslcwodetail....{

"dcterms:creator": {"rdf:resource": "http://host:port/maximo/oslc/os/oslcperson/_V0lOU1RPTg--"

},"dcterms:title": "Check-out Leaking","spi_wm:orgid": "EAGLENA","spi_wm:siteid": "BEDFORD","spi_wm:woclass": "WORKORDER","oslc:shortTitle": "T5050","spi:asset": {

"rdf:resource": "http://host:port/maximo/oslc/os/oslcasset/_MTMxNDUvQkVERk9SRA--"},"spi:location": {

"rdf:resource": "http://host:port/maximo/oslc/os/oslcoperloc/_U0hJUFBJTkcvQkVERk9SRA--"},"spi:status": "WAPPR"

}.....

要求が正常に処理されると、コンシューマー・アプリケーションは以下の応答を受信します。


201 CreatedLocation: http://host:port/maximo/oslc/os/oslcwodetail/_ABCD--ETag: 1234567

HTTP 応答のメッセージの本文は空になっています。新しく作成されたリソースの詳細を取得するために、コンシューマー・アプリケーションは、HTTP ヘッダーのロケーション・プロパティーに指定された URI に HTTP GET 要求を送信する必要があります。コンシューマー・アプリケーションは、 HTTP ヘッダーの ETag プロパティーを使用して、プロバイダー・アプリケーションに条件付き更新の要求を送信することができます。

業務上の検証、認証、許可などのさまざまな理由により、OSLC 要求は失敗する可能性があります。要求が失敗した場合、コンシューマー・アプリケーションは、応答として HTTP エラー・コード (400 Bad Request エラーなど) を受け取ります。このエラー・メッセージの本文には、エラーの詳細が記述されています。

リソースの修正HTTP PUT メソッドは OSLC のリソースを置き換え、 HTTP PATCH メソッドはOSLC のリソースの一部を更新します。

OSLC リソースの置き換え:

HTTP PUT メソッドは、リテラル・プロパティーやローカル・リソース・プロパティーなど、OSLC リソースのすべてのプロパティーを置き換えます。また、このPUT メソッドは、要求内で指定されていないローカル・リソースのプロパティーもすべて削除します。

PUT メソッドを使用して OSLC リソースを置き換える際、以下のルールが適用されます。

v HTTP 要求ドキュメントで指定されたすべてのリテラル・プロパティーが更新されます。要求の一部として指定されていないリテラル・プロパティーは、要求による明示的な影響は受けません。ただし、リソースに関連するビジネス・ロジックにより、リテラル・プロパティーが暗黙的に影響を受ける可能性があります。

v ローカル・リソースのすべてのプロパティーが、要求内に指定された対応する値で置き換えられます。リソース・プロパティーが PUT 要求に含まれている場合、その値によってサーバー上の値が置き換えられます。リソース・プロパティーが HTTP 要求に含まれていない場合、サーバー上で対応するプロパティーが削除されます。

v 参照リソースを明示的に更新することはできませんが、リソースを参照するプロパティーは更新することができます。その場合、それらのプロパティーは、リテラル・プロパティーの更新モデルに従って更新されます。

以下の例では、作業指示書リソースに title というリテラル・プロパティーと、wplabor というリソース・プロパティーがそれぞれ 1 つずつあります。wplabor プロパティーは、ローカル・リソース WPLABOR を指し、2 つの作業計画作業員レコードが関連付けられています。PUT 要求に title プロパティーが含まれていて、wplabor プロパティーが含まれていない場合、タイトルは更新され、作業計画作業員データは削除されます。


例: リテラル・プロパティーの更新

以下のメソッドは、リテラル・プロパティー title を更新し、wplabor プロパティーと関連データを削除します。

PUT /maximo/oslc/os/oslcwodetail/abc

{"dcterms:title": "Check-out Leaking – Modified for Test"

}

要求が正常に処理された場合、コンシューマー・アプリケーションは以下の HTTP

応答を受信します。

204 No ContentETag: 123456

タイトルは Check-out Leaking – Modified for Test に変更されます。wplabor データは含まれていないため、作業計画作業員レコードは削除されます。

例: リソース・プロパティーの更新

以下のメソッドは、リソース・プロパティー wplabor を更新します。

PUT /maximo/oslc/os/oslcwodetail/abc

{“spi:wplabor”: [

{“spi_wm:wplaborid": "0000000067",

"spi_wm:rate": 18.5}

]}

要求が正常に処理された場合、コンシューマー・アプリケーションは以下の HTTP

応答を受信します。

204 No ContentETag: 123456

この要求は、0000000067 という ID を持つ作業計画作業員レコードの検索を開始します。この作業計画作業員レコードが存在する場合、そのレコードが更新されます。一致するレコードが見つからない場合、0000000067 という ID で、新しい作業計画作業員レコードが作成されます。この作業指示書リソースのその他すべての作業計画作業員データは削除されます。title プロパティーは含まれていないため、タイトルは要求の一部ではなく、その値は影響されません。

OSLC リソースの部分的な更新:

HTTP PATCH メソッドは、OSLC リソースの一部を更新します。 PUT メソッドとは異なり、PATCH メソッドは、要求内で指定されていないローカル・リソースのプロパティーは削除しません。PATCH メソッドを実装するには、x-method-override ヘッダーが必要です。

PATCH メソッドを使用して OSLC リソースを置き換える場合、以下のルールが適用されます。


v 要求ドキュメントに指定されたすべてのリテラル・プロパティーが更新されます。要求の一部として指定されていないリテラル・プロパティーは、要求による明示的な影響は受けません。ただし、リソースに関連するビジネス・ロジックにより、リテラル・プロパティーが暗黙的に影響を受ける可能性があります。

v 対応するプロパティー値が PATCH 要求に含まれている場合は、ローカル・リソースのプロパティーが更新または置換されます。リソース・プロパティーが要求に含まれていない場合、対応するローカル・リソースは、要求による明示的な影響を受けません。要求にリソース・プロパティーが含まれている場合、受け取った値によってサーバーの値が置換または更新されます。

v 参照リソースを明示的に更新することはできませんが、リソースを参照するプロパティーは更新することができます。その場合、それらのプロパティーは、リテラル・プロパティーの更新モデルに従って更新されます。

HTTP PATCH 要求は、以下のシナリオで使用されます。

v PATCH 要求は、要求に含まれている内容で、配列 (ローカル・リソース) プロパティーを置き換えます。このシナリオが、デフォルトの実装になります。

v 要求に含まれている配列リソース・エレメントを検索し、サーバー上の対応するリソース・エレメントと突き合わせることができます。一致しているかどうかにより、配列リソース・エレメントが更新または挿入されます。配列エレメントがローカル・リソース・プロパティーから削除されることは決してありません。配列エレメントと突き合わせる PATCH 要求を使用するために、コンシューマー・アプリケーションは、PATCHTYPE HTTP 要求ヘッダーを MERGE (大/小文字が区別されます) という値に設定します。

例: リテラル・プロパティーの更新

以下のメソッドは、作業指示書のタイトル・プロパティーを更新します。

POST /maximo/oslc/os/oslcwodetail/abcdx-method-override: PATCH

{"dcterms:title": "Check-out Leaking – Modified for Test"

}

PUT メソッドとは異なり、この PATCH メソッドは、作業指示書の他のプロパティーを更新しません。

例: リソース・プロパティーの更新およびマージ

以下のメソッドは、PATCHTYPE ヘッダーを MERGE に設定して、リソースを更新します。

POST /maximo/oslc/os/oslcwodetail/abcdx-method-override: PATCHPATCHTYPE: MERGE

{"dcterms:title": "Check-out Leaking – Modified for Test",“spi:wplabor”: [

{“spi_wm:wplaborid": "0000000067",


"spi_wm:rate": 18.5}

]}

この要求は、0000000067 という ID を持つ作業計画作業員レコードの検索を開始します。この作業計画作業員レコードが存在する場合、そのレコードが更新されます。一致が見つからない場合、ID を 0000000067 に設定した作業計画作業員レコードが新規に作成されます。 PATCHTYPE ヘッダーが MERGE に設定されているため、この作業指示書リソースの他の作業計画作業員レコードは変更されません。

例: 条件付きの更新

以下のメソッドは、ETag 値が 1234567 の場合にリソースを更新します。

POST /maximo/oslc/os/oslcwodetail/abcdx-method-override: PATCHif-match: 1234567

ETag の値が 1234567 の場合、作業指示書リソースが更新されて、HTTP 204 応答がコンシューマー・アプリケーションに送信されます。

ETag 値が 1234567 でない場合は、サーバーがメッセージ「HTTP 412 前提条件を満たしていません」で応答します。このメッセージは、リソースが他のプロセスによって更新済みであり、要求側コンシューマー・アプリケーションのリソースのコピーが古いことを示しています。コンシューマー・アプリケーションは、abcd リソースに対して GET 要求を実行して、このリソースの新しいコピーを取得する必要があります。

HTTP ヘッダーOSLC は、トランザクションで追加の情報を交換するために、HTTP 要求と HTTP

応答のヘッダー・セクションで各種の値を提供します。これらのヘッダー値は、安定ページングやリソースの条件付き更新などの機能をサポートします。また、HTTP

接続障害が発生した場合に、重複するトランザクションの発生を防ぎます。

Etag 値と If-Match ヘッダーに基づく条件付きの更新

エンティティー・タグ (ETag) は、HTTP ヘッダー応答に含まれる値で、リソースの現在の状態を表します。 OSLC のコンシューマー・アプリケーションが GET 要求を作成すると、応答ヘッダーに ETag 値が組み込まれます。コンシューマー・アプリケーションは、後続の PUT 更新要求と PATCH 更新要求内に If-Match ヘッダーの一部として ETag 値を組み込みます。これにより、更新が条件付きの更新になり、ETag 値が作成されてからそのレコードが変更されていない場合のみ、更新が行われるようになります。条件付きの更新処理は、例えば 2 つのコンシューマーが同じリソースを更新しようとした場合など、無効な更新や競合状態を検出します。

コンシューマー・アプリケーションは ETag のヘッダー値を保管し、その値を後続の更新要求の HTTP If-Match ヘッダーの一部として送信します。サーバーはそのIf-Match ヘッダーを評価して、コンシューマー・アプリケーションのリソースのバージョンが古いものか最新のものかを判断します。ただし、コンシューマー・アプリケーションのリソースのバージョンが最新であるとサーバーが判断した場合は、業務上の検証やデータベースの制約が検出されない限り、更新処理が実行されます。要求で指定されたリソースのバージョンが古いと判断した場合、サーバーは


HTTP 412 の前提条件失敗の応答を返します。その場合、コンシューマー・アプリケーションはリソースを再び取得し、更新された ETag に基づく更新要求を送信する必要があります。

コンシューマー・アプリケーションは、If-Match ヘッダーが存在しない更新要求を送信することも、If-Match ヘッダーが「*」(アスタリスク) に設定された更新要求を送信することもできます。この要求の送信は、意味の上では更新要求に If-Match ヘッダーを含めないのと同じことになります。いずれの場合も、更新は無条件で実行されます。当該の URI で参照されるリソースが存在しており、業務上の検証やデータベースの制約が検出されない場合は、更新が実装されます。

コレクション・リソースの安定ページング

OSLC の安定ページングは、ページング対象のリソースがモバイル・デバイスなどのコンシューマー・アプリケーションにページングされる際に、そのリソースが変更されないようなページング・パターンを定義します。安定ページングは、コレクション・リソースに対してのみサポートされます。HTTP サーバーのデフォルトのページング形式ではありません。安定ページングを要求するために、 OSLC コンシューマー・アプリケーションは、HTTP 要求に stablepaging クエリー・パラメーターまたは stablepaging ヘッダーを組み込みます。サーバーは、要求されたコレクション・リソースをメモリーにロードし、 HTTP 応答は、OSLC コンシューマー・アプリケーションをロードされたコレクション・リソースが格納されている URI にリダイレクトします。以降のページに対する後続の要求では、常にメモリー内のリソースからロードされ、データベースからロードされることはありません。コンシューマー・アプリケーションは実行結果を使用してページングを行うため、安定ページングによってパフォーマンスが向上します。

安定ページングでは、安定ページングの初回の要求に対応したのと同じサーバー・プロセスまたはクラスター・メンバーが、次のページに対する後続の要求に対応しなければなりません。同じサーバー・プロセスが必要となる理由は、リソースはそのサーバー・プロセスのメモリーにロードされているのであって、他のクラスター・メンバーにはロードされていないためです。後続の要求が他のメンバーにロード・バランシングされると、コンシューマー・アプリケーションは「404 Not

Found」エラーを受け取ります。このエラーを避けるには、コンシューマー・アプリケーションからのすべてのセッション内要求を、同じサーバー・プロセスで処理する必要があります。

安定ページングの例

クライアントが、以下の資産リソースを要求します。

GET/oslc/os/oslcasset?stablepaging=true

この要求によって、以下の応答が生成されます。

303 RedirectingLocation: http://host:port/../olscasset?stableid=1234

クライアントがリダイレクト URI に対して GET 要求を実行します。

GET../oslcasset?stableid=1234


これに対する応答は、コレクションの最初のページです。次のページの URI は、メッセージの一部として oslc:ResponseInfo オブジェクトに組み込まれます。クライアントが各ページを移動すると、ロードされたページの有効期限が切れていきます。例えば、クライアントが 3 ページ目にいる場合、3 ページ目を再ロードすることも、1 ページ目や 2 ページ目を再ロードすることもできません。これらのページを再ロードしようとすると、HTTP 410 エラーが生成されます。ロードされたリソースは、mxe.oslc.idleexpiry システム・プロパティーで制御されるアイドル状態の有効期限に基づいて失効するまで、メモリーに保持されます。アイドル状態の有効期限は、クライアントがリソースにアクセスしなかった期間を意味します。クライアントは、oslc.select 文節を使用してメンバー・プロパティーを要求し、oslc.orderBy クエリー・パラメーターを使用して結果のコレクションを順序付けることができます。

部分的なリソース更新用に PATCHTYPE ヘッダーをマージするための設定

例えばモバイル・アプリケーション用にメッセージ・サイズを最小化する場合、コンシューマー・アプリケーションで PATCH 要求を使用して、変更されたデータだけに更新を制限することができます。例えば、作業指示書に関連する作業ログを更新するためにオブジェクト構造の子オブジェクトを更新する場合、コンシューマー・アプリケーションは、PATCHTYPE ヘッダー・プロパティーがマージ用に設定されている PATCH 要求を送信します。

HTTP 応答ヘッダーでリソース・プロパティーを返す

OSLC の共通基盤の実装には、HTTP 応答でのリソース属性値の戻りをサポートする properties という新しい HTTP ヘッダー・プロパティーが組み込まれています。コンシューマー・アプリケーションは、このプロパティー・ヘッダーを設定して、プロパティーのコンマ区切りのストリングを POST 要求、PUT 要求、またはPATCH 要求に組み込むことができます。HTTP 応答には、要求された属性値が格納されます。プロパティー・ヘッダーを使用すると、例えば、作業指示書を作成したPOST 要求に対する HTTP 応答で作業指示書の番号を受け取るなどの処理を実行することができます。

接続障害が発生した場合の重複トランザクションの回避

OSLC の共通基盤の実装には、コンシューマー・アプリケーションが各トランザクションに固有の ID を割り当てるために使用する transactionid という新しいHTTP ヘッダー・プロパティーが組み込まれています。プロバイダー・アプリケーションは、OSLC のトランザクション・テーブルにトランザクション ID を格納します。ネットワーク接続障害の発生後に、コンシューマー・アプリケーションがPOST 要求または PATCH 要求を再送信した場合、サーバーはトランザクション・テーブル内の値と照合してトランザクション ID を検証します。同じトランザクション ID が既に存在する場合、サーバーは HTTP 応答としてトランザクション競合エラーを返します。

HTTP 応答コードOSLC は、標準の HTTP 応答コードを使用します。例えば、Web ページが見つからない場合には、一般に HTTP 404 応答が返されます。OSLC では、リソースが見つからない場合に 404 応答コードが返されます。


一部の既存のエラー・コードは、デフォルトで HTTP コードにマップされます。実装者は、必要に応じて追加の応答コードをマップすることができます。

以下の HTTP 応答コードが OSLC によって実装されています。

HTTP コード OSLC の説明

200 成功。

201 成功。応答にリンクが含まれています。

204 リソースは正常に更新されました。応答エンティティーはありません。

400 要求処理中のエラー。このエラーは、要求の内容または URI が原因で発生する可能性があります。例えば、サーバー・サイドでビジネス・ロジックの検証エラーが発生した場合などです。

401 認証障害。

403 禁止されています。ユーザー・パスワードの有効期限が切れています。

404 リソースが見つからないか、無効なリソース・タイプが指定されました。

405 その HTTP メソッドはリソースに使用できません。

406 要求された表現はサポートされていません。

410 安定リソース・ページの有効期限が切れています。

412 クライアント・サイドのリソースが失効しているため、サーバーからリフレッシュする必要があります。リソースは別のユーザーまたはプロセスによって更新済みであるため、条件付きの更新は失敗しました。

500 他のすべてのサーバー・エラー。

これらのメッセージは、共通基盤によってサポートされる言語をサポートします。

OSLC コンシューマーとしての統合ご使用のアプリケーションの OSLC コンシューマーは、選択ダイアログ、作成ダイアログ、およびクエリーの 3 つのタイプの相互作用をサポートするように構成できます。リソース・リンクは、コンシューマー・アプリケーションによってプロバイダー・アプリケーションから取得されます。

次の図は、コンシューマー・アプリケーションとプロバイダー・アプリケーションの間の相互作用を示しています。OSLC コンシューマーとして、アプリケーションは、プロバイダー・アプリケーションのリソースをクエリーまたは作成でき、それらのリソースへのリンクを保持できます。リンクを使用して、コンシューマー・アプリケーションは、リソースをクエリー、更新、または削除するための要求をプロバイダー・アプリケーションに対して行うことができます。


リソース・リンク

OSLC

(IBM SmartCloudControl Desk )

コンシューマー・アプリケーション

など

67 ��ダイアログ

リソース・データ

OSLC

(Rational TeamConcert )

プロバイダー・アプリケーション

など

�/ ��ダイアログ

プレビュー・ダイアログ

クエリー��


コンシューマー・アプリケーションはリソース・リンクをして

リソースをまたはする

1

23 45

OSLC プロバイダー・レコードの作成レジストリー・サービス・リソース・レジストリーに登録する製品ごとに、OSLC

プロバイダー・アプリケーションでプロバイダー・レコードを作成する必要があります。プロバイダー・レコードを使用して、ユーザーが製品間でデータを共有および更新することを可能にする相互作用を作成できます。

レジストリー・サービス:

レジストリー・サービスとは、Open Services for Lifecycle Collaboration (OSLC) のサービス、リソース、およびコンシューマーが、統合サービス管理環境で OSLC インターフェースを使用して操作するためのメカニズムを提供する、Jazz™ for Service

Management 統合サービスです。

レジストリー・サービスは、環境内の使用可能な機能を追跡するためにプロバイダー・レジストリーを使用し、環境で管理可能なリソースを追跡するためにリソース・レジストリーを使用します。リソース・レジストリーを使用して、環境で管理可能なリソースを追跡します。共通基盤は、プロバイダー・レジストリーとリソース・レジストリーを使用して、複数の製品を統合します。

プロバイダー・レジストリー

プロバイダー・レジストリーとは、さまざまなドメインにわたって複数の製品で提供されるサービスが含まれるレジストリー・サービス・ディレクトリーです。プロバイダー・レジストリーは、環境内のすべてのサービス・プロバイダーを追跡し、これらのサービス・プロバイダーへの連絡方法に関する情報を提供するとともに、サービス・プロバイダーが実行するアクションのタイプをリストします。

OSLC コンシューマーとして選択ウィンドウ、作成ウィンドウ、またはクエリー相互作用を作成する際には、その相互作用がプロバイダー・レジストリー内のサービス・プロバイダーをディスカバーするように構成できます。


OSLC プロバイダーは、現在、アプリケーションのサービス・プロバイダーをプロバイダー・レジストリーに登録するためのサポートを提供していません。

リソース・レジストリー

リソース・レジストリーとは、さまざまなドメインにわたって複数の製品で管理または追跡されるリソースが含まれるレジストリー・サービス・ディレクトリーです。

OSLC コンシューマーは、リソース・レジストリーを使用してリソースをクエリーできます。クエリー相互作用を作成する際には、リソース・レジストリーを指すように、プロバイダー・レコードのパブリック URI を構成できます。また、デフォルトの PROVIDERREGISTRY エンドポイントを構成することもできます。

OSLC プロバイダーは、現在、アプリケーションのリソースをリソース・レジストリーに登録するためのサポートを提供していません。

サービス・プロバイダー:

サービス・プロバイダーは、プロジェクト、ユーザー・データベース、モジュールなど、関連するデータのコンテナーまたはコレクションです。サービス・プロバイダーは、欠陥やタスクなど、類似するリソースのグループ化をサポートしており、これは統合用に構成することができます。

OSLC プロバイダー・アプリケーションのサービス・プロバイダーには、アプリケーションの統合を通じてコンシューマー・アプリケーション・データにリンクできるリソース・データが含まれています。コンシューマー・アプリケーションとプロバイダー・アプリケーションを統合するには、プロバイダー・アプリケーションで使用可能なサービス・プロバイダーをコンシューマーがディスカバーまたは識別する必要があります。

OSLC プロバイダー・アプリケーションでサービス・プロバイダーをディスカバーする方法として、以下がサポートされます。

v カタログ・リスト

v 単一のサービス・プロバイダー

v プロバイダー・レジストリー

カタログ・リストまたは単一のサービス・プロバイダーをディスカバリーに使用するには、OSLC プロバイダー・アプリケーションで「サービス・プロバイダー・リスト URI」フィールドに URI を指定します。URI はサービス・プロバイダー・カタログ、サービス・プロバイダー・リスト、または個々のサービス・プロバイダーにリンクできます。

プロバイダー・レジストリーをディスカバリーに使用するには、OSLC プロバイダー・アプリケーションで「プロバイダー・レジストリーの使用」チェック・ボックスを選択します。エンドポイント・アプリケーションでは、プロバイダー・レジストリーへの接続情報を識別するために、PROVIDERREGISTRY という名前の定義済み HTTP エンドポイントが使用されます。

PROVIDERREGISTRY エンドポイントは、OSLC プロバイダー・アプリケーションがサービス・プロバイダー・データを登録できるプロバイダー・レジストリーを指


定します。このエンドポイントを使用する前に、いくつかの構成が必要です。プロバイダー・レジストリーの HTTP エンドポイントは、統合アプリケーション間での相互作用を実行する時に使用する OAuth エンドポイントや HTTP エンドポイントとは異なります。

リソース・タイプおよび Shape Document:

リソース・タイプは、統合アプリケーション間でリンクされるデータのタイプ (変更要求など) を識別します。リソース・タイプは Shape Document に関連付けることができます。Shape Document は、リソースのデータ構造を定義するという点でXML スキーマに似ています。

OSLC プロバイダー・アプリケーションで、「リソース・タイプの追加/変更」アクションを使用して、リソース・タイプを作成します。少なくとも 1 つのプロバイダーによってサポートされていて、リンク先となるデータのタイプごとに、リソース・タイプを作成します。プロバイダー・アプリケーションは、OSLC 相互作用で使用可能なリソース・タイプのサービス・プロバイダーを通して、リソース・タイプをサポートしていなければなりません。

リソース・タイプは、1 つのプロバイダーに関する複数の相互作用に対して使用できます。リソース・タイプは、同じリソース・タイプをサポートする複数の OSLC

プロバイダーで使用できます。

プロバイダー・アプリケーションからのリソース・データは、コンシューマー・アプリケーションでは、使用として利用できるようになります。使用はリソース・データのサブクラスです。例えば、変更要求のリソース・タイプには、使用として欠陥およびタスクが設定されている可能性があります。

Shape Document は、相互作用で使用できるリソース・データ・タイプを記述したResource Description Framework (RDF) ファイルです。リソース・タイプを作成するときに、そのリソース・タイプの Shape Document をインポートできます。Shape

Document には、リソース・タイプの属性のリストが含まれています。

OSLC 統合のエンドポイント:

エンドポイントは、サービス、プロセス、アプリケーション、またはトピック宛先へのエントリー・ポイントです。OSLC との統合には、2 つのタイプのエンドポイントを使用できます。統合エンドポイントは、コンシューマー・アプリケーションとプロバイダー・アプリケーションの間の OSLC 統合に使用されます。これにより、コンシューマー・アプリケーションが OSLC プロバイダー・アプリケーションと通信する方法が指定されます。統合エンドポイントは、OAuth エンドポイントまたは HTTP エンドポイントのいずれかです。プロバイダー・レジストリー・エンドポイントが使用されるのは、サービス・プロバイダー・ディスカバリー用に指定された方法がプロバイダー・レジストリー経由で行われる場合のみです。

統合エンドポイント

OSLC プロバイダー・レコードを作成するときに、プロバイダー・アプリケーションのエンドポイントを指定する必要があります。エンドポイントは、コンシューマー・アプリケーションとプロバイダー・アプリケーションの間のすべての相互作用に使用されます。一部のプロバイダー (Rational Team Concert™ など) との OSLC


統合では、OAuth ハンドラー・タイプのエンドポイントを使用する必要があります。他のプロバイダーでは、HTTP エンドポイントを使用する必要があるか、HTTP

エンドポイントまたは OAuth エンドポイントのいずれかがサポートされる可能性があります。

OAuth は、サイトまたはアプリケーション間での許可に関するオープン・スタンダードです。OAuth により、あるサイトに保管されているリソースを別のサイトと共有できるようになり、その際に完全な認証資格情報を提供する必要もありません。OAuth に関する追加情報は、Web ですぐに入手できます。

エンドポイント・アプリケーションでエンドポイント定義を作成します。エンドポイントでは、統合およびデータ・リンクを可能にする、プロバイダー・アプリケーションからの属性値を指定します。

重要: OAuth エンドポイント名には、英数字のみを使用してください。

OAuth エンドポイント・プロパティーの値は、プロバイダー・アプリケーションの構成に基づいています。

表 40. OAuth エンドポイントのプロパティー


ACCESSTOKENURL OSLC プロバイダー・アプリケーションからアクセス・トークン URL を取得します。この値は必須です。

AUTHORIZATIONURL OSLC プロバイダー・アプリケーションから許可トークン URL を取得します。この値は必須です。

CONSUMERKEY OSLC プロバイダー・アプリケーションから取得され、コンシューマー・アプリケーションによって使用される OAuth キー。この値は必須です。

CONSUMERSECRET OSLC プロバイダー・アプリケーションから取得され、コンシューマー・アプリケーションによって使用される OAuth の秘密またはパスワード。この値は暗号化形式で保管されます。これは必須です。

COOKIES エンドポイントにパススルーする Cookie。

HEADERS エンドポイントにパススルーするヘッダー・プロパティー。例えば、統合のコンシューマー側の言語コードをヘッダー・プロパティーに組み込む場合があります。

HTTPMETHOD 要求時に使用される HTTP メソッド。デフォルト値は GET です。この値は必須です。HTTPMETHOD プロパティーで「上書きを許可」が選択されていることを確認します。

REQUESTTOKENURL OAuth セキュリティー・プロバイダーのURL。OSLC プロバイダー・アプリケーションからこの値を取得します。この値は必須です。


表 40. OAuth エンドポイントのプロパティー (続き)


URL サービス・プロバイダー使用タイプのURL。この値は必須です。URL プロパティーに「上書きを許可」が選択されていることを確認します。

プロバイダー・レジストリー・エンドポイント

OSLC プロバイダーでサービス・プロバイダーをディスカバーする方法として、プロバイダー・レジストリーを使用することを製品で指定できます。この場合、統合に使用する OAuth エンドポイントまたは HTTP エンドポイントに加えて、ディスカバリー用に定義済みの HTTP エンドポイントを使用します。エンドポイント名PROVIDERREGISTRY は、mxe.oslc.prqueryep システム・プロパティーに登録されています。

IBM のオープン・サービス・デリバリー・プラットフォーム (OSDP) には、Transparent Development プログラムの下で利用可能な独自のバージョンのプロバイダー・レジストリーがあります。このレジストリーの詳細情報および現行バージョンのダウンロード方法については、https://www.ibm.com/developerworks/

servicemanagement/iosdp/index.html を参照してください。このレジストリーは、実装されると、PROVIDERREGISTRY エンドポイントとして構成できます。

PROVIDERREGISTRY エンドポイントはエンドポイント・アプリケーションで事前定義されていますが、一部のプロパティーは構成されていません。プロバイダー・レジストリー経由でのサービス・プロバイダー・ディスカバリーをサポートするには、このエンドポイントを詳細に構成する必要があります。

表 41. PROVIDERREGISTRY HTTP エンドポイントのプロパティー


CONNECTTIMEOUT 接続がタイムアウト・エラーを出すまでの接続時間 (秒単位)。

COOKIES エンドポイントにパススルーする Cookie。

HEADERS エンドポイントにパススルーするヘッダー・プロパティー。例えば、統合のコンシューマー側の言語コードをヘッダー・プロパティーに組み込む場合があります。

HTTPEXIT プロバイダー・レジストリーに固有の処理をサポートするために用意されている Java exit

クラスです。

HTTPMETHOD 要求時に使用される HTTP メソッド。デフォルト値は GET です。この値は必須です。HTTPMETHOD プロパティーで「上書きを許可」が選択されていることを確認します。

PASSWORD レジストリーが保護されている場合、ユーザー名に対応するパスワードが必要です。


表 41. PROVIDERREGISTRY HTTP エンドポイントのプロパティー (続き)


READTIMEOUT コンシューマー・アプリケーションによって行われた要求に対する応答がタイムアウト・エラーを出すまでの待機時間 (秒単位)。

URL プロバイダー・レジストリーの URL。必須。デフォルト値は https://oslc-registry/oslc/pr

です。この値は、レジストリーのローカル実装を反映するように更新する必要があります。URL プロパティーに「上書きを許可」が選択されていることを確認します。

USERNAME レジストリーが保護されている場合、ユーザー名および対応するパスワードが必要です。

PROVIDERREGISTRY エンドポイント定義を構成するときは、少なくとも次の 2

つのプロパティーの値を指定する必要があります。

v HTTPMETHOD: GET に構成します。

v URL: デフォルト値があります。その値を更新して、レジストリーのローカル実装を反映します。

プロバイダー・レジストリーのセキュリティー構成によっては、USER 値とPASSWORD 値も構成する必要があります。

シングル・サインオン

シングル・サインオンを使用することを予定している場合は、HTTP エンドポイントの COOKIES プロパティーを LtpaToken2 に設定する必要があります。

OSLC 相互作用の設計OSLC 統合は、いずれかのユーザー・アプリケーションのデータと、外部の OSLC

プロバイダー・アプリケーションのデータとの間にリンクを確立します。OSLC 相互作用を設計することにより、OSLC プロバイダー・アプリケーションを使用してアプリケーションを統合します。

OSLC プロバイダー・アプリケーションは、ユーザー・インターフェースから生成される OSLC 相互作用の作成をサポートしています。設計できる相互作用には次の3 種類があり、ユーザーはこれらを使用して、アプリケーション・データをプロバイダーのリソース・データにリンクすることができます。

v 作成相互作用では、ユーザーは OSLC プロバイダー・アプリケーションのリソース・データを作成し、そのリソース・データをアプリケーション・レコードにリンクすることができます。

v 選択相互作用では、ユーザーは OSLC プロバイダー・アプリケーションの既存のリソース・データを選択し、そのリソース・データをアプリケーション・レコードにリンクすることができます。

v クエリー相互作用では、ユーザーが OSLC プロバイダー・アプリケーションの定義済みクエリーを選択して、リソース・データを取得することができます。

相互作用を設計する前に、以下のレコードを適切な場所に置く必要があります。


v エンドポイント・アプリケーションにプロバイダー・アプリケーションの OAuth

または HTTP 統合エンドポイント・レコードが存在しなければなりません。

v OSLC プロバイダー・アプリケーションに OSLC プロバイダー・アプリケーションのレコードが定義されていなければなりません。

v 1 つ以上のプロバイダー・リソース・タイプが使用可能でなければなりません。OSLC プロバイダー・アプリケーションの「リソース・タイプの追加/変更」ウィンドウで、リソース・タイプを追加します。

OSLC プロバイダー・アプリケーションの「OSLC 相互作用の作成」ウィザードは、OSLC 選択相互作用を設計するための 3 つのステップを示します。このウィザードには、OSLC 作成相互作用に関する 1 つのステップと、OSLC クエリー相互作用に関する 2 つのステップがさらに追加されています。

例: OSLC 作成相互作用または選択相互作用の設計:

サービス要求アプリケーションのユーザーがプロバイダー・アプリケーションRational Team Concert で欠陥を作成できるように OSLC 相互作用を設計するとします。作成される欠陥は、サービス要求アプリケーションのサービス要求にリンクされます。

準備作業

OSLC プロバイダー・アプリケーションで、Rational Team Concert のプロバイダー・レコードを作成します。Rational Team Concert の OAuth エンドポイントおよびパブリック URI を指定し、サービス・プロバイダーを識別する方法を指定します。

「リソース・タイプの追加/変更」アクションを使用して、Rational Team Concert でサポートされているリソース・タイプ (複数可) を追加し、ユーザーがサービス要求アプリケーションからリンクできることを指定します。

相互作用の定義および使用 URI の選択: ステップ 1

「OSLC 相互作用の作成」アクションを選択します。

Rational Team Concert レコードの OSLC 相互作用の名前として「欠陥の作成」を指定します。「CREATIONDIALOG」を相互作用タイプとして選択します。

値一覧から、「変更要求」などのリソース・タイプを選択します。この一覧には、事前に作成したリソース・タイプ (1 つまたは複数) が取り込まれます。

Rational Team Concert ログイン・ページが表示されます。続行するには、Rational

Team Concert へのログインが必要です。

ログインすると、「使用 URI」の値一覧には、選択されたリソース・タイプのリソース使用タイプが Rational Team Concert から取り込まれます。欠陥使用タイプを選択します。オプションで、使用 URI を指定することができます。

サービス・プロバイダーおよび関連付けプロパティーの選択: ステップ 2

ステップ 2 では、相互作用に対してすべての Rational Team Concert サービス・プロバイダーを使用可能にするか、1 つのサービス・プロバイダーのみを使用可能に


するかを指定します。プロバイダー・アプリケーション (Rational Team Concert) からコンシューマー・アプリケーション (サービス要求) へのリンクを確立できるように、関連付けプロパティーを指定することもできます。

デフォルトの選択を使用して、すべてのサービス・プロバイダーを使用可能にします。サービス要求アプリケーションのユーザーがサービス要求アプリケーションで相互作用を開始するときに、選択したリソースと使用の組み合わせが複数のサービス・プロバイダーでサポートされている場合には選択ウィンドウが表示されます。例えば、選択ウィンドウには、欠陥をサポートする Rational Team Concert プロジェクトの一覧が表示される場合があります。ユーザーは、欠陥を作成するサービス・プロバイダーまたはコンテナーを選択できます。

もう 1 つの方法は、個々のサービス・プロバイダー URI を指定することです。この場合、サービス要求アプリケーションは、指定されたサービス・プロバイダーに直接接続します。

Rational Team Concert からサービス要求アプリケーションへのリンクを有効にするには、関連付けプロパティーを指定する必要があります。関連付けプロパティーは、Rational Team Concert リソースに結合しています。リソース・タイプに Shape

Document が関連付けられている場合、関連付けプロパティーとして選択できる値はShape Document から取得されます。リソース・タイプに関連付けられた Shape

Document がない場合は、関連付けプロパティーを指定できます。関連付けプロパティーは Rational Team Concert ユーザー・インターフェースに表示されます。このプロパティーには、サービス要求へのリンクが取り込まれています。Rational Team

Concert ユーザーは、このリンクをクリックしてサービス要求アプリケーションを開き、関連サービス要求を Rational Team Concert で確認することができます。

OSLC 相互作用のコンシューマー・アプリケーションの選択: ステップ 3

ステップ 3 では、プロバイダー・アプリケーション Rational Team Concert と相互作用するコンシューマー・アプリケーションを指定します。コンシューマー・アプリケーションはサービス要求アプリケーションです。

デフォルト設定では、コンシューマー・アプリケーションのユーザー・インターフェースの変更は、ウィザードによって自動的に生成されます。デフォルト設定のままにする場合は、相互作用テーブルおよびボタンを追加するアプリケーション・タブを指定する必要があります。

タブ、テーブル・ウィンドウ、およびボタンをサービス要求アプリケーションの「関連するレコード」タブに追加することを指定します。デフォルトで、プッシュボタン名は、相互作用に対して指定した名前「欠陥の作成」と同じになります。ボタンの名前を変更できます。

ボタンがユーザーに表示されるようにするには、相互作用の実行権限を持つセキュリティー・グループを指定する必要があります。権限を持つグループ内のユーザーにのみボタンが表示されるので、これらのユーザーだけが Rational Team Concert

で欠陥を作成することができます。

あるいは、「アプリケーションに相互作用タブ、テーブル、およびプッシュボタンを作成」チェック・ボックスをクリアし、アプリケーション・デザイナーを使用し


てサービス要求アプリケーションのすべてのユーザー・インターフェース変更を作成することができます。

相互作用フィールド・マッピングの指定: ステップ 4

ステップ 4 は相互作用の作成のみで使用できます。オプションで、コンシューマー・アプリケーションからプロバイダー・アプリケーションのターゲット・フィールドにデータをマップすることができます。ユーザーがボタンをクリックしてリソースを作成するときに、フィールドは、コンシューマー・アプリケーションに表示されるプロバイダー・ウィンドウにマップされます。例えば、サービス要求ユーザーに対して表示される Rational Team Concert の「リソースの作成」ウィンドウのフィールドに、サービス要求番号と説明が事前に入力されるようにします。相互作用の完了後でも、追加のフィールド・マッピングを指定したり、フィールド・マッピングを改訂したりできます。

リソースの Shape Document には、リンクをサポートする属性が指定されます。ご使用のアプリケーションから、リンクをサポートするターゲット・フィールドにマップするリンクが含まれているフィールドのみを選択します。マップしたデータが表示されるようにするため、ターゲット・フィールドがプロバイダー・アプリケーション・ウィンドウのユーザー・インターフェースに表示されるフィールドであることを確認してください。

Rational Team Concert ウィンドウの欠陥の説明にサービス要求の説明をマップするとします。ソース・マッピング式として :description を指定し、ターゲット・リソース・プロパティーとして「説明」を指定します。

複数の相互作用の作成

1 つのコンシューマー・アプリケーションに複数の相互作用を作成できます。例えば、サービス要求アプリケーションの選択相互作用も作成しなければならない場合があります。選択ウィンドウで、ユーザーはボタンをクリックすると、Rational

Team Concert の既存のリソース (欠陥など) を選択できます。同じアプリケーション・タブで同じリソース・タイプと使用の組み合わせに対して複数の相互作用を作成する場合は、プッシュボタンが同じタブおよびテーブル・ウィンドウに追加されます。

サービス要求アプリケーションの選択相互作用も設計する場合、ユーザーには以下のオプションがあります。

v 欠陥を作成し、その新規欠陥にサービス要求をリンクします。

v 既存の欠陥を選択し、その欠陥にサービス要求をリンクします。

サポートされるリソース・タイプまたは使用タイプ (タスクなど) に対して、追加の作成相互作用を設計する場合もあります。リソース・タイプと使用の組み合わせが異なると、追加の相互作用ボタンに対して別個のタブおよびテーブル・ウィンドウが生成されます。

コンシューマー・アプリケーションでの新規相互作用の確認

相互作用の完了後に、再びログインする必要があります。新規ログインにより、ステップ 3 で指定した最新のセキュリティー・アクセスが付与されます。ログインし


た後、サービス要求アプリケーションにナビゲートして、ユーザー・インターフェースの変更を確認します。随時、アプリケーション・デザイナー・アプリケーションを使用して、サービス要求アプリケーションで自動生成されたユーザー・インターフェースの変更を改良または追加できます。

ボタン (複数可) をテストして、サービス要求アプリケーションで Rational Team

Concert ウィンドウが期待どおりに表示されるかを確認することができます。ウィンドウが表示されない場合や、予期しないフィールドにデータが表示される場合は、誤ったデータ・マッピングが原因である可能性があります。OSLC プロバイダー・レコードのマッピング・テーブルで相互作用のデータ・マッピングを確認し改訂することができます。

サービス要求アプリケーションのユーザーに、Rational Team Concertにリンクするために新しく追加されたボタンが表示されない場合、ユーザーが再度ログインしたことと、権限を持つセキュリティー・グループに属していることを確認してください。また、これらのユーザーが有効な Rational Team Concert ログイン資格情報を持っていることも確認します。

OSLC 作成相互作用または選択相互作用の変更

OSLC 相互作用の設計が完了した後に、その相互作用に対して行える変更は限られています。関連付けプロパティーの更新、およびフィールド・マッピングの改訂が可能です。

新しい関連付けプロパティーを指定すると、プロバイダー・アプリケーションからコンシューマー・アプリケーションへのリンクを提供する新規プロパティー名が設定されます。

相互作用マッピング・テーブルでは、既存のマッピングの改訂、マッピングの削除、マッピングの追加を行うことができます。リソースの Shape Document には、リンクをサポートする属性が指定されます。コンシューマー・アプリケーションから、リンクをサポートするターゲット・フィールドにマップするリンクが含まれているフィールドのみを選択します。マップしたデータが表示されるようにするため、ターゲット・フィールドがプロバイダー・アプリケーション・ウィンドウのユーザー・インターフェースに表示されるフィールドであることを確認してください。

Java クラスをマッピング・ロジックの一部として使用するために指定することもできます。提供するフィールド・マッピング定義が十分でない場合は、Java クラスを使用できます。「相互作用マッピング・クラス」フィールドに Java クラスを指定してください。フィールド・マッピングが存在するかどうかにかかわらず、マッピング・クラスを提供できます。

OSLC 作成相互作用または選択相互作用の削除

相互作用の削除は、その相互作用を参照するコンシューマー・アプリケーション内に既存のリンクがない場合に限り実行可能です。OSLC プロバイダー・レコードから相互作用を削除する前に、すべての関連アプリケーション・リンクを削除する必要があります。


相互作用を削除すると、その相互作用の設計時に行われた、対応するユーザー・インターフェース変更が更新されます。相互作用のボタンはアプリケーションから削除されます。このボタンが存在していたウィザード作成のタブおよびテーブル・ウィンドウに他の相互作用のボタンが含まれていない場合に限り、それらのテーブル・ウィンドウとタブも削除されます。相互作用に対して作成された関係および署名オプションも削除されます。

相互作用のユーザー・インターフェースの変更を手動で構成した場合、それらの変更を削除するにはアプリケーション・デザイナーを使用する必要があります。

孤立リンク

コンシューマー・アプリケーションのオブジェクト・レコードとプロバイダー・アプリケーション・リソースの間に生成されたリンクは、OSLCLINK データベース表に保管されます。

リンクを持つオブジェクト・レコードを削除した場合、OSLCLINK 表には、削除されたオブジェクト・レコードに関連付けられている 1 つ以上の孤立リンクが含まれます。

OSLCDeleteLinks クーロン・タスクは孤立リンクを削除します。デフォルトでは、OSLCDeleteLinks クーロン・タスクを 1 日 1 回実行するように設定されています。「クーロン・タスクのセットアップ」アプリケーションでクーロン・タスクを表示および編集できます。

例: OSLC クエリー相互作用の設計:

資産アプリケーションのユーザーが IBM Tivoli Application Dependency Discovery

Manager などのプロバイダーのリソース・データをクエリーおよび取得できるように、OSLC 相互作用を設計するとします。

準備作業

OSLC プロバイダー・アプリケーションでは、リソース・レジストリーがクエリー相互作用のデフォルトのプロバイダーです。デフォルト設定の一部としてPROVIDERREGISTRY エンドポイントが指定されていますが、エンドポイントのプロパティーを構成して、リソース・レジストリーのパブリック URI を指定する必要があります。また、サービス・プロバイダーの識別方法を指定する必要もあります。

「リソース・タイプの追加/変更」アクションを使用して、リソース・レジストリーでサポートされているリソース・タイプ (複数可) を追加し、追加したリソース・タイプに Shape Document (使用可能な場合) を関連付けます。また、ユーザーが資産アプリケーションからリソース・レジストリーにリンクできるように指定できます。

相互作用の定義および使用 URI の選択: ステップ 1

「OSLC 相互作用の作成」アクションを選択します。

OSLC 相互作用の名前として「コンピューター」を指定し、相互作用タイプとして「QUERYCAPABILITY」を選択します。


値一覧から、「COMPUTERSY」などのリソース・タイプを選択します。この一覧には、事前に作成したリソース・タイプ (1 つまたは複数) が取り込まれます。

オプションで、使用 URI を指定することができます。「使用 URI」の値一覧には、選択されたリソース・タイプのリソース使用タイプ (1 つまたは複数) がリソース・レジストリーから取り込まれます。使用 URI を指定しない場合は、該当のリソース・タイプのデフォルトの使用タイプが使用されます。

サービス・プロバイダーおよびリンク・プロパティーの選択: ステップ 2

ステップ 2 では、相互作用に対してすべてのサービス・プロバイダーを使用可能にするか、1 つのサービス・プロバイダーのみを使用可能にするかを指定します。プロバイダー・アプリケーション (リソース・レジストリー) からコンシューマー・アプリケーション (資産) へのリンクを確立できるように、リンク・プロパティーおよびリンク・ラベルを識別することもできます。

デフォルトの選択を使用して、リソース・レジストリー・サービス・プロバイダーのみを使用可能にします。資産アプリケーションのユーザーがクエリーを実行して相互作用を開始するときに、選択したリソースと使用の組み合わせが複数のサービス・プロバイダーでサポートされている場合には選択ウィンドウが表示されます。例えば、選択ウィンドウには、指定されたリソースのデータを含んでいるサービス・プロバイダーの一覧が表示される場合があります。ユーザーは、クエリーのベースとなるサービス・プロバイダーを選択することができます。

もう 1 つの方法は、個々のサービス・プロバイダー URI を指定することです。クエリーは、指定されたサービス・プロバイダーに基づいて実行されます。リンク・プロパティーは、プロバイダーのリソース・レジストリーからリソース・データを取得するために使用されます。リンクおよびリンク・ラベルは、クエリー結果が提供されるときに、コンシューマー・アプリケーションのユーザーに表示されます。

リソース・レジストリーから資産アプリケーションへのリンクを有効にするには、プロバイダー・アプリケーションがリンク・プロパティーの使用をサポートしていなければなりません。リンク・プロパティーは、リソース・レジストリーのリソースに結合しています。リソース・タイプに Shape Document が関連付けられている場合、リンク・プロパティーとして選択できる値は Shape Document から取得されます。リソース・タイプに関連付けられた Shape Document がない場合は、リンク・プロパティーおよびリンク・ラベルを指定できます。

OSLC 相互作用のコンシューマー・アプリケーションの選択: ステップ 3

ステップ 3 では、プロバイダー・アプリケーション (リソース・レジストリー) と相互作用する製品アプリケーションを指定します。コンシューマー・アプリケーションは製品のどのアプリケーションでも構いませんが、この例では資産アプリケーションを使用します。

デフォルト設定では、指定されたアプリケーションに自動的にプッシュボタンが生成されます。デフォルト設定のままにする場合は、クエリー相互作用をサポートするための相互作用ボタンを追加するアプリケーション・タブを指定する必要があります。


資産アプリケーションの「メイン」タブにボタンを追加するように指定します。デフォルトで、プッシュボタン・ラベルは、相互作用に対して指定した名前「コンピューター」と同じになります。ボタン・ラベルは変更できます。

ボタンがユーザーに表示されるようにするには、相互作用の実行権限を持つセキュリティー・グループを指定する必要があります。権限を持つグループ内のユーザーにのみボタンが表示されるので、これらのユーザーだけがクエリーを実行してリソース・データを取得することができます。

クエリーおよびクエリー・パラメーターの指定: ステップ 4

ステップ 4 では、相互作用としてクエリーを作成します。これらのクエリーが、リソース・レジストリーのリソース・データをクエリーするために使用されます。Select 文節は、リソースから選択する属性を識別します。すべての値を取得するには、アスタリスク (*) を指定できます。あるいは、Shape Document からのリソース属性のコンマ区切りリストを指定して、取得する値のリストをフィルタリングすることもできます。

クエリーの WHERE 条件を定義するには、以下のいずれかの方法を使用できます。

v WHERE 条件を定義する Java クラスを実装します。

v WHERE 条件に値を取り込みます。

v パラメーター値を使用して WHERE 条件を構成します。パラメーター値はアプリケーションのメイン・オブジェクトから選択され、プロバイダー・アプリケーションのリソース・データの属性に対して比較されます。

クエリーは、クエリー・テーブルに指定された順序で実行されます。最初の条件が満たされない場合、クエリー条件が満たされるまで、以降のすべてのクエリーが順に処理されます。条件が満たされると、そのリソース・データが取得され、コンシューマー・アプリケーションのユーザーに返されます。クエリーの応答で返すデータを順序付ける orderby クエリー・パラメーターを識別することもできます。

相互作用の設計中に作成されるクエリーは検証されません。したがって、実行時にメッセージを生成するクエリーを作成する可能性があります。例えば、以下のクエリー条件を作成するとします。Query Query Type Property Operand Mapped Expression Is Literal?10 Parameter http://open-services.net/ns/crtv#%7Dmanufacturer IN IBM, Dell Checked

しかし、このクエリーは "IBM","Dell" という 2 つの属性ではなく、"IBM, Dell"

という 1 つの属性を検索しているため、実行時にエラーが生成されます。次の例は、属性の正しい形式を示しています。Query Query Type Property Operand Mapped Expression Is Literal?10 Parameter http://open-services.net/ns/crtv#%7Dmanufacturer IN "IBM","Dell" Checked

相互作用グループの指定: ステップ 5

ステップ 5 では、オプションとして、クエリー相互作用を相互作用グループに追加し、グループの条件 (存在しない場合) を指定できます。

相互作用グループを使用すると、複数の関連するクエリーをまとめて 1 つのユーザー・インターフェース・コントロールの下にグループ化することができます。相互


作用グループを指定することにより、ユーザーは、そのグループ内の相互作用に関連付けられた条件に基づき、さまざまなプロバイダーに対して複数の相互作用を実行できます。

グループ内のすべての相互作用は、同じメイン・オブジェクトおよびリソース・タイプに基づきます。クエリー相互作用を相互作用グループに追加する場合、その相互作用はグループの一部としてのみ実行されます。クエリー相互作用は独立して実行されません。グループ内の相互作用の順序によって、その相互作用グループでのクエリーの実行順序が決まります。

CICOMPUTERSY 相互作用グループと XYZ 条件を指定します。相互作用グループを作成済みの場合、「相互作用グループの追加/変更」アクションを使用して、その相互作用グループの追加詳細を指定できます。資産アプリケーションで、ユーザーがボタンをクリックしてクエリーを実行し、条件が満たされると、クエリー結果が「プレビュー」ウィンドウに表示されます。

コンシューマー・アプリケーションでの新規相互作用の確認

クエリー相互作用を作成した後、再びログインする必要があります。新規ログインにより、ステップ 3 で指定した最新のセキュリティー・アクセスが付与されます。ログインした後、資産アプリケーションにナビゲートして、ユーザー・インターフェースの変更を確認することができます。

ボタンをテストして、そのボタンが期待どおりに資産アプリケーションに表示されるかを確認できます。クエリーを実行し、クエリーが有効であること、およびリソース・データが返されることを確認できます。結果が返されない場合、クエリー・パラメーターが誤っている可能性があります。OSLC プロバイダー・アプリケーションでクエリー・パラメーターを確認し、必要に応じて更新します。

ユーザーが再びログインした後で、新しく追加されたボタンが表示されない場合は、そのユーザーが権限を持つセキュリティー・グループに属していることを確認してください。

OSLC 相互作用の変更

OSLC クエリー相互作用の設計が完了した後に、その相互作用に対して行える変更は限られています。リンク・プロパティーの更新、クエリー・パラメーターの更新、およびフィールド・マッピングの改訂が可能です。

新しいリンク・プロパティーを指定すると、プロバイダー・アプリケーションからコンシューマー・アプリケーションへのリンクを提供する新規プロパティー名が設定されます。

クエリー・マッピング・テーブルでは、既存のマッピングの改訂、マッピングの削除、マッピングの追加を行うことができます。リソースの Shape Document には、リンクをサポートする属性が指定されます。コンシューマー・アプリケーションから、リンクをサポートするターゲット・フィールドにマップするリンクが含まれているフィールドのみを選択します。マップしたデータが表示されるようにするため、ターゲット・フィールドがプロバイダー・アプリケーション・ウィンドウのユーザー・インターフェースに表示されるフィールドであることを確認してください。


Java クラスをマッピング・ロジックの一部として使用するために指定することもできます。提供するフィールド・マッピング定義が十分でない場合は、Java クラスを使用できます。「クエリー・マッピング・クラス」フィールドに Java クラスを指定してください。フィールド・マッピングが存在するかどうかにかかわらず、マッピング・クラスを提供できます。

クエリー相互作用の Select 文節は、相互作用の作成後に更新できます。

OSLC クエリー相互作用の削除

クエリー相互作用の削除は、その相互作用が相互作用グループに結合されていない場合に限り可能です。相互作用を削除するには、その前に、相互作用をグループから除去する必要があります。

相互作用を削除すると、その相互作用の設計時に行われた、対応するユーザー・インターフェース変更が更新されます。相互作用のボタンはアプリケーションから削除されます。相互作用に対して作成された関係および署名オプションも削除されます。

相互作用グループの作成相互作用グループを使用して、複数のクエリー相互作用を単一のユーザー・インターフェース・コントロール (例えば、ボタン) で照合することができます。これらのクエリー相互作用は、単一のプロバイダーを対象としたものでも、複数のプロバイダーを対象としたものでも構いません。

始める前に

相互作用グループを作成するには、1 つ以上のクエリー相互作用を作成する必要があります。


グループ内の各クエリー相互作用が実行され、その条件に基づいてユーザーにデータが返されます。クエリー相互作用に、現在のアプリケーション・データに基づく条件が含まれる場合、相互作用グループではそのデータを使用して、該当するクエリーだけを実行します。複数のクエリーによるクエリー結果が結合されて、結果のビューに表示されます。

OSLC 相互作用を作成するには、基本言語を使用している必要があります。クエリー相互作用ウィザードで相互作用グループを作成することもできます。

手順1. OSLC プロバイダー・アプリケーションで、「相互作用グループの追加/変更」アクションを選択します。

2. 新規行を追加して、相互作用グループの名前と、そのグループに関連付けるメイン・オブジェクトを指定します。

3. オプション: 相互作用グループを複数のプロバイダーに関連付ける場合は、「複数プロバイダーの結合ビューのサポート」チェック・ボックスを選択します。


4. 「相互作用」タブで、グループの一部として実行する、少なくとも 1 つの相互作用を選択します。選択可能な相互作用は、相互作用グループに対して指定されているメイン・オブジェクトに基づきます。

5. 「アプリケーション」タブで、相互作用グループの追加先とするアプリケーションを追加します。

6. オプション: 相互作用グループのメイン・オブジェクトが、指定されたアプリケーションのメイン・オブジェクトではない場合は、関係を指定する必要があります。相互作用グループに対して指定したメイン・オブジェクトとアプリケーションとの間に関係が存在しない場合は、データベース構成アプリケーションの「関係」タブで関係を作成または変更する必要があります。

7. コンシューマー・アプリケーションの相互作用を使用可能にする場所に応じて、ボタンのラベル、詳細メニュー項目のラベル、またはその両方を指定します。

8. 「セキュリティー・グループ」タブで、アプリケーションおよび相互作用グループに適用するセキュリティー・グループを選択します。

9. 相互作用グループを詳細メニュー項目に追加するには、「アプリケーション・メニュー」タブを選択し、そのグループを追加するコンシューマー・アプリケーション内のロケーションを指定し、「OK」をクリックしてグループを保存します。コンシューマー・アプリケーションの既存のフィールドが、「詳細メニューの選択」ダイアログ・ボックスに表示されます。

例: OSLC 相互作用の実行アプリケーション・ユーザーは、統合設計者が統合したアプリケーション間のOSLC 相互作用を実行できます。コンシューマー・アプリケーションのボタンをクリックすることにより、OSLC 相互作用を開始します。相互作用のタイプに応じて、外部プロバイダー・アプリケーションにリソース・レコードを作成したり、プロバイダー・アプリケーションの既存のリソースにリンクしたりできます。

この例では、ご使用のアプリケーションはコンシューマーで、Rational Team

Concert はプロバイダーです。ただし、このプロセスはどの OSLC プロバイダーでも機能します。

サービス要求アプリケーションを使用して、チームが開発しているソフトウェアに対する修正の要求を入力します。統合設計者は OSLC プロバイダー・アプリケーションを使用して、サービス要求アプリケーションと Rational Team Concert アプリケーションを統合しました。 2 つの OSLC 相互作用が作成されました。サービス要求アプリケーションには、現在、「関連するレコード」タブに「欠陥」というラベルのタブがあります。このタブには「欠陥」ウィンドウがあり、ウィンドウには「欠陥の作成」および「欠陥の選択」という 2 つのプッシュボタンがあります。

これで、サービス要求アプリケーションから離れることなく、サービス要求を入力し、同時に、関連する欠陥を Rational Team Concert に作成できるようになります。あるいは、「欠陥の選択」ボタンを使用して、Rational Team Concert の既存のリソースに要求を関連付けることもできます。


欠陥の作成

サービス要求アプリケーションで、サービス要求を作成し、説明やその他の情報を入力して、要求を保存します。「関連するレコード」タブを開き、「欠陥」タブの「欠陥の作成」ボタンをクリックします。

外部アプリケーション Rational Team Concert でリソース・レコードを作成しているため、Rational Team Concert にサインインする必要があります。 Rational Team

Concert のログイン・ウィンドウが表示されます。ユーザー ID とパスワードを入力すると、「リソースの作成」ウィンドウが表示されます。「リソースの作成」ウィンドウは Rational Team Concert のウィンドウですが、OSLC 統合の結果として、サービス要求アプリケーション内で使用できるようになりました。

作成するリソースのタイプとして、欠陥を指定します。さらに、「要約」フィールドに情報を入力し、欠陥が提出されるプロジェクトまたはコンテナーを指定する必要があります。

この相互作用を作成するときに、統合設計者は「サービス要求の説明」フィールドを Rational Team Concert の説明プロパティーにマップしました。結果として、サービス要求の説明は「リソースの作成」ウィンドウの「説明」フィールド内に存在します。説明は必要に応じて編集できます。

プロバイダー・アプリケーション・リソース・レコード・データのプレビュー

Rational Team Concert でレコードを作成すると、サービス要求アプリケーションの欠陥テーブルにも行が作成されます。「説明」フィールドには、Rational Team

Concert 内のリンク先リソースに関する情報が含まれています。このテーブル行には、リンク先リソース・レコードの URL も示されます。

「説明」フィールドには、小さな青い円の中に「i」と書かれた情報アイコンがあります。情報アイコンの上にカーソルを移動させると、Rational Team Concert の欠陥レコードからのデータを示すウィンドウが表示されます。 (プロバイダー・アプリケーションにサインインしていない場合は、情報アイコン上にカーソルを移動させると、メッセージと、サインインするためのリンクが表示されます。プロバイダー・アプリケーションが OSLC プレビューをサポートしていない場合、2 番目のアイコンが表示されます。このアイコンをクリックして、プレビューを表示することができます。)

プレビュー・ウィンドウを使用すると、Rational Team Concert 欠陥レコードに関するステータスやその他の情報をサービス要求アプリケーション内から確認できます。

欠陥の選択

サービス要求アプリケーションで、2 番目のサービス要求を入力します。この要求は、以前に報告された問題の事例を修正することであり、この問題についてはRational Team Concert に欠陥が存在します。 2 番目の要求に対して、欠陥レコードを作成するのではなく、既存の欠陥にリンクします。「関連するレコード」タブの欠陥テーブルで、「欠陥の選択」をクリックします。


プロバイダー・アプリケーションが複数のコンテナーをサポートする場合は、欠陥の Rational Team Concert プロジェクトなどのコンテナーを選択しなければならない可能性があります。

「リソースの選択」ウィンドウで、選択するリソースのタイプとして「欠陥」を指定します。欠陥番号や説明などの検索情報を指定すると、検索基準に一致する欠陥が表示されます。欠陥を選択して「OK」をクリックすると、Rational Team Concert

欠陥リソースへのリンクが確立されます。サービス要求アプリケーションの欠陥テーブルに、この欠陥の行が追加されます。欠陥を作成して追加された行の場合と同じように、情報アイコンを使用して欠陥情報を表示することができます。

パブリック URI の変更OSLC プロバイダー・アプリケーションが別のサーバーに移動する場合や、別の理由でそのパブリック URI が変更される場合は、OSLC プロバイダー・レコードのパブリック URI を変更できます。パブリック URI を更新すると、パブリック URI

に基づく URI も変更されるので、リンクは切断されません。

OSLC プロバイダー・アプリケーションで、パブリック URI の変更アクションを使用して、OSLC プロバイダーの新しいパブリック URI を指定します。パブリックURI を変更すると、パブリック URI に基づく URI (サービス・プロバイダー URI

やリソース URI など) も変更されます。新しいパブリック URI に適合するようにリンクを更新することで、リンクはアクティブな実行可能リンクとして存続します。

OSLC 統合のマイグレーション製品のインスタンス間で、OSLC プロバイダー定義とその関連相互作用をマイグレーションできます。例えば、開発環境またはテスト環境で OSLC 統合をセットアップする場合があります。統合が正しく機能していることを確認した後で、それを実稼働環境にマイグレーションできます。

OSLC 統合のマイグレーションは、既存のマイグレーション・マネージャー・アプリケーション機能を使用して、主にマイグレーション・マネージャー・アプリケーションで行われます。OSLC プロバイダー・アプリケーションには、マイグレーションされるパッケージを生成するためのアクションがあります。

OSLC プロバイダーのマイグレーション・アクションを実行する前に、マイグレーション・マネージャー・アプリケーションで準備作業を行います。OSLCPROVIDER

パッケージ定義は、マイグレーション・マネージャー・アプリケーションで提供されます。OSLCPROVIDER パッケージ定義に対して、OSLC プロバイダー・アプリケーションで生成するパッケージのターゲット・データベースまたはファイル宛先を指定します。

OSLC プロバイダー・アプリケーションの OSLC プロバイダーのマイグレーション・アクションを使用してパッケージを生成し、それをマイグレーション・マネージャー・アプリケーションで管理します。このパッケージには、統合コンシューマー・アプリケーション (1 つまたは複数) の OSLC プロバイダー・レコード、関連相互作用、および関連ユーザー・インターフェース変更が含まれています。

OSLC プロバイダーのマイグレーション・アクションの実行後に、システム・メッセージが表示されます。ログ・メッセージの最終行に、パッケージの名前が示され


ます。このパッケージは、ソース環境のマイグレーション・マネージャー・アプリケーションにおける OSLCPROVIDER パッケージ定義の「パッケージ」タブにリストされます。

ターゲット環境で、マイグレーション・マネージャー・アプリケーションを使用して、パッケージをインポートしデプロイします。

OSLC 統合でカスタム Java マッピング・ファイルを使用する場合、カスタム Java

マッピング・ファイルはパッケージに含まれません。カスタム・マッピング・ファイルおよび対応するクラス・ファイルをターゲット環境に手動で移動するか、それらをパッケージに手動で追加する必要があります。

OSLC プロバイダーのマイグレーション・アクションでは、現在の OSLC プロバイダー・レコードについてのみパッケージが生成されます。複数の OSLC プロバイダー・レコードがある場合は、それぞれを個別にマイグレーションする必要があります。

マイグレーション・マネージャーは、相互作用グループのマイグレーションをサポートしていません。相互作用グループに含まれるオブジェクトをマイグレーションするには、以下のオブジェクトを使用する新規オブジェクト構造を作成します。

OSLCINTGROUPOSLCGRPAPPSOSLCGRPAPPMENUOSLCGRPMEMBERS

この新規オブジェクト構造を OSLCPROVIDER マイグレーション・パッケージに含める必要があります。

手動による UI 変更アプリケーション間の OSLC 相互作用の設計では、コンシューマー・アプリケーションの複数のユーザー・インターフェース (UI) を変更する必要があります。いくつかのシナリオでは、アプリケーション・デザイナー・アプリケーションを使用して、統合の一部としての UI 変更を追加または改良することになる可能性があります。

UI 変更の手動実装および相互作用のセキュリティー:

ウィザードによるコンシューマー・アプリケーションのユーザー・インターフェース (UI) 変更の自動生成を行わないことにした場合は、UI を自分で変更する必要があります。ユーザー・インターフェースでは、プッシュボタンを通してユーザーが相互作用を使用できるようにしなければなりません。ウィザードでセキュリティー・グループを選択しない場合は、相互作用にアクセスできるセキュリティー・グループを指定してください。

ユーザー・インターフェースの変更を自動生成しない場合でも、OSLC 相互作用を作成すると、リンク関係およびプッシュボタン署名オプションが作成されます。リンク関係名は、指定されたリソース・タイプまたは使用に基づいています。署名オプション名は、相互作用名に基づいています。関係名および署名オプション名は、「OSLC プロバイダー」タブの相互作用の詳細にリストされます。UI 変更を手動で実装する場合は、これらの 2 つの値が必要です。


アプリケーション・デザイナー・アプリケーションを使用して、コンシューマー・アプリケーションのユーザー・インターフェースを変更します。OSLC 相互作用を実行してリンクを作成できるようにプッシュボタンを作成する必要があります。さらに、プロバイダー・アプリケーションのリソースへのリンクが格納されたテーブルを表示するタブも用意する必要があります。一般に、このボタンとリンク・テーブルは同じタブに配置します。

セキュリティー・グループ・アプリケーションを使用して、プッシュボタンにアクセスできるグループを指定します。権限を持つグループ内のユーザーにのみボタンが表示されるので、これらのユーザーだけがボタンを使用してプロバイダー・アプリケーション・ウィンドウを表示し、相互作用を実行することができます。

ユーザー・インターフェースの改良:

コンシューマー・アプリケーションのユーザー・インターフェース (UI) 変更を自動生成するときでも、その UI に対して改良または追加を行った方がよい場合があります。

ユーザー・インターフェース変更を自動生成する OSLC 相互作用を設計した後に、アプリケーション UI を確認すると、改訂が必要であることが判明する場合があります。例えば、新しいタブ、テーブル・ウィンドウ、またはプッシュボタンのラベルを編集したい場合があります。あるいは、UI 要素の位置を調整したい場合もあります。アプリケーション・デザイナー・アプリケーションを使用して、UI 要素を変更または追加します。

相互作用の設計時に、相互作用に対してすべてのサービス・プロバイダーがコンシューマー・アプリケーションで使用可能であることを指定できます。そのような場合は、相互作用が開始されると、コンテナーの選択ウィンドウが表示されます。このウィンドウは、相互作用で使用するサービス・プロバイダーまたはコンテナーを指定するために使用されます。コンテナーの選択ウィンドウにヘルプ・グリッド・テキストを設定した方がよい場合もあります。例えば、選択項目が表しているものがプロジェクトか、データベースか、あるいは他のリソース・コンテナーかを示すためにヘルプ・グリッド・テキストを追加します。ウィンドウ・タイトルのラベルを変更して、ユーザーが選択するべきものを明確にすることもできます。

変換されていない UI 要素の変換:

相互作用の設計によって追加された、アイコンのツールチップなど、一部のユーザー・インターフェース (UI) 要素を変更および変換するには、アプリケーション・デザイナー・アプリケーションを使用します。

相互作用は基本言語で作成する必要があるため、OSLC 相互作用の設計によって追加された一部のユーザー・インターフェース要素は、インターフェースに応じた言語では表示されません。要素の追加は、元の UI 要素が変換されてから、アプリケーションがデプロイメントされるまでの間に行われます。UI 要素をアプリケーション UI の言語に変換するには、アプリケーション・デザイナー・アプリケーションを使用して、変換されていないテキスト要素を変更します。


OSLCのプロパティーシステム・プロパティーを使用して、Open Services for Lifecycle Collaboration

(OSLC) アプリケーション統合の管理に役立てることができます。

表 42. OSLCのプロパティープロパティー説明デフォルト値

mxe.oslc.collectioncount OSLC コレクションの合計カウントを表します。 0

mxe.oslc.defaultep デフォルトの OSLC エンドポイントを表します。 OSLCDEFAULT

mxe.oslc.defaultformat OSLC のデフォルトのフォーマットを表します。 oslcjson

mxe.oslc.dfltconsumerversion コンシューマーが使用するデフォルトの OSLC バージョンを表します。

2.0

mxe.oslc.dfltversion OSLC プロバイダーのデフォルトの OSLC バージョンを表します。

2.0

mxe.oslc.enableprovider OSLC プロバイダーを使用可能にします。 1

mxe.oslc.idleexpiry システムのアイドル状態が許容される時間 (秒数)

を表します。この時間を過ぎると、セッションの有効期限が切れます。

300


mxe.oslc.preferproviderdesc リソース・レジストリー調整 URI で OSLC プロバイダーの説明を優先するかどうかを指定します。

true

mxe.oslc.prettyjson 読みやすく整えられた JSON を表します。 1

mxe.oslc.prettyrdf 読みやすく整えられた RDF を表します。 1

mxe.oslc.prqueryep プロバイダー・レジストリー・クエリー・エンドポイントを表します。

PROVIDERREGISTRY

mxe.oslc.webappurl プロバイダーのパブリック URI を表します。 http://localhost/maximo/oslc/

統合クエリー統合フレームワークは、外部システムからのクエリーをサポートします。外部システムは統合フレームワークへのクエリーを実行するために XML メッセージを送信し、統合フレームワークはクエリーに対する応答として XML メッセージを返します。オブジェクト構造およびエンタープライズ・サービスのクエリーを実行するには、Web サービスで HTTP、Java™ Remote Method Invocation (RMI)、またはSimple Object Access Protocol (SOAP) 要求を使用します。

XML クエリーのサポートは、ほとんどのアプリケーションの「一覧」タブから使用できるシステムの例示クエリー・プログラム (QBE) 機能に基づいています。XML

ベースのクエリーでは、一部のシステム・アプリケーションで利用できる属性検索に対するサポートを除き、アプリケーションで提供されているものと同じクエリー・サポートが提供されます。統合クエリーのタイムアウトは、mxe.db.Query.Timeout システム・プロパティーで制御されます。

関連概念:



クエリー・サービスオブジェクト構造サービスとエンタープライズ・サービスではクエリー操作がサポートされます。外部ソースはサービスを使用してクエリーを実行し、システムからデータを取得します。どちらの場合も、クエリーの要求とクエリーの応答の XML

内容はオブジェクト構造スキーマによって定義されます。

レベル数が 2 つより多いビジネス・オブジェクトを持つオブジェクト構造の場合、クエリー・フレームワークは要求の XML の上位 2 つのレベルでのビジネス・オブジェクト属性の使用に対応しています。クエリー応答の XML には、オブジェクト構造内のすべてのオブジェクトが含まれます。

「使用者」値が INTEGRATION であるすべてのシステム提供オブジェクト構造では、デフォルトでクエリー操作がサポートされます。オブジェクト構造を構成して、クエリー操作のみをサポートし、オブジェクトの更新をサポートするその他の操作はサポートしないようにすることができます。クエリー操作をサポートするための追加のオブジェクト構造を作成する場合は、「オブジェクト構造」アプリケーションを使用することができます。

エンタープライズ・サービス・クエリーの作成外部ソースは、エンタープライズ・サービスを使用してクエリーを実行し、システムからデータを取得できます。


サンプルのエンタープライズ・サービス・クエリー MXINVBALQInterface が提供されています。このサンプルを、エンタープライズ・サービス・クエリーの作成時に参照データとして使用できます。

手順1. クエリーのアクセス対象となっているオブジェクトを含むオブジェクト構造がない場合は、作成してください。

2. クエリーに使用するオブジェクト構造を実装するエンタープライズ・サービスを定義します。

3. クエリーをエンタープライズ・サービス上で操作として指定します。

4. エンタープライズ・サービスを外部システムと関連付けて、外部システムとそのエンタープライズ・サービスを使用可能にします。

Web サービスのクエリーエンタープライズ・サービス・アプリケーションおよびオブジェクト構造アプリケーションで作成されるクエリー・サービスは、Web サービスとしてデプロイできます。クエリーをサポートするには、エンタープライズ Web サービスを構成してJMS キューをバイパスする必要があります。

Web サービスで実行されるクエリーに対する正常な応答では、クエリー結果セットが返されます。結果セットが空の場合 (レコードが含まれない場合)、SOAP 本体で返される XML には次のような空の MXPERSONSet タグが含まれます。


<max:QueryMXPERSONResponse xmlns:max="http://www.ibm.com/maximo"creationDateTime="2011-04-28T21:49:45"baseLanguage="EN" transLanguage="EN" messageID="12345"maximoVersion="7.5" rsStart="1" rsCount="10" rsTotal="10"></max:MXPERSONSet>

</max:QueryMXPERSONResponse>

エラーが発生した場合、応答コード 500 が、SOAP 障害を詳述するエラー・メッセージと共に返されます。

クエリー Web サービスでは次の URL を使用します。


v host:port/meaweb は、統合 Web アプリケーションの URL プロパティーの値です。

v web service name は、Web サービスの名前です。

エンタープライズおよびオブジェクト構造のクエリー・サービスは、Web サービス・ライブラリー・アプリケーションを使用して Web サービスとしてデプロイします。

XML 構造のクエリークエリーのルート要素の名前は、操作 (クエリー) と関連のオブジェクト構造の名前を連結したものです。例えば、QueryMXPERSON です。この MXPERSON がオブジェクト構造です。

ルート要素

クエリーのルート要素の名前は、操作とオブジェクト構造の名前を連結したものです。例えば QueryMXPERSON という名前の場合、MXPERSON はオブジェクト構造です。次の表に、クエリーのルート要素、クエリーへの応答、またはこの両方に具体的に適用できる属性をリストします。この表のすべての属性はオプションです。

属性説明タイプ適用先

uniqueResult クエリーが応答で 1 つのレコードまたは複数のレコードのどちらを予期するかを指定します。

値 0 (デフォルト): クエリーは複数のレコードを返すことができます。

値 1: クエリーは単一のレコードを返すことができます。それ以外の場合、エラーが発生します。

ブール型クエリー

maxItems クエリーが複数のレコードを返すことができる場合、この属性は、一度に返されるレコード数を制限します。

この属性が指定されていない場合、応答には結果セット全体が含まれます。

PositiveInteger クエリー



rsStart クエリー要求の中で、次のようにします。

maxItems と一緒に使用して、応答で返される最初のレコードを指定します。

maxItems が 10 であり、rsStart が指定されていない場合、応答では結果 0 から 9 が返されます。結果 10

から 19 を受け取るには、rsStart=10

を指定してクエリーを再送信します。

rsStart が指定されていない場合、応答は結果セットの最初のレコードから開始します。クエリーの結果セットのレコード数が rsStart の値より少ない場合、応答ではレコードは返されません。

整数型クエリー

rsStart クエリー応答の中で、次のようにします。

この値は、対応する要求の rsStart

値と一致します。

対応する要求に maxItems 値が含まれる場合、追加レコードの要求の中の rsStart 値は rsStart + rsCount + 1

です。

この属性が指定されていない場合、応答は結果セットの最初のレコードから開始し、rsCount 属性によって指定されたレコード数を含みます。

整数型応答

rsCount メッセージで返されるレコード数。

rsCount は、応答処理層の一部としてスキップされる行を反映しません。

整数型応答

rsTotal 結果セットの合計レコード数。

クエリーが maxItems 値を指定しない場合、rsTotal 値は rsCount 値と同じです。

整数型応答 (出力)

例えば、rstart 値を 11 に設定し、maxItems 値を 10 に設定すると、このクエリー要求に対する応答で、クエリー結果セットのレコード 11 から 20 が返されます。


<max:QueryMXINVBAL xmlns:max="http://www.ibm.com/maximo"creationDateTime="2011-049-28T21:49:45"baseLanguage="EN" transLanguage="EN" messageID="12345"maximoVersion="7.5" uniqueResult="0" maxItems="10" rsStart="11"><max:MXINVBALQuery orderby="string" operandMode="OR">

次のクエリー結果セットには rsTotal に示されるように合計 35 行が含まれていますが、行 11 から 20 のみが返されます。

<max:QueryMXINVBALResponse xmlns:max="http://www.ibm.com/maximo"creationDateTime="2011-04-28T21:49:45"baseLanguage="EN" transLanguage="EN" messageID="12345"maximoVersion="7.5" rsStart="11" rsCount="10" rsTotal="35"><max:MXINVBALSet>

.

.

.</max:MXINVBALSet>

クエリー演算子

QueryOperatorType データ型は、複数の異なる演算子の使用に対応しています。クエリー要求の XML では複数の異なる演算子を使用して、クエリーを発行した外部ソースに返されるデータをフィルターに掛けることができます。

QueryMXPERSON 要素

QueryMXPERSON 要素には、以下のタイプがあります。

v QueryMXPERSON 要素のタイプは QueryMXPERSONType です。

v QueryMXPERSONType には、タイプ MXPERSONQueryType の要素MXPERSONQuery があります。

v MXPERSONQueryType には、PERSON オブジェクトとその下位階層にある全オブジェクト (EMAIL、PHONE、および SMS) のすべての構成済み属性に対応する要素が含まれています。

QueryMXPERSON 操作要素では、以下の属性が使用されます。

v uniqueResults – ブール型の値。この値が 1 (True) に設定されると、単一の固有レコードを返すようにクエリーに指示します。複数のレコードが検出されると、エラーが返されます。この属性が指定されない場合のデフォルト値は 0 (False)

です。

v maxItems – クエリーでこの値を 10 に設定すると、そのクエリーでは結果セットに 10 を超えるレコードがある場合でも、返されるレコード数は 10 に制限されます。この属性が定義されない場合は、クエリーの結果セットのすべての行が返されます。

v rsStart – クエリーでこの値を 11 に設定すると、結果セットのレコード 11 以降のすべてのレコードが返されます。このクエリーの結果ではレコード 1 から 10

はスキップされます。この属性が定義されない場合、結果セットのレコード 1 以降のレコードが返されます。

MXPERSONQuery 内容要素では、以下の追加属性が使用されます。

v orderby – この値を使用すると、SQL ステートメントで Order By を使用する場合と同じ機能が得られます。この属性には、ASC および DESC オプションも含


むコンマ区切りフィールド名のリストを含めることができます。この属性が定義されない場合、そのクエリーではデータベースによって取り出されたときの順序でレコードが返されます。

v operandMode – この値には 2 つの有効な値 AND および OR が含まれます。クエリー実行時の評価で 1 つ以上のフィールドが使用されると、システムはこの値を使用します。AND 値を使用する場合は、すべてのフィールド評価が True でなければなりません。OR 値を使用する場合は、フィールド評価の 1 つのみがTrue でなければなりません。この属性が定義されない場合のデフォルト値はAND です。

QueryMXPERSONResponse 要素

QueryMXPERSONResponse 要素には、以下のタイプがあります。

v 要素 QueryMXPERSONResponse のタイプは QueryMXPERSONResponseType です。

v QueryMXPERSONResponseType には、タイプ MXPERSONSetType の要素MXPERSONSet があります。

v MXPERSONSetType には、PERSON オブジェクトのすべての構成済み属性の要素、およびオブジェクト構造で定義された下位階層オブジェクト(PHONE、EMAIL、XYZ、および SMS) の要素があります。

QueryMXPERSONResponse 要素には、以下の属性があります。

v rsStart – この値にはクエリー要求で設定された値が含まれます。要求でこの値が定義されていない場合のデフォルト応答値は 1 です。

v rsCount – この値には、クエリー応答で返されるレコード数が含まれます。

v total – この値には、クエリーの最終的な結果セットのレコード数が含まれます。クエリー要求で maxItems 属性が使用されているときは、total 値の方が返されるレコード数より多い場合があります。

クエリーの選択基準

クエリー要求のオブジェクト構造要素には、クエリーの選択基準が含まれています。クエリーでは、単一値、一定範囲の値、または指定した「where」文節に基づいてレコードを選択できます。統合フレームワークは = や > などのクエリー演算子の使用に対応しています。

選択基準は、オブジェクト構造の上位 2 つのレベルにあるオブジェクト (プライマリー・オブジェクトおよびその直接の下位階層のオブジェクト) の属性のみに適用されます。ただし、応答にはオブジェクト構造のすべてのオブジェクトのデータが含まれます。

フィールドの選択フィールドに基づくクエリーでは、データベース・フィールドの値がクエリー要求の XML フィールドの値と比較されます。

以下のサンプル・クエリーでは、従業員が検索されます。


<QueryMXPERSON><MXPERSONQuery><PERSON></PERSON></MXPERSONQuery></QueryMXPERSON>

以下のサンプル・クエリーでは、PERSONID が ATI に等しく、STATUS がACTIVE に等しい従業員が検索されます。

<QueryMXPERSON><MXPERSONQuery><PERSON><PERSONID operator ="=">ATI</PERSONID><STATUS operator ="=">ACTIVE</STATUS></PERSON></MXPERSONQuery></QueryMXPERSON>

MXPERSONQuery 要素の operandMode 属性は、フィールド評価間に AND またはOR 条件を指定して実行されるステートメントを定義します。システムで使用されるデフォルトの条件は AND 条件です。さらに、フィールド・レベルでoperandMode 属性を指定することができます。この場合はフィールド要素を複数記述することができ、複数の条件について評価することができます (例えば、数量フィールドが 2 未満または 10 超過と評価される場合、など)。

以下のサンプル・クエリーでは、PERSONID が %ATI% のようになっている従業員が検索されます。このオペランドはデフォルトの動作を表し、演算子の値を必要としません。

<QueryMXPERSON><MXPERSONQuery><PERSON><PERSONID>ATI</PERSONID></PERSON></MXPERSONQuery></QueryMXPERSON>

以下のサンプル・クエリーでは、保管箱番号が Null でない在庫量が検索されます。

<QueryMXINVBAL><MXINVBALQuery>

<INVBALANCES><BINNUM operator =”!="></BINNUM></INVBALANCES ></MXINVBALQuery></QueryMXINVBAL>

以下のサンプル・クエリーでは、保管箱番号が Null の在庫量が検索されます。

<MXINVBAL><INVBALANCES><BINNUM>NULL</BINNUM></INVBALANCES ></MXINVBAL>

以下のサンプル・クエリーでは、SQL の IN 文節に相当する文を使用して、ステータスが ACTIVE または INACTIVE である従業員が検索されます。

<QueryMXPERSON><MXPERSONQuery><PERSON>


<STATUS>ACTIVE,INACTIVE</STATUS></PERSON></MXPERSONQuery></QueryMXPERSON>

以下のサンプル・クエリーでは、PERSONID が文字 A で始まる従業員が検索されます。

<QueryMXPERSON><MXPERSONQuery><PERSON><PERSONID operator ="SW">A</PERSONID></PERSON></MXPERSONQuery></QueryMXPERSON>

以下のサンプル・クエリーでは、PERSONID が文字 Z で終わる従業員が検索されます。

<QueryMXPERSON><MXPERSONQuery><PERSON><PERSONID operator ="EW">Z</PERSONID></PERSON></MXPERSONQuery></QueryMXPERSON>

フィールド評価operator 属性は、データベース・フィールドの値を 1 つ以上の値と比較し、その形式は operator = value です。

value 属性は、以下の値をとることができます。

値説明

= 等しい

!= 等しくない

< 未満

<= 以下

> より大きい

>= 以上

EW 末尾の文字

SW 先頭の文字

「未満」および「より大きい」の属性は数値および日付フィールドでのみ使用します。

例えば、ACTIVE ステータスのすべての従業員を検索するには、クエリーを次のようにフォーマット設定します。

<QueryMXPERSON><MXPERSONQuery><PERSON><STATUS operator ="=">ACTIVE</STATUS></PERSON></MXPERSONQuery></QueryMXPERSON>


範囲選択クエリーでは、ある範囲の値に含まれる値を持つレコードを検索できます。フォーマットは、選択基準が無制限であるか、または選択基準に範囲の上限および下限があるかによって異なります。

以下のサンプル・クエリーでは、DEPARTMENT が 1000 より大きい注文書が検索されます。

<QueryMXPERSON><MXPERSONQuery><PERSON>< DEPARTMENT operator=">=">1000</DEPARTMENT></PERSON></MXPERSONQuery></QueryMXPERSON>

以下のサンプル・クエリーでは、PERSONID が 1000 より大きく、20000 より小さい担当者レコードが検索されます。このクエリーでは、1 つのフィールド要素の 2

つのインスタンスが使用されます。1 つには「範囲の下限」選択基準が適用され、もう 1 つには「範囲の上限」選択基準が適用されます。

<QueryMXPERSON><MXPERSONQuery><PERSON>< PERSONID operator=">=">1000</PERSONID >< PERSONID operator="<=">20000</PERSONID ></PERSON></MXPERSONQuery></QueryMXPERSON>

Where 文節の選択クエリーでは、統合クエリー XML の一部として指定できる SQL の「Where」文節に基づいてレコードを検索できます。Where 文節は、より複雑なクエリーと、分類関連データの照会をサポートしています。

「Where」文節と個々の要素を同時に使用することはできません。クエリー要求がXML 内の Where 要素およびその他の要素にデータを与えるという内容の場合、クエリーの実行時には WHERE 要素のみが使用されます。

WHERE 要素は、以下の例に示すように、オブジェクト構造（注文書）内の最上位オブジェクトと同じレベルに置きます。

<QueryMXPO xmlns="http://www.ibm.com/maximo"><MXPOQuery><PO> </PO><WHERE> </WHERE>

</MXPOQUERY></QueryMXPO>

WHERE 要素は、操作が「クエリー」である場合にのみ、スキーマ内で使用できます。また、使用できるのは 1 回のみです。クエリー内で複数のテーブルを結合するには、アプリケーションの「一覧」タブからの WHERE 文節と同じように、Where

文節内で「exists」を使用します。次のサンプル・クエリーでは、MXPO オブジェクト構造を使用して、部品番号 1002 の注文書明細が含まれる注文書を検索します。

<QueryMXPO xmlns="http://www.ibm.com/maximo"><MXPOQuery><WHERE>(siteid = ’BEDFORD’) and (exists (select 1 from maximo.poline where


(i temnum=’1002’) and (ponum=po.ponum and revisionnum=po.revisionnum andsiteid=po.siteid)))</WHERE></MXPOQUERY></QueryMXPO>

このクエリーの結果として、次の 2 つの注文書が検索されました (この例にはすべての要素が含まれているわけではありません)。

<?xml version="1.0" encoding="UTF-8"?><QueryMXPOResponse xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" creationDateTime="2012-03-21T11:20:13-04:00"transLanguage="EN" baseLanguage="EN" messageID="1332343214013260273" maximoVersion="7 5 20110413-2230 V7500-721" rsStart="0" rsTotal="2" rsCount="2">

<MXPOSet><PO>

<DESCRIPTION>Window and installation for office building</DESCRIPTION><ORDERDATE>2000-04-20T14:00:00-04:00</ORDERDATE><ORGID>EAGLENA</ORGID><PONUM>1013</PONUM><POTYPE>STD</POTYPE><VENDOR>JK</VENDOR>

.

.

.<POLINE>

<DESCRIPTION>5 ft. X 6 ft. window pane</DESCRIPTION><ITEMNUM>1002</ITEMNUM><ITEMSETID>SET1</ITEMSETID><ORDERQTY>1.0</ORDERQTY><POLINENUM>1</POLINENUM>

.

.

.<POCOST>

<COSTLINENUM>1</COSTLINENUM>...

</POCOST></POLINE><POLINE>

<DESCRIPTION>Installation of window pane</DESCRIPTION><ITEMNUM /><ITEMSETID>SET1</ITEMSETID><ORDERQTY>6.0</ORDERQTY><POLINENUM>2</POLINENUM>

.

.

.<POCOST>


</POCOST></POLINE>

</PO><PO>

<DESCRIPTION>Window and installation for Office Building</DESCRIPTION><ORDERDATE>2003-02-27T10:07:24-05:00</ORDERDATE><ORGID>EAGLENA</ORGID><PONUM>1029</PONUM><POTYPE>STD</POTYPE><VENDOR>JK</VENDOR>

.

.

.


<POLINE><DESCRIPTION>5 ft. X 6 ft. window pane</DESCRIPTION><ITEMNUM>1002</ITEMNUM><ITEMSETID>SET1</ITEMSETID><ORDERQTY>1.0</ORDERQTY><POLINENUM>1</POLINENUM>

.

.

.<POCOST>


</POCOST></POLINE><POLINE>

<DESCRIPTION>Installation of window pane</DESCRIPTION><ITEMNUM /><ITEMSETID>SET1</ITEMSETID><ORDERQTY>6.0</ORDERQTY><POLINENUM>2</POLINENUM>

.

.

.<POCOST>


</POCOST></POLINE>

</PO></MXPOSet>

</QueryMXPOResponse>

インターフェース・テーブルインターフェース・テーブルは、データの交換にデータベース表を使用するシステムと統合するためのオプションです。この統合オプションはエンタープライズ・サービスとパブリッシュ・チャネルのみに適用され、常に、JMS キューを使用して非同期処理されます。

外部システム内には、統合用にインターフェース・テーブルと一緒に使用される 1

つ以上のパブリッシュ・チャネルおよびエンタープライズ・サービスがある場合があります。インターフェース・テーブルを使用するチャネルやサービスは、フラット・ファイルに対応するように構成されているオブジェクト構造に関連付ける必要があります。また、別名の競合はすべて解決する必要があります。

インターフェース・テーブルの場所

外部システムまたはパブリッシュ・チャネルのエンドポイント定義は、そのインターフェース・テーブルが保管されているデータベースを指します。このデータベースは、ローカル・アプリケーション・データベースまたはリモート・データベースにすることができます。事前定義の内容には、アプリケーション・データベースを指す MXIFACETABLE インターフェース・テーブル・エンドポイントが含まれています。リモート・データベース用の追加エンドポイントを追加することができます。


インターフェース・テーブルの名前

統合フレームワークは、インターフェース・テーブル名をエンタープライズ・サービスまたはパブリッシュ・チャネルに登録します。インターフェース・テーブルのデフォルト名は指定されていません。インターフェース・テーブルに命名する際は、以下のガイドラインを適用します。

v 同じオブジェクト構造を使用するパブリッシュ・チャネルおよびエンタープライズ・サービスは、同じインターフェース・テーブル名または異なるインターフェース・テーブル名を使用することができます。

v 異なるオブジェクト構造を使用するパブリッシュ・チャネルおよびエンタープライズ・サービスは、異なるインターフェース・テーブル名を使用する必要があります。

インターフェース・キュー・テーブル

インターフェース・キュー・テーブルは、受信システムがそれぞれのインターフェース・テーブルのレコードを処理する順序を示します。2 つのキュー・テーブルがあり、1 つはインバウンド・トランザクション用で、もう 1 つはアウトバウンド・トランザクション用です。トランザクションによっては、前のトランザクションが正常に処理されていることが前提条件となるものがあります。例えば、ユーザーをセキュリティー・グループに追加するには、まずそのユーザーを作成する必要があります。受信システムは、送信システムがレコードを作成した順序でそれらのレコードを処理する必要があります。

表 43. インターフェース・キュー・テーブル

インターフェース・キュー・テーブル方向

MXOUT_INTER_TRANS アウトバウンド

MXIN_INTER_TRANS インバウンド

アウトバウンド・メッセージ用のデータを取り出す外部アプリケーションは、アウトバウンド・インターフェース・キュー・テーブル (mxout_inter_trans) を使用することができます。ただし、その外部アプリケーションは、統合要件を満たすアウトバウンド・メッセージを取り込む他のメソッドの使用を選択することもできます。

すべてのインバウンド・トランザクションおよびアウトバウンド・トランザクションでは、対応するインバウンドまたはアウトバウンド用のキュー・テーブルに必ずレコードが挿入されます。このレコードには TRANSID 値が含まれます。これは、トランザクション・データの書き込み先のインターフェース・テーブルを識別する固有 ID です。対応するインターフェース・テーブルでは TRANSID 値を使用して、トランザクションに関連付けられているレコード (1 つ以上) を指定します。トランザクションの内容を識別するには、対応するインターフェース・テーブル内で所定の TRANSID 値を持つすべてのレコードを検索します。

TRANSID の順序は、レコードが統合フレームワークによって処理される順序を示します。例えば、ユーザーとセキュリティー・グループをシステムに入力する場合、ユーザー・レコードの TRANSID 値は、そのユーザーを参照するセキュリティー・グループ・レコードの TRANSID 値より低くなければなりません。


MXIN_INTER_TRANS キュー・テーブルと MXOUT_INTER_TRANS キュー・テーブルの違いは、追跡するインターフェース・テーブル・レコードの方向です。必ず外部システムが MXIN_INTER_TRANS キュー・テーブルに書き込み、統合フレームワークがこのキュー・テーブルから読み取ります。さらに統合フレームワークがMXOUT_INTER_TRANS キュー・テーブルに書き込み、外部システムがこのキュー・テーブルから読み取ります。

外部システムは、MXOUT_INTER_TRANS テーブルを使用したり、アウトバウンド・レコードをインターフェース・テーブルから取得したりすることができます。インターフェース・キュー・テーブルは、エンドポイント用のインターフェース・テーブルを最初に作成する時点で生成されます。各エンドポイントには、アウトバウンド TRANSID値を維持するための専用のインターフェース・キュー・テーブルとカウンターがあります。

インターフェース・テーブルの作成エンタープライズ・サービスとパブリッシュ・チャネルが同じインターフェース・テーブルを使用すると、「インターフェース・テーブルの作成」ウィンドウに、インターフェース・テーブルの名前とそれに対応するエンドポイントの一意性に基づいてインターフェース・テーブルのリストが表示されます。

エンタープライズ・サービスおよびパブリッシュ・チャネルのインターフェース・テーブルを作成できるのは、関連するオブジェクト構造がフラットをサポートすることが示されている場合です。オブジェクト構造の「フラット構造をサポート」チェック・ボックスを選択する必要があります。また、インターフェース・テーブルを作成する前に、オブジェクト構造で別名の競合をすべて解決しておく必要があります。

エンタープライズ・サービスおよびパブリッシュ・チャネルでデータ同期用のインターフェース・テーブルを作成することができます。インターフェース・テーブルでは、クエリーおよび呼び出し操作はサポートされません。特定のエンドポイント用のインターフェース・テーブルを作成することができます。テーブルを作成する場所を示す必要があります。

エンドポイントによって参照されるデータベース・ロケーションは、ローカル・データベース、リモート・データベースのどちらの場合もあります。ローカル・データベースでインターフェース・テーブルを作成する場合、カラムがシステム・データ・ディクショナリーに登録されます。データベース構成操作を実行すると、データベース表とデータベース・カラムを使用するローカル・インターフェース・テーブルには基本カラム属性 (データ型など) に対するすべての更新 (挿入と削除を除く) が示されます。基本テーブルでカラムが追加または削除された場合にそのカラムの変更を適用するには、対応するエンタープライズ・サービスおよびパブリッシュ・チャネルのインターフェース・テーブルを再生成する必要があります。リモート・データベースでは変更は適用されません。そのため、カラムの変更を適用するためにリモート・インターフェース・テーブルの再生成が必要になります。


インターフェース・テーブルの再生成システム・データベース・テーブルでカラムを追加または削除するときは、それらのオブジェクト構造に関連付けられたすべてのローカルおよびリモートのインターフェース・テーブルを再生成する必要があります。

インターフェース・テーブルを再生成するには、外部システム・アプリケーションで「インターフェース・テーブルの作成」アクションを使用します。「既存のものを名前変更する」チェック・ボックスを選択すると、アプリケーションは対応するインターフェース・テーブル内の既存のデータを INTERFACETABLENAME_BAK

テーブルにバックアップします。

必要に応じて、そのデータを新規テーブルにリストアすることができます。マルチテナンシー環境の構成によっては、リストアするデータにアクセスするためにシステム・プロバイダーの支援が必要となる場合があります。テーブルをバックアップしておかないと、テーブルの再生成時にテーブルが除去され、データは失われます。MXIN_INTER_TRANS キュー・テーブルにインターフェース・テーブルを指すレコードが含まれている場合、そのインターフェース・テーブルを再生成することはできません。そのキュー・テーブルに行が存在するときは、対応するインバウンド・トランザクションの処理準備ができています。準備ができていない場合、そのインバウンド・トランザクションがエラーになっています。

インターフェース・テーブル作成プロセスでは、MXOUT_INTER_TRANS キュー・テーブルにレコードがあるかどうかは検査されません。

インターフェース・テーブルおよびレコードの削除インターフェース・テーブルで関連のインバウンド・トランザクション・レコードが正常に処理されると、対応するレコードが MXIN_INTER_TRANS キュー・テーブルから削除されます。削除は、そのトランザクションがインバウンド用の JMS

キューに正常に配信されたことを意味します。

レコードは MXIN_INTER_TRANS キュー・テーブルから削除されるだけで、個々のインターフェース・テーブルからは削除されません。システム管理者がインターフェース・テーブルからレコードを削除する時期と方法を決定します。

アウトバウンド・トランザクションの場合、外部システムは、キュー・テーブルおよびインターフェース・テーブルのデータの削除およびアーカイブを管理する必要があります。インターフェース・テーブルの削除は、ユーザー・インターフェースを使用したり、対応するオブジェクト構造を削除したりする方法では実行できません。管理者は、インターフェース・テーブルのデータのアーカイブを管理する必要があり、必要に応じてテーブルを削除できます。

インターフェース・テーブルの形式インターフェース・テーブルは、それに対応するオブジェクト構造と同じ形式になります。永続カラムと非永続カラムは組み込まれ、オブジェクト構造から除外されているカラムはすべて除外されます。

インターフェース・テーブルには、さまざまなインターフェース・テーブルで送信システムがレコードを書き込み受信システムがそれらのレコードを処理する際の順序を示す、追加のカラムが組み込まれています。


キー・カラム

インターフェース・テーブルが上位階層と下位階層のオブジェクト関係を含む階層オブジェクト構造を表している場合、このテーブルには、上位階層オブジェクトのキー・カラムに含まれている下位階層オブジェクトのキー・カラム部分は含まれません。例えば、PERSONID は PERSON、PHONE、EMAIL、および SMS レコードにあるキー・カラムです。PERSONID カラムは、MXPERSON_IFACE インターフェース・テーブルの上位階層 (PERSON) レベルにのみ表示されます。

重複したカラムおよび別名

階層オブジェクト構造の XML 表現には重複したカラム名が含まれますが、インターフェース・テーブルおよびフラット・ファイルの表現には含まれません。上位階層オブジェクトと下位階層オブジェクトの両方に重複した非キー・カラム名がオブジェクト構造にあると、インターフェース・テーブルまたはフラット・ファイル・レコードが生成されるときに重複カラム名エラーが発生します。

この問題を解決するには、いずれかの重複カラム名の別名を変更します。システム・データベース・カラムにはすべてエイリアスの代替名を付けることができます。エイリアスが存在する場合、システムではインターフェース・テーブルとフラット・ファイルの生成時にそのエイリアスが使用されます。重複したカラム名のエラーが発生しないようにするには、エイリアスを変更します。

ほとんどのカラムにはエイリアスはありませんが、一部のカラムには定義済みのエンタープライズ・サービスまたはパブリッシュ・チャネルをサポートするエイリアスがあります。

オブジェクト構造内のカラムには、別名を 1 つだけ指定できます。オブジェクト構造が複数のパブリッシュ・チャネルおよびエンタープライズ・サービスで使用されている場合に別名を変更すると、オブジェクト構造に関連付けられているすべてのインターフェース・テーブルが影響を受けます。

定義済みのオブジェクト構造のカラムには、システムが割り当てたエイリアスがあります。階層オブジェクト構造を作成するとき、または定義済みオブジェクト構造にオブジェクトを追加するときは、重複がないか確認してください。「別名の追加/

修正」ウィンドウに、選択したオブジェクト構造のオブジェクトに対応するフィールドと別名が表示され、重複した別名には重複カラムにチェック・マークが付いています。重複した別名が存在する場合は、「ALIASNAME」カラム内でその値を上書きしてください。

制限付きカラム

HASLD フィールドは内部システムのカラムで、すべてのオブジェクト構造から除外されます。このカラムは、インターフェース・テーブルに関連付けられたオブジェクト構造には含めないでください。LANGCODE フィールドも定義済みオブジェクト構造から除外されます。


統合処理のカラム

次の表に、インターフェース・テーブルの順序付け、取得、および処理で使用されるカラムを示します。カラムには、インターフェース・キュー・テーブルまたはインターフェース・テーブルのどちらか一方に含まれるものと、この両方に含まれるものがあります。

表 44. 統合処理のカラム

カラム名


インターフェース・テーブル説明

IFACENAME はいいいえ IFACENAME カラムには、トランザクションで使用されるエンタープライズ・サービスまたはパブリッシュ・チャネルの名前が含まれます。このカラムは、アウトバウンド・トランザクションで取り込まれます。インバウンド・トランザクションの場合は、外部システムが、インターフェース・テーブルに挿入される行に対応するエンタープライズ・サービスまたはパブリッシュ・チャネルの名前をこのカラムに取り込む必要があります。

TRANSID はいはいインターフェース・キュー・テーブルの TRANSID カラムは、統合トランザクションを一意的に指定する順序番号です。TRANSID およびインターフェース・テーブル名は固有トランザクションを指定します。インターフェース・キュー・テーブルには、TRANSID 値を持つレコードを 1 つ含めることができます。対応するインターフェース・テーブルには、エンタープライズ・サービスまたはパブリッシュ・チャネルの一部としてそのインターフェース・テーブルに書き込まれるレコード数に応じて、TRANSID 値を持つレコードを 1 つ以上含めることができます。

トランザクションで複数のインターフェース・テーブルへの書き込みが行われる場合、インターフェース・キュー・テーブルには、インターフェース・テーブルごとにそれぞれ固有の TRANSID 値を持つ別個のレコードが入れられます。

各インターフェース・キュー・テーブルは、独自の TRANSID カウンターを維持します。アウトバウンド TRANSID 値はインターフェース・キュー・テーブル・レコードの生成時に初期化されます。インバウンド用のキュー・テーブルおよびインターフェース・テーブル・レコードにデータを追加する TRANSID カウンターを作成して維持する必要があります。

外部システムがインバウンド用の TRANSID カウンターを正しく管理しないと、順次処理が確実に行われません。外部システムが生成する TRANSID 値が、生成されている TRANSID 値と重複しないようにしてください。重複した TRANSID 値が存在し、1 つのインターフェース・テーブルを使用してインバウンドとアウトバウンドの両方向で同じオブジェクト構造を処理すると、エラーが発生します。

各エンドポイントには、それぞれ独自のインターフェース・キュー・テーブル・セットおよび独自のアウトバウンド用 TRANSID カウンターがあります。


表 44. 統合処理のカラム (続き)

カラム名



TRANSSEQ いいえはいインターフェース・テーブルの複数のレコードが同じ TRANSID 値を共用する場合、TRANSSEQ カラムは、これらのレコードが処理される順序を示す第 2 の順序番号を提供します。

EXTSYSNAME はいいいえインターフェース・キュー・テーブル内の EXTSYSNAME カラムには、インバウンド・データまたはアウトバウンド・データを入れることができます。インバウンド・トランザクションの場合、このカラムには、統合フレームワークで定義されている有効かつ使用可能になっている外部システムの名前が入ります。アウトバウンド・トランザクションの場合、このカラムには、トランザクションの宛先である外部システムの名前が入ります。

ACTION はいいいえ ACTION カラムには、外部システム (アウトバウンド) または統合フレームワーク (インバウンド) で実行するアクションが入ります。以下のアクションを使用できます。

v 追加: メッセージに示されているデータを挿入します。

v 削除: 上位階層データおよび関連するすべての下位階層データをデータベースから削除します。

v 変更: メッセージの上位階層および下位階層データの内容を更新しますが、メッセージで明示的に指定されていない既存の下位階層データは削除しません。

v 置換: 既存のレコードをメッセージの内容と置き換え、メッセージで参照されていない既存の下位階層データを削除します。

v 追加変更: プライマリー・レコードが存在しない場合は、追加アクションとして処理します。それ以外の場合は変更アクションとして処理します。

v Null: プライマリー・レコードが存在しない場合は、追加アクションとして処理します。それ以外の場合は置換アクションとして処理します。

IMPORTMESSAGE はい (インバウンドでのみ使用)

いいえ IMPORTMESSAGE カラムは、インターフェース・テーブルの行がインバウンド用のキューに移動されたときに作成されたエラー・メッセージを保持します。

TRANSLANGUAGE はいいいえ TRANSLANGUAGE カラムは、トランザクションの言語を指定します。アウトバウンド・トランザクションの場合、この値は、トランザクションを開始したユーザーの言語を示します。インバウンド・トランザクションの場合、この値は、トランザクションの言語を示します。複数言語環境をサポートするすべての属性は、TRANSLANGUAGE 値によって定義される言語になっていると想定されます。

MESSAGEID はい (アウトバウンドでのみ使用)

いいえ MESSAGEID カラムは、システムがすべてのアウトバウンド・トランザクションに割り当てる固有 ID です。


表 44. 統合処理のカラム (続き)

カラム名



IFACETBNAME はい (アウトバウンドでのみ使用)

いいえ IFACETBNAME カラムは、IFACENAME カラムに対応するインターフェース・テーブルの名前です。このカラムは、アウトバウンド・トランザクションにのみ適用されます。

Oracle Databaseの詳細説明カラム

詳細説明カラムは、Oracle Databaseの CLOB (文字形式のラージ・オブジェクト) カラムに保管されます。インターフェース・テーブルには、各 CLOB カラムの 2 つのバージョンが含まれます。1 つはデータ型が CLOB のもの、もう 1 つは文字長が 4000 でデータ型が ALN のものです。次の例では、CLOB カラムの名前はカラムの別名です。英数字カラムの名前は、サフィックス 2 が付いたカラムの別名です。

表 45. Oracle Databaseの詳細説明カラム

データ型説明カラムの名前

CLOB PERSON_DESCRIPTION_LD

ALN PERSON_DESCRIPTION_LD2

システムは、両方のカラムをアウトバウンド・トランザクションに取り込みます。インバウンド・トランザクションの場合、統合フレームワークは、ALN カラムの値が NULL 以外である場合はこの値を使用します。NULL である場合、CLOB カラムの値が使用されます。

インターフェース・テーブルのポーリング定義済みクーロン・タスクは、インターフェース・キュー・テーブルをポーリングし、IFACENAME、EXTSYSNAME、および TRANSID の値を使用して、対応するレコードを適切なインバウンド JMS キューに入れ、処理されるようにします。インターフェースのポーリング・プロセスは、外部システム名およびエンタープライズ・サービス名が有効かつ使用可能になっていることを検査します。

インターフェース・テーブルのポーリングを開始するには、クーロン・タスクを構成する必要があります。また、追加のタスクを実行して、インターフェースのポーリング中のパフォーマンスを向上させることもできます。

インターフェース・テーブルのポーリング・クーロン・タスクIFACETABLECONSUMER クーロン・タスクは、インバウンド・インターフェース・キュー・テーブルをポーリングして新規処理レコードの有無を調べる事前定義のクーロン・タスクです。


インターフェース・テーブルのポーリング・プロセスは、外部システム名およびエンタープライズ・サービス名が有効で、現在使用可能になっていることを検査します。そうでない場合、レコードはエラーのマークを付けられ、インターフェース・テーブルに残されます。

インターフェース・テーブルのポーリングを使用不可に設定している場合、新規のレコードはインターフェース・テーブルに残されます。インバウンド用の JMS キューに送信されたメッセージは処理されます。

インターフェース・テーブルからアウトバウンド・トランザクションを取得するメカニズムをセットアップする必要があります。これには、システムがインバウンド・トランザクションに対して実行するポーリング・プログラム、トリガー、または他の任意のメカニズムを使用することができます。

このクーロン・タスクには以下の構成可能パラメーターがあります。パラメーターはすべてオプションです。

表 46. インターフェース・テーブルのポーリング・クーロン・タスクのパラメーター


EXITCLASS インバウンド用のキューに書き込まれる前にデータを操作できるようにする Java 出口クラス。

ENDPOINT インターフェース・テーブルに関連付けられたエンドポイント。デフォルト値は、ローカル・データベースを指す定義済みのエンドポイント値です。

ENTERPRISESERVICE ポーリングされるエンタープライズ・サービス。デフォルト (NULL 値) は、すべてのエンタープライズ・サービスです。このパラメーターに値を指定する場合、EXTSYSNAME

パラメーターにも値を指定する必要があります。これらの値を指定すると、すべてのエンタープライズ・サービスをポーリングするデフォルトの動作ではなく、ポーリング・スレッドが特定のエンタープライズ・サービスに制限されます。


EXTSYSNAME ポーリングされる外部システム。

QUEUETABLE エンタープライズ・サービス・キュー・テーブル。デフォルト値は MXIN_INTER_TRANS

です。


インターフェース・テーブルのポーリングの拡張インターフェース・テーブルのポーリング・プロセスの拡張構成を実行すると、インターフェース・テーブルからデータを読み取る際のパフォーマンスを向上できます。

インバウンド・メッセージを継続中の JMS キューを介して送信し、メッセージを先入れ先出し順序で維持する必要がない場合は、インターフェース・テーブルのポーリングのパフォーマンスを向上することができます。

複数のクーロン・タスク

インターフェース・テーブルのポーリング・プロセスでは、単一のクーロン・タスクを使用して、テーブルに書き込みを行うすべての外部システムに関するすべてのメッセージをすべてのインターフェース・テーブルから読み取ります。それぞれ異なるプロパティー値を持つ複数の IFACETABLECONSUMER クーロン・タスク・インスタンスを構成することによって、パフォーマンスの向上を図ることができます。マルチスレッド・ポーリングでは複数のスレッドが複数の異なるサーバーで稼働でき、ロード・バランシングが可能になるため、このポーリングはクラスター構成で有効に機能します。

クーロン・タスクのインスタンスを特定のアプリケーション・サーバーで実行するように指定するには、「クーロン・タスクのセットアップ」アプリケーションでTARGETENABLED プロパティーを 1 に設定し、-DIFACETBCONSUMER.instance1=1

を設定します。また、複数のクーロン・タスクを実装するときは、相互排他的なセレクターを実装して、1 つのメッセージが 2 回以上処理される事態を回避する必要があります。

セレクターを定義するには、「クーロン・タスクのセットアップ」アプリケーションで EXTSYSNAME パラメーターおよび ENTERPRISESERVICE パラメーターに値を割り当てます。例えば、EXTSYSNAME=EXTSYSNAME1 およびENTERPRISESERVER=MXPERSONInterface を設定することができます。複数のテーブルを追加するには、パイプ区切り文字を使用します (例えば、Set

ENTERPRISESERVICE=MXPERSONInterface|MXPHONEInterface)。

クーロン・タスクの複数のインスタンスを構成する場合、メッセージが複数回処理されないようにするため、セレクターを相互に排他的にする必要があります。メッセージが未処理のまま残されないように、セレクターで、使用されているすべてのエンタープライズ・サービス・トランザクションを取得しなければなりません。

複数のキュー

複数のインターフェース・キュー・テーブルをセットアップすると、パフォーマンスを向上することができます。例えば、各インターフェースをそれぞれ別個のキュー・テーブルに書き込み、別個のクーロン・タスクを定義してキュー・テーブルを相互に独立させて処理することができます。さらに、各外部システム用に別個のキュー・テーブルをセットアップし、各キュー・テーブル内で各インターフェース用のセレクターを定義することもできます。統合の複雑さの程度に応じて、複数のセレクターを使用する代わりに複数のキュー・テーブルを使用することができます。複数のキュー・テーブルをセットアップするには、インターフェース・テーブルと同じデータベースにキュー・テーブルを作成して、MXIN_INTER_TRANS キュー・


テーブル内にあるすべての列を組み込みます。外部システムは適切なキュー・テーブルに書き込むように設計する必要があります。外部システムが 1 つのインターフェース・テーブル・メッセージを複数のキュー・テーブルに挿入しないようにして、メッセージが複数回処理される事態を防止してください。

外部システムでのインターフェース・テーブルの処理インターフェース・テーブルを使用するように外部システムを有効にするには、インターフェース・テーブルを作成し、インターフェース・テーブルを復元するためのバックアップ手順を定義し、インターフェース・テーブルのアーカイブを構成する必要があります。

インバウンド処理の有効化外部システムからのインターフェース・テーブル・データのインバウンド処理を構成するには、TRANSID カウンターを作成し、インターフェース・テーブルおよびキューのレコードを作成する必要があります。

始める前に

インターフェース・テーブルを使用するには、テーブルを作成して、IFACETABLECONSUMER クーロン・タスクを構成する必要があります。

手順1. アウトバウンド用の TRANSID カウンターを作成し、初期設定します。

2. インバウンド・トランザクションが書き込みをするインターフェース・テーブルごとにレコードを作成し、各レコードに以下の情報を取り込みます。

a. トランザクション・データ

b. 増分した TRANSID 値

c. 同じインターフェース・テーブルに対して複数のレコードが存在する場合は、増分された TRANSSEQ 値

3. MXIN_INTER_TRANS キュー・レコードを作成して、以下の情報を取り込みます。

a. インターフェース・テーブル・レコードに含まれるものと同じ TRANSID 値

b. IFACENAME カラムにある、インターフェース・テーブルに対応するエンタープライズ・サービスの名前

c. オプション: ACTION 値

d. EXTSYSNAME カラムにある、外部システムの ID

4. 単一コミットを実行して、一度にトランザクションのすべてのレコードをコミットします。

アウトバウンド処理の有効化アウトバウンド処理を構成するには、MXOUT_INTER_TRANS キュー・テーブルからトランザクションを取得するために、ポーリング・プログラムやトリガーなどのプロセスをセットアップおよび構成する必要があります。


始める前に

インターフェース・テーブルを使用するには、テーブルを作成する必要があります。

手順1. MXOUT_INTER_TRANS キュー・テーブルを使用してインターフェース・テーブル・トランザクションを取得するプロセスをセットアップします。ポーリング・プログラム、トリガー、または他の任意のメカニズムを使用することができます。

2. ポーリング・プログラムでトランザクションが順次に処理されるようにするには、MXOUT_INTER_TRANS キュー・テーブルのレコードを TRANSID の順序で読み取るようにこのプログラムを構成します。

3. MXOUT_INTER_TRANS キュー・テーブルの各レコードで、以下ができるようにします。

a. 直前に確認したインターフェース・テーブルにアクセスして、TRANSID 値が現行の MXOUT_INTER_TRANS キュー・レコードの TRANSID 値と一致する最初のレコードを取得します。インターフェース・テーブルに TRANSID

値が同じレコードが複数ある場合は、TRANSSEQ の順序で取得して処理します。

b. インターフェース・キュー・テーブルの ACTION カラムの値に従ってデータを処理します。

4. 1 つのデータベース・トランザクションのすべてのレコードをコミットします。

5. MXOUT_INTER_TRANS キュー・テーブルから現行レコードを削除します。

次のタスク

外部システムの要件に基づいてエラー管理を実装します。

統合モジュール統合モジュールは、プロセス管理製品が外部の運用管理製品を呼び出すためのメカニズムを提供します。統合モジュールの構成を行うと、運用管理製品を使用してソフトウェア導入などの論理管理操作を自動化することができます。

工程管理製品は、アプリケーション、ワークフロー・プロセス、またはエスカレーション・プロセスから統合モジュールを呼び出すことができます。こうして呼び出された統合モジュールが運用管理製品を呼び出します。運用管理製品は、ソフトウェア導入などのサービス管理プロセスを自動化します。この実装では結果が工程管理製品に返されます。

ご使用の運用管理製品に事前定義モジュールがある場合は、Process Solution Installer

を使用してそれらのモジュールを統合フレームワークにロードします。運用管理製品用のプログラミング・インターフェースの知識がある場合は、統合モジュールがないときに自分で作成することができます。


統合モジュールのコンポーネント統合モジュールは定義済みの統合フレームワーク・コンポーネントから構成されています。統合モジュールの構成を行うと、Java クラスまたは呼び出しチャネルとして実装することができます。

定義済みの統合モジュールをインストールすると、Java クラス・ファイルおよびXSL ファイルを含んだ統合モジュールの成果物が提供されます。さらに統合モジュールによって論理管理操作定義も提供されます。

統合モジュールの定義統合モジュールをインストールするときに、選択したオプションを使用してモジュール定義が作成されます。

統合モジュールの定義には、以下の情報が含まれます。

v 統合の名前、バージョン、および説明

v 運用管理製品およびバージョン

v 統合モジュールが運用管理製品の呼び出しに使用するプロトコルを識別するハンドラー

v 統合モジュールの実装の選択項目 (Java クラスまたは呼び出しチャネル)

統合モジュールの定義には、以下のコンポーネントが含まれます。

v 統合モジュールがサポートする論理管理操作。

v その統合モジュールに固有の統合モジュール・プロパティー。このプロパティーを使用して、統合モジュールの動作を構成します。

運用管理製品運用管理製品は、ソフトウェア・デプロイメントなどのシステム・プロセスを自動化します。運用管理製品のサービスが、サーバーなどの資産に対して実行されます。こうした資産は「構成アイテム」と呼ばれます。

実動環境には、運用管理製品の複数のインスタンスを存在させることができます。複数の運用管理製品が 1 つの構成アイテムを管理できます。各運用管理製品には、構成アイテムごとにソース・トークンと呼ばれる独自の固有 ID があります。

データベースには、運用管理製品と構成アイテム情報のリポジトリーが組み込まれています。この情報には、運用管理製品と構成アイテムの関係、および工程管理製品と運用管理製品の統合を実現するソース・トークンが含まれます。

論理管理操作論理管理操作は、統合モジュールがサポートするアクション (「ステータスの取得」および「ソフトウェアのデプロイ」など) を識別します。論理管理操作は、データ・ソース、ターゲット、およびプロセスを呼び出すときにソースとターゲットが使用する特定のオブジェクト・フィールド属性で構成されています。

論理管理操作は、工程管理製品と統合モジュールの間のインターフェースとして機能します。統合モジュールと工程管理製品は、それぞれ独立して設計・開発するこ


とができます。論理管理操作定義は、製品と一緒にインストールすることができます。また、論理管理操作アプリケーションで論理管理操作を作成することもできます。

論理管理操作の定義には、以下のプロパティーが含まれます。


名前アクションの名前 (「ステータスの取得」および「ソフトウェアのデプロイ」など)。

名前空間固有の修飾子 (com.ibm.tivoli.deployment

など)。

呼び出しパターン v 同期: プロセス管理製品が要求を発行すると、統合モジュールは即時に操作結果を返します。

v 非同期一方向: プロセス管理製品が要求を発行しても、応答は返されません。

v 非同期据え置き応答: プロセス管理製品が要求を発行し、トークンがその要求のインスタンスを識別します。工程管理製品がトークンを別の論理管理操作への入力として渡し、受け取った側の論理管理操作は元の要求のステータスを取得します。

v 非同期コールバック: プロセス管理製品が要求を発行し、トークンがその要求のインスタンスを識別します。運用管理製品はトークンを使用してコールバックを実行し、元の要求のステータスを識別して報告します。統合モジュールが実行するコールバックによって、ビジネス・オブジェクトが挿入または更新されます。

ソース・ビジネス・オブジェクト論理管理操作の入力オブジェクト。

応答ビジネス・オブジェクト論理管理操作のオブジェクトの出力。

ビジネス・オブジェクト属性入力または出力のいずれかに必要なオブジェクトの特定の属性、およびそのデータ型。

入力オブジェクトおよび入力オブジェクト属性は、プロセス管理製品が統合モジュールに渡すデータを指定します。論理管理操作が入力属性を使用して構成され、入力オブジェクトを含んでいない場合、工程管理製品は必要な入力属性を持つ任意のビジネス・オブジェクトを渡すことができます。入力オブジェクトが指定されている場合、工程管理製品はビジネス・オブジェクトを統合モジュールに渡す必要があります。応答オブジェクトおよび属性は、統合モジュールが返すデータを指定します。

実装の前提条件統合モジュールの実装を行う前に、論理管理操作が 1 つ以上の統合モジュールに関連付けられていることを必ず確認します。その後に、統合モジュールを運用管理製品と関連付けることが必要です。最後に、各運用管理製品上で論理管理操作を使用可能にしなければなりません。


論理管理操作の関連付け

通常、論理管理操作と運用管理製品機能の間では 1 対 1 の通信が行われます。ただし、1 回の論理管理操作の呼び出しによって、統合モジュールが運用管理製品を複数回呼び出す場合があります。

呼び出しチャネルを使用する統合モジュールは、以下の状況が該当する場合にのみ論理管理操作を実行することができます。

v 論理管理操作で定義されたソース・オブジェクトは、呼び出しチャネルで定義された要求オブジェクト構造のメイン・オブジェクトと一致していなければなりません。

v 呼び出しチャネルが応答を処理するように構成されていない場合は、応答オブジェクトを論理管理操作と関連付けることができません。

v 論理管理操作で定義された応答オブジェクトは、呼び出しチャネルで定義された応答オブジェクト構造のメイン・オブジェクトと一致していなければなりません。一致する必要があるのは、応答を処理するように呼び出しチャネルを構成する時点です。

運用管理製品の関連付け

統合モジュールは、1 つの運用管理製品に対して複数の論理管理操作をサポートすることができます。統合モジュールを実行する場合、実行するアクションは論理管理操作の名前と名前空間値によって指定されます。

運用管理製品と統合モジュールの関連付けは、OMPPRODUCTNAME 値およびOMPVERSION 値が統合モジュールに追加されるときに作成されます。複数のバージョンの運用管理製品を統合モジュールで使用する場合は、OMPVERSION に Null

値を使用します。

論理操作管理の使用可能性

複数の統合モジュールが 1 つの運用管理製品に同じ論理管理操作を実装することができます。運用管理製品の論理管理操作用に推奨される統合モジュールを識別するには、ISPRIMARY 属性を使用します。1 つの論理管理操作/運用管理製品の組み合わせに対し、ISPRIMARY 値を True に設定できる統合モジュールは 1 つだけです。

実装プロパティー統合モジュールを実装すると、統合フレームワークが自動的に統合データを処理できるようになります。自動処理の特定部分をバイパスしたい場合は、実装をカスタマイズできます。

統合モジュールのパラメーター統合フレームワークには、ソース・オブジェクトおよび応答オブジェクト、オブジェクト・セット、エンドポイント名などの統合モジュール入力パラメーターが用意されています。これらのパラメーターは、統合モジュールを Java クラスまたは呼び出しチャネルとして実行するときに渡されます。


次の表に、psdi.iface.omp.IMConstants インターフェースのパラメーターとその名前をリストします。

名前説明

IM Java 統合モジュールまたは呼び出しチャネルとなり得る、インスタンス化されたServiceInvoker オブジェクト。

IMNAME 統合モジュールの名前。

IMVERSION 統合モジュールのバージョン。

LMONAME 呼び出された論理管理操作の名前。

LMONAMESPACE 呼び出された論理管理操作のネーム・スペース。

OMPGUID 統合モジュールが使用する運用管理製品のグローバル・ユニーク ID (GUID)。

ENDPOINTNAME 統合モジュールが運用管理製品との通信に使用するエンドポイントの名前。

ENDPOINTPROP エンドポイント・プロパティーを上書きするString.psdi.iface.mic.MaxEndPointPropInfo プロパティーのマップ。

USERNAME 統合フレームワークがエンドポイントとの通信に使用するユーザー名。

PASSWORD USERNAME に対応するパスワード。

統合モジュールのプロセス・フローJava ベースの統合モジュールは、論理管理操作の応答オブジェクトまたは応答オブジェクト・セットに操作の結果を取り込みます。呼び出しチャネルの場合は、運用管理製品の応答から応答オブジェクトまたは応答オブジェクト・セットへのマッピングを指定することができます。統合フレームワークはデータを応答オブジェクトまたは応答オブジェクト・セットにコピーします。

統合モジュールは即座に呼び出し元に制御を戻す必要があります。外部サービスが長時間実行サービスの場合は、統合モジュールは別のスレッドを作成する必要があります。新しいスレッドが運用管理製品への呼び出しを行い、その一方で、元のスレッドは呼び出し元に返されます。

統合モジュールは、以下の処理タスクを実行します。

1. ソース・オブジェクトまたはソース・オブジェクト・セットから入力を取得する。

2. 統合モジュール固有のプロパティーを取得する (該当する場合)。

3. 論理管理操作が運用管理製品を呼び出す前に、その論理管理操作に必要なすべての処理ロジックを実行する。

4. 運用管理製品を呼び出す。

5. 運用管理製品の応答を処理する (該当する場合)。

6. 応答オブジェクトまたは応答オブジェクト・セットに戻りデータを取り込む (該当する場合)。

7. 処理情報を呼び出し元に返す。


エンドポイント呼び出しチャネルを含む統合モジュールはエンドポイントを使用する必要があります。Java クラスの統合モジュールはエンドポイントまたはカスタム・アプローチを使用して外部サービスを呼び出すことができます。

エンドポイントには、使用するトランスポート・メカニズムを指定する URL プロパティーおよびハンドラー・プロパティーが含まれます。Web サービス・ハンドラーを使用するエンドポイントには、コマンド行ハンドラーを使用するエンドポイントとは異なるプロパティーが含まれます。統合モジュール・エンドポイントおよびエンドポイント・プロパティーは、実行時にプロセス管理製品がエンドポイント・プロパティーを統合モジュールへの入力として渡すときに上書きすることができます。資格情報マッパーから返された USERNAME および PASSWORD プロパティーも、エンドポイント・プロパティーを指定変更することができます。

Java 統合モジュールは、エンドポイントを使用せずに、直接運用管理製品または外部統合モジュールと通信することができます。エンドポイントを使用しないことで、Java 統合モジュールがソース・オブジェクトを必要な XML フォーマットに変換する必要がなくなります。エンドポイントを使用しない場合、運用管理製品でサポートされているどの通信プロトコルでも使用できるようになります。統合モジュールではエンドポイントを使用する必要がありません。統合モジュール・プロパティーを使用すると、運用管理製品と通信できるように統合モジュールを構成することができます。

統合フレームワークには、HTTP や Web サービスなどの通信プロトコルをサポートする定義済みのハンドラーが用意されています。使用可能な定義済みのハンドラーの中に運用管理製品のサービス・プロトコルをサポートするものがない場合は、外部統合モジュールを実装してください。外部統合モジュールは、使用可能なハンドラー・プロトコルのいずれかを使用できる運用管理製品サービスとのインターフェースの働きをします。これに代わる解決策として、運用管理製品サービス・プロトコルをサポートするカスタム・ハンドラーを作成する方法があります。

各製品用に個別のプロトコルを設定するには、運用管理製品ごとにそれぞれ異なるエンドポイントを構成します。エンドポイント用に定義するハンドラーは、統合モジュール用に構成するハンドラーと一致している必要があります。

呼び出しチャネルに基づく統合モジュールには、エンドポイントが必要です。エンドポイント名は、統合フレームワークが入力として呼び出しチャネルに渡すパラメーターの 1 つです。統合モジュールの呼び出し元はエンドポイント名を指定変更することができます。

運用管理製品との通信にエンドポイント・ハンドラーを使用するかどうかに関係なく、統合モジュールは、1 回の論理管理操作の実行に対して運用管理製品を複数回呼び出す必要がある、というシナリオに対応できなければなりません。

呼び出しチャネルまたは Java クラスの実装統合モジュールは Java クラスまたは呼び出しチャネルとして実装することができます。統合モジュールを開発する前に、呼び出しチャネルを使用する場合と Java クラスを使用する場合の、それぞれの利点と欠点について検討してください。


呼び出しチャネルと Java クラスの比較統合モジュールを開発する前に、Java クラスまたは呼び出しチャネルを使用する場合の利点と欠点について検討してください。

呼び出しチャネルを使用する場合の利点と欠点

呼び出しチャネルを使用して統合モジュールを実装する場合、次のような利点があります。

v 呼び出しチャネルは複雑なデータをエンドポイントに渡す場合に有効です。また、ソース・オブジェクトのフィールドとエンドポイントに必要な入力との間に明確なマッピングを定義できる場合にも有効です。

v 入力および出力トランザクションの階層オブジェクト構造をサポートできる。

v 統合フレームワークでは、オブジェクトから XML、および XML からオブジェクトへの変換が実施されます。

v インバウンドおよびアウトバウンド・トランザクション用に処理クラス、ユーザー出口、および XSL マッピングを使用するように構成できる。

v 統合フレームワークがエンドポイントの呼び出しを行う。

v 統合モジュールまたは論理管理操作との関連付けがなくても、直接呼び出すことができる。

v アプリケーション・サーバーの再始動が不要なシステム構成を使用して、単純な統合を実装できる。

呼び出しチャネルを使用して統合モジュールを実装する場合、次のような欠点があります。

v 呼び出しが単純に行える場合でも、システムによる成果物の登録と構成の作業がより多く必要となる。

v 複数の異なるビジネス・オブジェクトを含む統合モジュールは複数のアプリケーションによって使用できない。

v 統合フレームワークに関してさらに多くの知識が必要。

v 構成済みのエンドポイントの呼び出しは 1 回しかサポートされない。複数回の呼び出しをサポートするには、追加のコーディングが必要です。

v 長時間実行のサービスをサポートするには、追加のコーディングが必要。デフォルトでは、呼び出しチャネルはエンドポイントからの応答を待ちます。

Java クラスを使用する場合の利点と欠点

Java クラスを使用して統合モジュールを実装する場合、次のような利点があります。

v システムによる成果物の登録と構成作業が少なくて済む。

v 複数の異なるビジネス・オブジェクトを使用しているときに、複数のアプリケーションによって使用できる。

v 複数の外部呼び出しを実行できように設計可能。

v 異なる論理管理操作および運用管理製品に対して、異なる通信プロトコルを使用できる。

v 長時間実行サービスに対応できるよう、別のスレッドの使用がサポートされている。


v 入力構成と出力構成が異なる場合でも、複数の論理管理操作を実装できる。

v 外部統合モジュールの使用が必要となる可能性が少ない。

Java クラスを使用して統合モジュールを実装する場合、次のような欠点があります。

v より多くの Java コーディングを実行する必要がある。

v 入力または出力として上位階層と下位階層の関係を使用するオブジェクト構造をサポートしていない。上位階層オブジェクトしか入力として使用できず、Java コードによって下位階層関係を検出する必要があります。

v エンドポイント・ハンドラーを使用する場合に、オブジェクトから XML およびXML からオブジェクトへの変換をコーディングする必要がある。

v 統合モジュールの設計にカスタマイズを組み込む必要がある。コードの再導入を行わない限り、カスタマイズを後で追加することはできない。

v エンドポイント・ハンドラーなどの統合フレームワーク・コンポーネントを使用するには、Java クラス内でのコーディングが必要。

呼び出しチャネルの実装呼び出しチャネルの場合、メッセージ・データの内容を拡張するためにその実装の中でオブジェクト構造が使用されます。オブジェクト構造は、工程管理製品がソース・オブジェクトとして渡すオブジェクトを使用して、複数の関連オブジェクトから成る 1 つのレコードを作成します。

オブジェクト構造で指定されたオブジェクトは、XML メッセージの作成で使用されます。呼び出しチャネルを使用する場合、データは、関連付けられたオブジェクト構造に対して指定された XML スキーマに準拠していなければなりません。また、呼び出しチャネル用のエンドポイントを定義する必要があります。

呼び出しチャネルは、オプションのインバウンドおよびアウトバウンド処理出口クラスをサポートします。統合フレームワークは、処理出口クラスを使用して、追加のロジックを実装します。インバウンドおよびアウトバウンド処理出口クラスは、Java クラス psdi.iface.migexits.ExternalExit のインスタンスでなければなりません。

アウトバウンド・トランザクションの場合、統合フレームワークは以下のメソッドを呼び出します。

public StructureData setDataOut(StructureData irData)

インバウンド・トランザクションの場合、統合フレームワークは以下のメソッドを呼び出します。

public StructureData setDataIn(StructureData erData)

これらのメソッドを指定変更すると、追加の統合モジュール処理を実行することができます。呼び出しチャネルに渡されるプロパティーは、処理クラスで使用することができます。

次のアウトバウンド処理クラス・コードは、呼び出しチャネルの実行時に運用管理製品のグローバル・ユニーク ID を取得する方法を示しています。


import psdi.server.MXServer;import psdi.iface.omp.IMConstants;import psdi.iface.omp.OmpServiceRemote;import psdi.iface.mic.*;import psdi.iface.migexits.*;...public class OutboundCIExit extends ExternalExit implements IMConstants{public StructureData setDataOut(StructureData irData)throws MXException,RemoteException{IntegrationContext cntx = IntegrationContext.getCurrentContext();String ompGUID = cntx.getStringProperty(OMPGUID);...

}}

呼び出しチャネルの追加機能には、ユーザー出口 Java クラスおよび XSL マッピング層があります。XSL マッピング層は、XML マッピングまたはデータ変換を行うように構成することができます。

統合モジュールの呼び出しに必要なオブジェクト構造が存在しない場合は、「オブジェクト構造」アプリケーションでオブジェクト構造を作成できます。また、MXINTOBJECT オブジェクト構造で XML を使用すると、インストール・プロセスの一環としてオブジェクト構造を作成することもできます。

Java クラスの実装Java クラス・ファイルを使用するために統合モジュールを実装することができます。Java クラス・ファイルを使用すると、統合コンポーネントの登録と構成を行う必要がなくなります。さらに、基礎となっている統合モジュールの実装はすべて、工程管理製品に対して透過的に行うことができます。

Java クラスの統合モジュールでは、psdi.iface.mic.ServiceInvoker Java インターフェースを実装する必要があります。サービス呼び出し側の Java インターフェースは、businessobjects.jar ファイルに含まれています。統合モジュールの Java クラスは、実行時にシステム・クラス・パスに組み込みます。

サービス呼び出し側の Java インターフェースには、次のメソッド・シグニチャーのさまざまなバリエーションが含まれています。

public byte[] invoke(Map String,Object metaData, MboRemote sourceMbo,

MboRemote targetMbo, String endPointName) throws MXException,

RemoteException;

v metaData は、以下を含む名前と値のプロパティーのマップです。

– 統合モジュールの名前とバージョン。

– 論理管理操作の名前とネーム・スペース。

– 運用管理製品のグローバル・ユニーク ID。

– 上書きされるエンドポイント名とエンドポイント・プロパティー。


v sourceMbo は、論理管理操作で定義したソース・オブジェクトです。

v targetMbo は、論理管理操作で定義した応答オブジェクトです。

v endPointName は、運用管理製品との通信に使用するエンドポイントの名前です。

複数の論理管理操作を実装するように統合モジュールを構成した場合、どの論理管理操作を呼び出すかをその統合モジュールが決定する必要があります。統合モジュールは、実行時に以下の metaData 入力マップから LMONAME およびLMONAMESPACE プロパティーを取得します。

import psdi.iface.omp.IMConstants;...String lmoName = metaData.get(IMConstants.LMONAME);String lmoNamespace =metaData.get(IMConstants.LMONAMESPACE);

統合モジュールは論理管理操作のデータをソース・オブジェクトから取得することができます。次のコード例では、論理管理操作の値がソース・オブジェクトから取得されます。

String guid = sourceMbo.getString("GUID");int packID = sourceMbo.getInt("PACKID");boolean hasSubs = sourceMbo.getBoolean("HASSUBS");

この例で、論理管理操作にはグローバル・ユニーク ID と呼ばれる英数字の入力属性、PACKID という整数属性、および HASSUBS というブール型属性が含まれています。

サービス呼び出し側のメソッドは、ソース入力として単一の MboRemote 値ではなく、MboSetRemote 値セットを取ることができます。場合により、統合モジュールがオブジェクト・セット内のすべてのオブジェクトを運用管理製品に渡すことがあります。そうでない場合、統合モジュールはオブジェクト・セットの最初のオブジェクトのみを渡します。統合モジュールの動作に適用される設定済みのルールはありませんが、想定される動作を論理管理操作の説明の中で明確に定義する必要があります。

統合モジュールの処理プロセス管理製品は、システム・アクションを使用して統合モジュールを開始します。このアクションは、エスカレーションまたはワークフローと関連付けることができますが、メニュー項目またはボタンから開始することもできます。プロセス管理製品は、統合モジュールを呼び出し、統合モジュールが返す応答を処理するアクション・クラスを提供します。

統合コンポーネントの識別開始アクション・クラスは、統合のために必要なコンポーネント (論理管理操作、運用管理製品、および統合モジュールなど) を識別します。

論理管理操作は、運用管理製品を使用して構成アイテムでソフトウェア導入などのプロセスを実行します。工程管理製品は、論理管理操作で定義されたビジネス・オブジェクトおよび属性の入力に基づいて、統合モジュールに必要な入力を提供します。


Java アクション・クラスは、選択された構成アイテムで論理管理操作を実行する運用管理製品を指定します。構成アイテムと運用管理製品をインストールすると、コンポーネントの関係もインストールされます。

統合モジュール・レコードは、どの論理管理操作が運用管理製品でサポートされているかを示します。統合モジュール、構成アイテム、および運用管理製品が登録されると、工程管理製品の Java クラスがルックアップを実行します。この Java クラスは、自身が使用する構成アイテムに基づいて、呼び出す統合モジュールを判断します。

統合フレームワークには、このクラスによる統合モジュールのルックアップを支援する以下のユーティリティー・メソッドを提供するサービスが含まれています。

ユーティリティー・メソッド機能

psdi.iface.app.omp.OmpSetRemote getOMPListForIM

(String imName, String imVersion)

統合モジュールに関連付けられている運用管理製品のリストを取得します。

psdi.iface.app.im.MaxIMSetRemote getIMListForLMO

(String lmoName, String lmoNamespace)

指定された論理管理操作を実装する統合モジュールのリストを取得します。

psdi.iface.app.im.MaxIMSetRemote

getIMListForLMOWithOMP (String lmoName, String

lmoNamespace)

いずれかの運用管理製品上に指定された論理管理操作を実装する統合モジュールのリストを取得します。

psdi.iface.app.im.MaxIMSetRemote getIMListForOMP

(String ompGuid)

運用管理製品上に少なくとも 1 つの論理管理操作を実装する統合モジュールのリストを取得します。

Collection getIMListForOMPAndLMO (String ompGUID,

String lmoName, String lmoNamespace)

指定された運用管理製品上に論理管理操作を実装する統合モジュールのリストを取得します。

psdi.iface.omp.OmpImLmoRelInfo オブジェクトのコレクションを返します。

Collection getIMListForOMPAndLMO (String ompHostname,

String ompProductname, String ompManufacturer,

String lmoName, String lmoNamespace)

指定された運用管理製品上に論理管理操作を実装する統合モジュールのリストを取得します。

psdi.iface.omp.OmpImLmoRelInfo オブジェクトのコレクションを返します。

psdi.iface.omp.OmpImLmoRelInfo getPreferredIM

(String ompGUID, String lmoName, String

lmoNamespace)

指定された運用管理製品上に論理管理操作を実装する、推奨された統合モジュールを取得します。

psdi.iface.omp.OmpImLmoRelInfo getPreferredIM

(String ompHostname, String ompProductname, String

ompManufacturer, String lmoName, String

lmoNamespace)

指定された運用管理製品上に論理管理操作を実装する、推奨された統合モジュールを取得します。

統合モジュールの呼び出し統合モジュールは、Java クラスまたは呼び出しチャネルのいずれかとして実装できます。統合モジュールのインスタンスは、Java インターフェースpsdi.iface.mic.ServiceInvoker を実装しているために、サービス呼び出し側と呼ばれます。


サービス呼び出し側のインターフェースは、基礎となっている実装が呼び出し元から見えないように隠します。呼び出し元による統合モジュールの呼び出しは、基礎にある実装に関係なく同じになります。

サービス呼び出し側のプロパティー・マップ:

get service invoker ユーティリティー・メソッドは、名前と値のペアのマップを返します。

psdi.iface.omp.IMConstants Java インターフェースは、このマップで返されるプロパティーの名前を定義します。プロパティー IMConstants.IM には、プロセス管理製品が呼び出す統合モジュールのインスタンスが含まれています。

プロパティー IMConstants.ENDPOINTNAME には、運用管理製品、統合モジュール、および論理管理操作の関係で関連付けられたエンドポイントの名前が含まれています。ほとんどの場合、エンドポイント・プロパティーは工程管理製品が統合モジュールに渡す値です。ただし、まれにアクション・クラスが構成済みのエンドポイントを上書きする場合があります。

資格情報マッパーが構成されている場合、get service invoker ユーティリティー・メソッドは資格情報マッパーを呼び出して、エンドポイントの通信用に使用されるUSERNAME と PASSWORD を取得します。これらのプロパティーは、プロパティー IMConstants.ENDPOINTPROPS によって識別される、マップ内のユーティリティー・メソッドによって返されます。呼び出し元はエンドポイント・プロパティーをこのマップに追加して、そのプロパティーを上書きすることができます。

アクション・クラスは、統合モジュールを呼び出す前にソース・オブジェクトに論理管理操作の入力フィールドを取り込まなければなりません。この後アクション・クラスは、get service invoker ユーティリティー・メソッドによって返されたマッピングを添えてソース・オブジェクト・データを統合モジュールに渡します。必要な場合、アクション・クラスは論理管理操作の応答オブジェクトを統合モジュールに提供します。

論理管理操作の応答オブジェクトには属性が必要です。アクション・クラスは、その応答オブジェクトに論理管理操作の属性があることを確認しなければなりません。この属性は永続または非永続のどちらでもかまいません。通常、この応答オブジェクトにはソース・オブジェクト・データが含まれています。

呼び出しメソッド:

統合フレームワークには、呼び出し元が統合モジュールの呼び出しに使用する呼び出しメソッドがいくつか用意されています。呼び出しメソッドはプロパティーを使用して、どのオブジェクト・データが呼び出し元に返されるかを決定します。さらにこれらのプロパティーによって、返されたデータに対して実行されるアクション、および統合フレームワークが呼び出し元と通信する方法が決定されます。

サービス呼び出し側インターフェースには、以下の 4 つの呼び出しメソッド・シグニチャーがあります。

v public byte[] invoke(Map <String,Object> metaData, MboRemote sourceMbo,

MboRemote targetMbo, String endPointName)


v public byte[] invoke(Map <String,Object> metaData, MboRemote sourceMbo,

MboSetRemote targetMboSet, int action, String endPointName)

v public byte[] invoke(Map <String,Object> metaData, MboSetRemote

sourceMboSet, MboRemote targetMbo, String endPointName)

v public byte[] invoke(Map <String,Object> metaData, MboSetRemote

sourceMboSet, MboSetRemote targetMboSet, int action, String endPointName)

アクション・クラスは、インスタンス化されたサービス呼び出し側で呼び出しメソッドのいずれかを呼び出す際に、以下のプロパティーを渡します。


メタデータ get service invoker ユーティリティー・メソッドが返すプロパティー・マップ。

ソース・オブジェクトおよびオブジェクト・セット

論理管理操作で定義された入力属性を含むオブジェクト。このプロパティーには NULL

値を含めることができます。

ターゲット・オブジェクトおよびオブジェクト・セット

戻りデータを含むオブジェクトおよびオブジェクト・セット。このプロパティーにはNULL 値を含めることができます。

アクションこのパラメーターは、targetMboSet 内の既存のオブジェクトを更新するか、新しいオブジェクトを追加するかを示します。

アクションに指定できる値は以下です。

v psdi.mbo.MboSetRemote.INSERTONLY

v psdi.mbo.MboSetRemote.UPDATEONLY

エンドポイント名統合モジュールが通信用に使用するエンドポイントの名前。

運用管理製品のサービス・メソッド:

アクション・クラスに構成アイテムとの関係がある場合、または構成アイテム・グローバル・ユニーク ID (CIGUID) 属性がある場合は、運用管理製品のサービス・メソッドを使用します。

アクション・クラスに実際の構成アイテムではなく認定済み構成アイテムがある場合は、その認定済み構成アイテムの構成アイテム・グローバル・ユニーク ID 属性を使用することができます。

次のサービス・メソッドは、推奨される統合モジュール (サービス呼び出し側) のリストを取得します。統合モジュールは、指定された実際の構成アイテムを管理する運用管理製品上に、指定された論理管理操作を実装します。

public Collection Map getServiceInvokerListForCIAndLMO(String actCIGUID,

String lmoName, String lmoNamespace, UserInfo userInfo)

指定された実際の構成アイテムとの関係を持つ各運用管理製品は、その論理管理操作に関して推奨されている統合モジュールを返します。


サービス呼び出し側のユーティリティー・メソッド:

getServiceInvoker ユーティリティーには、論理管理操作および運用管理製品用の統合モジュールのインスタンスを取得するためのメソッドが含まれています。

以下の表に、getServiceInvoker ユーティリティーで提供されるユーティリティー・メソッドをリストします。

ユーティリティー・メソッド機能

Map<String, Object> getServiceInvoker

(psdi.iface.omp.OmpImLmoRelInfo ompImLmoRelInfo,

psdi.security.UserInfo userInfo)

指定された統合モジュール、論理管理操作、および運用管理製品用のサービス呼び出し側を取得します。

Map<String, Object> getServiceInvoker

(psdi.iface.app.im.OmpImLmoRelRemote

ompImLmoRelRemote, psdi.security.UserInfo userInfo)


Map<String, Object> getServiceInvoker (String

ompGUID, String imName, String imVersion, String

lmoName, String lmoNamespace, psdi.security.UserInfo

userInfo)


Map<String, Object> getServiceInvoker (String

ompGUID, String lmoName, String lmoNamespace,

psdi.security.UserInfo userInfo)

指定された運用管理製品および論理管理操作用に推奨される統合モジュールのサービス呼び出し側を取得します。

Collection<Map> getServiceInvokerListForCIAndLMO

(String actCIGUID, String lmoName, String

lmoNamespace, psdi.security.UserInfo userInfo)

運用管理製品上に指定された論理管理操作を実装する推奨統合モジュールのサービス呼び出し側のリストを取得します。

運用管理製品には構成アイテムとの関係があります。

統合モジュールの応答処理論理管理操作に応答オブジェクトがある場合、統合モジュールはその呼び出しからの結果を適用して応答オブジェクトを更新します。その結果をデータベースに保存するかどうかは、アクション・クラスが決定します。アクション・クラスが結果を保存しない場合は、ユーザー・インターフェースで応答結果を表示するときにそのデータを保存できます。

応答オブジェクトがアプリケーションからのプライマリー・オブジェクトである場合、または更新されたオブジェクトがアプリケーションのプライマリー・オブジェクトとの関係に基づく場合、アクション・クラスはそのオブジェクトを保存しません。それに代わり、ユーザー・インターフェースからオブジェクトの保存を促すプロンプトが出されます。ただし、更新されたオブジェクトがアプリケーションのプライマリー・オブジェクトとの関係を持たない場合、アクション・クラスは変更内容を保存してコミットします。

統合モジュールの構成統合モジュールは、プロセス管理製品からデータ要求を受け取り、運用管理製品からの応答データを返します。


統合モジュールの作成統合モジュールを作成すると、ローカル・アプリケーションと外部アプリケーションの間のデータを受け渡すことができます。必要に応じて、統合モジュールを呼び出しチャネルまたは Java クラスとして実装できます。呼び出しチャネルおよびJava クラスは両方とも、プロセス管理製品が統合モジュールを起動するときに、データベースおよびメモリー内のすべてのオブジェクトにアクセスします。

手順1. 統合モジュール・アプリケーションで、「新規統合モジュール」をクリックします。

2. 「名前」フィールドに統合モジュールの名前を入力し、「バージョン」フィールドに、バージョン番号を入力します。この名前とバージョン番号の組み合わせは固有です。「バージョン」フィールドの値は、V で始まり、その後に 1 つの整数値 (0 から 9) が続きます。この整数値の後に、小数点 (.) と最大 17 桁の整数値を追加できます。例えば、V2.99. または V9.123456 です。



運用管理製品名統合モジュールが呼び出す運用管理製品。1

つの統合モジュールを複数の製品で使用する場合は、製品名は指定しません。

運用管理製品バージョン統合モジュールが呼び出す製品のバージョン。1 つの統合モジュールが運用管理製品の複数バージョンで機能する場合は、バージョン値を指定しません。

ハンドラー名統合モジュールが運用管理製品を呼び出すために使用するプロトコル。関連付けられているエンドポイントが呼び出しチャネルにある場合は、統合モジュール用のハンドラーを構成することはできません。

呼び出しチャネル名統合モジュールを実行する呼び出しチャネルの名前。統合モジュールは、呼び出しチャネルまたは Java クラスを使用します。いずれか一方のみを指定してください。

クラス名統合モジュールを実行する Java クラスの名前。統合モジュールは、呼び出しチャネルまたは Java クラスを使用します。いずれか一方のみを指定してください。

4. 「統合モジュールの保存」をクリックします。

次のタスク

論理管理操作を統合モジュールに関連付け、プロセス・マネージャーが実行するアクションを定義できます。また、統合モジュールに運用管理製品を関連付け、プロセス管理製品から呼び出すことができる外部アプリケーションを定義することもできます。


統合モジュールの論理管理操作の選択「操作の選択」ダイアログ・ボックスを使用して、1 つの統合モジュール・レコードに 1 つ以上の論理管理操作を関連付けることができます。論理管理操作は、プロセス・マネージャー製品がアプリケーションから実行するアクションを定義します。

始める前に

まず、論理管理操作を運用管理製品に関連付けてから、プロセス管理製品が論理管理操作を実行できるようにする必要があります。呼び出しチャネルで使用する統合モジュールに関連付ける論理管理操作レコードには、「ソース・オブジェクト名」の値が必要です。この値は、呼び出しチャネルに登録されている最上位のソース・オブジェクトと同じにする必要があります。また、呼び出しチャネルで応答を処理する場合、論理管理操作レコードには応答オブジェクト名の値が必要です。この値は、呼び出しチャネルに登録されている最上位のオブジェクトと同じにする必要があります。論理管理操作アプリケーションで論理管理操作ソースと応答オブジェクト値を定義できます。

手順1. 統合モジュール・アプリケーションで、論理管理操作に関連付ける統合モジュール・レコードを選択します。

2. 「論理管理操作」タブで「操作の選択」をクリックします。

3. 統合モジュール・レコードに関連付ける論理管理操作を選択します。



次のタスク

統合モジュールに運用管理製品を関連付け、プロセス管理製品から呼び出すことができる外部アプリケーションを定義できます。

運用管理製品の論理管理操作の選択:

「操作の選択」ダイアログ・ボックスを使用して、運用管理製品に 1 つ以上の論理管理操作を関連付けます。運用管理製品との関連付けにより、論理管理操作が有効になります。この有効化により、論理管理操作が使用可能になります。

始める前に

運用管理製品で論理管理操作を有効にする前に、論理管理操作を統合モジュールに関連付ける必要があります。

手順

1. 統合モジュール・アプリケーションで、論理管理操作に関連付ける統合モジュール・レコードを選択します。

2. 「運用管理製品」サブタブで、論理管理操作に関連付ける運用管理製品を選択します。

3. 「運用管理製品の論理管理操作」テーブル・ウィンドウで、「操作の選択」をクリックします。


4. 運用管理製品用に使用可能にする論理管理製品を選択します。



論理管理操作の統合モジュールとの関連付け論理管理操作を統合モジュールに関連付け、運用管理製品で実行するアクションを定義できます。変更やデプロイなどのプロセス管理製品は、統合モジュールを呼び出して運用管理製品を実行します。その後に運用管理製品がデプロイ・ソフトウェアなどの論理管理製品を実行して、プロセス管理製品にアクション・ステータスを通知します。

始める前に

まず、論理管理操作を運用管理製品に関連付けてから、プロセス管理製品が論理管理操作を実行できるようにする必要があります。呼び出しチャネルで使用する統合モジュールに関連付ける論理管理操作レコードには、「ソース・オブジェクト名」の値が必要です。この値は、呼び出しチャネルに登録されている最上位のソース・オブジェクトと同じにする必要があります。また、呼び出しチャネルで応答を処理する場合、論理管理操作レコードには応答オブジェクト名の値が必要です。この値は、呼び出しチャネルに登録されている最上位のオブジェクトと同じにする必要があります。論理管理操作アプリケーションで論理管理操作ソースと応答オブジェクト値を定義できます。


呼び出しパターンの値によって、論理管理操作が長時間実行されるのかどうかが決定されます。さらに、プロセス管理製品が運用管理製品に応答を求める方法も決定されます。

手順1. 統合モジュール・アプリケーションで、論理管理操作に関連付ける統合モジュールを選択します。

2. 「論理管理操作」サブタブで、「新規行」をクリックします。



論理管理操作名統合モジュールがサポートするアクション、およびプロセス管理製品が要求するアクションを指定します。

名前空間論理管理操作名のドメインを指定します。例として com.ibm.mss などがあります。


次のタスク

統合モジュールに運用管理製品を関連付け、プロセス管理製品から呼び出すことができる外部アプリケーションを定義できます。


運用管理製品の統合モジュールとの関連付け:

統合モジュールに運用管理製品を関連付け、プロセス管理製品から呼び出すことができる外部アプリケーションを定義できます。変更やデプロイなどのプロセス管理製品は、統合モジュールを呼び出して運用管理製品を実行します。その後に運用管理製品がデプロイ・ソフトウェアなどの論理管理製品を実行して、プロセス管理製品にアクション・ステータスを通知します。

始める前に

プロセス管理製品が統合モジュールを呼び出して、運用管理製品で論理管理操作を実行できるようにするには、以下のコンポーネントを構成します。

v 論理管理操作を定義して、構成する

v 統合モジュールを、論理管理操作および運用管理製品に関連付ける

v 統合モジュールの論理管理操作を、運用管理製品で使用可能にする


統合モジュール、運用管理製品、および論理管理操作の間の関係を作成および構成できます。また、以下のアクションを実行できます。

v 複数の運用管理製品を統合モジュールに関連付ける

v 統合モジュールの論理管理操作を、運用管理製品で使用可能にする

v 運用管理製品で特定の論理管理操作に使用するデフォルトの統合モジュールを指定する

v 統合モジュールと運用管理製品の組み合わせ用のエンドポイントを構成する (呼び出しチャネルにエンドポイントが関連付けられていない場合)

手順

1. 統合モジュール・アプリケーションで、運用管理製品に関連付ける統合モジュールを選択します。

2. 「運用管理製品」サブタブで、「新規行」をクリックします。


v 運用管理製品


4. 「論理管理操作」テーブル・ウィンドウで、「新規行」をクリックします。

5. 「論理操作管理名 (Logical Operation Management Name)」フィールドに値を入力します。「ネーム・スペース」および「説明」フィールドにデフォルト値が表示されます。

6. オプション: 「プライマリーですか」チェック・ボックスを選択して、この統合モジュールを、選択した論理管理操作のデフォルトの統合モジュールにします。選択した論理管理操作を複数の統合モジュール・レコードで使用可能にする場合は、「プライマリーですか」チェック・ボックスを選択します。



次のタスク

論理管理操作を統合モジュールに関連付け、運用管理製品で実行するアクションを定義できます。

論理管理操作の構成論理管理操作を作成して、統合フレームワークからプロセス管理製品が実行するアクションを定義できます。論理管理操作が使用する特定のオブジェクト・フィールド属性を定義することもできます。

論理管理操作の作成論理管理操作で呼び出しパターンを定義することができます。パターンの値によって、論理管理操作が長時間実行されるかどうか、およびプロセス管理製品が運用管理製品に応答を求める方法が決定されます。

始める前に

プロセスを呼び出すには、運用管理製品および統合モジュールに対する論理管理操作の関係を定義しする必要があります。

手順1. 論理管理アプリケーションで「新規論理管理操作」をクリックします。

2. 「名前」フィールドに論理管理操作 ID を指定します。



ソース・オブジェクト名論理管理操作の入力オブジェクト。

呼び出しパターン論理管理操作の呼び出しのパターン。

名前空間論理管理操作レコードのセカンダリー ID。

応答オブジェクト名論理管理操作のオブジェクトの出力。

4. 「論理管理操作の保存」をクリックします。

属性の論理管理操作への追加論理管理操作に属性を追加して、論理管理操作データのソースとターゲットが使用する特定のオブジェクト・フィールド属性を指定することができます。入力と出力の両方の論理管理操作呼び出しについて、個別の属性エントリーを定義できます。


入力オブジェクト属性は、プロセス管理製品が統合モジュールに渡すデータを指定します。出力オブジェクト属性は、統合モジュールが返すデータを指定します。フィールド選択に使用可能な属性は、選択したソース・オブジェクトおよび応答オブジェクトのそれぞれの属性のみです。ソース・オブジェクトまたは応答オブジェクトのいずれも定義しない場合は、すべてのオブジェクト属性が選択項目として使用可能になります。


手順1. 論理管理操作アプリケーションで、属性を追加する論理管理操作を選択します。

2. 「LMO の属性」ウィンドウで、「新規行」をクリックします。

3. 「名前」フィールドに値を入力します。

4. オプション: 属性が論理管理操作呼び出しの出力用であることを示すには、「入力」チェック・ボックスをクリアします。

5. オプション: 論理管理操作の呼び出しでフィールド属性が不要であることを示すには、「必須」チェック・ボックスをクリアします。

「コンテキストでの起動」機能「コンテキストでの起動」アプリケーションを使用して、同じブラウザー・セッションまたは異なるブラウザー・セッションで外部アプリケーションを開く起動エントリー・レコードを作成および変更します。アプリケーション統合シナリオとは無関係に。またはその一部として、アプリケーションを開くことができます。

起動エントリー・レコードは、アプリケーション・デザイナーの以下のオプションを使用して外部アプリケーションを開くことができます。

v アクション・メニュー項目

v ハイパーリンク

v ボタン

「コンテキスト内での起動」アプリケーションを使用して、起動エントリーを作成および更新することができます。起動エントリーは外部アプリケーション用のコンソールを開く URL を定義します。起動エントリーは、アプリケーションから外部コンソールにコンテキストと呼ばれるデータを渡すことができます。コンソールURL は Web ベースのコンソールを使用する任意のアプリケーションに対して構成できます。さらに、Java™ Web Start を使用するコンソールに対してもコンソールURL を構成することができます。起動エントリーは、Web に対応していないアプリケーションを開く場合には使用できません。任意のアプリケーションからの起動ポイントを構成できます。

外部アプリケーションの準備ほとんどの外部アプリケーションには、URL から Web ブラウザーに開くことができる Web ベースのコンソールがあります。「コンテキストでの起動」機能がサポートするコンソール・タイプには、Webアプリケーション (サーブレットまたはJSP)、ポータル、および Java Web Start があります。

ナビゲーションを実行するには、外部アプリケーション・コンソールが、URL で渡されるデータを受け入れる「コンテキスト内で取得」機能をサポートしている必要があります。外部コンソールは URL を使用して、その URL で渡されたデータを表示するウィンドウを開きます。

外部アプリケーションに「コンテキスト内で取得」機能がない場合は、「コンテキストでの起動」機能が、コンテキスト・データが含まれていない標準の開始ページをコンソール内に開くことができます。アプリケーションがシングル・サインオン認証をサポートしている場合、アプリケーション・ユーザーは認証され、外部コン


ソールに誘導されます。シングル・サインオン認証が実装されていない場合は、外部コンソールが、アプリケーション・ユーザーを認証するためのログイン・パネルを開きます。

外部アプリケーションへの起動エントリー URL起動エントリー URL 値には、アプリケーションで表示する関連ビジネス・オブジェクトからのデータを使用する置換変数を含めることができます。

例えば、担当者アプリケーションに実装されている起動エントリーの場合、属性名{attributename} を使用して名前の値を URL ストリングに代入することができます。以下の URL は、PERSONNAME 属性を使用する担当者アプリケーションのURL です。

https://extsyshost:9045/tcWebUI/interactionhandler?actionId=viewPerson

&Person={PERSONNAME}

関係名および属性名 {relationshipname.attributename} を指定すると、メイン・ビジネス・オブジェクトに関連するオブジェクトからの属性を提供することもできます。次の URL には住所の「市町村」属性が含まれます。ADDRESS オブジェクトが関係名 ADDRESS により PERSON オブジェクトに関連付けられている場合は、担当者アプリケーションで以下の URLを使用します。

https://extsyshost:9045/WebUI/interactionhandler?actionId=viewCity

&cityname={ADDRESS.CITY}

運用管理製品コンソールを起動する場合は、URL に {sourcetoken} 値および{reportinghostname} 値を使用します。

製品アプリケーションへの起動エントリー URL起動エントリー URL 値には、属性変数および SQL Where 文節変数を含めることができます。

外部アプリケーションは、製品を起動したり、特定の製品アプリケーションを開いたり、表示する特定のビジネス・オブジェクトを検索したりすることができます。

製品を起動すると、製品のサインオン画面が表示されます。ユーザーがサインオンすると、指定されたアプリケーションが開きます。オプションで、ユーザー名およびパスワードを URL に組み込んでサインオン画面をバイパスできますが、これができるのは Secure Socket Layer (SSL) が構成されて HTTP アクセスが保護されている場合のみです。

製品を起動する URL の形式は以下のとおりです。

http://<server>:<port>/<maximo>/ui/<product.jsp>?event=loadapp&value=<appID>

以下の例の URL では、作業指示書管理アプリケーションを開き、ID が 1000 の作業指示書を表示します。

http://<server>:<port>/<maximo>/ui/<maximo.jsp>?event=loadapp&value=<wotrack>

&attrname1=<WONUM>&attrvalue1=<1000>:


レコードの検索はアプリケーションの「一覧」タブの動作に似ていて、フィルター行のカラム全体にわたって複数の値が取り込まれます。属性の名前は、起動されるアプリケーションのプライマリー MBO のデータベース名です。

拡張検索が必要な場合、以下の例で使用されている形式で、SQL WHERE 文節をURL に追加することができます。

http://:<server>:<port>/maximo/ui/maximo.jsp?event=loadapp&value=wotrack

&sqlwhere=WONUM%3D1000

送信者は有効な URL を指定する必要があります。前の例では、無効な「=」値が「%3D」に変換されています。

URL に属性タイプ・パラメーターと SQL Where 文節パラメーターの両方が含まれている場合、SQL Where 文節パラメーターが使用され、属性タイプ・パラメーターは無視されます。

コンテキストでの起動の有効化外部アプリケーションでコンテキスト・データを含む可能性のあるブラウザー・ウィンドウを開くには、ユーザーが、ソース・アプリケーションでその起動をアクティブ化できることが必要です。さらにユーザーには、メニュー項目またはツールバー・ボタンを表示するためのセキュリティー権限も必要です。リモート・アプリケーションからのウィンドウ要求を受け入れるよう、ターゲット・アプリケーションを構成する必要があり、そのトランザクションを保護するための手配を整えることも必要です。

起動エントリーの作成起動エントリーを作成して、同じブラウザー・セッションまたは新規のブラウザー・セッションで、外部アプリケーションを開くことができます。起動エントリー・レコードは、アプリケーションと外部運用管理製品または Web サイトとの間に Web サイト・ベースのリンクを作成します。

手順1. コンテキストでの起動アプリケーションで、「新規起動エントリー」をクリックします。

2. 「起動エントリー名」フィールドに、起動エントリー ID を指定します。

3. 「コンソールの URL」フィールドに、ブラウザー・セッションで開く Web サイトの URL か、運用管理製品のコンソールの URL を指定します。

4. 「ターゲット・ブラウザー・ウィンドウ」フィールドに、以下のいずれかの値を指定します。

v _usecurrent 値 (デフォルト) は、現在のブラウザー・セッションでアプリケーションまたは Web サイトを開きます。

v _blank 値は、新規ブラウザー・セッションでアプリケーションまたは Web

サイトを開きます。

5. オプション: 起動エントリーのターゲットが運用管理製品のコンソールの場合、「OMP 製品名」フィールドおよび「OMP バージョン」フィールドに運用管理製品の名前とバージョンを指定します。


6. 「起動コンテキスト」テーブルで、「新規行」をクリックします。

7. 「リソース・オブジェクト名」フィールドで、起動エントリー・レコードの使用を、このオブジェクトをサポートするアプリケーションに制限するビジネス・オブジェクトを指定できます。起動エントリーは 1 つまたは複数のビジネス・オブジェクトをサポートすることができます。ビジネス・オブジェクトを選択しない場合は、起動エントリーの使用に制限は適用されません。起動エントリーの分類値属性。分類値により、表示される起動エントリーを制限することができます。複数のビジネス・オブジェクトが分類属性をサポートします。分類の制限は、システム条件を使用している場合、実行時に実装されます。起動エントリーの動作を制御するために既成の条件が用意されています。ただし、独自の条件を作成することもできます。例えば、このフィールドにPERSON を指定すると、担当者アプリケーションについてのみ起動エントリーを使用できます。このフィールドの値が Null の場合は、任意のアプリケーションで起動エントリー・レコードを使用できます。

8. 「リソースの分類」フィールドで、指定されたリソース・オブジェクトについて分類属性が定義されている場合、起動エントリーの表示を制限する属性を選択できます。多くのビジネス・オブジェクトが分類属性をサポートします。分類の制限は、システム条件を使用している場合、実行時に実装されます。起動エントリーの動作を制御するための定義済み条件が用意されています。ただし、独自の条件を作成することもできます。

9. 起動エントリー・レコードに下位階層オブジェクトのリソースの分類を含めるには、「下位階層の分類を含む」チェック・ボックスを選択します。

10. 「起動エントリーの保存」をクリックします。

次のタスク

起動エントリー・レコードを、アプリケーション・デザイナー・アプリケーションの署名オプションに関連付けることができます。これらの関連付けが、起動エントリーで使用するメニュー・アクションを定義および制御します。

運用管理製品に固有のプロパティー:

起動エントリー・レコードを作成する場合、一部のプロパティーは特に運用管理製品で使用されます。

運用管理製品を起動エントリーに関連付けると、統合フレームワークが、構成アイテムを管理するデータベース内の運用管理製品サーバー上にその製品名があるか検索します。運用管理製品のバージョンを指定すると、統合フレームワークは指定されたバージョンを検索します。サーバー・データが起動 URL の {sourcetoken} および {reportinghostname} 変数に取り込まれます。

統合フレームワークは、どの構成アイテムで作業が行われているかを判別するために、表示されているビジネス・オブジェクト内で構成アイテム・グローバル・ユニーク ID (CIGUID) 属性を探します。構成アイテムのビジネス・オブジェクトが表示されている場合は、グローバル・ユニーク ID (GUID) 属性が代わりに使用されます。

ソース・トークンは、構成アイテムと運用管理製品サーバーの関係を示す属性です。運用管理製品コンソールはソース・トークンを構成アイテム ID として受け入


れます。{sourcetoken} を起動 URL に組み込むと、フレームワークはそれを、選択された運用管理製品サーバーの対応するソース・トークンに置き換えます。

報告側ホスト名は、選択された運用管理製品サーバーのホスト名です。{reportinghostname} 値が起動エントリーの URL に含まれている場合、フレームワークはそれを、選択された運用管理製品のホスト名に置き換えます。ソース・トークンとホスト名の情報は、ディスカバリー・エンジンからロードされます。ホスト名の情報がこのディスカバリー・エンジンからロードされない場合は、自分でデータベースに運用管理製品サーバーの情報を追加する必要があります。

起動ポイントの署名オプションの構成起動ポイントの署名オプションを作成すると、ユーザー・インターフェース・コントロール内でその署名オプションが使用できるようになります。

手順1. アプリケーション・デザイナーで、起動ポイントを構成するアプリケーションを選択します。

2. 「署名オプションの追加/変更」アクションを選択します。

3. 「署名オプションの追加/変更」ウィンドウで、「新規行」をクリックします。

4. 「オプション」フィールドおよび「説明」フィールドに値を指定します。

5. 「署名の詳細オプション」テーブルで、「コンテキスト内で起動を使用可能にするための、起動エントリーへの関連付け」オプションを選択します。「署名の詳細オプション」テーブルにアクセスするには、「署名オプションの追加/変更」ウィンドウの終わりまでスクロールし、「最大化」をクリックして選択可能なオプションを表示します。

6. 「起動エントリー名」フィールドで、起動エントリーの名前を指定します。

7. 「OK」をクリックしてアプリケーション・デザイナーに戻ります。

8. 「アプリケーション定義の保存」をクリックして、アプリケーションへの変更をデータベースにコミットします。

アプリケーション・メニューへの起動ポイントの追加起動ポイントの署名オプションを構成したら、そのオプションをアプリケーション・メニューに追加することができます。この手順は、アクションまたはツールバー・メニューに起動ポイントを追加する場合と似ています。

手順1. アプリケーション・デザイナーで、以下のいずれかのアクションを選択します。

v 「アクションの選択」メニューの追加/変更

v ツールバー・メニューの追加/変更


3. 「要素のタイプ」フィールドで、OPTION 値を指定します。

4. 「キー値」フィールドで、起動ポイントに対して構成した署名オプションの名前を指定します。

5. 「位置」フィールドで、その項目のメニュー内での相対位置を示す数値を指定します。


6. 「タブ」フィールドで、以下のいずれかの値を選択します。

v 起動 URL に置換変数が含まれている場合は、MAIN 値を選択します。

v 起動 URL に置換変数が含まれていない場合は、ALL 値を選択します。

7. 必要に応じて、他のオプション・フィールドに値を指定します。



次のタスク

ユーザーが新しいメニュー項目またはツールバー・ボタンを表示できるようにするには、それに対するアクセス権限をユーザーおよびグループに付与しておく必要があります。権限の付与は、セキュリティー・グループ・アプリケーションの「アプリケーション」タブの「オプション」セクションで行います。

起動ポイントとしてのボタンの追加起動ポイントとして機能するボタンをアプリケーションに追加する場合、その起動ポイントの署名オプションを使用するようにボタンを構成します。

手順1. アプリケーション・デザイナーで、「コントロール・パレット」をクリックします。

2. プッシュボタン・コントロールをアプリケーション・ワークスペースにドラッグします。

3. プッシュボタン・コントロールの「プロパティー」ウィンドウを開きます。

4. 「ラベル」フィールドで、ボタンに表示する名前を指定します。

5. 「イベント」フィールドで、署名オプションの名前を指定します。



起動ポイントへの条件の追加条件を作成し、その条件を起動ポイントの署名オプションと関連付けることができます。条件を署名オプションと関連付けると、ユーザー・インターフェースの動作がその条件および表示されるデータに基づいて変更されます。

手順1. セキュリティー・グループ・アプリケーションで、条件を適用するグループを選択します。

2. 「アプリケーション」タブで、条件の適用対象のアプリケーションを選択します。

3. 「オプション」テーブルで、作成した条件値を選択します。

4. 「グループの保存」をクリックします。


署名オプションの条件:

表示されているデータに基づいてユーザー・インターフェースの動作を制御する条件を適用することができます。

統合フレームワークには、現在のオブジェクトの分類が起動エントリーの分類値と一致しない場合に起動エントリー・メニュー項目を非表示にする、事前定義の条件クラス psdi.iface.app.launch.LaunchCICondition が用意されています。この条件は、分類属性を持つすべてのオブジェクトに適用されます。

また、その起動エントリーで構成されている運用管理製品が構成アイテムを管理しない場合にも、起動エントリー・メニュー項目を非表示にすることができます。この条件は、構成アイテム・オブジェクトまたは実際の構成アイテム・オブジェクトと関連付けられた起動エントリーに適用されます。

事前定義の条件クラスを使用する条件を構成することができます。また、「条件式マネージャー」アプリケーションを使用してカスタム条件を実装するための条件を構成することもできます。

条件を使用しない場合は、表示されているデータに関係なく、アプリケーションから起動ポイントを使用することができます。表示するデータは、ユーザー・グループの署名オプション・セキュリティー設定に制限されます。また、設定されたグループ・アクセス権限に基づいて起動ポイントを非表示にするよう、セキュリティー設定を構成することもできます。

Java 条件クラスを使用する場合は、条件の EXPRESSION 属性を起動エントリーの名前に変更する必要があります。この Java クラスは、どの起動エントリーを実行するかを指定することができます。この式の属性値は、起動エントリーの名前と完全に一致していなければなりません。値には大/小文字の区別があります。

統合の参照情報参照情報には、統合フレームワークで使用される XML 構造およびスキーマ、設定できるシステム・プロパティー、およびアプリケーションで提供される定義済みのコラボレーション・スイッチのガイドが含まれています。

統合システム・プロパティーシステム・プロパティーは、統合フレームワークの動作と特性を定義します。統合フレームワークのプロパティーを確認または変更するには、システムのプロパティー・アプリケーションでプロパティーをフィルタリングします。

一般統合プロパティー

一般的な統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.int を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。


表 47. 一般統合プロパティープロパティー説明デフォルト値

mxe.int.containerdeploy Web サービスをアプリケーション・サーバー・コンテナーにデプロイします。0 (False) に設定すると、Web

サービスはプロダクト・コンテナーにデプロイされます。

0

mxe.int.credentialmapperclassname 資格情報マッパー・クラス名。統合モジュールの実装時に資格情報のマッピングに使用できるクラス・ファイルです。

mxe.int.genboolasbool ブール値をスキーマ・ブール値として生成します。 1

mxe.int.globaldir 統合グローバル・ディレクトリーを指定します。 1

mxe.int.queueusercachesize インバウンド・キュー・メッセージにキャッシュされたユーザー数。

10

mxe.int.resolveschema インライン・スキーマ定義を含めるために、すべてのスキーマ・インクルードを解決します。

1

mxe.int.servicedeployer Web サービス・デプロイヤー・クラスは、デフォルトのデプロイヤー・クラスが使用されない場合の Web

サービス・デプロイメント用のカスタム Java クラスです。

mxe.int.uddiinqurl 統合 UDDI レジストリーの URL 照会を表します。

mxe.int.uddiname 統合 UDDI レジストリーのユーザー ID を表します。

mxe.int.uddipassword 統合 UDDI レジストリーのパスワード。

mxe.int.uddipuburl 統合 UDDI レジストリーの URL 公開。

mxe.int.validatedbupdates 統合によって完了したデータベース更新を検証します。1 (True) に設定すると、データベース構成アプリケーションを通じてユーザーが実行したビジネス・オブジェクト、属性、インデックス、および関係の削除が、統合コンテンツと照らし合わせて検証されます。検証では、削除されるデータが統合コンポーネントによって参照されていないことが確認されます。参照が存在する場合、ユーザーは削除アクションを完了できません。

1

mxe.int.validatemmpackage 統合によるマイグレーション・マネージャー・データベース更新を検証します。

0

mxe.int.verifywebappurl スキーマ・ファイルの生成時に Web アプリケーションの URL を検証します。

1

mxe.int.webappurl 統合 Web アプリケーションの URL を表します。このプロパティーは、正しいホスト名とポート番号が含まれるように構成します。

http://localhost:9998/meaweb

mxe.int.wsdlcurrentschema 現在のスキーマ定義を WSDL で表示します。 1

mxe.int.wsdlincludesschema スキーマを直接 WSDL に含めます。 1

mxe.int.wsdlnamespace 統合 WSDL ネーム・スペースを表します。 http://www.ibm.com/maximo/wsdl

mxe.int.xmlnamespace 統合 XML ネーム・スペースを表します。 http://www.ibm.com/maximo

mxe.int.binarytext テキスト値を Base64 エンコード値に変換します。 10

mxe.int.defaultaction フラット・ファイルのインポートのデフォルト・アクション。

AddChange

mxe.int.defaultoperation アプリケーション・エクスポートのデフォルトの操作。

Sync

mxe.int.dfltuser 統合のデフォルト・ログイン・ユーザーを表します。 mxintadm

mxe.int.doclink.maxfilesize 統合メッセージの一部として含まれている添付ファイルの最大ファイル・サイズ (MB) を表します。

10

mxe.int.enabledatemillis ミリ秒部分までの日付を有効化します。 0




mxe.int.expupdatesender データのエクスポート中にプライマリー・オブジェクトの SENDERSYSID フィールドを更新します。

0

mxe.int.extracttrycount ファイル抽出再試行数は、ファイル・ベース・エラー管理の使用時に、データのインポート中に再試行されるエラー・メッセージの数です。

0

mxe.int.flatfiledelimiter 統合フラット・ファイルのテキスト区切り文字は、アプリケーション・インポートの有効化とデータ・インポート用に使用されるデフォルトの区切り文字値です。

,

mxe.int.flatfilenewline 改行文字をフラット・ファイルに保持します。改行文字を含めることができるフィールド (説明など) では、このプロパティーの値が 1 (True) であれば、これらの文字は統合メッセージに保持されます。

0

mxe.int.interactiveimport アプリケーション・インポートを対話式で実行します。

0

mxe.int.keyresponse すべての操作に関するインバウンド統合メッセージに応答の内容を提供します。 1 (True) に設定すると、すべてのサービス操作に対して応答の内容 (プライマリー・オブジェクトのキー値を含む) が提供されます。0 (False) に設定すると、クエリーおよび作成の操作のみに対して応答の内容が提供されます。

1

mxe.int.maxextractdocs 抽出ファイルの作成時に各一時ファイルに書き込まれるエラー文書の数を表します。

1000

mxe.int.mdbdelay エラー・キューからのメッセージを処理するまでの待機時間 (ミリ秒単位) を表します。

-1

mxe.int.propagateuser インバウンド・キューを介して認証済みユーザーを伝搬します。 1 (True) に設定すると、統合メッセージのユーザーがキュー・メッセージとともに保存され、メッセージの処理で使用されます (そのユーザーがキューからビジネス・オブジェクトに処理されるため)。

0

mxe.int.savemessage JMS メッセージの保存を示します。 0

mxe.int.setclobasaln インターフェース・テーブルに送信される文字の短縮を制御します。

0

mxe.int.textqualifier フラット・ファイル・テキスト修飾子は、アプリケーション・インポートの有効化とデータ・インポートにおけるデフォルトのテキスト修飾子の値です。

"

mxe.int.updatecoafromglcomp 特定されたコンポーネントを含む勘定科目一覧を更新します。1 (True) に設定すると、インバウンド GL 勘定科目構成データの処理により、GL 勘定科目構成を参照する勘定科目一覧データに対する関連の更新が開始されます。

1

mxe.int.usescientific 2 つの値に浮動小数を使用します。 1

mxe.int.validatexmltext XML 要素の値を検証して、無効な XML 文字があるか確認します。1 (True) に設定すると、アウトバウンド・メッセージが検証され、メッセージ内のすべてのデータに有効な XML 文字が使用されていることが確認されます。メッセージに無効文字が含まれる場合、操作は停止し、アウトバウンド・メッセージは配信されません。

0

mxe.int.whereclausepolicy 統合クエリーの where 文節ポリシーを設定します。 parse




mxe.int.adminfromemail 統合で電子メールが開始されるときに From 電子メール・アドレスとして使用される、電子メール・アドレスの FROM 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。

mxe.int.admintoemail 統合で電子メールが開始されるときに To 電子メール・アドレスとして使用される、電子メール・アドレスの TO 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。複数の電子メール・アドレスをコンマ区切りリストで指定することができます。

表 48. 一般統合プロパティー：


mxe.int.containerdeployWeb サービスをアプリケーション・サーバー・コンテナーにデプロイします。0 (False) に設定すると、Web サービスはプロダクト・コンテナーにデプロイされます。


mxe.int.credentialmapperclassname資格情報マッパー・クラス名。統合モジュールの実装時に資格情報のマッピングに使用できるクラス・ファイルです。


mxe.int.genboolasboolブール値をスキーマ・ブール値として生成します。


mxe.int.globaldir統合グローバル・ディレクトリーを指定します。


mxe.int.queueusercachesizeインバウンド・キュー・メッセージにキャッシュされたユーザー数。


mxe.int.resolveschemaインライン・スキーマ定義を含めるために、すべてのスキーマ・インクルードを解決します。


mxe.int.servicedeployerWeb サービス・デプロイヤー・クラスは、デフォルトのデプロイヤー・クラスが使用されない場合の Web サービス・デプロイメント用のカスタムJava クラスです。


mxe.int.uddiinqurl統合 UDDI レジストリーの URL 照会を表します。


mxe.int.uddiname統合 UDDI レジストリーのユーザー ID を表します。


mxe.int.uddipassword統合 UDDI レジストリーのパスワード。


mxe.int.uddipuburl統合 UDDI レジストリーの URL 公開。





mxe.int.validatedbupdates統合によって完了したデータベース更新を検証します。1 (True) に設定すると、データベース構成アプリケーションを通じてユーザーが実行したビジネス・オブジェクト、属性、インデックス、および関係の削除が、統合コンテンツと照らし合わせて検証されます。検証では、削除されるデータが統合コンポーネントによって参照されていないことが確認されます。参照が存在する場合、ユーザーは削除アクションを完了できません。


mxe.int.verifywebappurlスキーマ・ファイルの生成時に Web アプリケーションの URL を検証します。


mxe.int.webappurl統合 Web アプリケーションの URL を表します。このプロパティーは、正しいホスト名とポート番号が含まれるように構成します。

http://localhost:9998/

meaweb


mxe.int.wsdlcurrentschema現在のスキーマ定義を WSDL で表示します。


mxe.int.wsdlincludesschemaスキーマを直接 WSDL に含めます。


mxe.int.wsdlnamespace統合 WSDL ネーム・スペースを表します。

http://www.ibm.com/maximo/

wsdl


mxe.int.xmlnamespace統合 XML ネーム・スペースを表します。

http://www.ibm.com/maximo グローバル管理者

mxe.int.binarytextテキスト値を Base64 エンコード値に変換します。


mxe.int.defaultactionフラット・ファイルのインポートのデフォルト・アクション。

AddChange グローバル管理者、テナント管理者

mxe.int.defaultoperationアプリケーション・エクスポートのデフォルトの操作。

Sync グローバル管理者、テナント管理者

mxe.int.dfltuser統合のデフォルト・ログイン・ユーザーを表します。

mxintadm グローバル管理者、テナント管理者

mxe.int.doclink.maxfilesize統合メッセージの一部として含まれている添付ファイルの最大ファイル・サイズ (MB) を表します。


mxe.int.enabledatemillisミリ秒部分までの日付を有効化します。


mxe.int.expupdatesenderデータのエクスポート中にプライマリー・オブジェクトの SENDERSYSID フィールドを更新します。


mxe.int.extracttrycountファイル抽出再試行数は、ファイル・ベース・エラー管理の使用時に、データのインポート中に再試行されるエラー・メッセージの数です。


mxe.int.flatfiledelimiter統合フラット・ファイルのテキスト区切り文字は、アプリケーション・インポートの有効化とデータ・インポート用に使用されるデフォルトの区切り文字値です。

, グローバル管理者、テナント管理者




mxe.int.flatfilenewline改行文字をフラット・ファイルに保持します。改行文字を含めることができるフィールド (説明など) では、このプロパティーの値が 1 (True) であれば、これらの文字は統合メッセージに保持されます。


mxe.int.interactiveimportアプリケーション・インポートを対話式で実行します。


mxe.int.keyresponseすべての操作に関するインバウンド統合メッセージに応答の内容を提供します。 1 (True) に設定すると、すべてのサービス操作に対して応答の内容(プライマリー・オブジェクトのキー値を含む) が提供されます。 0 (False) に設定すると、クエリーおよび作成の操作のみに対して応答の内容が提供されます。


mxe.int.maxextractdocs抽出ファイルの作成時に各一時ファイルに書き込まれるエラー文書の数を表します。


mxe.int.mdbdelayエラー・キューからのメッセージを処理するまでの待機時間 (ミリ秒単位) を表します。

-1 グローバル管理者、テナント管理者

mxe.int.propagateuserインバウンド・キューを介して認証済みユーザーを伝搬します。 1 (True) に設定すると、統合メッセージのユーザーがキュー・メッセージとともに保存され、メッセージの処理で使用されます (そのユーザーがキューからビジネス・オブジェクトに処理されるため)。


mxe.int.savemessageJMS メッセージの保存を示します。


mxe.int.setclobasalnインターフェース・テーブルに送信される文字の短縮を制御します。


mxe.int.textqualifierフラット・ファイル・テキスト修飾子は、アプリケーション・インポートの有効化とデータ・インポートにおけるデフォルトのテキスト修飾子の値です。

" グローバル管理者、テナント管理者

mxe.int.updatecoafromglcomp特定されたコンポーネントを含む勘定科目一覧を更新します。1 (True) に設定すると、インバウンド GL 勘定科目構成データの処理により、GL 勘定科目構成を参照する勘定科目一覧データに対する関連の更新が開始されます。


mxe.int.usescientific2 つの値に浮動小数を使用します。


mxe.int.validatexmltextXML 要素の値を検証して、無効な XML 文字があるか確認します。1 (True) に設定すると、アウトバウンド・メッセージが検証され、メッセージ内のすべてのデータに有効な XML 文字が使用されていることが確認されます。メッセージに無効文字が含まれる場合、操作は停止し、アウトバウンド・メッセージは配信されません。


mxe.int.whereclausepolicy統合クエリーの where 文節ポリシーを設定します。

parse グローバル管理者、テナント管理者




mxe.int.adminfromemail統合で電子メールが開始されるときに From 電子メール・アドレスとして使用される、電子メール・アドレスの FROM 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。


mxe.int.admintoemail統合で電子メールが開始されるときに To 電子メール・アドレスとして使用される、電子メール・アドレスの TO 統合管理。[email protected] などの有効な電子メール・アドレス・フォーマットでなければなりません。複数の電子メール・アドレスをコンマ区切りリストで指定することができます。


REST 統合プロパティー

REST API 統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.rest を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。

表 49. REST API 統合プロパティープロパティー説明デフォルト値

mxe.rest.format.json.mimetypes REST がサポートする json 用MIME タイプ。

application/json

mxe.rest.format.xml.mimetypes REST がサポートする json 用MIME タイプ。

application/xml,text/xml

mxe.rest.handler.mbo REST MBO リソース・ハンドラー。



mxe.rest.handler.os REST オブジェクト構造リソース・ハンドラー。



mxe.rest.handler.ss REST 標準サービス・リソース・ハンドラー。



mxe.rest.serializer.mbo.

imglib.image

イメージ・フォーマット用imagelib MBO の REST シリアライザー。


ImageLibSerializer

mxe.rest.serializer.mbo.json json フォーマット用 MBO のREST シリアライザー。


MboJSONSerializer

mxe.rest.serializer.mbo.xml XML フォーマット用 MBO のREST シリアライザー。


MboXMLSerializer

mxe.rest.serializer.os.json json フォーマット用オブジェクト構造の REST シリアライザー。


OSJSONSerializer

mxe.rest.serializer.os.xml XML フォーマット用オブジェクト構造の REST シリアライザー。


OSXMLSerializer

mxe.rest.serializer.ss.json json フォーマット用標準サービスの REST シリアライザー。



mxe.rest.serializer.ss.xml XML フォーマット用標準サービスの REST シリアライザー。



mxe.rest.webappurl Web アプリケーション URL のトークン認証。


表 49. REST API 統合プロパティー (続き)


mxe.rest.mbo.blockaccess MBO のコンマ区切りリストへのアクセスをブロックします。

mxe.rest.mbo.defaultformat すべての MBO の REST デフォルト・フォーマット。

xml

mxe.rest.mbo.imglib.defaultformat MBO imglib の REST デフォルト・フォーマット。

image

mxe.rest.os.blockaccess オブジェクト構造の区切りリストへのアクセスをブロックします。

10

mxe.rest.os.defaultformat すべてのオブジェクト構造のREST デフォルト・フォーマット。

xml

mxe.rest.ss.defaultformat すべての標準サービス応答のREST デフォルト・フォーマット。

xml

mxe.rest.supportedformats REST がサポートする応答用のフォーマット。

xmljsonimage

mxe.rest.whereclausepolicy REST クエリーの where 文節ポリシーを設定します。

parse

OSLC 統合プロパティー

OSLC 統合プロパティーのリストを表示するには、システムのプロパティー・アプリケーションで、フィルター条件として mxe.oslc を指定します。boolean プロパティー (True/False) では、値 0 は False を意味し、値 1 は True を意味します。

表 50. OSLC 統合プロパティープロパティー説明デフォルト値

mxe.oslc.dfltconsumerversion コンシューマーが使用するデフォルトのOSLC バージョン。

2

mxe.oslc.dfltversion OSLC プロバイダーのデフォルトの OSLC

バージョン。2

mxe.oslc.enableprovider OSLC プロバイダーを有効にします。 1

mxe.oslc.idleexpiry アイドル状態の有効期限切れ時間を示します。

300

mxe.oslc.webappurl プロバイダーのパブリック URL。 http://localhost/maximo/oslc/

mxe.oslc.collectioncount OSLC コレクション内の合計カウントを追加します。

0

mxe.oslc.defaultep デフォルトの OSLC エンドポイント。 OSLCDEFAULT

mxe.oslc.defaultformat OSLC のデフォルトの形式。 oslcjson

mxe.oslc.errorresponse OSLC のエラー応答形式。 1

mxe.oslc.preferproviderdesc リソース・レジストリー調整 URL のOSLC プロバイダーの説明を優先します。

False

mxe.oslc.prefersmallpreview OSLC コンシューマーの簡易プレビューを優先します。

False

mxe.oslc.prettyjson 読みやすく整えられた JSON。 0

mxe.oslc.prettyrdf 読みやすく整えられた RDF。 0

mxe.oslc.prqueryep プロバイダー・レジストリー・クエリー・エンドポイント。

PROVIDERREGISTRY


表 50. OSLC 統合プロパティー (続き)



統合 XML大半の統合 XML メッセージは、オブジェクト構造と、チャネルまたはサービスが実行する操作に基づいています。ただし、標準のサービスはオブジェクト構造をサポートしていないため、これらの XML メッセージを構成するには、事前定義のXML スキーマが使用されます。

概要オブジェクト構造を構成するときには、統合メッセージの内容および構造を定義する適切な XML スキーマを統合フレームワークが規定します。

メッセージ内容

オブジェクト構造に基づいた XML メッセージに対しては、以下のチャネルおよびサービスを使用できます。




v オブジェクト構造サービス

以下の操作がサポートされています。

v 作成

v 削除

v 起動

v パブリッシュ

v クエリー

v 同期

v 更新

操作の値には大/小文字の区別があります。

メッセージ構造

統合 XML メッセージの標準形式は、オブジェクト構造要素が含まれているルート要素で始まります。オブジェクト構造要素には、オブジェクト構造に定義されているプライマリー・オブジェクトとそのフィールドの要素、および下位階層オブジェクトの要素が含まれています。以下の例は、PERSON オブジェクト構造に基づいています。ここでは、プライマリー・オブジェクトとそのフィールドが下位階層オブジェクトとそのフィールドより前に記述されています。

<?xml version="1.0" encoding="UTF-8"?><max:SyncMXPERSON xmlns:max="http://www.ibm.com/maximo"> (ルート要素)

<max:MXPERSONSet> (オブジェクト構造要素を設定)<max:PERSON> (プライマリー・オブジェクトのオブジェクト要素)


<max:PERSONID>Value</max:PERSONID> (オブジェクト・フィールド要素)<max:EMPLOYEETYPE>Value</max:EMPLOYEETYPE> (オブジェクト・フィールド要素)

.

.

.<max:PHONE> (下位階層オブジェクト要素)

<max:PHONENUM>Value</max:PHONENUM> (下位階層オブジェクト・フィールド要素)<max:TYPE>Value</max:TYPE> (下位階層オブジェクト・フィールド要素)

</max:PHONE><max:EMAIL> (下位階層オブジェクト要素)

<max:EMAILADDRESS>New value to update</max:EMAILADDRESS><max:TYPE>Value</max:TYPE> (下位階層オブジェクト・フィールド要素)

</max:EMAIL>...

</max:PERSON></max:MXPERSONSet>

</max:SyncMXPERSON>

ルート要素の名前は、チャネルまたはサービスに指定した操作とオブジェクト構造の名前を連結したものです。この例では、SyncMXPERSON というルート要素は、同期操作と MXPERSON オブジェクト構造を結合しています。

各要素には、1 つ以上の属性を含めることができます。この XML メッセージの例では、ルート要素に名前空間属性が含まれています。

スキーマの生成

スキーマを生成し、生成された XML を表示するには、以下のいずれかのアプリケーションで特定のレコードをフィルターに掛け、「スキーマ/ビュー XML の生成」アクションを選択します。





v Web サービス・ライブラリー

XML 構造標準的な統合 XML メッセージには、ルート要素、オブジェクト構造要素、およびオブジェクト構造に定義されているオブジェクトの要素があります。オブジェクト要素にはオブジェクト・フィールドの要素が含まれ、要素には 1 つ以上の属性を含めることができます。属性名と値には大/小文字の区別があります。

ルート要素および属性:

XML メッセージのルート要素は、通信に使用するチャネルまたはサービスに指定されているオブジェクト構造および操作に基づいています。ルート要素には、1 つ以上の属性を含めることができます。

次の表に、ルート要素に適用できる属性を示します。属性名と値には大/小文字の区別があります。属性はすべてオプションです。



baselanguage コンテンツの値が指定される基本言語。

string すべての入出力操作

creationDateTime コンテンツが生成された日時。

dateTime すべての入出力操作

maximoVersion すべてのパブリッシュ済みXML に対して生成されるメジャー・バージョン、マイナー・バージョン、ビルド、およびデータベースのビルド。

MaximoVersionType すべての入出力操作

messageID すべてのメッセージに対して生成される固有 ID。


transLanguage 複数言語対応のフィールドに値が指定される言語。


event アウトバウンド XML メッセージの発信元。有効な値は以下のとおりです:

v 0 (False)。データのエクスポート機能によってメッセージが生成されたことを示します。

v 1 (True)。アウトバウンド統合イベント・リスナー(つまり、アプリケーションでのデータ入力) によってメッセージが生成されたことを示します。

eventType すべての出力操作

uniqueResult クエリーが応答で 1 つのレコードまたは複数のレコードのどちらを予期するかを指定します。値が 0 であるか、属性が指定されていない場合、クエリーは複数のレコードを返すことができます。値が 1 である場合、クエリーが返すことができるのは 1 つのレコードのみであり、それ以外の場合はエラーが発生します。

ブール型クエリー (入力)

maxItems クエリーが複数のレコードを返すことができる場合、この属性は、一度に返されるレコード数を制限します。この属性が指定されていない場合、応答には結果セット全体が含まれます。

positiveInteger クエリー (入力)



rsStart 応答時に返す最初のレコードを指定します。指定しなかった場合、応答は結果セットの最初のレコードから開始されます。結果セットでの結果の数が rsStart 値よりも小さい場合、応答ではレコードが返されません。

maxItems 値を指定した場合は、rsStart 値から始まる、指定された数のレコードが応答で返されます(rsStart を指定した場合)。

例えば、maxItems=10 であり、rsStart が指定されていない場合、応答では結果 1

から 10 が返されます。結果 11 から 20 を受け取るには、rsStart=11 を指定してクエリーを再送信します。

INTEGER クエリー (入力)

rsStart この値は、対応するクエリーの rsStart 値と一致します。

クエリーに maxItems 値が含まれる場合、追加レコードを求める要求の rsStart

値は、rsStart + rsCount +

1 になります。

この属性が指定されていない場合、応答は結果セットの最初のレコードから開始し、rsCount 属性によって指定されたレコード数を含みます。

INTEGER 応答 (出力)

rsCount メッセージで返されるレコード数。元のクエリーでmaxItems 値が指定されている場合、追加レコードにある後続の要求の rsStart 値は rsStart + rsCount + 1

です。




rsTotal 結果セットの合計レコード数。クエリーが maxItems

値を指定しない場合、rsTotal 値は rsCount 値と同じです。


オブジェクト構造要素:

オブジェクト構造要素には、プライマリー・オブジェクトの要素、およびそのオブジェクト構造に対して定義されている下位階層オブジェクトの要素が含まれます。この要素は、プライマリー・オブジェクトおよびその下位階層オブジェクトの複数のオカレンスに対応できます。

プライマリー・オブジェクト要素には、各オブジェクト・フィールドの要素が含まれています。下位階層オブジェクト要素には、そのオブジェクト・フィールドの要素が含まれますが、プライマリー・オブジェクトの後に表示されます。

オブジェクト要素および属性:

オブジェクト要素には、オブジェクト・フィールドの要素が入っています。各オブジェクト要素には、1 つ以上の属性を含めることができます。

以下の表に、オブジェクト要素に適用できる属性を示します。属性名と値には大/小文字の区別があります。属性はすべてオプションです。


action この値は、メッセージ内のプライマリー・オブジェクトのアクション属性から得られます。アウトバウンド・メッセージの場合、この属性は通知のみを目的としています。

インバウンド・メッセージの場合、処理ロジックはこの値を同期操作の場合にのみ使用します。その他の操作の場合、この値は無視されます。

ProcessingActionType すべての入出力操作

relationship システムが上位階層オブジェクトを使用してオブジェクトを取得するために使用する関係を示します。




deleteForInsert 再挿入前に削除する必要がある下位階層オブジェクトを識別します。この属性は、操作が「同期」であり、アクションが「変更」であるインバウンド・メッセージのみに適用されます。


関連資料:

396ページの『アクション属性』アクション属性は、XML メッセージ上で実行する処理のタイプを受信システムに対して指定するオプションの属性です。アクション属性は、同期操作を使用してデータを同期するインバウンド XML メッセージとパブリッシュ・チャネルを使用するアウトバウンド XML メッセージに適用されます。

オブジェクト・フィールドの要素および属性:

あるオブジェクト構造内の上位階層オブジェクトと下位階層オブジェクトの両方について、キーに同じフィールドが含まれている場合、このフィールドは上位階層オブジェクトのみに含まれます。各オブジェクト・フィールドには、1 つ以上の属性を含めることができます。

変更フィールド属性:

アウトバウンド XML メッセージのブール値を 1 (True) に設定することにより、フィールドの値が変更されていることを示すことができます。変更属性は、データのエクスポート機能によって生成された XML には設定されていません。

変更属性は、トランザクションが以下の条件をすべて満たす場合にのみ、アウトバウンド XML メッセージに設定されます。

v イベント・ベースのアウトバウンド・トランザクションがメッセージを作成します。

v 変更アクション属性または置換アクション属性がプライマリー・オブジェクトに設定されています。

v 送信側のオブジェクト構造に、受信側のアプリケーションと同じ上位階層 - 下位階層間オブジェクト関係があります。

以下の例では、上位階層オブジェクトに対して置換アクション属性が設定され、ADDRESSLINE フィールドの変更 (changed) 属性が 1 に設定されます。

<MXPERSON><PERSON action="Replace">

<PERSONID>123</PERSONID><ADDRESSLINE1 changed="1" >1 Main Street</ADDRESSLINE1>

総勘定元帳 (GL) タイプのフィールドでは、常に名前要素 (以下の例ではGLDEBITACCT) に変更属性が設定されます。


<GLDEBITACCT changed="1"><VALUE>6600-800-SAF</VALUE><GLCOMP glorder="0">6600</GLCOMP><GLCOMP glorder="1">800</GLCOMP><GLCOMP glorder="2">SAF</GLCOMP>

</GLDEBITACCT>

GL フィールド属性:

glorder 属性は、GLDEBITACCT フィールドなど、総勘定元帳 (GL) 勘定科目を識別するフィールドの GLCOMP 要素に設定されます。各 GLCOMP 要素には、勘定科目番号の一部が含まれており、glorder 属性は、これらの要素を結合して GL 値を構成する方法を識別します。

アウトバウンド XML メッセージでは、GL タイプのフィールドの値 (区切り文字を含む) が、フィールド内の VALUE 下位階層要素に設定されます。値のコンポーネントは、コンポーネントのデータベース定義に基づいて、GLCOMP 要素に組み込まれます。各 GLCOMP 要素の glorder 属性は、コンポーネントの順序を 0 から最大 20 まで識別します。以下の例では、勘定科目番号に 3 つの GL コンポーネントがあります。

<GLDEBITACCT><VALUE>6600-800-SAF</VALUE><GLCOMP glorder="0">6600</GLCOMP><GLCOMP glorder="1">800</GLCOMP><GLCOMP glorder="2">SAF</GLCOMP>

</GLBDEBITACCT>

インバウンド XML メッセージでは、関連の glorder 属性を使用して、VALUE 要素または GLCOMP 要素に GL 勘定科目番号を設定できます。このメッセージにGLCOMP 要素が含まれる場合、勘定科目番号は、GLCONFIGURE テーブルで定義された区切り文字に基づいて再作成されます。メッセージに VALUE 要素とGLCOMP 要素の両方が含まれる場合は、VALUE 要素が使用され、GLCOMP 要素は無視されます。

変換可能フィールド属性:

langenabled 属性は、アウトバウンド XML メッセージ内で変換できるすべてのフィールドで 1 (True) に設定されます。

シノニム・フィールド属性:

アウトバウンド・メッセージの場合、シノニム・タイプ・ドメインに関連付けられたフィールドでは、maxvalue 属性を使用して対応する内部値を指定します。この値は、必要に応じてカスタマイズまたは出口処理に使用できます。この属性は通知のみを目的としており、インバウンド・メッセージ処理には使用されません。

以下の例では、NOLOT という maxvalue が LOTTYPE フィールドに設定されます。

<MXITEM><ITEM><ITEMNUM>560-00</ITEMNUM><DESCRIPTION>チュービング、銅 - 内径 1 インチ x .030 インチ壁面テスト</DESCRIPTION><LOTTYPE maxvalue="NOLOT">NOLOT</LOTTYPE>


暗号化フィールド属性:

パスワード・フィールドなどのフィールドにあるデータを暗号化すると、ブール型属性 (maxencrypted) は 1 (true) に設定されます。外部システムは、この値を使用して、フィールド内の情報に暗号化解除処理を適用するかどうかを判別します。

以下の例では、MXPERSUSER オブジェクト構造を使用してパスワードなどのユーザー情報が提供され、MAXUSER オブジェクトの PASSWORD フィールドにmaxencrypted 属性が設定されます。

<MXPERUSER><PERSON action="Replace"><PERSONID>123</PERSONID><MAXUSER><MAXUSERID>10</MAXUSERID><PASSWORD maxencrypted=”1”> dmFzdG8=</PASSWORD><MAXUSER><PERSON><MXPERUSER>

アクション属性:

アクション属性は、XML メッセージ上で実行する処理のタイプを受信システムに対して指定するオプションの属性です。アクション属性は、同期操作を使用してデータを同期するインバウンド XML メッセージとパブリッシュ・チャネルを使用するアウトバウンド XML メッセージに適用されます。

以下では、同期操作を使用するインバウンド・メッセージの処理について説明します。外部システムは、アウトバウンド・メッセージと一緒に提供されるアクション・コードを評価し、その外部アプリケーションに適切な処理を判別する必要があります。

アクション属性は、オブジェクト構造内にある上位階層オブジェクトおよび下位階層オブジェクトの内容に適用できます。上位階層オブジェクトに適用されるアクション属性は、上位階層レコードおよび下位階層レコードの処理アクション全体を規定します。適用先が下位階層オブジェクトの場合、アクションは、そのレコードに固有の処理を示します。下位階層オブジェクトに提供される属性は、プライマリー・オブジェクトのアクション値が「変更」の場合にのみ評価されます。プライマリー・オブジェクトのアクションが「変更」でない場合、下位階層オブジェクトのアクションは無視されます。

ビジネス・ルールは、アクション属性より優先されます。インバウンド XML メッセージに指定されているアクションをビジネス・ルールで禁止すると、エラーが発生します。例えば、終了した注文書を更新しようとするインバウンド・トランザクションを行うと、エラーが発生します。

XML メッセージにオブジェクト構造の複数インスタンスが含まれる場合、オブジェクト構造の各インスタンスは異なるアクション属性を指定することができます。以下の例では、COMPANIES レコードに複数の下位階層 COMPCONTACT レコードがあり、各インスタンスにはこのレコード独自のアクション属性があります。

<MXVENDOR><COMPANIES action="Change">

<COMPANY>TEST4<NAME>test</NAME><ADDRESS1>100 Main Str</ADDRESS1>


<COMPCONTACT action="Add"><NAME>SMITH</NAME><TITLE>MANAGER</TITLE>

</COMPCONTACT><COMPCONTACT action="Change">

<NAME>JONES</NAME><TITLE>ENGINEER</TITLE>

</COMPCONTACT></COMPANY>

</COMPANIES></MXVENDOR>

アクション属性は、以下の値をとることができます (値は大文字と小文字を区別します)。

v Add

v Delete

v Change

v Replace

v AddChange

v Null

値説明

Add 受信システムのデータベースにレコードを追加します

Delete 受信システムのデータベースからレコードを削除します

Change 受信システムのデータベースにある既存のレコードを更新します

Replace プライマリー・レコードがデータベースに存在するかどうかに応じて、受信システムにレコードを追加するか、または受信システムのレコードを置換します。

AddChange 受信システムのデータベースにある既存レコードを追加または更新します

Null プライマリー・レコードがデータベースに存在するかどうかに応じて、受信システムにレコードを追加するか、または受信システムのレコードを置換します。

デフォルトのアクション処理

インバウンド XML メッセージにアクション属性が含まれていない場合、このメッセージは以下のように処理されます。

v プライマリー・レコードがデータベースに存在しない場合は、追加アクションが適用されます。

v プライマリー・レコードがデータベースに存在する場合は、置換アクションが適用されます。

フラット・ファイルまたはインターフェース・テーブルを送信元とするメッセージの場合、プライマリー・オブジェクトにのみアクション・コードを提供することが


できます。下位階層オブジェクトへのアクション・コードの提供はサポートされていません。

追加アクション

追加アクションは、受信システムのデータベースにレコードを追加します。

インバウンド・トランザクションの場合、そのデータがすでに存在するとエラーが発生します。追加アクションを上位階層オブジェクトに設定すると、追加アクションは下位階層オブジェクトにも適用されるため、下位階層オブジェクト・レベルで追加アクションを指定する必要はありません。アウトバウンド・トランザクションでは、オブジェクトの挿入によってトランザクションが生成される場合に追加アクションが含まれます。

削除アクション

削除アクションは、受信システムのデータベースからレコードを削除します。

削除アクションを上位階層オブジェクトに設定すると、削除アクションは下位階層オブジェクトにも適用されるため、下位階層オブジェクト・レベルで削除アクションを指定する必要はありません。

下位階層オブジェクトが含まれていないアウトバウンド XML メッセージ内の上位階層オブジェクトに削除アクションを設定すると、下位階層オブジェクトの識別および削除を受信システムが担当します。

インバウンド XML メッセージ内の上位階層オブジェクトに削除アクションを設定すると、関連の下位階層オブジェクトを統合フレームワークが削除します。上位階層オブジェクトがデータベースに存在しない場合は、送信システムにエラーは報告されません。

変更アクション

変更アクションは、受信システムのデータベースにある既存のレコードを更新します。

XML メッセージのプライマリー・オブジェクトに対する変更アクションがある場合、追加、変更、または削除される 1 つ以上の上位階層レコードまたは下位階層レコードがそのメッセージに含まれていることを示します。上位階層が変更されない場合でも、更新される下位階層レコードの上位階層が常にメッセージに含まれます。

プライマリー・オブジェクトの変更アクションが、下位階層オブジェクトにアクションを提供できる唯一のケースです。インバウンドまたはアウトバウンド XML メッセージのプライマリー・オブジェクトに変更アクションが含まれる場合、そのメッセージ内の各下位階層オブジェクトには次のいずれかのアクションが含まれる可能性があります。


下位階層オブジェクトのアクション属性処理アクション

Add 下位階層レコードを追加します。下位階層レコードが既に存在する場合は、エラーが発生します。

Delete 下位階層レコードを削除します。下位階層レコードが存在しない場合は、エラーが発生します。

Change 下位階層レコードを更新します。下位階層レコードが既に存在する場合は、エラーが発生します。

Null またはアクションの指定なし下位階層レコードが存在する場合は、下位階層レコードを更新します。下位階層レコードが存在しない場合は、下位階層レコードを追加します。

置換アクション

置換アクションは、受信システムのデータベースにある既存のレコードを更新します。

XML メッセージのプライマリー・オブジェクトに対する置換アクションは、オブジェクト構造に対する追加、変更、および削除の結果を表す一連のオブジェクトがそのメッセージに揃っていることを示しています。これらのオブジェクトが既存のデータベース・レコードと置き換えられ、XML メッセージで参照されていないレコードはすべて削除されます。

アウトバウンド処理の場合は、変更アクションではなく、置換アクションが必ず使用されます。

インバウンド処理の場合は、メッセージ内で明示的に言及されていない既存の下位階層レコードがすべて削除されます。外部システムは、XML メッセージに含まれていない下位階層レコードもすべて削除する必要があります。

置換アクションは、XML メッセージのプライマリー・オブジェクトに対してのみ適用できます。プライマリー・オブジェクトに変更アクションが含まれているときにインバウンド XML メッセージの下位階層レコードに置換アクションが含まれる場合、このメッセージは処理されません。上位階層に変更以外のアクションが含まれているときに下位階層レベルのレコードに置換アクションが含まれる場合、下位階層レコードに対するアクションは無視されます。

追加変更アクション

追加変更アクションは、受信システムのデータベースにレコードを追加するか、受信システムのデータベースにある既存のレコードを更新します。追加変更アクションは置換アクションに似ていますが、追加変更アクションは下位階層オブジェクトに適用されない点が異なります。

プライマリー・レコードがデータベースに存在しない場合、プライマリー・オブジェクトに追加変更アクションを設定すると、プライマリー・レコードと、メッセージに指定されているすべてのサブレコードが追加されます。プライマリー・レコー


ドが存在する場合は、メッセージ内に含まれている下位階層レコードと一緒に更新されます。インバウンド・メッセージに指定されていない既存の下位階層レコードは削除されません。

追加変更アクションは、外部システムに存在しない要素がオブジェクト構造に含まれている場合に便利です。例えば、外部システムは販売元情報を維持できますが、連絡先情報はデータベースにのみ保管されます。アクション値が NULL である販売元レコードを持つインバウンド・メッセージを使用すると、データベースの連絡先情報が削除されます。このトランザクションに対してアクションを「追加変更」に設定すると、販売元情報が更新され、連絡先情報は同じ状態で残ります。

変更、置換、および追加変更アクションの比較

変更、置換、および追加変更アクションの相違点は、これらのアクションが XML

メッセージに組み込む情報および受信システムで必要とする処理です。

アクション属性の組み合わせ

次の表に、プライマリー・レコードおよび下位階層レコードで組み込むことができるアクション属性の組み合わせを示します。

下位階層レコード Add Delete Change Replace AddChange 値なし注釈

プライマリー・レコード

Add N/A N/A N/A N/A N/A N/A すべての下位階層の値は無視されます

Delete N/A N/A N/A N/A N/A N/A すべての下位階層の値は無視されます

Change はいはいはいいいえいいえはい (挿入、更新)

置換および追加変更は下位階層レベルでは許可されません

Replace N/A N/A N/A N/A N/A N/A すべての下位階層の値は無視されます

AddChange N/A N/A N/A N/A N/A N/A すべての下位階層の値は無視されます

値なし N/A N/A N/A N/A N/A N/A すべての下位階層の値は無視されます

関連資料:

393ページの『オブジェクト要素および属性』オブジェクト要素には、オブジェクト・フィールドの要素が入っています。各オブジェクト要素には、1 つ以上の属性を含めることができます。


フィールド値タイプ:

統合フレームワークは、フィールド値の形式を設定するために使用するさまざまなデータ型の処理動作を指定します。

ブール型のカラム

インバウンド・トランザクションで、ブール型フィールドを表す要素には値 0

(False) または 1 (True) が含まれている必要があります。要素に 0 または 1 が含まれない場合は、エラーが発生します。XML にブール型フィールドの要素が含まれない場合、対応するデータベース値が、そのカラムに定義されているデフォルト値(0 または 1) で更新されます。

暗号化されたフィールド

インバウンド・トランザクションで、maxencrypted フィールドを表す属性には値 0

(False) または 1 (True) が含まれている必要があります。属性値が 1 の場合は、受信データに暗号化解除処理が適用されます。属性値が 0 の場合、受信データの暗号化解除は行われません。

この属性に 0 または 1 のいずれも含まれない場合、受信データの暗号化解除は行われません。XML フィールドに暗号化フィールドの要素が含まれない場合、受信データの暗号化解除は行われません。

文字のエンコード

統合 XML は UTF-8 エンコード方式を使用します。インバウンド・トランザクションでその他のエンコード方式が指定される場合、メッセージ全体がそのエンコード方式を使用する必要があります。UTF-8 以外のエンコード方式を使用するインバウンド・トランザクションの処理中にエラーが発生した場合、書き込まれたエラーのある XML 全体が UTF-8 としてエンコードされます。

<?xml version="1.0" encoding="ISO-8859-2"?>

日付形式

統合 XML は次の ISO 8601 日付形式をサポートします。

2011-04-06T10:11:58-05:00

Null カラム

インバウンド・トランザクションの要素に値が含まれない場合、対応するデータベース・カラムは NULL 値で更新されます。XML で特定フィールドの要素が含まれない場合、データベース内のそのフィールドは更新されません。

フラット・ファイルまたはインターフェース・テーブルをソースとするインバウンド・データの場合、フラット・ファイルまたはインターフェース・テーブルのフィールド値に「NULL」を指定して、フィールドを NULL に設定することができます。統合処理により、指定された「NULL」値に対応する XML メッセージ内に空のタグが作成されます。この機能は、ソースのインターフェース・テーブルの数値フィールドまたは日付フィールドをサポートしません。


数字フォーマット

アプリケーション・サーバーまたはデータベースのロケール設定に関係なく、すべての 10 進数フィールドでは、小数点のプレースホルダーとしてピリオド (.) を使用する必要があります。プレースホルダーの左側にある数字をフォーマットしないでください。このフォーマットはインバウンドとアウトバウンドのデータに適用されます。

$1,738,593.64 は 1738593.64 というフォーマットである必要があります。

統合 XML スキーマチャネルおよびサービス (標準サービスを除く) 用の XML スキーマは、オブジェクト構造に組み込まれているオブジェクトの構成に基づいています。スキーマは統合アプリケーションで生成することができます。

XML スキーマの概要:

統合フレームワーク・スキーマには、メタデータ用の定義済みのスキーマ・コンポーネント、および構成されたオブジェクト、オブジェクト構造、および標準サービスに基づくスキーマ・コンポーネントが含まれています。

以下のコンポーネントが使用される XML ベースの統合シナリオをサポートするためのスキーマを生成できます。

v オブジェクト構造サービス




v 標準サービス

キー・フィールド

XML スキーマの annotation は、対応するオブジェクトのオブジェクト構造定義およびデータ・ディクショナリー定義を基にして、サービスまたはチャネルのキー・フィールドを識別します。

以下の例では、MXITEM オブジェクト構造のスキーマにあるキー・フィールドとして ITEMNUM 要素が識別されます。

<xsd:element name="ITEMNUM" minOccurs="0" type="MXString"><xsd:annotation>

<xsd:documentation>ITEMNUM is a key field</xsd:documentation></xsd:annotation>

</xsd:element>

XML 検証

インバウンドおよびアウトバウンド XML トランザクションでは、対応する XML

スキーマとの照合による検証は行われません。統合ビジネス・ルールは、スキーマ検証に関係なくインバウンド・データに適用されます。オブジェクト構造サービスおよびエンタープライズ・サービスの場合、統合は、オブジェクト構造層によってメッセージが処理される時点でのスキーマ・フォーマットに従っている必要があります。


ネーム・スペースのプロパティー

XML ネーム・スペースの指定を変更するには、システムのプロパティー・アプリケーションで mxe.int.xmlnamespace プロパティーを更新します。デフォルトのnamespace プロパティー値は http://www.ibm.com/maximo です。namespace プロパティーを変更すると、MXMeta.xsd ファイルは再生成されます。このファイルには、他のすべてのスキーマを作成するときに使用するメタデータ・スキーマ情報が含まれています。統合フレームワークはインバウンド XML メッセージとともに提供されるネーム・スペースを検証します。


オブジェクト構造またはデータ・ディクショナリーを変更する場合は、その影響を受けるスキーマを再生成する必要があります。以下の変更後にもスキーマを再生成する必要があります。

v データベース・フィールドの必須フィールドまたはオプション・フィールドへの切り替え

v データベース・フィールドのデータ型の変更

v オブジェクト構造のフィールドの追加または削除

v オブジェクト構造の構造に対する変更

Web サービスをデプロイすると、スキーマは自動的に生成されます。

スキーマを手動で生成するには、以下のアプリケーションでレコードを選択し、「スキーマ/ビュー XML の生成」アクションを選択します。





v Web サービス・ライブラリー

スキーマのディレクトリーおよびファイル

生成されたスキーマ・ファイルは、サーバー上のスキーマ・ディレクトリー内にある関連したサブディレクトリーに配置されます。

グループサブディレクトリー説明

メタデータ <root>/schema/common/meta メタデータ・スキーマ・ファイル、MXMeta.xsd

オブジェクト構造 <root>/schema/common/mos オブジェクト構造スキーマ・ファイル

オブジェクト <root>/schema/common/mbo オブジェクト・スキーマ・ファイル

サービス <root>/schema/service エンタープライズ・サービスおよびオブジェクト構造サービスのスキーマ・ファイル


グループサブディレクトリー説明

標準サービス <root>/schema/service/ss 標準サービスのスキーマ・ファイル

スキーマ構造:

スキーマ構造には、オブジェクト、オブジェクト構造、サービスおよび標準サービス用の事前定義のメタデータ・スキーマ・コンポーネントが含まれ、これらはすべてスキーマの作成時に生成されます。

メタデータ・スキーマ:

MXMeta.xsd ファイルには、他のすべてのスキーマを作成するときに使用するメタデータ情報が含まれています。MXMeta.xsd ファイルは変更しないでください。変更すると、スキーマが不正確になり、Web サービスに関する問題が発生する可能性があります。誰かがネーム・スペースのプロパティーを変更すると、システムはこのスキーマを再生成します。

メタデータ・スキーマ・ファイルには、データの内容以外に、メッセージに関する以下の追加情報が含まれています。

v 属性グループ

v コンテンツ・タイプ

v クエリー・データ型

v サポート・データ型

属性グループ

次の表に、グループ別の属性をリストします。

グループ属性適用先

CommonContentGroup v baseLanguage

v creationDateTime

v maximoversion

v messageID

v transLanguage

すべての入出力スキーマ・タイプのルート要素。

ObjectStructurePropertyGroup v action

v relationship

v deleteForInsert

すべての入出力スキーマ・タイプのオブジェクト要素。

PublishingContentGroup v event すべての出力スキーマ・タイプのルート要素。

QueryContentGroup v maxItems

v rsStart

v uniqueResult

すべてのクエリー入力スキーマ・タイプのルート要素。


グループ属性適用先

ResponseContentGroup v rsCount

v rsStart

v rsTotal

すべての応答出力スキーマ・タイプのルート要素。

コンテンツ・タイプ

以下の表に、メタデータ・スキーマでのコンテンツ・タイプを示します。

タイプ説明属性

MaximoVersionType 以下を識別する連結ストリング:

v メジャー・バージョン

v マイナー・バージョン

v ビルド

v 作成されたデータベース

ソフトウェアのバージョンを識別します

MXBooleanType integer の拡張 changed

MXDateTimeType dateTime の拡張 changed

MXDomainType string の拡張。ドメイン値に対応するMaxvalue を識別します。

changed

maxvalue

MXDoubleType double の拡張 changed

MXFloatType float の拡張 changed

MXGLAccountType 2 つの値 VALUE および GLCOMP

を持つ複合タイプ。個々の GL コンポーネントおよび勘定科目でのそれらの順序を識別します。

changed

MXGLComponentType string の拡張。勘定科目構造図の中のGL コンポーネントの順序を識別します。

glorder

MXIntType integer の拡張 changed

MLLangStringType MXString の拡張 changed

languageEnabled

MXLongType long の拡張 changed

MXStringType string の拡張 changed

クエリー・タイプ

以下の表に、メタデータ・スキーマでのクエリー・タイプを示します。


MXBooleanQueryType integer の拡張 operator

MXDateTimeQueryType dateTime の拡張 operator



MXDomainQueryType string の拡張 operator

maxvalue

MXDoubleQueryType double の拡張 operator

MXFloatQueryType float の拡張 operator

MXGLAccountQueryType VALUE という値を持つ複合タイプ operator

MXGLComponentQueryType string の拡張 operator

MXIntQueryType integer の拡張 operator

MXLongQueryType long の拡張 operator

MXStringQueryType string の拡張 operator

データ型

以下の表に、メタデータ・スキーマでのデータ型を示します。

タイプ説明制限付きの値

BooleanType 論理テストの結果が True またはFalse のどちらであるかを示します。

v 0 (False)

v 1 (True)

ChangeIndicatorType フィールドに新しい値があるかどうかを示します。

イベントによって生成されたオブジェクト構造にのみ適用されます。

1 (True)

EventType パブリッシュ済みオブジェクト構造がイベントの結果であるかどうかを示します。値が 1 である場合、パブリッシュ済み構造がイベントの結果です。

EventType は、BooleanType の拡張です。

v 0 (False)

v 1 (True)

ProcessingActionType 統合サービスがサポートする処理アクション。

v Add

v Change

v Replace

v Delete

v AddChange

QueryOperatorType 対応するフィールドに対して実行される例示照会プログラムのアクションを示します。

v =

v !=

v &lt

v <=

v &gt

v >=

v SW

v EW


オブジェクト構造スキーマ:

オブジェクト構造スキーマは、オブジェクト構造の内容を定義します。各オブジェクト構造には独自のスキーマがあり、このスキーマには、構造内のオブジェクトごとに定義されている永続フィールドおよび非永続フィールドがすべて含まれます。オブジェクト構造スキーマは入出力タイプを定義するために使用され、サービスの入力または出力として直接使用されることはありません。

ファイル名およびロケーション

命名規則により、オブジェクト構造スキーマ名にはオブジェクト構造名 (例えば、MXPERSON.xsd) が使用されます。すべてのオブジェクト構造スキーマにはMXMeta.xsd スキーマ・ファイルが含まれます。生成されたスキーマは、schema/common/mos ディレクトリーにあります。


以下のコンポーネントを生成すると、オブジェクト構造スキーマが再生成されます。

v オブジェクト構造スキーマ (オブジェクト構造アプリケーションのアクションの使用による)

v オブジェクト構造がサービスによって参照されるエンタープライズ・サービス・スキーマ

v オブジェクト構造がチャネルによって参照されるパブリッシュ・チャネル・スキーマ

スキーマ・オブジェクト構造の内容

オブジェクト構造スキーマには、以下の要素があります。


v オブジェクト・セット

v オブジェクト・クエリー

例えば、MXPERSON オブジェクト構造のスキーマには以下の要素があります。

エレメント要素名タイプ

オブジェクト MXPERSON MXPERSONType

オブジェクト・セット MXPERSONSet MXPERSONSetType

オブジェクト・クエリー MXPERSONQuery MXPERSONQueryType

スキーマ・オブジェクトの内容

オブジェクト要素には、以下の内容があります。

v MXPERSON 要素には、MXPERSONType というタイプがあります。

v MXPERSONType は複合タイプで、PERSON 要素を持っていますが、この要素には MXPERSON_PERSONType というタイプがあります。


v 複合タイプ MXPERSON_PERSONType は、PERSON オブジェクトのすべての構成済み属性の要素、およびオブジェクト構造の下位階層オブジェクトの要素を持ちます。

v スキーマの追加オブジェクトには、PERSON オブジェクトを定義するMXPERSON_PERSONType などの対応する複合タイプがあります。

エレメントタイプ

PERSON (プライマリー・オブジェクト) MXPERSON_PERSONType

PHONE (下位階層オブジェクト) MXPERSON_PHONEType

EMAIL (下位階層オブジェクト) MXPERSON_EMAILType

SMS (下位階層オブジェクト) MXPERSON_SMSType

以下の例は、対応する XML の構造を示しています。

<MXPERSON><PERSON>

<PHONE></PHONE>

.

.

.<EMAIL></EMAIL>

.

.

.<SMS></SMS>

.

.

.</PERSON>

</MXPERSON>

オブジェクト・セットの内容

この MXPERSON の例では、MXPERSONSet 要素が MXPERSON 要素に置き換わり、MXPERSONSetType が複合タイプ MXPERSONType に置き換わります。その他はいずれも変わりません。set 要素は、プライマリー・オブジェクト (MXPERSON)

およびその下位階層オブジェクトの複数のオカレンス用のラッパーとして機能します。

オブジェクト・クエリーの内容

クエリー要素はサービス・レベル・スキーマのコンテキスト内のみで使用できます。

オブジェクト・クエリー要素には次のフォーマットの内容が含まれます。

v MXPERSONQuery 要素のタイプは MXPERSONQueryType です。

v MXPERSONQueryType は複合タイプであり、オブジェクト構造のプライマリー・オブジェクト (PERSON) のすべての構成済み属性の要素を持っています。

オブジェクト・クエリーとオブジェクト・セットは以下の点で異なります。


v クエリー要素には、オブジェクト構造のプライマリー・オブジェクトのみが含まれます。

v クエリー要素には非永続カラムがありません。

v クエリー要素では、日付範囲など、ある範囲に対するクエリーをサポートするために、要素を 2 回出現させることができます。

クエリーに含まれるのはオブジェクト構造の最上位オブジェクトのみであるため、例えば、担当者を電話番号別に照会することはできません。電話番号は、下位階層の PHONE オブジェクトの中に存在します。

オブジェクト・スキーマ:

オブジェクト・スキーマは、オブジェクトの内容を定義します。各オブジェクトにはそれぞれ固有のスキーマがあり、永続オブジェクトのすべての永続フィールド、および非永続オブジェクト用に定義されたすべての非永続フィールドがそこに含まれます。オブジェクト・スキーマは入出力タイプを定義するために使用され、サービスの入力または出力として直接使用されることはありません。


オブジェクト・スキーマの命名規則はオブジェクト名 (例えば、PERSON.xsd) であり、ファイルは schema/common/mbo ディレクトリーに置かれます。


オブジェクト・スキーマ・ファイルは、以下のコンポーネントを生成すると生成されます。

v オブジェクトを含むオブジェクト構造スキーマ

v オブジェクトを含むオブジェクト構造を参照するオブジェクト構造サービスまたはエンタープライズ・サービス・スキーマ

v オブジェクトを含む標準サービス・スキーマ

すべてのオブジェクト・スキーマに MXMeta.xsd スキーマ・ファイルが含まれます。

スキーマの内容

このスキーマには以下の要素が含まれます (例として MXPERSON を使用)

エレメントタイプコメント

PERSONMbo PERSONMboType このタイプには、PERSONMbo 要素の 1 つのインスタンスが含まれます。

PERSONMboSet PERSONMboSetType このタイプには、PERSONMbo 要素の複数インスタンスが含まれます。


エレメントタイプコメント

PERSONMboKey PERSONMboKeyType このタイプには、PERSONKeyType であるPERSON 要素の単一インスタンスが含まれます。PERSONKeyType には、PERSON オブジェクトのPERSONID のプライマリー・キーである属性が含まれます。

1 つのオブジェクトのプライマリー・キーが複数の属性によって構成される場合、objectKeyType にはそのプライマリー・キーを構成する属性が含まれます。

この要素は、作成操作への応答に含まれます。

PERSONMboKeySet PERSONMboKeySetType このタイプには、PERSONKeyType であるPERSON 要素の複数インスタンスが含まれます。

PERSONKeyType には、PERSON オブジェクトのPERSONID のプライマリー・キーである属性が含まれます。

1 つのオブジェクトのプライマリー・キーが複数の属性によって構成される場合、objectKeyType にはそのプライマリー・キーを構成する属性が含まれます。

この要素は、作成操作の応答に含まれます。

PERSONMboQuery PERSONMboQueryType このタイプには、PERSON 要素の 2 つのインスタンスが含まれます。この 2 つのインスタンスにより、クエリーで開始日と終了日などの範囲を指定することができます。

複数名詞メッセージ:

XML メッセージには複数の名詞を含めることができます。


<MXPERSON><MXPERSONSET>

<PERSON>..<SMS></SMS></PERSON><PERSON>..<SMS></SMS></PERSON>

</MXPERSONSET></MXPERSON>

サービス・レベル・スキーマ:

サービス・レベル・スキーマは、エンタープライズ・サービス、オブジェクト構造サービス、および標準サービスに適用されます。同じスキーマが、エンタープライズ・サービスおよびオブジェクト構造サービスを記述します。別のスキーマが標準サービスを記述します。

エンタープライズ・サービス、オブジェクト構造サービス、および標準サービスは、これらのサービスがサポートする操作の入出力としてオブジェクトおよびオブジェクト構造を使用します。複数のサービスが同じ入出力を使用して同じ操作を実行することができます。

パブリッシュ・チャネルおよび呼び出しチャネルの事前定義入出力を使用してこれらのチャネルを実装し、外部サービスを呼び出すか、他の出力形式にマップします。


命名規則により、オブジェクト構造スキーマおよびエンタープライズ・サービス・スキーマにはアプリケーション・サービス名に Service を加えた名前(PERSONService.xsd などで、PERSON がアプリケーション・サービス名) が使用されます。

同様に、命名規則により、サービス・レベル・スキーマにはオブジェクト構造にService を加えた名前 (MXPERSONService.xsd など) が使用されます。

スキーマ・ファイルは、/schema/service ディレクトリーにあります。

スキーマ・ファイルは、<root>/schema/common/service ディレクトリーにあります。


事前定義のサービス・レベル・スキーマ・ファイルは提供されていません。Web サービスを導入するときには、関連するオブジェクト構造についてサービス・レベル・スキーマ・ファイルが生成されます (未生成の場合)。Web サービス・ライブラリー・アプリケーションのアクションを使用してサービス・レベル・スキーマを生成することもできます。


すべてのサービス・レベル・スキーマには、メタデータ・スキーマ・ファイル、および適用されるオブジェクト構造とオブジェクト・スキーマ・ファイルが含まれます。

スキーマの内容

スキーマ・ファイルは、オブジェクト構造ごとに 1 つずつ生成され、各ファイル内には複数のデータ型が存在します。各データ型は、サービスとして導入または処理できる各入力および出力操作に対応します。さまざまなサービスが、これらのスキーマにあるデータ型を再利用します。単一のスキーマですべてのデータ型を使用するサービスはありません。

MXPERSON の例を使用した場合、サービス・レベル・スキーマには以下のタイプが入っています。

v CreateMXPERSON

v CreateMXPERSONResponse

v DeleteMXPERSON

v InvokeMXPERSON

v InvokeMXPERSONResponse

v PublishMXPERSON

v QueryMXPERSON

v QueryMXPERSONResponse

v SyncMXPERSON

v UpdateMXPERSON

標準サービス・スキーマの入出力:

標準サービスは、オブジェクトに対する特定の操作を実行するためにアプリケーションによって提供され、複数のメソッドを Web サービスとして公開できます。標準サービスは、サービスの中で適切に注釈が付けられたメソッドでのみ使用可能です。

標準サービス用に生成されたサービス・レベル・スキーマは、対応するアクションによってのみ使用されます。

オブジェクト構造およびエンタープライズ・サービスの入出力:

オブジェクト構造には、オブジェクト構造サービス・スキーマとエンタープライズ・サービス・スキーマの両方の内容が含まれています。オブジェクト構造サービスは、すべての定義済み操作をサポートしていますが、エンタープライズ・サービスがサポートしているのは、特定の 1 つの操作のみです。複数の操作をサポートするには、それらの操作が同じオブジェクト構造を参照し、同じスキーマを使用する場合でも、複数のエンタープライズ・サービスを作成する必要があります。

オブジェクト構造スキーマおよびエンタープライズ・サービス・スキーマは、以下のことを識別します。

v オブジェクト構造サービスおよびエンタープライズ・サービスの入出力

v 呼び出しチャネルの入出力


v パブリッシュ・チャネルによって得られる出力

以下のように、すべての操作はそれぞれ 1 つの出力タイプをサポートします。

v 作成、更新、削除、および同期の各操作の出力は、プライマリー・オブジェクト・キー、内部 ID フィールド、および自動キーの値です。

v クエリー操作の出力は、オブジェクト構造の結果セットです。

以下の例では、MXPERSON オブジェクト構造に基づいて、オブジェクト構造サービスおよびエンタープライズ・サービスの内容について説明しています。

CreateMXPERSON 要素

CreateMXPerson 要素には、以下の定義があります。

v CreateMXPERSON 要素のタイプは CreateMXPERSONType です。

v CreateMXPERSONType には、タイプ MXPERSONSetType の要素 MXPERSONSet

があります。MXPERSONSet は、オブジェクト構造スキーマから導出されます。

v MXPERSONSetType には、PERSON オブジェクトのすべての構成済み属性の要素、およびオブジェクト構造で定義されている下位階層オブジェクト(PHONE、EMAIL、および SMS) の要素があります。

次の要素およびタイプの定義は、CreateMXPERSON の要素およびタイプに相当します。

エレメントタイプ

UpdateMXPERSON UpdateMXPERSONType

SyncMXPERSON SyncMXPERSONType

InvokeMXPERSON InvokeMXPERSONType

InvokeMXPERSONResponse InvokeMXPERSONResponseType

MXPERSONResponse 要素の作成

CreateMXPERSONResponse 要素には、以下の定義があります。

v CreateMXPERSONResponse 要素のタイプは CreateMXPERSONResponseType です。

v CreateMXPERSONResponseType には、タイプ PERSONMboKeySetType の要素PERSONMboKeySetがあります。

v PERSONMboKeySetType には、タイプ PERSONKeyType の要素 PERSON があります。

v PERSONKeyType に含まれているのは PERSON オブジェクトの PERSONID 属性のみであり、これは PERSON オブジェクトのプライマリー・キーです。

PublishMXPERSON 要素

PublishMXPERSON 要素には、以下の定義があります。

v PublishMXPERSON 要素のタイプは PublishMXPERSONType です。


v PublishMXPERSONType には、タイプ MXPERSONSetType の要素MXPERSONSet があります。MXPERSONSet は、オブジェクト構造スキーマから導出されます。

v MXPERSONSetType には、PERSON オブジェクトのすべての構成済み属性の要素、およびオブジェクト構造で定義されている下位階層オブジェクト(PHONE、EMAIL、および SMS) の要素があります。

Publish 要素は Create 要素と似ていますが、メタデータ・スキーマのPublishingContentGroup で定義される追加の属性 (event) を使用します。

DeleteMXPERSON 要素

DeleteMXPERSON 要素には、以下の定義があります。

v DeleteMXPERSON 要素のタイプは DeleteMXPERSONType です。

v DeleteMXPERSONType には、タイプ MXPERSONDeleteType の要素MXPERSONDelete があります。

v MXPERSONDeleteType には、PERSON オブジェクトのすべての構成済み属性の要素があります。Delete は、オブジェクト構造の最上位 (プライマリー) オブジェクトのみをサポートします。

QueryMXPERSON 要素

QueryMXPERSON 要素には、以下の定義があります。

v QueryMXPERSON 要素のタイプは QueryMXPERSONType です。

v QueryMXPERSONType には、タイプ MXPERSONQueryType の要素MXPERSONQuery があります。

v MXPERSONQueryType には、PERSON オブジェクトのすべての構成済み属性があります。Query は、オブジェクト構造の最上位 (プライマリー) オブジェクトに対するクエリーのみをサポートします。

Query 要素は、メタデータ・スキーマの QueryContentGroup で定義される追加の属性 uniqueResults、maxItems、および rsStart を使用します。

QueryMXPERSONResponse 要素

QueryMXPERSONResponse 要素には、以下の定義があります。

v QueryMXPERSONResponse 要素のタイプは QueryMXPERSONResponseType です。

v QueryMXPERSONResponseType には、タイプ MXPERSONSetType の要素MXPERSONSet があります。

v MXPERSONSetType には、PERSON オブジェクトのすべての構成済み属性の要素、およびオブジェクト構造で定義された下位階層オブジェクト(PHONE、EMAIL、および SMS) の要素があります。

v QueryMXPERSON 要素は、クエリーをオブジェクト構造の最上位オブジェクト(PERSON) に制限しますが、応答には下位階層オブジェクト (PHONE、EMAIL、および SMS) が含まれることがあります。


Query Response 要素は、メタデータ・スキーマの ResponseContentGroup で定義される追加の属性 rsStart、rsCount、および Total を使用します。

コラボレーション・スイッチコラボレーション・スイッチは、所有権の概念を使用して、統合フレームワークと外部システムの間でのインバウンド・データの同期を管理しやすくします。このスイッチは、トランザクション内のさまざまなデータ・オブジェクトの所有権に基づいてアプリケーション内の特定のサブプロセスを制御できる機能を提供します。

大半のマスター・データおよび文書の統合オブジェクトのオブジェクト構造のプライマリー・オブジェクトには OWNERSYSID 属性があります。デフォルトでは、インバウンド統合処理は OWNERSYSID フィールドに値を指定せず、エンタープライズ・サービスは標準の方法で処理されます。

コラボレーション・スイッチの形式コラボレーション・スイッチは、特定タイプのトランザクションのデフォルト処理をバイパスできるようにして、一部のインバウンド・トランザクションの処理を制御する柔軟なユーザー定義の方法を提供します。コラボレーション・スイッチはMXCOLLAB テーブルにあります。

スイッチ・エレメント

それぞれのコラボレーション・スイッチには 4 つの要素があり、そのうち 3 つは結合して固有キーを作成します。以下の表では、これらのエレメントおよび固有キーを構成するエレメントに、アスタリスク (*) のマークが付いています。

エレメント対応する MXCOLLAB フィールド

プロセス・コントロール ID* PCID

システム ID 1* OWNER1SYSID

システム ID 2* OWNER2SYSID

プロセス・コントロール値 PCVALUE

プロセス・コントロール ID

プロセス・コントロール ID は、請求書照合の検証、一括注文書リリースの作成、および在庫実棚数の更新などのアプリケーション内のビジネス・プロセスを識別します。

次の表に、プロセス・コントロール ID のプレフィックスと、その適用対象のアプリケーションを示します。

プロセス・コントロール ID のプレフィックス対応するアプリケーション

INV 請求書

ITM 部品

IV 在庫

LT 作業員

PO 注文書


プロセス・コントロール ID のプレフィックス対応するアプリケーション

PR 購買要求書

WO 作業指示書

例えば、IVRC、IVRCY、および IVWO のコラボレーション・スイッチはいずれも在庫処理に関連しています。

システム ID 値

システム ID 1 およびシステム ID 2 は、内部システムと外部システムを識別します。これらのフィールドの値は、トランザクションおよびトランザクション内のオブジェクトによって異なります。一般的に、システム ID 1 はオブジェクトを作成したシステムを示し、システム ID 2 は参照または更新中のレコードを作成したシステムを示します。

プロセス・コントロール値

プロセス・コントロール値は、ビジネス・コンポーネントがプロセス・コントロール ID、システム ID 1、およびシステム ID 2 によって識別されるトランザクションのタイプのデフォルト処理をバイパスするかどうかを指定します。プロセス・コントロール値は 0 (False) または 1 (True) のいずれかであり、それぞれ以下の意味があります。

プロセス・コントロールの値説明

0 デフォルトの処理を実行します

1 デフォルトの処理をバイパスします

コラボレーション・スイッチの取得各プロセス・コントロール ID は少なくとも 3 つのコラボレーション・スイッチ(デフォルト・スイッチとユーザーが追加するスイッチ) に関連付けられています。統合フレームワークは、MXCOLLAB テーブルからコラボレーション・スイッチを取得するときに設定するシステム ID 値を判別するロジックを提供します。

手順1. 統合フレームワークが、インバウンド・トランザクションのプロセス・コントロール ID に基づいてシステム ID 1 およびシステム ID 2 の値を判別します。例えば、プロセス・コントロール ID が PRDEL の場合、システム ID 1

は THISMX で、システム ID 2 は購買要求書を所有するシステムです。

2. システム ID 1 の値が空、NULL、または MAXVARS テーブルの MXSYSID

行の値と等しくなっている場合、システム ID 1 は THISMX に設定されます。

3. システム ID 2 の値が空、NULL、または MAXVARS テーブルの MXSYSID

行の値と等しく、プロセス・コントロール ID が PRPAB でない場合、システム ID 2 は THISMX に設定されます。


4. プロセス・コントロール ID が PRPAB である場合、システム ID 2 の値はステップ 1 の後で NULL に設定され、システム ID 2 は EXT に設定されます(一括注文書が存在しない場合)。

5. システム ID 1 とシステム ID 2 の両方が THISMX に設定されるようになった場合、デフォルト処理が使用され、残りのロジックは適用されません。

6. 該当するキーのあるレコードが含まれているか確認するために、MXCOLLAB

テーブルが調べられます。該当するレコードが存在する場合、そのレコードのプロセス・コントロール値が標準処理を使用するかバイパスするかを示し、残りのロジックは適用されません。

7. 一致するレコードがデータベースに存在しない場合、以下の方法でキーが変更されます。

v システム ID 1 が THISMX と等しくなっており、システム ID 2 がTHISMX と等しくない場合、システム ID 2 の値として EXT が設定されます。

v システム ID 1 の値が THISMX と等しくなく、システム ID 2 が THISMX

と等しい場合、システム ID 1 の値として EXT が設定されます。

8. 変更されたキーのあるレコードが含まれているか確認するために、再度MXCOLLAB テーブルが調べられます。該当するレコードが存在する場合、そのレコードのプロセス・コントロール値が標準処理を使用するかバイパスするかを示し、残りのロジックは適用されません。

9. システム ID 1 とシステム ID 2 の両方の値として EXT が設定されます。

10. 変更されたキーのあるレコードが MXCOLLAB テーブルから取得されます。すべてのプロセス・コントロール値には両方のシステム ID が EXT に設定されたデフォルトのコラボレーション・スイッチがあるため、このレコードは常に存在します。

11. このレコードのプロセス・コントロール値が、標準処理を使用するかバイパスするかを示します。

コラボレーション・スイッチの構成定義済みのコラボレーション・スイッチを使用することも、必要に応じて新しいコラボレーション・スイッチを構成することもできます。

コラボレーション・スイッチの表示:

任意のデータベース・ツールを使用して SQL クエリーを実行し、MXCOLLAB テーブル内の値を表示するか、レポートを生成してその内容を表示します。

手順

1. 単一のプロセス・コントロール ID のコラボレーション・スイッチを表示するには、次の SQL クエリーを使用します。

select pcid, owner1sysid, owner2sysid, pcvaluefrom mxcollabwhere pcid = ’PCID’order by pcid, owner1sysid, owner2sysid;

2. すべてのコラボレーション・スイッチを表示するには、次の SQL クエリーを使用します。


select pcid, owner1sysid, owner2sysid, pcvaluefrom mxcollaborder by pcid, owner1sysid, owner2sysid;

3. プロセス・コントロール ID の簡略説明を表示するには、次の SQL クエリーを使用します。

select * from mxcollabref order by pcid;

コラボレーション・スイッチの変更:

許可ユーザーは、コラボレーション・スイッチのプロセス・コントロール値を変更することができます。既存のコラボレーション・スイッチに関するPCID、OWNER1SYSID、または OWNER2SYSID の値を変更しないでください。


MXCOLLAB テーブルの値では、大文字と小文字が区別されます。

手順

1. データベース・ツールを使用して Maximo データベースに接続します。

2. コラボレーション・スイッチのプロセス・コントロール値を変更するには、次のSQL ステートメントを使用します。

update mxcollabset pcvalue = PCVALUEwhere pcid = 'PCID'and owner1sysid = 'OWNER1SYSID'and owner2sysid = 'OWNER2SYSID';

3. コラボレーション・スイッチのキャッシュされた値を最新表示するために、アプリケーション・サーバーを再始動します。

データベースへのコラボレーション・スイッチの追加:

許可ユーザーは、コラボレーション・スイッチを MXCOLLAB テーブルに追加できます。新しいスイッチは既存のプロセス・コントロール ID を使用する必要がありますが、新しいシステム ID を使用できます。


デフォルトのコラボレーション・スイッチのみがシステム ID フィールドで値THISMX および EXT を使用できます。

手順

1. データベース・ツールを使用して Maximo データベースに接続します。

2. コラボレーション・スイッチを追加するには、次の SQL ステートメントを使用します。

insert into mxcollab(pcid, owner1sysid, owner2sysid, pcvalue)values('PCID', 'OWNER1SYSID', 'OWNER2SYSID', PCVALUE);

例

例えば、Oracle Financials システムおよびその他のアプリケーションと統合するように統合フレームワークを構成できるとします。 Oracle Financials がシステム所有の


在庫を出庫する場合、統合フレームワークはそのトランザクションを受け入れて、Maximo データベースの在庫量とコストを更新します。他のアプリケーションがシステム所有の在庫を出庫する場合、統合フレームワークはそのトランザクションを受け入れますが、Maximo データベースの在庫量もコストも更新しません。

これらの条件を反映させるために MXCOLLAB テーブルを変更する前は、INV コラボレーション・スイッチに次の値が指定されています。

プロセス・コントロール ID システム ID 1 システム ID 2


INV THISMX EXT 1

INV EXT THISMX 0

INV EXT EXT 1

このシナリオをサポートするために MXCOLLAB テーブルを変更するには、次のようにします。

1. コラボレーション・スイッチを更新するには、次の SQL ステートメントを使用します。

update mxcollabset pcvalue = 1where pcid = ’INV’and owner1sysid = ’EXT’and owner2sysid = ’THISMX’;

このステートメントにより、INV/EXT/THISMX コラボレーション・スイッチの値が 1 に変更され、通常の更新処理がバイパスされます。

2. 次の SQL ステートメントを使用して、Oracle Financials システムからのトランザクション用の新しいコラボレーション・スイッチを追加します。

insert into mxcollab(pcid, owner1sysid, owner2sysid, pcvalue)values

(’INV’, ’ORC’, ’THISMX’, 0);

新しいコラボレーション・スイッチは、システム ID として ORC を設定し、プロセス・コントロール値を 0 に設定することで、Oracle Financials から受け取った出庫トランザクションに通常の処理が適用されるようにします。OWNERSYSID が空の場合、DEFEXTSYS 統合コントロールの値が使用されます。

この手順を実行した後、INV コラボレーション・スイッチには次の値が指定されます。

プロセス・コントロール ID システム ID 1 システム ID 2


INV THISMX EXT 1

INV EXT THISMX 1

INV EXT EXT 1

INV ORC THISMX 0


例えば、ISUIN 統合コントロールの値を 1 に設定すると、出庫トランザクションが外部システムによって受け入れられます。INV コラボレーション・スイッチは、出庫に関連する在庫量とコストの更新を制御します。必要に応じて、その更新処理がバイパスされるように、このスイッチの設定を調整できます。

INV/EXT/THISMX コラボレーション・スイッチは、外部システム (システム ID 1

= EXT) で出庫され、システム (システム ID 2 = THISMX) によって所有されている在庫 (この場合、プロセス・コントロール ID = INV) の処理を制御します。

INV/EXT/THISMX コラボレーション・スイッチの値が 0 の場合、デフォルト処理が適用され、在庫量とコストの値が更新されます。

INV/EXT/THISMX コラボレーション・スイッチの値が 1 の場合、デフォルト処理がバイパスされ、在庫量とコストの値は更新されません。

この例では、ISUIN はシステムへの出庫をすべて受け入れます。INV/EXT/THISMX

コラボレーション・スイッチは、在庫ビジネス・コンポーネントがそれぞれのタイプの出庫を処理する方法を決定します。

定義済みのコラボレーション・スイッチ用意されているデフォルトのコラボレーション・スイッチおよび定義済みのコラボレーション・スイッチを使用することができます。

デフォルトのコラボレーション・スイッチ:

プロセス・コントロール ID ごとに、異なる組み合わせのシステム ID 値を持つデフォルトのコラボレーション・スイッチが 3 つ作成されます。認証済みユーザーは、必要に応じて追加のスイッチを作成することができます。

デフォルトのスイッチは、システム ID 1 およびシステム ID 2 フィールドの以下の値をさまざまに組み合わせて使用します。

システムID 値意味

THISMX MAXVARS.MXSYSID で識別されるシステム

コラボレーション・スイッチは MXSYSID の実際の値を使用しません。

EXT MAXVARS.MXSYSID で識別されるシステムではない任意のシステム

許可ユーザーは、デフォルトのコラボレーション・スイッチのプロセス・コントロール値のみを更新できます。デフォルトのコラボレーション・スイッチを削除したり、プロセス・コントロール値以外のフィールドを変更したりすると、システム障害が生じる可能性があります。

在庫コラボレーション・スイッチ:

在庫アプリケーション用に定義済みのコラボレーション・スイッチが用意されています。


プロセス・コントロール ID 説明値およびアクション

システム ID 1 の導出値


INV 在庫を更新します。

出庫、返品、その他の受領または調整の作成時に使用されます。在庫はこのシステムに存在する必要があります。

0

1

在庫を更新します。

在庫を更新しないでください。

INVTRANS またはMATUSETRANS

INVENTORY

INVDEL 在庫を削除します。

外部で所有されている在庫の削除時に使用されます。値が 1 の場合、関連したオープン状態の購買要求書、注文書、見積要求、作業指示書などに部品と保管場所が引き続き存在することになります。そのために、これらの明細の送受信で問題が発生する可能性があります。

0

1

通常のシステム検証をパスした部品を削除します。

検証を行わずに在庫を削除して、部品のINVBALANCES レコードを削除します。

“THISMX” INVENTORY

INVISS 部品の出庫を入力します。

資材の出庫時に使用されます。

0

1

在庫の資材出庫を許可します。

在庫の資材出庫を禁止します。

MATUSETRANS INVENTORY

INVISSR 部品出庫返却を入力します。

資材の返却時に使用されます。

0

1

資材の返却を許可します。

資材の出庫返却を禁止します。

MATUSETRANS INVENTORY

INVISSWO 作業指示書の実績コストである設備の INVCOST を更新します。

出庫または返却の処理時に使用されます。システム間の場合の処理を対象としており、これらの更新は別々に行われます。

0

1

作業指示書の資材実績コストである設備の INVCOST

を更新します。

作業指示書の資材実績コストである設備の INVCOST

を更新しません。

MATUSETRANS WORKORDER

INVPHY 外部実棚数を入力します。

実棚数の作成時に使用されます。

0

1

在庫の実棚数を許可します。

在庫の実棚数を禁止します。

INVTRANS INVENTORY





INVTR 社内注文書の移動時または受領時に移動元保管場所を更新します。

社内注文書の移動の作成時または受領の作成時に使用されます。

0

1

「移動元保管場所」のINVBALANCES を更新します。

「移動元保管場所」のINVBALANCESを更新しません。

MATRECTRANS LOCATIONS (移動の保管場所、社内注文書の販売元)

ITMDEL 項目を削除します。

このシステムが所有していない部品の削除時に使用されます。

重要: 値が 1 の場合、関連したオープン状態の購買要求書、注文書、見積要求、作業指示書などに部品が引き続き存在することになります。そのために、これらの明細の送受信で問題が発生する可能性があります。

0

1

通常のシステム検証をパスした部品を削除します。

検証を行わずに部品を削除します。部品のINVENTORY、INVBALANCES、およびINVVENDOR レコードも削除します。

“THISMX” ITEM

請求書コラボレーション・スイッチ:

請求書アプリケーション用に定義済みのコラボレーション・スイッチが用意されています。




IVILC 在庫の最終コストを更新します。

請求書の承認時に使用されます。

0

1

在庫の最終コストを更新します。

在庫の最終コストを更新しません。

INVOICE INVENTORY

IVINV 在庫の平均コストを更新します。


0

1

在庫の平均コストを更新します。

在庫の平均コストを更新しません。

INVOICE INVENTORY





IVMATCH 請求書照合を使用および検証します。


1 に設定する場合、IVPO も 1 に設定する必要があります。

0

1

照合を検証します。

得られるどの照合も検証しません。

“THISMX” INVOICE

IVPO 注文書と受領を更新します。


0

1

注文書ステータスおよび受領を更新します。

注文書ステータスまたは受領を更新しません。

INVOICE PO

IVPRO 請求書のヘッダーと明細の差異を検査して比例配分します。


0

1

ヘッダーと明細合計の差異を比例配分します。

ヘッダーと明細合計の差異を比例配分しません。


IVRC 注文書参照がない請求書明細のサービス受領を作成します。

明細に注文書参照がない請求書の承認時に使用されます。

0

1

注文書参照がない請求書明細のサービス受領を生成します。

注文書参照がない請求書明細にサービス受領を生成しません。


IVRCY 注文書参照およびRECEIPTREQD = N

が指定された請求書明細のサービス受領を作成します。

対応する POLINE

がサービスである注文書参照、およびRECEIPTREQD = N

が指定された請求書の承認時に使用されます。

0

1

請求書明細のサービス受領を生成します。

請求書明細のサービス受領を生成しません。

INVOICE PO





IVTOL 請求書の許容額をチェックする検証を実行します。


0

1

請求書に関するすべての許容額の検査を実行します。

請求書に関する許容額の検査を実行しません。


IVVLC 販売元の最終コストを更新します。


0

1

販売元の最終コストを更新します。

販売元の最終コストを更新しません。

INVOICE INVVENDOR

IVWO 作業指示書を更新します。


0

1

作業指示書を更新します。

作業指示書を更新しないでください。

INVOICE WORKORDER

作業員トランザクション・コラボレーション・スイッチ:

作業員トランザクション用に定義済みのコラボレーション・スイッチが用意されています。

プロセス・コントロールID 説明値およびアクション

システム ID

1 の導出値システム ID

2 の導出値

LTSRC 注文書のサービス受領を生成します。

作業員トランザクションの作成時またはステータスの変更時に使用されます。注文書がこのシステムに存在する必要があります。

0

1

LABTRANS. GENAPPRSERVRECEIPT の値を Y に設定することを許可します。「アプリケーションの設定」で構成可能です。

LABTRANS. GENAPPRSERVRECEIPT の値を N のままにします。

LABTRANS PO


注文書コラボレーション・スイッチ:

注文書用に定義済みのコラボレーション・スイッチが用意されています。


システム ID 1

の導出値システム ID 2

の導出値

PODEL PO を削除します。

PO の削除時に使用されます。注文書の変更のために注文書を削除してから後で再追加する場合にのみ使用します。

いずれかの PRLINE に注文書への参照が含まれる場合は消去します。必要な場合は、PR を再度開きます。注文書が再追加されると、PRLINE は再び確立されます。

0

1

注文書を削除しません。

注文書および PRLINE を削除して、POSTATUS を削除しません。

“THISMX” PO

POINV 社内注文書の参照されていない外部在庫を禁止します。

注文書明細の追加時または更新時、および社内注文書のステータスの変更時に使用されます。

0

1

部品と販売元の組み合わせがINVENTORY テーブルにない場合はエラーです。

部品と販売元の組み合わせがINVENTORY テーブルで見つからない場合 (ここで、PO.VENDOR =

LOCATIONS.LOCATION)、エラーを無視します。

PO LOCATIONS

(販売元は保管場所)

POIVM 販売元に関する在庫販売元情報を作成します。

PO の承認時に使用されます。

0

1

INVVENDOR レコードを更新または作成します。

INVVENDOR レコードを作成しないでください。

PO POLINE のITEM

POPR 購買要求書ステータスを更新します。

購買要求書明細を注文書にコピーする場合に使用して、購買要求書から注文書を作成し、購買要求書を再オープンします。

0

1

購買要求書ステータスを変更するか(MAXVAR 設定値に基づく自動クローズ)、購買要求書参照を含むPOLINE の削除時またはその他の再オープンのインスタンスで再オープンします。

PR ステータスを変更しないでください。

PO PR



システム ID 1


の導出値

POREL 一括注文書のリリースを作成します。

購買要求書の承認時に購買要求書明細に一括参照が含まれる場合、およびリリースが購買要求書なしに注文書から直接的に作成される場合に使用されます。

0

1

PO リリースを生成します。(PRLINE.AGREEMENTPONUM が注文書にない場合は、注文書リリースを生成しません。)

注文書リリースを再生成しません。

PR 一括契約のPO

PORES 資材予約を処理します。

社内注文書のステータスの変更時に使用されます。

0

1

在庫予約を生成します。部品と販売元の組み合わせ (販売元は社内保管場所) が INVENTORY テーブルにない場合、注文書予約を生成しません。この状況は POINV が 0 の場合に生じる可能性があります。

在庫予約を生成しません。

PO INVENTORY

購買要求書コラボレーション・スイッチ:

購買要求書用に定義済みのコラボレーション・スイッチが用意されています。


システム ID 1


の導出値

PRDEL PR を削除します。

PR の削除時に使用されます。購買要求書の変更のために購買要求書を削除してから後で再追加する場合にのみ使用します。

WPMATERIAL または MRLINE に購買要求書への参照が含まれている場合は、消去してください。これらの参照は、購買要求書を読み取るときに再設定されます。

0

1

購買要求書を削除しません。

購買要求書および PRLINE を削除して、PRSTATUS を削除しません。

“THISMX” PR



システム ID 1


の導出値

PRINV 社内購買要求書の参照されていない外部在庫を禁止します。

保管場所が外部システムで維持されている場合に使用されます。部品はシステム内の部品マスターにあります。保管場所はLOCATION として定義されます。INVENTORY

は、システムによって所有されていないため、部品と保管場所の組み合わせ用に定義されていません。

購買要求書の所有者は、購買要求書を作成するシステムのMXSYSID です。検証は、部品と保管場所(INVENTORY)

が PRLINE に対して検証される場合に行われます。保管場所のOWNERSYSID

が購買要求書のOWNERSYSID

と比較され、その組み合わせが許可されるかどうかがフラグによって決定されます。

0

1

部品と販売元の組み合わせがINVENTORY テーブルにない場合は、エラーになります。

部品と販売元の組み合わせ (販売元は社内保管場所) が INVENTORY テーブルにない場合

PR.VENDOR = LOCATIONS.LOCATION は、エラーを無視します。LOCATIONS は存在していなければなりません。つまり、ロケーションについての標準の検証をパスしている必要があります。

PR LOCATIONS

(販売元は社内保管場所)



システム ID 1


の導出値

PRPAB 参照されていない外部購買契約/一括契約を禁止します。

購買要求書明細の追加時または更新時、および購買要求書のステータスの変更時に使用されます。

0

1

PRLINE.AGREEMENTPONUM が注文書にない場合は、エラーです。

PRLINE.AGREEMENTPONUM が注文書にない場合は、エラーを無視します。

PR “EXT”

通常は一括契約の PO (注文書)

から導出されますが、この場合は一括契約のPO が存在しません

受領コラボレーション・スイッチ:

受領用に定義済みのコラボレーション・スイッチが用意されています。




RC 注文書受領を入力します。

受領の作成時に使用されます。

0

1

注文書に対する受領を許可します。

注文書に対する受領を禁止します。

MATRECTRANS

またはSERVRECTRANS

PO

RCILC 在庫の最終コストを更新します。

受領の承認時に使用されます。

0

1

在庫の最終コストを更新します。

在庫の最終コストを更新しません。

MATRECTRANS INVENTORY

RCINV 在庫を更新します。

受領時または受領の承認時に使用されます。

0

1

在庫が存在する場合は更新します。

在庫を更新しないでください。

MATRECTRANS INVENTORY

RCIV 注文書受領の請求書を生成します。


0

1

PayOnReceipt の値が設定されている場合に請求書を生成します。

PayOnReceipt の値が設定されていても請求書を生成しません。

MATRECTRANS


PO

RCPO 外部注文書を更新します。


0

1

PO を更新します。

PO を更新しないでください。

MATRECTRANS


PO





RCR 注文書の受領返品を入力します。

受領返品の作成時に使用されます。

0

1

注文書の受領返品を許可します。

注文書の受領返品を禁止します。

MATRECTRANS


PO

RCVLC 販売元の最終コストを更新します。

受領の承認時または注文書明細の受領時に使用されます。

0

1

販売元の最終コストを更新します。

販売元の最終コストを更新しません。

MATRECTRANS INVVENDOR

RCWO 作業指示書を更新します。


0

1

作業指示書を更新します。

作業指示書を更新しないでください。

MATRECTRANS


WORKORDER

作業指示書コラボレーション・スイッチ:

作業指示書用に定義済みのコラボレーション・スイッチが用意されています。




WORES 資材予約を処理します。

作業指示書のステータスの変更時に使用されます。在庫はこのシステムに存在する必要があります。

0

1

在庫予約を生成します。

在庫予約を生成しません。

WORKORDER INVENTORY



特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510

東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

© Copyright IBM Corp. 2008, 2014 431

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758 U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。これらのサンプル・プログラムは特定物として現存するままの状態で提供されるものであり、いかなる保証も提供されません。IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。

商標IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された International

Business Machines Corporation の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtml をご覧ください。


http://www.ibm.com/legal/copytrade.shtml

Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における登録商標です。

Microsoft、Windows および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

特記事項 433


��

Printed in Japan

データの外部アプリケーション への統合 - IBM · v Open Services for Lifecycle Collaboration (OSLC) 統合仕様をサポートするアプリ...

Documents

データの外部アプリケーションへの統合 - IBM · v Open Services for Lifecycle Collaboration (OSLC) 統合仕様をサポートするアプリ...