Test scenarios

This page lists the scenarios of the certification, interface by interface, in the order D-EDGE works through them; the phase two scenarios add the calls your platform makes. Use the scenario identifiers when you report a result to your D-EDGE Connectivity Project Manager. Most scenarios run on every integration. A marker next to an identifier means the scenario needs a condition: hover it to read which one. Your questionnaire is what tells D-EDGE which conditions you meet.

Phase one: basic behaviour

D-EDGE runs these scenarios against your test environment, without Push bookings. The requests arrive exactly as in production, namespace declarations and <authentication> element included: see Requests. The room and rate codes they use are the ones your Get hotel response returns.

Checks on every response

Every request of the plan carries these four checks, success or failure alike: a response that misses one fails the scenario whatever else it contains.

Check	What must be true
Status	`200 OK`, on a failure too. See Always 200 OK.
Content type	A `Content-Type: application/xml` header, and a body that parses as XML with `<message>` as its root.
Response time	Under 5 seconds, or 30 seconds on Get bookings.
Envelope	On a failure, exactly one `<failure>` element carrying a `type` from the error tables, its `message` when you send one, and at most one `<comment>` with no stack trace in it.

Get hotel

The first scenario feeds the rest of the plan: D-EDGE reads your price model, your currency, and your room and rate codes from its response.

ID	What we send	What we expect
GH-01	A request with valid credentials and the test hotel’s `hotelCode`	The hotel configuration, checked against the Get hotel reference, on a test hotel that carries at least three room types and three rates in total, one room carrying at least two rates
GH-02	The same request without credentials	A `<failure>` of type `3`. D-EDGE also accepts type `203`.
GH-03	The same request with a wrong password	A `<failure>` of type `3`
GH-04	A request without `hotelCode`	A `<failure>` of type `1`, `2`, or `203`
GH-05	A request with an unknown `hotelCode`	A `<failure>` of type `1` or `2`

Planning updates

The prices of each scenario arrive in the shape of your price model. Every date range is relative to the day of the session.

Updates you must accept

ID	What we send	What we expect
PU-01	Room inventory only: one room, several contiguous ranges, no `rate` element	`<success>`, and the quantities applied on your platform
PU-02	Room inventory up to the maximum horizon you declared	`<success>`
PU-03	A range that starts yesterday	`<success>`; the past day is ignored, the rest applied. See Engineer for the traffic pattern.
PU-04	Room inventory plus an `availability` attribute on `planning`, for one room and rate, up to the maximum horizon you declared	`<success>`, with the rate-level availability applied
PU-05	`minimumStay` only, on two rates of the same room, each over its own ranges	`<success>`
PU-06	`maximumStay` only, on two rates of the same room, each over its own ranges	`<success>`
PU-07	`noArrival` only, on two rates of the same room, each over its own ranges	`<success>`
PU-08	`noDeparture` only, on two rates of the same room, each over its own ranges	`<success>`
PU-09	`isClosed` only, on two rates of the same room, closed then reopened on the first and the reverse on the second	`<success>`, and the room and rate closed then reopened on your platform
PU-10	Prices only, no inventory and no restriction	`<success>`
PU-11	Prices and restrictions together, no inventory	`<success>`
PU-12	A full update of one room and one rate: inventory, prices, and restrictions over several ranges, including a single-day range	`<success>`, and every value applied
PU-13	Ranges that leave gaps between them, in the inventory and in the planning	`<success>`; the days not covered are left untouched
PU-14	One room with several rates, each with its own prices and restrictions, and an availability quantity of `0` on one range	`<success>`, and the room closed to sale on that range
PU-15	Several rooms with a single rate	`<success>`
PU-16	Several rooms with several rates, one of the rooms carrying inventory only	`<success>`
PU-17	Several rooms up to the maximum horizon you declared	`<success>`
PU-18	Prices of `2.00`, `200.00`, and `340000000.50`	`<success>`, because the hotel set them. A price check on your side belongs in an internal alert, not in the response.
PU-19	A rate with `mealPlanType` and `mealPlan` elements: adult only, child only, then adult and child	`<success>`, with `unitPrice` applied as the total price, meals included. See Meal plans.

Updates you must refuse

Each of these messages is valid XML with one wrong value.

ID	What we send	What we expect
PU-F1	A wrong password in `<authentication>`	Type `3`, `BadAuthentication`
PU-F2	An unknown `hotelId`	Type `1` or `2`
PU-F3	An unknown room `id`	Type `4`, `RoomMappingError`
PU-F4	An unknown room next to a valid room	Type `4`, and the valid room applied anyway. See Your response.
PU-F5	An unknown `rateCode`	Type `5`, `RateMappingError`
PU-F6	An unknown rate next to a valid rate	Type `5`, and the valid rate applied anyway

Get bookings

The content checks run on whatever your test hotel returns. Before the session, create a one-room booking, a booking with several rooms and a child, a modified booking, and a cancelled one. D-EDGE can create them instead, through a booking engine on the hotel. With no booking in the window, the request scenarios still pass on a bare <success>.

Requests

ID	What we send	What we expect
GB-01	The per-hotel variant with `duration`	`<success>` followed by one `<bookings>` element for the hotel, with the bookings whose latest action falls in the window
GB-02	The per-hotel variant with `from` and `to`	Same
GB-03	The per-hotel variant with no window parameter	Same, behaving as `duration=1`
GB-04	The all-hotels variant with `duration`	`<success>` followed by one `<bookings>` element per hotel with bookings
GB-05	The all-hotels variant with `from` and `to`	Same
GB-06	The all-hotels variant with no window parameter	Same, behaving as `duration=1`
GB-F1	A request with a wrong password	Type `3`, `BadAuthentication`
GB-F2	A request with an unknown `hotelId`	Type `1` or `2`
GB-F3	A `duration` that is not an integer	Type `203`, naming the parameter in the comment
GB-F4	A `from` or `to` that does not match `YYYY-MM-DDTHH:MM:SS`	Type `203`, naming the parameter in the comment

Booking content

These checks apply to every booking of every successful response, against the booking message structure.

ID	What we check
GB-C1	Each booking appears once, with an `id` unique in the response, under the `action` of its latest action and dated with that action’s time in `YYYY-MM-DDTHH:MM:SS`. See What belongs in a window.
GB-C2	`currency` matches the currency your Get hotel response declares
GB-C3	`totalAmount`, `paidAmount`, `dueAmount`, and `payableAmount` are present and decimal, and `totalAmount` equals the sum of every stay’s `unitPrice` times `quantity`, plus every extra
GB-C4	`paxCount` is at least 1, `adultCount`, `childCount`, and `infantCount` are either all present or all absent, and the optional attributes take their documented values when present: `commissionType`, `sellType`, `dayUse`, `arrivalTime`, `departureTime`
GB-C5	The `customer` carries a first and last name, except on a cancellation; `title`, when present, is `Mr`, `Mrs`, or `Miss`
GB-C6	`creditCard`, when present, carries `expiryDate` in `YYYY-MM` and a documented `cardType`; `company` and `travelAgent`, when present, carry a `name`
GB-C7	Every room `id` and every stay `rateCode` exist in your Get hotel response
GB-C8	Every `stay` carries a `date` in `YYYY-MM-DD`, a `quantity` of at least 1, a `unitPrice`, and a `rateCode`
GB-C9	Every room carries one `guest` per person, each with an `ageRange` of `10`, `8`, or `6`
GB-C10	Every `extra` carries `unitPrice`, `extraCode`, `quantity`, `inclusive`, and `pricingType`, at the level it applies to. See Put extras where they belong.

Confirm bookings

The acknowledgements refer to bookings your endpoint returned, so these scenarios run after the Get bookings ones.

ID	What we send	What we expect
CB-01	A `bookingConfirmation` with `status="Create"`, naming a booking you returned in `partnerBookingId` and the D-EDGE reference in `crsBookingId`	`<success>`, and the booking marked as integrated on your side
CB-02	A `bookingConfirmation` with `status="Modify"` for a modified booking	`<success>`
CB-03	A `bookingConfirmation` with `status="Cancel"` for a cancelled booking	`<success>`

Phase two: live certification

Push bookings is in play from here. Your D-EDGE Connectivity Project Manager works on the D-EDGE test hotel linked to yours, in production conditions, and checks the result on your side.

ID	What happens	What we expect
LC-01	D-EDGE changes availability, prices, and each restriction you declared on the D-EDGE test hotel	Each change reaches your platform within minutes and is applied, in the shape of your price model
LC-02	Your platform pushes the creation, then the modification, then the cancellation of a booking through Push bookings, while D-EDGE also pulls them through Get bookings	A `<success>` from D-EDGE on each push, each action integrated once, and a Confirm bookings acknowledgement with the matching `status` on your endpoint
LC-03	D-EDGE reads the integrated bookings	Guests, amounts, and extras exactly as your booking messages described them

Run them yourself

The phase one scenarios ship as a collection for Postman and Insomnia.

The collection covers the 43 scenarios that are requests D-EDGE sends to your endpoints. The other 13 run with D-EDGE during the session. The booking content checks GB-C1 to GB-C10 read what your endpoint answers, and the phase two scenarios need the D-EDGE platform on the other side.

D-EDGE Docs: Channel Manager API test scenarios

The downloads, the variables to fill, and the order to run the folders in, on the API collections page.

Get started

Build

Get certified

Resources

Phase one: basic behaviour

Checks on every response

Get hotel

Planning updates

Updates you must accept

Updates you must refuse

Get bookings

Requests

Booking content

Confirm bookings

Phase two: live certification

Run them yourself

D-EDGE Docs: Channel Manager API test scenarios

Next steps

Certification steps

Questionnaire

​Phase one: basic behaviour

​Checks on every response

​Get hotel

​Planning updates

​Updates you must accept

​Updates you must refuse

​Get bookings

​Requests

​Booking content

​Confirm bookings

​Phase two: live certification

​Run them yourself

D-EDGE Docs: Channel Manager API test scenarios

​Next steps

Certification steps

Questionnaire

Phase one: basic behaviour

Checks on every response

Get hotel

Planning updates

Updates you must accept

Updates you must refuse

Get bookings

Requests

Booking content

Confirm bookings

Phase two: live certification

Run them yourself

Next steps