Beckn Gateway Optimization

[ravi-prakash-v]

There are multiple requirements here.
For Beckn G/W:

Beckn G/W could send search requests to fewer and relevant BPPS if it knew the location where service is required and the regions where a BPP provides services to do the matching.

What is needed for this use case is: "Where is the service Required?" in a domain agnostic way. Since, in mobility it is start, in kirana, it is end. It was thought, that user's location could be a proxy for this service location in a domain-agnostic way. However, In the meeting it was pointed that users may book for other people (whose location would be the service location).

Considering these aspects, We could pass a separate "service-location" element in context /headers to be used by beckn gw for determining the bpps to fire the searches on

Therefore for this usecase, "service-location" in context/header would be sufficient. BAP may duplicate the fulfillment start/end in this attribute based on domain so the gw could use it in a domain agnostic way.

For A BPP:

By knowing the real BAP user, BPP would be able to customize searches and/or give promotions based on BPP's own analytics of the real user who is placing the order. This is for knowing the "ordering user".

To Summarize:
We may need 2 attributes in context.

1. user (for BPP)
2. service-location (for G/W). Or else every time a new domain is added. G/W would need to understand the fulfillment element for that domain. This goes against optimal ignorance principle.

Originally posted by @venkatramanm in #86 (comment)

[ravi-prakash-v]

I see the User as an attribute still present on the schema. A more generic schema is needed. For further discussions, I have opened a Github Issue on the same topic.