OTST_TS_SNCF_PAX_INFO_UPD

[NicolasAU35]

Description: Scenario with an offer request based on a trip specification for a passenger, booking request based on the response of the offer response. Update passenger information (first name, last name, birthdate, phone number, mail). The booking will be fulfilled with status confirmed. The trip is based on a single outbound leg.

Scenario:

1. Generate and send a post offer request with one passenger
2. Generate and send a post booking request
3. Update passenger information (first name, last name, birthdate, phone number, mail)
4. Generate and send a post fulfillment request
5. Generate and send a get booking request

SFR

[jspetrak]

21 OTST_TI_PATCH_PASSENGER from @LucFen duplicated this. Adding its description for reference.

Description Scenario includes: • POST /offers request based on a tripSearchCriteria, containing origin, destination and departure time • POST /bookings request based on the response of the offer response. • Patch of the passenger name using patch /bookings/{bookingId}/passengers/{passengerId}

Scenario

Generate and send a post /offers request with a tripSearchCriteria, containing origin, destination and departure time
Generate and send a post /bookings request using one offer in the post /offers response
Generate and send a patch /bookings/{bookingId}/passengers/{passengerId} request using the bookingId and passengerId contained in the post /bookings response

[jspetrak]

TODO - Check with tech group how should API providers handle properties that they don't read for passenger. If they do not return the patched value, validation would fail. In that case, configuration in data_file would be needed to specify supported passenger/purchaser properties. (this is different from the requestedInformation pattern)

[TOP-PHE]

Outcome of OTSTS meeting:

The scenario should valiadte the behavior of the API and check that API is answering with error messaeg when a request is sent for an unsupported field by the inventory. IT should check also the error message provided when the rquest send a mix of supported and unsupported fields. As the scenario is also used by to support companies implementing OSDM on their own inventory system, We should also check with a get booking that the change is implemented in the booking displayed.

As this is not yet validated fully by OSTS teamm, discussion will continue next week.

[TOP-PHE]

OTST meeting discussion. Use case of a request with one supported and one non supported paratmeter change request: What type of repsponse expceted 1) an error message 2) update of supported parameter and warning message ? 3) Only store the info required but no warning message ?

Also an open point on GDPR , should we store the Email if not needed even if globally it is supported.

To be discussed with the expert group .