OData Error Target Messaging for Partial Processing Failures

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

OData protocol does not provide a mechanism for an OData service to inform an HTTP-based application about partial request processing failures, where some parts of the request are successfully processed while others are not, without indicating the specific errors.

Innovation Solution

Introducing a new type of HTTP response message that includes an HTTP response header specifying the target field with an error and a human-readable error message, allowing the application to display additional information to the user.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If OData service processes requests with partial failures, then request processing capability is improved, but error information delivery is worsened

Engineering Contradiction:
Improverequest processing capabilityVSAvoiderror information delivery
Core Design Contradiction:
ProductivityVSLoss of information

Solution Approach 1:

The patent segments the error information delivery by introducing a separate `errorTargets` collection in the OData response. This allows the successful request processing to be maintained while error details are delivered through a dedicated structure that identifies specific target entities and their associated errors, resolving the contradiction between processing capability and error information delivery.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements feedback mechanisms by providing detailed error information back to the client application through the `errorTargets` collection. Each error target includes identifiers and error messages that feed back to the application, enabling it to present meaningful error information to users while maintaining the ability to process requests with partial failures.

Inventive Principle:
Principle #23Feedback

2Ease of operation

If OData service provides detailed error information, then user experience is improved, but response message complexity is worsened

Engineering Contradiction:
Improveuser experienceVSAvoidresponse message complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent segments error information into a dedicated `errorTargets` collection within the response message. This structured approach organizes detailed error information (including target entity identifiers and error messages) in a predictable format, improving user experience while keeping the response structure manageable and not excessively complex.

Inventive Principle:
Principle #1Segmentation

3Difficulty of detecting and measuring

If OData protocol is extended with error target messaging, then error identification capability is improved, but protocol complexity is worsened

Engineering Contradiction:
Improveerror identification capabilityVSAvoidprotocol complexity
Core Design Contradiction:
Difficulty of detecting and measuringVSDevice complexity

Solution Approach 1:

The patent extends the OData protocol with a universal `errorTargets` collection structure that can be applied across different service scenarios. This multi-functional error messaging mechanism provides consistent error identification capability while adding minimal protocol complexity by building upon existing OData response structures.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS11860715B2Messaging for OData error targets
Publication Date: 2024.01.02 SAP SE
  • US11860715B2 patent drawing
  • US11860715B2 patent drawing
  • US11860715B2 patent drawing

AI summary

Provided are systems and methods which provide an OData messaging protocol for HTTP messages that are processed successfully but with some errors. In one example, the method may include transmitting a HTTP request to an OData service, the HTTP request comprising identifiers of one or more input fields and one or more values for the one or more input fields, receiving, from the OData service, an HTTP response indicating that the HTTP request was processed successfully with one or more errors, identifying an input field which is a target of the error and a reason for the error from a field in the HTTP response indicating that the HTTP request was processed successfully with one or more errors, and rendering, via the application, a visual identifier of the error in association with a display of the input field on the user interface.