| Oracle® Fusion Middleware Oracle Business Data Synchronization Server管理者ガイド 11g リリース2 (11.1.2.1.0) B66162-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Data Synchronization Server管理者ガイド 11g リリース2 (11.1.2.1.0) B66162-01 |
|
前 |
次 |
この章では、BDSSでカレンダ・ドメイン・レコードを同期化する方法について説明します。
この章の構成は、次のとおりです。
カレンダ・ドメインは、レコード・データ書式と参加者に関連する処理を除いて、他のドメインと同様に同期化されます。ただし、カレンダ・ドメインのレコード・データ書式は、他のドメインのレコード・データ書式とは異なります。つまり、他のドメインでは、ドメイン・レコードがXMLドキュメントとして表現され、そのレコードの各フィールドがXMLドキュメントのノードとして表現されます。ハブ・カレンダ・ドメインの場合、レコードは同様にXMLドキュメントですが、各フィールドがドキュメントの個別のノードになるのではなく、単一のノードがあり、その値がiCalendar (ICAL)メッセージになります(http://www.ietf.org/rfc/rfc2445.txtの「RFC 2445: Internet Calendaring and Scheduling Core Object Specification」を参照してください)。埋め込まれたICalendarメッセージには、個別のフィールド名と値が格納されます。
|
注意: ICALは、カレンダ・データを交換するための広く受け入れられた基準である一方で、XMLに関しては現在まで明確な規定がなく、ICALからXMLへのマッピング基準はありません(http://www.ietf.org/old/2009/proceedings/02mar/I-D/draft-ietf-calsch-many-xcal-01.txtの「IETF draft for XCAL」を参照してください)。 |
ハブ・カレンダ・ドメインには、ICalBodyというフィールドが1つのみあります。ICalBodyの値は、RFC 2445に準拠するVCALENDARコンテンツです。このフィールドは、ハブからPIMおよびPIMからハブへのXSLファイルによってマップされます。
例9-1 ハブXML
<?xml version="1.0" encoding="windows-1252" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://xmlns.oracle.com/bdss/hub/CalendarDomain" targetNamespace="http://xmlns.oracle.com/bdss/hub/CalendarDomain" elementFormDefault="qualified"> <xsd:element name="HubCalendarDomain"> <xsd:complexType> <xsd:sequence> <xsd:element name="ICalBody" type="xsd:string" minOccurs="1" maxOccurs="1" nillable="false"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
|
注意: このドキュメントは、値がICALメッセージであるフィールドが埋込みICALとして格納されているXMLドキュメントを参照します。 |
この変換は、他のすべてのドメインと同様に、変換によって2つのXSDが適切になる場合に、ハブとPIM間でのXML形式の変換の際にXSL変換で作成される内容に関するコネクタ実装詳細です。
ハブXMLレコードをPIM XMLレコードに変換する場合、コネクタは、埋込みICALからXMLへの変換または埋込みICALから埋込みICALへの変換を実行します。同様にPIM XMLレコードをハブXMLレコードに変換する場合も、コネクタは、XMLから埋込みICALへの変換または埋込みICALから埋込みICALへの変換を実行する可能性があります。たとえば、ハブからPIMの書式にXMLを変換する場合、あるコネクタのXSL実装ではハブのICalBodyフィールドをICALのXMLに相当する形式に変換し、別のコネクタではICalBodyをICALメッセージとして保持する可能性があります。いずれの場合も、目的のPIMのレコードを作成または更新する際は、結果のPIM XMLを解析して、PIM APIで使用可能な形式に変換する必要があります。ハブICalBodyフィールドをICALのXMLに相当する形式に変換するコネクタの場合、PIM API変換ルーチンでは、変換対象のXMLからICALを取得し、ICALを解析してPIM APIコンストラクトを作成します。ICalBodyをICALメッセージとして保持するコネクタの場合、PIM API変換では、ICAL表現のXMLを解析し、PIM APIコンストラクトを作成します。
この変換は、フィールド・マッピング・カスタマイズの実行方法、またはコネクタ実装でカスタマイズが許可されるかどうかに関するコネクタ実装詳細です。第8章「ハブ・フィールドへのコネクタ・フィールドのマッピング」で説明されているように、コネクタはXSDおよびXSLTを使用して、レコードのハブおよびPIMのXML表現を変換します。これはカレンダ・ドメインについても当てはまります。
カレンダ・データはICALが埋め込まれているXMLドキュメントとしてシステム内を移動するため、ハブ・カレンダとPIMカレンダ間のフィールド・マッピングをカスタマイズすると、第8章「ハブ・フィールドへのコネクタ・フィールドのマッピング」に記載されているマッピングより複雑になります。
コネクタのXSLTでICALからXML、XMLからICALに変換できる場合は、XSLを変更してフィールド・マッピングをカスタマイズできます。ただし、このXSLTフィールド・マッピングは、他のドメインXSLTより複雑になる可能性があります。
コネクタのXSLTが埋込みICALからXMLへの変換またはXMLから埋込みICALへの変換を行わない場合、コネクタ実装により、PIMカレンダ・レコードのテンプレート(繰返しプロパティのないフィールドのサブセットが格納されているカレンダ・レコードを表すため、ここではテンプレートと呼びます)を表すPIM XSDファイルおよびXSLTファイルの個別のセットを定義することで、マッピング・カスタマイズ機能を提供できます。一方のXSDには、マッピング可能なICALフィールド名のサブセット(つまり、単一のVEVENTに関するフィールドで、すべてのフィールドがXSDに記載されているわけではない)を格納できます。もう一方のXSDにはPIMフィールド名が格納されます。コネクタは、ハブに用意されているICALメッセージの指定のVEVENTを解析して処理するため、ICALを使用してVEVENTのXMLメッセージを作成した後、XSLを使用してデータを変換し、それによってマッピングをカスタマイズできる機能が得られます。その後、コネクタは、結果のXMLを使用してPIM API変換を実行できます。このドキュメントでは、この方式を2次変換方式と呼びます。
図9-1は、XSDおよびXSLTのグラフィック表現です。コネクタがICAL VEVENTを処理するため、exchangevirtualcalendar.xsdに準拠するXMLメッセージが作成されます。その後、コネクタはXSLを使用してexchange2007calendar.xsdに準拠する形式にXMLを変換します。図9-1に示したカスタマイズでは、同期化の対象としてLOCATIONがマップされていません。
ハブに公開されない一連のXSDには、2次変換方式を使用してカスタム・フィールドを追加できます。コネクタによるハブとの同期を有効にするには、次のXSDファイルを作成する必要があります。
コネクタのフィールド定義を定義するXSDファイル
フィールド定義のICALに対応する部分を定義するXSDファイル
コネクタのフィールド定義をICALの定義に変換するXSLTファイル
ICALのフィールド定義をコネクタの定義に変換するXSLTファイル
これらのファイルは、ハブに公開されることはないため、2次ファイルとみなされます。Exchange 2007コネクタでは、2次変換XSDファイルとXSLTファイルを更新することで、カスタム・カレンダ・フィールドの同期化を有効にできます。詳細は、付録E「カスタム・フィールドのXSLTおよびXSD」を参照してください。
ハブ・スキーマでの同期化のサポートは、VEVENT、VTIMEZONE、VALARMカレンダ・コンポーネントに制限されています。
|
注意: Oracle Fusion Middleware 11g リリース1では、BDSSはVTODO、VJOURNALおよびVFREEBUSYコンポーネントに関するカレンダの同期化をサポートしていません。 |
ハブでは次のことも必要です。
METHODプロパティは常にREQUESTである必要があります。
単一のICALメッセージでPIMカレンダ・レコードを表す必要があります。例外がある繰返しパターンがカレンダ・レコードに含まれている場合、ICALメッセージには複数のVEVENTコンポーネントが(ICALメッセージの最初のVEVENTコンポーネントがパターンのマスター・レコードで、後続の各VEVENTコンポーネントが例外を表すように)含まれている必要があります。
会議を記述するすべてのICALメッセージには、同じ会議IDが必要です。異なるシステム・キー・フィールドからのレコードが相互に一致する場合、同一の会議では抽出時に問題が発生する可能性があります。それらが一致する場合、レコードには異なる会議IDが確保されます。ハブでは、構成済のキー・フィールドに基づくレコードが一致した場合は、その一致を作成/作成競合として処理し、更新内容を非優先コネクタにプッシュします。非優先コネクタは、優先コネクタのレコードと確実に一致するようにレコード・データの更新操作を実行します。
ターゲット・システムのMeetingIdを更新すると、カレンダ・システムに問題が発生する可能性があります。コネクタでは、MeetingIdを変更する場合は注意が必要です。たとえば、ExchangeではMeetingIdを使用して、会議のすべての参加者全体で会議の更新電子メールと会議への招待電子メールを相互に関連付けます。ExchangeコネクタがMeetingIdを変更すると、コネクタはExchangeの通常の会議処理を中断し、電子メールは本来の方法では機能しません(本来の方法では、参加者が会議への招待を読んで招待を受諾したときにカレンダ・レコードが作成されます。参加者が会議の更新電子メールを読むと、対応するカレンダ・レコードが更新されます)。
RFC 2445の「Section 4.8.8.1: Non-Standard Properties」で説明されているように、ICAL標準では、名前がX-で開始するプロパティの形式でカスタム・フィールドを使用できます。たとえば、X-ORACLE-BDSS-EXCHANGE-F1やX-ORACLE-BDSS-BPEL-F1は、有効なカスタム・フィールド名の例です。さらに、カスタム・フィールドおよびカスタム・フィールド値は、繰返しのカレンダ・レコードに対する例外ごとに異なる可能性があります。カレンダ・ドメインを同期化するすべてのコネクタ全体でカレンダ・ドメインを正常に同期化できるように、開発者は、2次変換を介して、またはICALフィールドとカスタム・フィールドをハブ・カレンダ定義に含めることで、カスタム・フィールドを使用できるようにコネクタを実装する必要があります。
コネクタによる2次変換メカニズムの使用が選択された場合は、PIM固有のXSDにカスタム・フィールドを定義して、マッピングを定義できます。カスタム・フィールドは、ハブで提供されるICALメッセージに引き続き存在します。
コネクタで2次変換オプションを使用しないことが選択された場合は、ハブ・タイプ・ライブラリXSDにハブ・データ型を定義して、それぞれのXSDにこのタイプのカスタム・ハブ・フィールドおよびカスタムPIMフィールドを定義できます。これらのフィールドは、その後PIMからハブおよびハブからPIMへのXSLTファイルにマップできます。コネクタは、ICalBody外部にカスタム・フィールド・データを配置します。コネクタが各例外(おそらく、HubTokensデータ型に類似するなにか)に対して異なるカスタム・プロパティと値を指定できるように、データ型定義では複数の値を許可する必要があります。このアプローチでは、ソース・コネクタのICALカスタム・フィールドをターゲット・コネクタの標準のICALフィールドにマップできるため、データが失われる危険性があります。詳細は、第9.5.2項「標準のICALフィールドへのカスタムICALフィールドのマッピング」を参照してください。
次の理由でデータの消失が発生する可能性があります。
第9.2項「カスタム・カレンダ・フィールドの変換」で説明されているように、ICALフィールドを同期化しないとデータが失われる危険性があります。したがって、ターゲット・カレンダ・システムが指定のフィールドをサポートしていない場合は、コネクタが非表示のカスタム・フィールドを使用してすべてのICALフィールドの同期化を試行する必要があります。
コネクタのPIMサーバーが非表示のカスタム・フィールドをサポートしていない場合は、コネクタ実装でフィールド・データを保持して取り出すための対策を講じる必要があります。このアプローチを使用してもデータの消失が発生する可能性があります。埋込みICALからXMLに変換するXSLの場合、XSLでICALフィールドが省略されると、ターゲット・コネクタがフィールドに値を書き込まないため、データの消失が発生します。コネクタが2次変換アプローチを使用するときは、ICALフィールドのマッピングが行われない場合に同じ問題が発生します。いずれの場合も、各ICALフィールドが確実にマップされるようにすることで改善できます。クライアント・アプリケーションがデフォルトで表示しないカスタムPIMフィールドにフィールドを同期化すると、コネクタには、そのフィールドが同期化されていないかのように表示される可能性があります。コネクタのシステムが非表示のカスタム・フィールドをサポートしていない場合、コネクタは、抽出時にフィールド・データをハブに提供できるように、フィールド・データを保持する方法について対策を講じる必要があります。
コネクタが埋込みICALをXMLに変換できない場合、または2次変換方式を適用しないように選択した場合は、フィールド・マッピング・カスタマイズがサポートされず、PIMフィールド名へのICALフィールド名の自然なマップに依存します。この場合、フィールド定義またはマッピング・カスタマイズのサポートはありません。
第9.4項「カスタム・カレンダ・フィールドの作成」で説明されているように、ICalBody外部にフィールド・データを配置するコネクタは、ソース・コネクタのICALカスタム・フィールドをターゲット・コネクタの標準のICALフィールドにマップすることになります。たとえば、BPELカレンダに「HTTP Link」というフィールドがあり、BPELユーザーがクリックすると、カレンダ・レコードに関連付けられている情報を提供するBPELアプリケーションのページに移動するとします。また、管理者は、このフィールドをExchangeのフィールドと同期化する必要があると仮定します。このフィールドを表現できるICALフィールドがないため、X-ORACLE-BDSS-BPEL-HTTP-LINKなどのカスタムICALフィールドを定義します。ICALのX-で開始するフィールド(X-ORACLE-BDSS-HUB-HTTP-LINKなど)を保持するためにハブXSDを変更し、BPELタスク・コネクタで使用される(ハブからPIM、PIMからハブへの)XSLの2つのフィールドをマップします。フィールドをExchangeと同期化するには、ExchangeのカスタムICALフィールド(ORACLE-BDSS-EXCHANGE-HTTP-LINKなど)を定義して、Exchangeコネクタで使用される(ハブからPIM、PIMからハブへの)XSLのORACLE-BDSS-HUB-HTTP-LINKフィールドにマップします。
Exchangeのカスタム・フィールドをExchange XSDに定義する場合は、拡張フィールドまたは索引のないフィールドとして定義できます。「HTTP Link」をExchangeカレンダの「Location」フィールドに書き込むと、フィールドはExchangeの索引のないフィールド「Location」として定義されます。この索引のないフィールドは「ICAL LOCATION」フィールドに自然にマップされるため、コネクタは「ICAL LOCATION」フィールド値ではなくORACLE-BDSS-EXCHANGE-HTTP-LINK値を使用して「Location」フィールドを更新し、BPELタスク・コネクタは、Exchangeからの変更があった場合にリンクを使用して「ICAL LOCATION」フィールドを自然にマップする後続の同期化セッションでフィールドを上書きします。コネクタが「ICAL LOCATION」フィールドを使用してORACLE-BDSS-EXCHANGE-HTTP-LINK値を無視して「Location」フィールドを更新すると、Exchangeで変更が発生した場合に、後続のセッションでBPELタスク・コネクタが「HTTP Link」フィールド値を削除することになります。
カスタム・フィールドを指定する拡張フィールド(つまり、Outlook UIにフィールドを公開するOutlookカスタム・フォームを定義していないかぎり非表示となる)としてフィールドを定義した場合、このようなデータの消失は発生しません。
|
注意: この例では、BPELタスク・コネクタは、ハブに送信されるICALを作成するときに「HTTP Link」値を「LOCATION」フィールド値として指定することで、このカスタマイズをハードコード化しません。 |
