9.23 ENDPOINT Overrides
This topic describes the endpoint overrides.
To enhance the endpoint override extensibility, we've added a new column, CCA_NAME, to the PRODUCT_SERVICE_EXT_LEDGER table.
This column provides an extensibility for overriding the existing endpoint behaviour for specific UI components.
How to configure:
- Determine the component for which you want to override the endpoint.
- Enter the component's name in the CCA_NAME column of the PRODUCT_SERVICE_EXT_LEDGER table.
- PRODUCT_NAME & ENDPOINT_KEY must be same as endpoint we are extending.
- The ENDPOINT_VALUE field should be populated with the new endpoint URI, while the SERVICE_NAME field should specify the corresponding service to which this endpoint belongs.
- An entry of extension service should also be present in PRODUCT_SERVICE_CTX_LEDGER to pick up the new APPID or other properties.
- If CCA_NAME column contains NULL value, then endpoint override will be applicable across all components subscribed to respective ENDPOINT_KEY.
How it works:
When a request is made for the component, the ext orchestrator service will now consult the CCA_NAME column. If a matching entry exists, the endpoint specified in the ext orchestrator service (PRODUCT_SERVICE_EXT_LEDGER) will take precedence over the existing endpoint of base product.
This new approach offers several advantages:
- Any endpoint can be extended using this approach.
- The PRODUCT_SERVICE_EXT_LEDGER table is independent of product-related flyway updates, ensuring that future changes won't impact existing overrides.
- This extensibility allows for specific endpoint overrides, other components are unaffected with their original endpoints.
Parent topic: Extensibility Use Cases for OBX