ホテルへのお問い合わせ

ブルートフォースのアプローチで、過去1カ月に開催されたすべてのイベントを特定し、そのリストを作成することができます。 イベント前に、接触したホテルのpyGUIDを取得します。 次に、D_AddressesWithinDistanceデータページで、イベントが開催される会場から5マイル以内にある「IsFor=Hotel」レコードを検索させます。 D_AddressesWithinDistanceの結果セットの参照値が取得されます。 FSG-Data-Hotel pyGUIDのリストにない参照値は保持され、FSG-Data-Hotel pyGUIDと一致しない参照値は無視されます。 残りの参照値はすべてFSG-Data-Hotelのレコードを検索するために使用されます。 参照される各FSG-Data-Contactから連絡先情報（pyFirstName、pyLastName、pyEmail1）を取得します。

この反復アプローチの問題点は、1ヶ月の間に複数のイベントを同じ会場で開催する可能性があることです。 また、2つの会場が10マイル（16キロメートル）以内にある場合もあり、それぞれの会場の半径5マイル（8キロメートル）で重複が発生することになります。 同じホテルで過去1ヶ月間にさまざまなイベントが開催された可能性もあるため、そのホテルを除外するには、1回の問い合わせで十分です。 目標は、問い合わせのないホテルを見つけることです。

D_AddressesWithinDistanceデータページは、Connect-SQLルールを呼び出すアクティビティをソースとします。 このルールには、Haversine式をもとに算出された数値が含まれています。 2つ目のテーブルサブセレクトは、Haversine式では "p "と呼ばれているもので、現在1つの場所の座標を要求しています。

あるいは、テーブルサブセレクトで、過去1ヶ月に開催されたすべてのイベントの会場の緯度と経度をリストアップすることも可能です。 現在のように1つの行に結合するのではなく、複数の会場の住所座標にまたがって結合することができます。

Haversine式の変更により、過去1ヶ月間に問い合わせのあったホテルの住所はフィルタリングされません。 この変更は、クエリ内の別の場所で行う必要があります。

このソリューションには、次のような式の実装が必要です。

HotelAddressesNotContacted ::= AllAddressesWithinDistance EXCEPT HotelAddressesContacted

オプションは次のとおりです。

• (A) CustomerDataスキーマに会場と問い合わせしたホテルの履歴を格納する。
• (B) PegaDataschemaからpyGUIDのリストを取得し、Connect-SQLクエリに会場とホテルキーのリスト (pyGUID)を "挿入"する方法を見つける。

PegaPlatform™の将来のリリースでは、PegaPlatform 固有の列（px、py、または pzで始まる列）が存在する PegaDataスキーマテーブルに対して Connect-SQL ルールクエリを許可しない可能性があります。FSG-Data-Addres テーブルは CustomerDataスキーマで定義されており、Pega Platform 固有の列はありません。 その結果、そのテーブルはConnect-SQLのルールクエリで参照することができます。 しかし、Bookingアプリケーションのケースタイプのワークプールテーブルは、Connect-SQLルールを使用して照会してはいけません。なぜなら、そのテーブルには、pzInsKeyやpzPvStreamなどの列が含まれているからです。

アプローチ(A)の課題は、過去のpyGUIDと日時をCustomerDataスキーマに格納することは、一時テーブルを使用することと同等であるため、余分な作業が必要となることです。 アプローチ(A)では、同じ情報が複数の場所に格納されるため、データの整合性が損なわれる可能性があります。

一方、アプローチ(B)では、{Asis: property-name}のような構文でSQLを挿入することが可能です。 以下の例は、HotelAddressesNotContactedの式を修正したものです。

AsisExpression プロパティ値の例を以下に示します。

Hoteel pyGUIDの数は、SQLステートメント全体がデータベースの最大許容長を超えない程度に小さくする必要があります。 先の例のような長さは、GUIDの32ヘキサ文字の長さにも見えるため、SQLステートメントの最大許容長を超えることは困難です。 例えば、PostgresSQL の SQL 文の最大長は 2,147,483,648 文字であり、2GB に相当する。

FSG-Data-Addressに適用されるD_HotelsContactedデータページは、D_AddressWithinDistanceをモデル化したものにすることが可能です。 そうするには、Connect_SQL_pr_fsg_data_addressアクティビティは、まずConnect_SQL_HotelsNotContactedにコピーします。

Connect_SQL_HotelsNotContactedアクティビティは、まず、過去1ヶ月以内に問い合わせしたホテルのGUIDのリストを取得するレポートディフィニションを呼び出すD_HotelsContactedデータページを使用します。 その後、D_HotelsContactedデータページでは、pxResults() PageList を事後処理して、AsisExpressionというプロパティの値を構築しています。

(各イベント会場につき）AllAddressesWithinDistance を導き出すためのソリューションも、同様の処理を必要とします。 目標は、次の式の右辺を解くことです。 ここでは、"NOT IN"ではなく"IN"を使用します。

このAsIsExpression値は、過去1ヶ月間に開催されたFSGEイベントに関連するVenue Address pyGUID値のシーケンスです。 以下の値は、D_VenuesUsed.AsisExpressionプロパティ値の一例です。D_VenuesUsed.AsisExpressionは、一つのイベントにつき複数のホテルに問い合わせできるため、D_HotelsContacted.AsisExpressionよりも短いです。

Event.StartDT

前述のように、会場住所pyGUIDとホテル住所pyGUIDのAsIsExpression値を導出するデータページは、レポートディフィニションをソースとしています。 これらのレポートディフィニション（VenueAddressLatLongおよびHotelAddressLatLong）は、前月に開始されたイベントのみを確認する必要があります。BookEventケースの.Event.StartDTプロパティをケースレベルのプロパティとして公開することは、レポーティングのためのOptimizeの簡単な使用法です。  BookEventケースの .Event.StartDT プロパティをケースレベルのプロパティとして公開することは、Optimize for reportingの簡単な使用法です。 その結果は以下の通りです。

各レポートディフィニション内のフィルタの一部は、次のとおりです：  EVENT.Event.StartDT  Greater Than Previous Month

.RoomsRequest.HotelGUID

現在、コンタクトした各ホテルのGUIDは、各RoomsRequestケースのRoomsRequest抽象フィールドグループ内に存在します。 このフィールドグループは、コンポーネントによってHotelアプリケーションとHotelProxyアプリケーションの間で共有されていることを思い出してください。 公開されたVenueGUIDプロパティを持つBookEventケースとは異なり、RoomsRequestケースには、公開されたケースレベルの.HotelGUIDプロパティがありません。

公開されたHotelGUIDプロパティは、ビルトオンのHotelアプリケーションの FSG-Hotel-Work-RoomsRequest クラスではなく、FSG-Booking-Work-RoomsRequest クラス内に存在する必要があります。 FSG-Booking-Work-RoomsRequestに対してHotelGUIDプロパティを定義するのは簡単なことです。 そのプロパティ値は、.HotelGUID = .RoomsRequest.HotelGUID と定義された Rule-Declare-Expression を使用して設定することができます。

前のタスクでは、VenueAddressLatLong および HotelAddressLatLong のレポートディフィニションについて説明しました。 これらのレポートディフィニションがどのように定義されているかは、提供されたソリューションで確認することができます。 当然のことながら、Queryタブでのフィルタ条件は同一です。

RoomsRequestケースはBookEvent子ケースなので、EVENTエイリアスの定義は2つのレポートディフィニションで異なることになります。  FSG-Data-Addressは、ケースではなく、FSG-Data-Locationを参照することを思い出しましょう。

ソリューションの残りの部分はは、以下の表にまとめてあります。Responseデータトランスフォーム「GenerateAsisExpressionFromAddressReference」は、spyNoteを設定することに注意してください。

最後に仕上げの要素は、HotelsNotContacted Connect-SQLルールを定義することです。 以下にBrowseタブの内容を示します。

AdddressPageのpyNoteプロパティは、(param.dist_unit = "km" ? "111.045" : "69.407") という3項式で決定されていることに注意してください。

• SELECT pyGUID AS "pyGUID", Reference AS "Reference", IsFor AS "IsFor", Street AS "Street", City AS "City", State AS "State", PostalCode AS "PostalCode", Country AS "Country", Latitude AS "Latitude", Longitude AS "Longitude", Distance AS "Distance" FROM ( SELECT z.pyguid AS pyGUID, z.reference AS Reference, z.isfor AS IsFor, z.street AS Street, z.city AS City, z.state AS State, z.postalcode AS PostalCode, z.country AS Country, z.latitude AS Latitude, z.longitude AS Longitude, {AddressPage.pyNote Decimal } * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) AS Distance FROM {Class:FSG-Data-Address} AS z JOIN ( SELECT latitude AS latpoint, longitude AS longpoint FROM {Class:FSG-Data-Address} WHERE reference IN ({Asis:D_VenuesUsed.pyNote}) ) AS p ON 1 = 1 ) AS d WHERE distance <= {AddressPage.Distance Decimal } AND reference NOT IN ({Asis:D_HotelsContacted.pyNote}) AND isFor = 'Hotel' ORDER BY distance LIMIT 15