Server CompleteSet
69 views
Skip to first unread message
Stefano Seppi
Feb 8, 2018, 10:00:24 AM2/8/18
to AlpineBits
In the new version of AlpineBits it will be introduced the possibility for a server to ask for a CompleteSet and not only for Deltas. In order to allo to make reset of the data in case of risk of desincronization between server and client.
Tech YA
Jun 12, 2018, 11:00:47 AM6/12/18
to alpin...@googlegroups.com
Proposal: server requests client
for completeSet
Issue:
It may be necessary for the server to re-synchronize its data with the client in case of data corruption.
Use cases:
- the server is unable to process a delta thus suspecting of data inconsistency with the client
- an unexpected error causes some of the server data to become corrupted
Solution:
In these cases it would be useful for the server to be able to request the client to send a completeSet as soon as possible.
Implementation proposal:
For any RS message coming from the server regarding an AlpineBits action that accepts a completeSet
- use of the Status attribute in an empty Warning or Error element set as advisory (Type=”11”):
Since the completeSet request doesn’t necessarily imply an error nor a warning about the related RQ message, I thought at first that the advisory Warning element was the best choice for such request.
But since the purpose is to have a fixed standardized element to be used when necessary in order to ease the implementation, this was not possible in case of errors because the Warnings container requires the Success element which has no sense used together with the Errors container.
So the final proposal defines a fixed standardized element for both Warning and Error elements so that a server can use the one that best suits the response it is going to send.
The Status attribute according to OTA is defined as follows:
“If present, recommended values are those enumerated in the OTA_ErrorRS, (NotProcessed | Incomplete | Complete | Unknown) however, the data type is designated as string data, recognizing that trading partners may identify additional status conditions not included in the enumeration.”
OTA therefore allows the definition of additional values for such attribute so we could easily define the status “SendCompleteSet” (or a more implementation-oriented string such as “AlpineBitsCompleteSet”; we may discuss about it).
The Type attribute is set to “11” (advisory) so to make clear that the element is not an AlpineBits warning (Warning element with Type=”3”) nor an AlpineBits error (Error element with Type=”13”).
The content of the element can be left empty.
Upon receiving a response with one of these elements in the form described above, the client MUST transmit the required completeSet as soon as possible, ideally right after receiving the response, in order to avoid any inconsistency to remain on the server for too long.
In addition, to avoid loops,
A server MUST NOT send any completeSet request in this form in response to a completeSet sent by the client.
A client MUST ignore any completeSet request received in response to a completeSet.
Example 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
The server accepts the message but requests a completeSet.
Example 2:
<Success/>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
The server sends a warning together with a request for a completeSet.
Example 3:
<Errors>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”11” Status=”SendCompleteSet”></Error>
</Errors>
The server sends an error together with a request for a completeSet.
Alternative rule:
A client that receives such request without or along with AlpineBits advisory or AlpineBits warning messages, may decide to send the completeSet at the next scheduled connection instead of “as soon as possible” (which is still valid in case of AlpineBits error messages).
--------------------------------------------------------------------------------------------------------------
Proposta: richiesta di completeSet da parte del server
Problema:
Può capitare che il server talvolta abbia bisogno di ri-sincronizzare i dati col client in caso di compromissione degli stessi.
Casi di utilizzo:
- il server riceve dei delta non processabili facendolo sospettare di incoerenza dei dati fra lui e il client
- un errore imprevisto corrompe parte dei dati che il server ha in suo possesso
Soluzione:
Sarebbe utile che in questi casi il server possa richiedere l’invio di un completeSet il prima possibile per ri-allinearsi.
Proposta di implementazione:
Per ogni messaggio RS inviato dal server inerente a un’action AlpineBits che preveda l’uso di completeSet
-uso dell’attributo Status in un elemento Warning o Error vuoto usato come advisory (Type=”11”):
Siccome la richiesta di completeSet non implica necessariamente un errore o un warning relativo al messaggio RQ a cui il server sta rispondendo, ho inizialmente reputato che un singolo elemento Warning di tipo advisory fosse quello più adatto per l’implementazione.
Tuttavia, volendo proporre un elemento prefissato e standardizzato, per facilitare gli sviluppi, da usare liberamente quando necessario, esso non era sufficiente in quanto non sarebbe stato possibile utilizzarlo in caso di errori. Infatti l’elemento contenitore Warnings richiede la presenza dell’elemento Success, che non avrebbe senso utilizzare assieme all’elemento contenitore Errors.
Quindi la proposta finale definisce un elemento prefissato e standardizzato sia per l’elemento Warning che per l’elemento Error, in modo che il server utilizzi quello adeguato in base alla risposta che sta per inviare.
L’attributo Status è definito in OTA come segue:
“If present, recommended values are those enumerated in the OTA_ErrorRS, (NotProcessed | Incomplete | Complete | Unknown) however, the data type is designated as string data, recognizing that trading partners may identify additional status conditions not included in the enumeration.”
OTA quindi permette la creazione di nuovi valori per l’attributo permettendoci quindi di definire facilmente lo status “SendCompleteSet” (o una stringa più inerente alla nostra implementazione come “AlpineBitsCompleteSet”; se ne può discutere).
L’attributo Type è impostato a “11” (advisory) in modo da distinguere chiaramente l’elemento in questione dai warning AlpineBits (elemento Warning con Type=”3”) e dagli errori AlpineBits (elemento Error con Type=”13”).
Il contenuto dell’elemento può venir lasciato vuoto.
Alla ricezione di una risposta con uno di questi elementi nella forma appena descritta, il client DEVE trasmettere il completeSet richiesto il prima possibile, idealmente immediatamente dopo aver ricevuto la risposta, in modo da evitare la permanenza di eventuali incoerenze per troppo tempo sul server.
Inoltre, per evitare dei loop,
Un server NON DEVE inviare una richiesta di completeSet in questa forma in risposta all’invio di un completeSet da parte del client.
Un client DEVE ignorare qualsiasi richiesta di completeSet che riceva in risposta a un completeSet.
Esempio 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
Il server accetta il messaggio ma richiede un completeSet.
Esempio 2:
<Success/>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
Il server invia un warning assieme a una richiesta di completeSet.
Esempio 3:
<Errors>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”11” Status=”SendCompleteSet”></Error>
</Errors>
Il server risponde con un errore assieme alla richiesta di completeSet.
Regola alternativa:
Un client che riceva una richiesta di completeSet senza o assieme a degli advisory o a dei warning AlpineBits, può decidere di inviare il completeSet richiesto durante la prossima connessione programmata invece che “il prima possibile” (che resta valido nel caso in cui la riceva con degli errori AlpineBits).
Issue:
It may be necessary for the server to re-synchronize its data with the client in case of data corruption.
Use cases:
- the server is unable to process a delta thus suspecting of data inconsistency with the client
- an unexpected error causes some of the server data to become corrupted
Solution:
In these cases it would be useful for the server to be able to request the client to send a completeSet as soon as possible.
Implementation proposal:
For any RS message coming from the server regarding an AlpineBits action that accepts a completeSet
- use of the Status attribute in an empty Warning or Error element set as advisory (Type=”11”):
Since the completeSet request doesn’t necessarily imply an error nor a warning about the related RQ message, I thought at first that the advisory Warning element was the best choice for such request.
But since the purpose is to have a fixed standardized element to be used when necessary in order to ease the implementation, this was not possible in case of errors because the Warnings container requires the Success element which has no sense used together with the Errors container.
So the final proposal defines a fixed standardized element for both Warning and Error elements so that a server can use the one that best suits the response it is going to send.
The Status attribute according to OTA is defined as follows:
“If present, recommended values are those enumerated in the OTA_ErrorRS, (NotProcessed | Incomplete | Complete | Unknown) however, the data type is designated as string data, recognizing that trading partners may identify additional status conditions not included in the enumeration.”
OTA therefore allows the definition of additional values for such attribute so we could easily define the status “SendCompleteSet” (or a more implementation-oriented string such as “AlpineBitsCompleteSet”; we may discuss about it).
The Type attribute is set to “11” (advisory) so to make clear that the element is not an AlpineBits warning (Warning element with Type=”3”) nor an AlpineBits error (Error element with Type=”13”).
The content of the element can be left empty.
Upon receiving a response with one of these elements in the form described above, the client MUST transmit the required completeSet as soon as possible, ideally right after receiving the response, in order to avoid any inconsistency to remain on the server for too long.
In addition, to avoid loops,
A server MUST NOT send any completeSet request in this form in response to a completeSet sent by the client.
A client MUST ignore any completeSet request received in response to a completeSet.
Example 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
The server accepts the message but requests a completeSet.
Example 2:
<Success/>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
The server sends a warning together with a request for a completeSet.
Example 3:
<Errors>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”11” Status=”SendCompleteSet”></Error>
</Errors>
The server sends an error together with a request for a completeSet.
Alternative rule:
A client that receives such request without or along with AlpineBits advisory or AlpineBits warning messages, may decide to send the completeSet at the next scheduled connection instead of “as soon as possible” (which is still valid in case of AlpineBits error messages).
--------------------------------------------------------------------------------------------------------------
Proposta: richiesta di completeSet da parte del server
Problema:
Può capitare che il server talvolta abbia bisogno di ri-sincronizzare i dati col client in caso di compromissione degli stessi.
Casi di utilizzo:
- il server riceve dei delta non processabili facendolo sospettare di incoerenza dei dati fra lui e il client
- un errore imprevisto corrompe parte dei dati che il server ha in suo possesso
Soluzione:
Sarebbe utile che in questi casi il server possa richiedere l’invio di un completeSet il prima possibile per ri-allinearsi.
Proposta di implementazione:
Per ogni messaggio RS inviato dal server inerente a un’action AlpineBits che preveda l’uso di completeSet
-uso dell’attributo Status in un elemento Warning o Error vuoto usato come advisory (Type=”11”):
Siccome la richiesta di completeSet non implica necessariamente un errore o un warning relativo al messaggio RQ a cui il server sta rispondendo, ho inizialmente reputato che un singolo elemento Warning di tipo advisory fosse quello più adatto per l’implementazione.
Tuttavia, volendo proporre un elemento prefissato e standardizzato, per facilitare gli sviluppi, da usare liberamente quando necessario, esso non era sufficiente in quanto non sarebbe stato possibile utilizzarlo in caso di errori. Infatti l’elemento contenitore Warnings richiede la presenza dell’elemento Success, che non avrebbe senso utilizzare assieme all’elemento contenitore Errors.
Quindi la proposta finale definisce un elemento prefissato e standardizzato sia per l’elemento Warning che per l’elemento Error, in modo che il server utilizzi quello adeguato in base alla risposta che sta per inviare.
L’attributo Status è definito in OTA come segue:
“If present, recommended values are those enumerated in the OTA_ErrorRS, (NotProcessed | Incomplete | Complete | Unknown) however, the data type is designated as string data, recognizing that trading partners may identify additional status conditions not included in the enumeration.”
OTA quindi permette la creazione di nuovi valori per l’attributo permettendoci quindi di definire facilmente lo status “SendCompleteSet” (o una stringa più inerente alla nostra implementazione come “AlpineBitsCompleteSet”; se ne può discutere).
L’attributo Type è impostato a “11” (advisory) in modo da distinguere chiaramente l’elemento in questione dai warning AlpineBits (elemento Warning con Type=”3”) e dagli errori AlpineBits (elemento Error con Type=”13”).
Il contenuto dell’elemento può venir lasciato vuoto.
Alla ricezione di una risposta con uno di questi elementi nella forma appena descritta, il client DEVE trasmettere il completeSet richiesto il prima possibile, idealmente immediatamente dopo aver ricevuto la risposta, in modo da evitare la permanenza di eventuali incoerenze per troppo tempo sul server.
Inoltre, per evitare dei loop,
Un server NON DEVE inviare una richiesta di completeSet in questa forma in risposta all’invio di un completeSet da parte del client.
Un client DEVE ignorare qualsiasi richiesta di completeSet che riceva in risposta a un completeSet.
Esempio 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
Il server accetta il messaggio ma richiede un completeSet.
Esempio 2:
<Success/>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warning Type=”11” Status=”SendCompleteSet”></Warning>
</Warnings>
Il server invia un warning assieme a una richiesta di completeSet.
Esempio 3:
<Errors>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”11” Status=”SendCompleteSet”></Error>
</Errors>
Il server risponde con un errore assieme alla richiesta di completeSet.
Regola alternativa:
Un client che riceva una richiesta di completeSet senza o assieme a degli advisory o a dei warning AlpineBits, può decidere di inviare il completeSet richiesto durante la prossima connessione programmata invece che “il prima possibile” (che resta valido nel caso in cui la riceva con degli errori AlpineBits).
Il 08/02/18 16:00, Stefano Seppi ha
scritto:
In the new version of AlpineBits it will be introduced the possibility for a server to ask for a CompleteSet and not only for Deltas. In order to allo to make reset of the data in case of risk of desincronization between server and client.
--
You received this message because you are subscribed to the Google Groups "AlpineBits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+...@googlegroups.com.
To post to this group, send email to alpin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/f3c9bed0-5ca9-4421-9372-1604033d1f5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tech YA
Jun 25, 2018, 6:26:07 AM6/25/18
to alpin...@googlegroups.com
I reviewed some of the parts previously proposed
according to the discussion of the last developers' meeting and
added the suggested feature about requesting a completeSet
regardless of the RQ to which the server is responding.
Modified parts are highlighted in red.
--------------------------------------
Modified parts are highlighted in red.
--------------------------------------
Proposal: server requests client for completeSet
Issue:
It may be necessary for the server to re-synchronize its data with the client in case of data corruption.
Use cases:
- the server is unable to process a delta thus suspecting of data inconsistency with the client
- an unexpected error causes some of the server data to become corrupted
Solution:
In these cases it would be useful for the server to be able to request the client to send a completeSet as soon as possible.
Implementation proposal:
- use of the Status attribute in an empty Warning
or Error element set as advisory (Type=”11”):
This element can be used in any RS message
coming from the server responding to any AlpineBits RQ.
Limiting the request for a completeSet of a specific data only in response to the RQ of the corresponding AlpineBits action, could force a server to keep inconsistent data for a long time while waiting for the client to send the correct RQ. To avoid this, it has been proposed to allow a server to add such completeSet request in any AlpineBits RS so that it can use any communication started by the client to forward a specific data-synchronization request.
Since the completeSet request doesn’t necessarily imply an error nor a warning about the related RQ message, I found at first that the advisory Warning element was the best choice for such request.
Limiting the request for a completeSet of a specific data only in response to the RQ of the corresponding AlpineBits action, could force a server to keep inconsistent data for a long time while waiting for the client to send the correct RQ. To avoid this, it has been proposed to allow a server to add such completeSet request in any AlpineBits RS so that it can use any communication started by the client to forward a specific data-synchronization request.
Since the completeSet request doesn’t necessarily imply an error nor a warning about the related RQ message, I found at first that the advisory Warning element was the best choice for such request.
But since the purpose is to have a fixed standardized element to be used when necessary in order to ease the implementation, this was not possible in case of errors because the Warnings container requires the Success element which has no sense used together with the Errors container.
So the final proposal defines a fixed standardized element for both Warning and Error elements so that a server can use the one that best suits the response it is going to send.
The Status attribute according to OTA is defined as follows:
“If present, recommended values are those enumerated in the OTA_ErrorRS, (NotProcessed | Incomplete | Complete | Unknown) however, the data type is designated as string data, recognizing that trading partners may identify additional status conditions not included in the enumeration.”
OTA therefore allows the definition of additional values for such
attribute so we could easily define the following:
- ALPINEBITS_FREEROOMS for requesting a completeSet of free rooms data
- ALPINEBITS_RATEPLANS for requesting a completeSet of rate plan data (full data + completeSet)
- ALPINEBITS_INVENTORY for requesting the room configuration
The value for the Status attribute must be chosen from the above ones based on the needs of the server.
- ALPINEBITS_FREEROOMS for requesting a completeSet of free rooms data
- ALPINEBITS_RATEPLANS for requesting a completeSet of rate plan data (full data + completeSet)
- ALPINEBITS_INVENTORY for requesting the room configuration
The value for the Status attribute must be chosen from the above ones based on the needs of the server.
The Type attribute is set to “11” (advisory) so to make clear that the element is not an AlpineBits warning (Warning element with Type=”3”) nor an AlpineBits error (Error element with Type=”13”).
The content of the element can be left empty.
Only one of such elements may be sent in a
given response, implying that if a server requires several
completeSets for different data, it must request them in
different responses (one for each).
This is in order to maintain a form of single “request-response” communication without the client’s need to keep track of several completeSet requests in a single RS message.
A server SHOULD request a specific completeSet only regarding data that the client supports (i.e. that has been previously sent by the client at least once).
A client MUST ignore any completeSet request regarding data it does not support with the given server.
This is in order to maintain a form of single “request-response” communication without the client’s need to keep track of several completeSet requests in a single RS message.
A server SHOULD request a specific completeSet only regarding data that the client supports (i.e. that has been previously sent by the client at least once).
A client MUST ignore any completeSet request regarding data it does not support with the given server.
Upon receiving a response with one of these elements in the form described above, the client MUST transmit the required completeSet as soon as possible, ideally right after receiving the response, in order to avoid any inconsistency to remain on the server for too long.
A server MUST NOT request a completeSet in
response to a completeSet regarding the same data sent by the
client.
A client MUST ignore any completeSet request received in response to a completeSet if the requested completeSet refers to the same data just sent (FreeRooms, RatePlans or Inventory).
This is to avoid communication loops in which a server, due to processing errors, automatically requests a completeSet after receiving one, thus forcing a client to continuously send full data.
Example 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”ALPINEBITS_FREEROOMS”></Warning>
</Warnings>
The server accepts the message and requests a FreeRooms completeSet.
Example 2:
A client MUST ignore any completeSet request received in response to a completeSet if the requested completeSet refers to the same data just sent (FreeRooms, RatePlans or Inventory).
This is to avoid communication loops in which a server, due to processing errors, automatically requests a completeSet after receiving one, thus forcing a client to continuously send full data.
Example 1:
<Success/>
<Warnings>
<Warning Type=”11” Status=”ALPINEBITS_FREEROOMS”></Warning>
</Warnings>
The server accepts the message and requests a FreeRooms completeSet.
Example 2:
<Success/>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warnings>
<Warning Type=”3”>
Rate elements referred to same InvTypeCode with overlapping periods
</Warning>
<Warning Type=”11” Status=”ALPINEBITS_RATEPLANS”></Warning>
</Warnings>
The server sends a warning together with a request for a RatePlans completeSet.
Example 3:
</Warnings>
The server sends a warning together with a request for a RatePlans completeSet.
Example 3:
<Errors>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”13” Code=”321”>
missing Start attribute in StatusApplicationControl element
</Error>
<Error Type=”11” Status=”ALPINEBITS_FREEROOMS”></Error>
</Errors>
The server sends an error together with a request for a FreeRooms completeSet.
</Errors>
The server sends an error together with a request for a FreeRooms completeSet.
Il 12/06/18 17:00, Tech YA ha scritto:
Tech YA
Jul 6, 2018, 11:49:22 AM7/6/18
to alpin...@googlegroups.com
I added the changes proposed during the last
meeting and formatted the text in a more documentation-form.
I left some comments in square brackets where I had doubt about some wording.
I won't be able to attend the next Developers' meeting so if you have any changes to suggest, please let me know about them here or on GitLab, thanks.
Francesco Vovk
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
I left some comments in square brackets where I had doubt about some wording.
I won't be able to attend the next Developers' meeting so if you have any changes to suggest, please let me know about them here or on GitLab, thanks.
Francesco Vovk
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
Il 25/06/18 12:26, Tech YA ha scritto:
To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/96506612-2fd4-4813-369e-8018850b0446%40yesalps.com.
Reply all
Reply to author
Forward
0 new messages