Skip to content

service, vendor.SAP: add response_hook for pre-handler response inspection#305

Open
phanak-sap wants to merge 1 commit into
masterfrom
alternative154
Open

service, vendor.SAP: add response_hook for pre-handler response inspection#305
phanak-sap wants to merge 1 commit into
masterfrom
alternative154

Conversation

@phanak-sap

Copy link
Copy Markdown
Contributor
  • Add an optional response_hook=None parameter to Service and Client

    response_hook fires inside _call_handler() before the domain handler runs, covering both execute() and async_execute(). The hook is a stateless Callable[[response], None]; raising from it propagates to the caller and suppresses the domain result. No HTTP networking objects cross the OData API boundary.

  • Add sap_header_error_hook() to pyodata.vendor.SAP

    reads the sap-message response header and raises BusinessGatewayError when severity is "error".

  • Update tests and documentation accordingly

@phanak-sap phanak-sap added the enhancement New feature or request label Jun 20, 2026
@phanak-sap phanak-sap force-pushed the alternative154 branch 3 times, most recently from 4d5ea9f to 50c425f Compare June 20, 2026 13:11
…ction

- Add an optional response_hook=None parameter to Service and Client

  response_hook fires inside _call_handler() before the domain handler runs,
  covering both execute() and async_execute(). The hook is a stateless
  Callable[[response], None]; raising from it propagates to the caller
  and suppresses the domain result. No HTTP networking objects cross the OData
  API boundary.

- Add sap_header_error_hook() to pyodata.vendor.SAP

  reads the sap-message response header and raises BusinessGatewayError when
  severity is "error".

- Update tests and documentation accordingly
@phanak-sap

phanak-sap commented Jun 20, 2026

Copy link
Copy Markdown
Contributor Author

Left as open question for reviewers:

  • does that cover the original use case that was workerounded elsewhere? Is it usable together with sapcli or anything else
  • is 1 hook only OK or bad and should it be instead be list of hooks with possibility to register multiple different stateless response hooks? The logic chaining can always be solved IMHO outside of pyodata and provide one hook only for enforced simplicity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant