The Beckn Protocol Server is a service that helps applications in connecting to the Beckn Network. It follows the Beckn Protocol, making it easier for applications to begin using Beckn Protocol. Any network participant can run this server and connect with the Beckn Network.
The Protocol Server is the application that facilitates interaction between BAP and BPP with the network. Besides network interaction, it also validates network participants and keeps track of requests and responses made to the network or any network participant.
In the case of BAP
- Protocol server - Client-Facing
- Protocol server - Network-Facing
In the case of BPP
- Protocol server - Client-Facing
- Protocol server - Network-Facing
- Webhook
* Client and Network run the same codebase. For running the protocol server in BAP or BPP mode only change needed is at the configuration level.*
This server manages context building, validates request bodies based on the Standard Beckn Open API schema, listens to the Message Queue, aggregates results in Synchronous mode, and forwards the results to the client-side application as a webhook callback.
This server forwards requests to the respective Participant or Beckn Gateway (BG). It validates incoming requests from Participants & BG according to the Standard Beckn Open API schema and verifies the signature sent from clients to ensure data integrity.
This server listens to the Message Queue, forwards requests to the client-side application, exposes an endpoint for the client-side application to send results to the network. The received data is validated against the Standard Beckn Open API schema and pushed to the network-facing Protocol Server.
This server listens to the Message Queue, forwards requests to the respective Participant or BG, and validates incoming requests from Participants & BG based on the Standard Beckn Open API schema. It also verifies the signature sent from clients to ensure data integrity.
This is a Node.js application designed to function as an intermediary layer between the BPP client and the actual data source application. The application's workflow involves receiving requests from the BPP client, responding with an acknowledgment (ACK) to the BPP client, forwarding the original request to the actual data source application, receiving the response from the data source, and finally, initiating the reverse flow. The reverse flow includes triggering the 'on_action' routes of the BPP client, and the response then flows backward in the opposite direction.
To run the application, make sure you have the following installed:
- Node.js version 16 or above
- npm version 8 or above
- MongoDB version 4.4 or above
- RabbitMQ version 3.8 or above
- Redis version 6.2 or above
(Optional)
- Docker version 20.10 or above
Note: It's recommended to set up Docker Desktop to use docker-compose for development environments (Windows/Mac). We suggest configuring MongoDB, RabbitMQ, and Redis using Docker.
The protocol server can be set up in two env.
- Local System (Dev env) - Link to local-setup.md
- Production env - Link to prod-setup.md
Ans: The Message ID and Transaction ID are like special labels that help keep track of API calls and the different stages an order goes through.
Transaction ID: It is used both at the Beckn Application Platform (BAP) and Beckn Provider Platform (BPP) to keep an eye on and recognize the whole journey of an order.
Message ID: Is used to indentify a specific Becknified API calls during the order process. It is also used as a primary key in storing the response on the BAP side by keeping it in MongoDB, a dedicated system used for saving responses for fast retreival of data on the BAP side.
Q. Are these IDs mandatory or optional? If mandatory, please specify the specific cases in which they are required.
Ans: These IDs are mandatory in the protocol server architecture. If you forget to provide them, the protocol server will create them on its own, use them to build the context object, and check the response.
Q.What is the format of these IDs and how are they being used at the infra level i.e - Redis / MongoDB / RabbitMQ.
Ans: The IDs are strings. For message_id, it's important to be unique in each Beckn-specific API call to get new responses instead of cached ones. Meanwhile, transaction_id, used to identify the entire order lifecycle at the BAP or BPP level, can change in different order lifecycles. These IDs are created using the random_uuid npm package in the Protocol server and are used as a primary key to store every Beckn API response in the MongoDB.