Disclaimer

This document is only collection of author’s notes, experiences and point of views. It is not, in any meaning, either complete description of the topic nor official RTB documentation. It may be inaccurate, incomplete, obsolete, misleading or completely wrong. It may even cause loss of data or damage system integrity. It may not comply with company codex, values, presentation style or economic interests or may reveal company secrets.

As such, it is absolutely prohibited to distribute this document outside of RTB & Co. GmbH. Such an action may result into legal acts against both the sender and the company. It is only intended, after review of technical and presentational correctness and accuracy, to be used as an information source for official documentation.

Always contact documentation department for information about current presentation style and allowed formats before creating customer’s documentation.

1. Overview

The PDM needs to request some information from PDM.control in real time. Usually there is a time delay (1-5 seconds) caused mainly by mobile network and implementation in PDM. The delay is added s added to each request. Therefore multiple requests accumulate the time delay which is unpleasant for the customer.

The target of this proposal is to eliminate the delay by connecting multiple requests into one package to transfer and process.

2. Current situation

Every real time requests contains mnemonic REQ with number indicating request type e.g. REQ1. Of course the request can have parameters which are included in the message from PDM. For instance the request number 1 requires following parameters: KNN, BET, TRC. The request processor reads the parameters which are needed and send the response in as an another parameter(s) e.g. CBL500.

It is not possible to send multiple requests simultaneously, because the input and output parameters can collide. It is necessary to distinguish which parameter belongs to which request.

3. Multi-request

Multi-request combines multiple requests into one data (JSON) structure. The server processes it and send the response, when all parts are resolved.

3.1. Request

3.1.1. Global context

Multi-requests starts with mnemonic MRQ followed by array of requests to process.

Example 1. Multi-request
MRQ[{REQ:0},{REQ:2},{REQ:5}];KNN57841;BET100;BID2;PAN6; ...

In this case will be the request with number 1, 2, 5 resolved with parameters from global context defined outside of MRQ object. All requested will be supplied with the same parameters (based on request needs).

3.1.2. Local context

It can also happened that the one (or more) of requests requites a different value of parameter which is already defined in global context. In this case can each requests overwrite parameters in its own context like this:

Example 2. Local context
MRQ[{REQ:1},{REQ:2,BET:50,LPN:"XYZ"},{REQ:5}];KNN57841;BET100;PAN6;LPNABC ...

This means that request with id

  • 1 will evaluated in global context: KNN57841;BET100;BID2;PAN6;LPNABC.

  • 2 will (locally) overwrite the value of parameter BET and LPN to provided values. Its evaluation context will be KNN57841;BET50;BID2;PAN6;LPNXYZ.

  • 3 will evaluated again in global context: KNN57841;BET100;BID2;PAN6;LPNABC.

4. Response

The values in response almost always collide because most of the requests returns a time, tariff or monetary bonus. Therefore it does not make much sense to work with global context and all the results of requests are returned directly in multi response MRQ mnemonic like this:

Example 3. Multi-response
MRQ[{REQ:1,BET:5},{REQ:2,LPN:"ABC",BET:170},{REQ:5}];DAT181009;TIM...

The response contains an (JSON) array where each object has REQ key with request id followed by request results. The order of key is in JSON object is not guaranteed although the order of response object in the array is (see next chapter).

4.1. Order immutability

Please note that, the order of response objects is the same as order of requests. Therefore it is possible to send the same request multiple times in with different parameters within one multi-request.

Example 4. Request ordering
MRQ[{REQ:2,LPN:"XYZ"},{REQ:2}];KNN57841;BET100;BID2;PAN6;LPNABC ...

which will be interpreted as

REQ2;KNN57841;BET100;BID2;PAN6;LPNXYZ

and

REQ2;KNN57841;BET100;BID2;PAN6;LPNABC

may result following response

MRQ[{REQ:2,TID:7},{REQ:2,TID:2}];DAT181009;TIM...

The first JSON object is the answer to the first request with id 2. The second object is the answer to second request with id 2, while both responses caries independent set of output parameters.