XML (eXtensible Markup Language) スキーマ
このセクションでは、XML スキーマをカスタマイズする方法について説明します。Windchill ESI は XSD (eXtensible Schema Definition) を介してすべての Windchill ESI スキーマを定義します。XSD が選ばれたのは、セマンティックの豊富さ、スケーラビリティ、および拡張性の点で DTD (ドキュメントタイプ定義) よりも優位に立っていることが理由です。カスタマイズ担当者は XML スキーマをカスタマイズして、SAP に送信される属性を追加または変更したり、既存の PRC 呼び出しを修正したりできます。
EAI ソフトウェアコンポーネントのスキーマ:
データモデルスキーマ (CBO および ESIResponse): Windchill PDMLink の属性を追加または変更するには、これらのスキーマを変更します。
内部 EAI スキーマ (ESIResultService、ESIErrorHandling、ESILogging): ソリューションのコアアーキテクチャが変更される場合にのみ変更されます。それ以外の場合、これらが標準実装の一部として修正されることはありません。
Windchill 通信スキーマ (ESIPostResult、ESIResponse): Windchill PDMLink と EAI ソフトウェアコンポーネントの間の通信を修正する必要がある場合、これらのスキーマを修正します。これには、RPC の更新や新規の追加が含まれます。例としていくつかのシナリオを次に示します。
シナリオ 1: 新規属性をオブジェクトに追加
説明: 新規属性を返すように GetPart RPC を更新します。これにより、Windchill から部品の EAI ソフトウェアコンポーネントに追加の属性が送信されます。
EAI ソフトウェアコンポーネントのカスタマイズ手順: ESIResponse スキーマを修正してこの新規属性を追加します (このパラメータを ERP システムに渡す場合、CBO も修正する必要があります)。
シナリオ 2: 新規フラグを RPC に追加
説明: GetPart RPC を更新して Iteration という名前の新規フラグを追加して、このフラグが true に設定されている場合に作業版数情報が送信されるようにします。既成では、GetPart RPC には Alternates と Documents の 2 つのフラグしかありません。
EAI ソフトウェアコンポーネントのカスタマイズ手順: ESIResponse スキーマと CBO スキーマを修正して、Windchill から送信された作業版数情報が考慮されるようにします。
シナリオ 3: 新規 RPC を追加
説明: GetDocumentStructure という名前の新規 RPC を追加して、ドキュメント構造を照会できるようにします。
EAI ソフトウェアコンポーネントのカスタマイズ手順: ESIResponse スキーマと CBO スキーマを修正して、Windchill から送信されたドキュメント構造が考慮されるようにします。
* 
(i) 上記のいずれにおいても、TIBCO BusinessWorks でプロセス定義を更新する必要があります。
(ii) GetPart RPC は、<Windchill>\tasks\com\ptc\windchill\esi\part\GetPart.xml 内の I*E タスクを意味します。ただし、既成では、ESI サービスは前述の I*E タスクではなくクラス StandardESIService の getPart() API を呼び出します。したがって、上記のシナリオ 1 とシナリオ 2 で GetPart RPC を更新するには、クラス StandardESIService (またはクラス ESIWTPartRenderer) の拡張を作成し、必要に応じて、オーバーライドされたバージョンの getPart() API を提供する必要があります。また、シナリオ 2 に対応するために、新規属性 (作業版数情報を送信するかどうかを指定) をタイプ ESISAPTarget に追加する必要があります。GetXXX RPC および対応する StandardESIService API の詳細については、Windchill Enterprise Systems Integration Open API Guide の「RPC クラスと RPC メソッドの照会」のセクションを参照してください。
(iii) ESI サービスは既成の GetXXX RPC を使用しませんが、引き続き使用可能であり、必要に応じて呼び出すことができます。
Windchill 対話スキーマのフロー
Windchill との対話には、JMS を介して送受信されるいくつかのスキーマが含まれます。これらのスキーマは次の順序で使用されます。
スキーマ
説明
ESIResponse
ユーザーがパブリッシングリクエストを開始すると、Windchill は応答メッセージを生成し、EAI ソフトウェアコンポーネントに送信します。このメッセージには、EAI ソフトウェアコンポーネントによって SAP にパブリッシングされるデータが含まれています。
ESIPostResult
EAI ソフトウェアコンポーネントがデータを処理すると、処理された各組織内のビジネスオブジェクトごとに、成功フラグまたは失敗フラグとともに PostResult メッセージが Windchill に送り返されます。これにより、Windchill はパブリッシングに成功したオブジェクトと、再サブミットを必要とするオブジェクトを追跡できます。
ESIResultResponse
これは、トランザクションが完了し、そのステータスが Windchill で正常に記録されたことを Windchill が EAI ソフトウェアコンポーネントに対して確認するものです。
タグの命名規則
Windchill ESI XML 内のタグは先頭大文字表記に従います。この表記では、単語が連結され、各単語の 1 つ目の文字が大文字になります (例: PartNumber)。
XML タグ名にはできるだけわかりやすい名前を付けてください。ただし、タグの親ノードまたはコンテキストが明確な場合には、タグに短い名前を付けても構いません。たとえば、部品構造内の <Number> タグは部品番号と見なされます。番号がドキュメントリンクなどの別のオブジェクトの子に属している場合、このフィールドには少なくとも "DocumentNumber" という文字列が必要です。この場合、"AssociatedDocumentNumber" など、さらにわかりやすい名前をフィールドに指定することをお勧めします。
詳細については、EAI ソフトウェアコンポーネントの命名基準の「命名基準」のセクションを参照してください。
SOAP のガイドライン
SOAP は、EAI ソフトウェアコンポーネントと Windchill の間の通信に使用される XML RPC プロトコルです。ほとんどの JMS 通信は SOAP エンコードされています。
ドキュメント内の <arguments> タグの外にあるすべての XML は静的なままでなければなりません。これらのタグ内の XML 構造は、Windchill 内の RPC が修正された場合に同等に修正できます。
ESIResponse、ESIResultResponse
ドキュメント内の <COLLECTION> タグの外にあるすべての XML は静的なままでなければなりません。これらのタグ内の XML 構造は、Windchill 内の RPC が修正された場合に同等に修正できます。
応答とそのすべての子構造内の COLLECTION オブジェクトでは、"<" と ">" にそれぞれ HTML 表記 "<" と ">" が使用されます。Info*Engine では整形式の XML ドキュメントが作成されますが、セキュリティ上の目的で、JAX-M SOAP クラスは予約済みの XML 文字 (" < ' > &) が対応する XML エンティティ ("""、"<" など) に変換されることを前提としています。したがって、応答の本文には、これらの文字の HTML 表記が含まれています。
スキーマを編集およびインポートする方法
スキーマは、Windows メモ帳などの任意のテキストエディタ、または TIBCO TurboXML などの XML エディタを使用して編集できます。
メイン CBO スキーマを表示するには、BusinessWorks からスキーマを抽出する必要があります。CBO スキーマは /SharedConfigurations/ESISchemas/EAIMiddlewareSchemas フォルダにあります。CBO は多数の参照元スキーマで構成されているので、上位レベルのオブジェクトを表示するには、すべての参照先スキーマを読み込む必要があります。
1. 各スキーマの「Source」タブをクリックし、コンテンツをコピーしてテキストエディタに貼り付けます。BusinessWorks に表示されているスキーマ名に拡張子 .xsd を付けてファイルを保存します。
2. 各構造は Turbo XML で開くことができます。
3. ほかのスキーマを参照する上位レベルのオブジェクトを表示する場合、参照先スキーマの場所を尋ねるプロンプトが Turbo XML で表示されます。この場所をブラウズし、「OK」をクリックします。このプロンプトは、すべての参照先スキーマの場所が特定されるまで表示されます。
次の点に注意してください。
一部のスキーマは、別のスキーマを複数回参照します。たとえば、BOM スキーマは ObjectHeader スキーマと Effectivity スキーマを複数回参照します。この場合、Turbo XML で次の警告メッセージが表示されます。「This element type has been defined more than once.The declaration can be ignored.」
別のスキーマを参照するスキーマを表示すると、BW でエレメントの横に警告アイコンが付いた状態で参照先スキーマが表示されます。これは単にそのエレメントがロックされていることを示すものなので、そのエレメントを修正することはできません。ロックを右クリックして「unlock」を選択することで、エレメントのロックを解除できます。これにより、参照先スキーマも修正できるようになります。詳細については、TurboXML のドキュメンテーションを参照してください。
以下のセクションで説明するように、各オブジェクトに作成されている UserArea スキーマを使用して CBO を修正することを強くお勧めします。メイン CBO スキーマを修正すると致命的なエラーが発生する可能性があります。
スキーマを BusinessWorks にインポートするには、"Schema Definition" アクティビティをリポジトリに追加します。アクティビティの「Source」タブで、「Load Schema」を選択します。XML はリポジトリへのインポート時に TIBCO BusinessWork によって検証されます。
これは役に立ちましたか?