Recording BackendTime incase of failure scenario

[PrathibaJee]

As per the requirement , the backend-time is the
"Value written by the service provider, reporting the elapsed time for data retrieval from the backend (service invocation, database access…). Expressed in milliseconds"

In version 1.0.0 of ApplicationPattern , there was no support for a database.
Whereas from version 2.0.0 , we have ElasticSearch as a backend for the applications EATL , OL and ALT.
So , the time spent in the backend is now included in the header parameter backendTime.

Please find the details of the scenarios for which we are recording and not recording the BackendTime ,

Scenarios	isRecorded?	comment
A successful Single call to ES	yes
A successful Single call to ES , but an internal error due to server side logic .	no
A REST service with multiple calls to ES. And all calls are successful	yes	consolidated time of each call to ES
A REST service with multiple calls to ES. And if any one call to ES is failed	no
A REST service with multiple calls to ES. And all calls are successful. but an internal error due to server side logic .	no

In a highlevel , in the server side implementation , for negative scenarios , we are not recording the backendTime and it will be 0.
@DanaSunal , kindly please provide your input aswell.

Kindly please let us know your views.
If this implementation is fine, then we also need to document it in the specification. Thanks.

Reference : openBackhaul/ApplicationLayerTopology#298 (comment)

[openBackhaul]

Provide whatever you either already have or could very easily add.
Avoid wrong values, but don't try to be complete before some stakeholder addresses concrete need for the information.
Operational personnel is about to join this call series for address their needs.

[openBackhaul]

During discussion it turned out that it does not make sense to provide the back end time for some operation that failed. So instead of thinking about how to fill the parameter in such case, it should just be deleted.

Decision on the ImplementersCall on 28th of April 2023:
The parameter shall be deleted from header of responses with HTTP status code 400 and higher.
It is an issue of low priority and shall no cause an additional release.
So shall be deleted with the next release.