I 72 Fulfillment Type Media override and named value list on Fulfillment Part - UnionInternationalCheminsdeFer/OSDM GitHub Wiki

I-72: Fulfillment Type/Media override and named value list on Fulfillment Part

DRAFT

Description

Enable distributors to override Fulfillment Type or Media in order to obtain correct Documents or Parts needed for resale. Include named value list on Fulfillment Part to pass (proprietary) information.

Owner

  • Josef Petrák, Bileto
  • Ralf Bayer, DB

Business Value

For distributors

who need to obtain a different fulfillment type or media than was originally offered to combine offers that do not support the same fulfillment types or media

who do not work with fares, but also require to produce the fulfillment at the distributor end

the fulfillment PATCH will provide fulfillment type/media override parameters

that will enforce fulfillment generated based on given type/media deviating from the type/media specified by the offer, if the given type/media is supported for the product, and optionally if the Requestor / application/client ID assocciated with the JWT is enabled for such override

and extend the Fulfillment Part with named value list

that will carry additional information that fare providers and certain distributors understand

so Bileto is able to migrate proprietary API with incumbend distributor to OSDM because

  • the distributor combines offers in its distribution system and produces A4_PDF with its own layout and design
  • and the distributor requires proprietary fare code list ID in order pair the offer with its internal fare code list in order to correctly calculate fees billed to the carrier.

Business Outcomes

Distributors with need to fulfill combined offers on type or media, that is not supported by both fare providers, may be allowed to customize the fulfillment generation.

Distributor with business agreement with fare provide to produce the fulfillment for Offers in the distribution system with custom type/media/layout, are allowed to obtain Fulfillment Parts instead of Fulfillment Documents from the provider.

Distributor with need to further understand Fulfillment Parts will be provided with named value list that may contain documented or proprietary information intended for all or single distributor.

Leading Indicators

Distributors with the need to produce fulfillment documents at their end, or to obtain specific fulfillment documents unsupported by offers, are able to integrate OSDM and continue to function.

Nonfunctional Requirements

None

Specification Effort

SMALL

Draft of the Change

  • extend available FulfillmentMediaType by FULFILLMENT_PARTS,
  • postFulfillments and finalizeFulfillment requests should take a body or query string parameters to optionally specify overrideFulfillmentType and overrideFulfillmentMedia and return HTTP 400 if such override is not supported or Requestor/JWT-associcated application is not allowed to such override,
  • document that Offers are fulfilled by Document and Fares by Fulfillment Parts, and that such override allows to fulfill offers by parts,
  • document that fulfillment media/type override may be unsupported for certain products or may be restricted by default and only allowed for agreed Requestor/application, noting such whitelisting is outside of the specification,
  • extends the FulfillmentPart with an optional named value list to pass information to the distributor.

Please note that originally the working group proposed to post and finalize the fulfillments as before, and only override the FulfillmentType or FulfillmentMediaType in getFulfillmentId request. However, the fulfillment document/part generation is triggered by the finalize request and thus we have to check on ability for override in the postFulfillments request in order not to confirm a booking the distributor can't fulfill as needed (e.g. doesn't have corrent printer, paper, ability to merge media types together with other offers, ...).

Also providing the override parameters in the request body is better suited for POST and PATCH requests. Query string was the option for the GET that we suggest to keep intact.