Date: Fri, 29 Mar 2024 14:36:21 +0000 (UTC) Message-ID: <586319966.21.1711722981189@2ceb05d3323e> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_20_478593708.1711722981189" ------=_Part_20_478593708.1711722981189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Request/response tracking functionality allows to save internal = communication between routes or communication with external systems into da= tabase.
Functionality is disabled by default - see ohf.requestSaving.enable&= nbsp;parameter to enable it. There is another parameter ohf.requestSaving.endpointFilter = em>that defines pattern for filtering endpoints URI which requests/res= ponse should be saved. See configuration for more det= ails.
Look at data model for more details about request an= d response tables.
Implementation is in core module, package org.openhubframework.openhub.core.reqres= .
Default implementation uses stan= dard Camel events that has one possible disadvantage - it's necessary to jo= in request and response= together (=3D two Camel events) and if exchange is changed from sending re= quest until response receive (e.g. using wireTap) then it's not possi= ble to join it. But this limitation is mainly for internal communication, t= here is no problem with saving request/response to/from external system.
Due to current Camel event emmit= ting implementation, it is not possible to save only responses, always a re= quest tracking must be enabled as well.
Requests/responses are saved int= o database, RequestResponseService defines contract. <= em>RequestResponseServiceDefaultImpl is default implementation that sa= ves them directly to DB in synchronous manner.