Introduction Of Idempotency Support Into BRM REST API Framework (Doc ID 2690210.1)

Last updated on APRIL 17, 2023

Applies to:

Goal

Introduction of idempotency support into Oracle Communications Billing and Revenue Management (BRM) Representational State Transfer (REST) Application Programming Interface (API) framework introduced in BRM 12.0.0 Version.

Enhancement Request:

In order to successfully integrate with modern micro service architectures and cloud based services, there is a general requirement and expectation that the APIs being called support Idempotency.

For example, many AWS services do not guarantee "once only" delivery of a message hence it is entirely possible that the Purchase Bundle REST API could be inadvertently called twice resulting in incorrect billing.

Another scenario is where the API call is submitted to BRM, but network issue or timeout occurs and the response is not received. However, the processing completes in BRM Connection Manager (CM) successfully. The upstream system should be able to resubmit the request without fear of creating a duplicate transaction in BRM.

It is expected a repeated request would simply complete successfully, without doing anything, returning success or a variant of success. This behavior allows for simplified operations and the building of robust retry and error handling outside of BRM.

Currently, this idempotency is achieved by the customer today through the use of a Unique Order ID (UUID). In the REST API Framework, they would want to pass this in as part of the Hypertext Transfer Protocol (HTTP) Header. The check must be done at CM layer for the best accuracy. All PUT/POST transactions should support this capability.
 
Currently BRM REST API framework does not support idempotent.

Use additional HTTP header with a UUID that the BRM opcodes use to test for duplicate transaction. This implies BRM needs to persist the UUID

Business Benefit:

This behavior is considered highly desirable for well designed/architected REST services. Modern Micro service architectures typically expect this behavior. It allows for easier integration and reduces billing errors.

This greatly reduces the possibility of Billing errors resulting in revenue loss or customer disputes. It Significantly make their integration via micro services more robust and supportable for Operations. Also this eeduce cost of integration and avoid trying to hack workarounds or customising all opcodes.
 

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.