uAPI Workshop Summary

Retain Reservation

 

예약시에, Schedule 이나 Price 아니면 혹은 둘다 변경이 됐을경우 PNR 생성에 대한 가능 여부를 제어하게 도와줍니다. AirCreateReservationReq @RetainReservation 는 예약 요청시 보낸값이 실제 항공사의 inventory 정보와 일치하지 않을경우 그 값을 비교하여 PNR 을 생성할지에 대한 결정을 내릴수 있도록 합니다. 만약 예약 요청시 보낸값과 실제 항공사 inventory 의 정보가 다를 경우 RS 내에 AirSolutionChangedInfo 값이 리턴되고 어떤 정보가 변경됐는지 에 대한 설명이 주어집니다. 리턴되는 Warning message 는 “Segment sync error. Flight times returned from the carrier do not match the flight times requested.” 입니다.  uAPI 16.3.0.2 에는 RetainReservation 에 새로운 로직이 소개되었습니다. 이로써, 고객들은 예약내의  sell failure 가 요금 때문인지 세그먼트 스케줄 때문인지 알수 있게 되고 이에따라 예약을 폐기 할지 안할지에 대한 선택을 가능하도록 합니다.

 

AirCreateReservation RQ의 가장 상단 부분에, RetainReservation 를 사용하십시오. 이에따라, Booking 시점에서 스케줄이나 요금변경에 따른 PNR 생성 여부를 관리 할수 있게 됩니다.

o   RetainReservation=”None”

·         만일 요금 아니면 스케줄 아니면 둘다 변경이 일어났을 경우 PNR 이 만들어 지지 않습니. AirSolutionChangeInfo 은 새로운 스케줄과 요금을 리턴합니다.

o   RetainReservation=”Price”

·         요금변경시에는 PNR 이 만들어지고, 스케줄만 변경 혹은 스케줄과요금 둘다 변경되었을경우는 PNR 이 만들어 지지 않습니다.

o   RetainReservation=”Schedule”

·          스케줄이 변경되었을 경우만 PNR 이 만들어 지고 요금만 변경 혹은 요금과 스케줄 둘다 변경 되었을 경우는 PNR 이 만들어 지지 않습니다.

o   RetainReservation=”Both”

·          스케줄이나 요금이 변경됐다거나 혹은 둘다 변경됐다 할지라도 PNR 이 만들어 집니다.

 

만일 RetainReservation 이 설정되었으나 스케줄이나 요금 변경이 발생하지 않았다면 AirSolutionChangedInfo 값이 리턴되지 않고 성공적으로 PNR 이 만들어 집니다.

 

RetainReservation equals	Changed Value	UR/PNR Created?	AirSolutionChangedInfo returns...
None	Schedule	No	New time.
	Price	No	New price.
	Both	No	New time and price.
Price	Schedule	No	New time.
	Price	Yes	Original price.
	Both	No	New time and price.
Schedule	Schedule	Yes	Original time.
	Price	No	New price.
	Both	No	New time and price.
Both	Schedule	Yes	Original time.
	Price	Yes	Original price.
	Both	Yes	Original time and price.

 

 

AirSolutionChangeInfo

 

AirSolutionChangedInfo 는 예약 시점시 요청된 요금이나 스케줄 변경이 발생됐을경우 리턴되는 값입니다. 여기에는, 어떤 값이 상이 한지에 해당하는 이유코드 (e.g., <AirSolutionChangedInfo ReasonCode="Price">)를 포함하고 있습니다.  예전에는 Air booking 이나 Universal Record 변경시 AirSolutionChangedInfo/AirPricingSolution 가 Air Pricing Solution 의 한 부분으로 총/기본 요금 그리고 Tax를 보여줬었으나, 현재는 요금 변경시 Air Pricing 내에서 어떤 요금 정보도 보여지지 않습니다. uAPI 15.2 (Air v32.0) 혹은 그 이정 버전에서는, 오직 출발 비행시간이 변경됐을 경우만 스케줄 변경값을 리런했었습니다. uAPI 15.3(Air v33.0)에서는 출발시간이나 도착시간 변경될 경우에도 AirSolutionChangedInfo 값이 리턴됩니다. 1G,1V,1P,1J 상에서, AirSolutionChangedInfo 에서 보여지는 데이타는 예약요청 RQ의 @RetainReservation 값에 따라 영향을 받게 니다.  ACH(Airline Content Hub) 는 @RetainReservation 을 지원하지 않으므로 예약이 성공적으로 요청된 이후에는 요금이나 스케줄 변경과는 상관없이 예약은 항상 유지가 되게 됩니다.

 

Air Segment Connection Logic

 

만일 LFS 에서 Connection/SegmentIndex 가 리턴된다면, 이는 둘 혹은 그 이상의 세그먼트에 커넥션이 존재한다는것을 알립니다.  Connection indicator 는 Pricing 이나 예약시에 Sell failure 없이 해당 항공편이 성공적으로 판매가 된것을 확신하기 위해 사용되어야 합니다.

커넥션 로직은 Air pricing 과 Air Booking 양쪽에 포함되어 있습니다. LFS 나 Air Availability 의 RS 에서 보여지는 Connection Segment index 정보는 데이타 배열처럼 보여집니다.

<air:Connection SegmentIndex="0" />

<air:Connection SegmentIndex="1" />

<air:Connection SegmentIndex="3" />

<air:Connection SegmentIndex="4" />

 

SegmentIndex 는 connection indicator 가 반드시 포함된 Air segment 를 보여줍니다. SegmentIndex 의 값은 air segment  리스트에 상의 Air Segment 의 위치값 + 1 로 계산하시면 됩니다. 바로위에 언급된 경우를 예로 들자면, 이 겨우 LFS 의 Airpricing 솔루션이 아래와 같이 리턴됩니다.

SegmentIndex="0" would link to the air segment in the first position in the list.

SegmentIndex="1" would link to the air segment in the second position in the list.

SegmentIndex="3" would link to the air segment in the fourth position in the list.

SegmentIndex="4" would link to the air segment in the fifth position in the list.

Note : 이는  <air:Connection SegmentIndex="#" /> 이 커넥션이라는것을 보여주는유일한 요소입니다. 만일 커넥션에 스탑오버가 포함되어 있을겨우는 커넥션으로 간주되지 않고 Stop 의 의미로 인식됩니다.  다시말해,  <air:Connection StopOver="true" SegmentIndex="3"/>는 커넥션이 아닌것으로 보시면 됩니다.

 

Air Availability Source

 

Airsegment 내의 AvailabilitySource 는 어떤 특정 Availability data 가 원천으로 리턴되었는지를 가르킵니다.

중요 : 이 값은 LFS 나 Availability 에서 리턴됩니다. 이 값은 반드시 Follow-on 리퀘스트의 용도로 리턴되며 이는  TVPT 내부 시스템의 보고,추적,문제해결 그리고 트랜잭션 실패로그를 보기위해 사용됩니다. 이는  Booking이나 Pricing 에 영향을 끼치지 않으며 하나의 값을 가지고 있습니다.

 

Availability information

Availability Status (AVS)/Numeric AVS (NAVS)

-          항공사 Availability 의 가장 오래된 데이타 형태

-          참여 항공사들은 트래블포트에 24/7 동안 AVS/NAVS 데이타를 푸쉬

-          이 메세지를 가지고 트래블 포트의 AVS/NAVS 데이타 베이스를 구축

-          어떤 항공사는 AVS/NAVS 의 정확도를 제공하기도 하나, 그보다 향상된 기능이 요구되는Availability 데이타 (e.g POS) 를 전부 만족시키지는 못함

-          트래블포트는 항공사가 Seamless 나 Direct Access 를 제공하지 않거나 Polling 이 허용되지 않은 경우 AVS/NAVS 데이타를 사용

 

Direct Access Availability

-          항공사 참여여부에 대한 동의가 반드시 필요

-          항공사들이 제공하는 상호교환적이고 실시간 응답 프로덕트

-          Direct Sell 이나 Seamless 에 참여 혹은 참여하지 않은 항공사들의 경우, Direct access Session 이 연결된 workflow 우회로 이루어집

-          실시간 Availability 를 위해서 트래블포트가 RQ내에서 Poll 을 요청함

-          항공사가 Seamless 를 제공하지 않고 Direct access modifier 가 포험되어 있을경우 트래블 포트는 항공사로 Poll 을 요청

-          Direct access 요청은 주어진 날짜/타임에 해당하는 가능한 항공편 데이타 요청을 항공사로 전송

-          항공사는 내부 알고리즘에 근거에 어 항공편을 리턴할지 결정

-          항공사는 RS에 모든 가능한 좌석 정보를 리턴

Note : 트래블포트는 항공사로 특정 항공 편수 리스트들을 보내지 않음. 항공사는 Inventory 요청이 된  Air Pricing 에서 필요한 항공편값을 리턴 할수도 안할수도 있음. 만일 항공사가 필요 항공정보를 리턴하지 않을경우 트래블 포트는 AVS/NAVS 데이타에 의존

 

Seamless Availability

-          항공사는 반드시 Seamless Availability 데이타 제공에 동의를 해야함

-          Seamless 참여 항공사는 Direct Sell(a sessioned book action that skips pricing)  에도 참여가능.

-          트래블포트는 항공사로 실시간 Availability 를 Poll 요청

-          만일 항공사가 Seamless 와 Direct Access Availability 에 참여할경우, 트래블 포트는 Shopping 이나 Low Fare Finder 로부터 항상 항공사 Poll  데이타를 사용

-          Seamless 는 항공사로 특정 항공편수 리스트를 보냄. 이때 해당 항공편이 직항인지 연결편인지를 구분하는 indicator 를 포함함

-          항공사는 자신들의 수익창출 로직에 맞추어 전체 Class 의 Availability 정보로 응답. 이때, 계산 방법은 아래의 조건을 하나 혹은 여러개를 포함할수도 있음 :

a)       the point of sale (agency and/or country where agency is located),

b)      the point of commencement,

c)       the Origin-and-Destination (e.g., direct vs connecting flights),

d)      Journey Data (flights currently booked and active in the agency’s AAA).