05. Error handling and operation

Check answers in three steps

1. Check HTTP status and content type. An HTML login page is not a successful API response.
2. For APIEntityResponse, also check success, data and errorMessages.
3. Check the technical result: correct customer, correct company, quantities, prices and, if necessary, the document generated.

Error and reaction

• 400: Correct mandatory fields, types, JSON and parameter positions. No unchanged repetition.
• 401 or redirect to login: Check cookie and expiration; Register again in a controlled manner. Do not resend write requests afterwards without checking them.
• 403: Check the WebApi permission mentioned in the message. No repeat loop.
• 404: Object or technical meeting does not exist or has expired; Verify identity and IDs.
• 422: Correct technical requirements, for example an empty shopping cart.
• 429: Note rate limitation, evaluate retry-after if necessary; In particular, do not repeat the login aggressively.
• 5xx, connection lost or timeout: The outcome may be unclear. For write accesses, first determine the actual status.
• 200 with success=false: Technical error despite successful HTTP transfer.

Repeats and orders

After temporary errors, reading calls can be repeated to a limited extent with increasing intervals. Define upper limits and log the last error.

AddToCart can increase quantities; WebshopPlaceOrder generates receipts. No idempotence key is documented for these actions in this contract. Having your own process identifier alone does not prevent duplicate execution on the ERP server. If the result is unclear, a comparison or manual clarification must be carried out.

The checked order code works in several steps. The documentation does not indicate a guaranteed atomic withdrawal of all steps. Check partial errors with the operator in the test environment and define a restart process.

Logging

Log time, own task ID, method, route, status, duration, and a sanitized error description. Do not log passwords, cookies, token hashes, or unfiltered customer/address data. Link unclear business processes to the support case in a comprehensible manner.

Acceptance before productive start

• Test login, session flow, missing rights and separate companies.
• Deny access to unauthorized business partners.
• Compare catalog prices and availability with X-ERP.
• Add, change and remove shopping cart; check invalid quantities.
• Create an order in the test company and check the assignment, streets, countries, positions and totals in the document.
• Deal with lost connections and unclear order status without blind repetition.
• Check the result of the helpdesk update and possible notifications if this write access is enabled.
• Document responsible persons, alerting and server/contract version.

This list describes necessary project reviews. It does not claim that these tests have already been performed for your environment.