Introduction Of Idempotency Support Into BRM REST API Framework
(Doc ID 2690210.1)
Last updated on JULY 15, 2020
Applies to:Oracle Communications Billing and Revenue Management - Version 22.214.171.124.0 and later
Information in this document applies to any platform.
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.
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
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document