Previous Next JavaScript must be enabled to correctly display this content

## 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:

1. Determine the component for which user want to override the endpoint.
2. Enter the component's name in the CCA_NAME column of the PRODUCT_SERVICE_EXT_LEDGER table.
3. PRODUCT_NAME & ENDPOINT_KEY must be same as endpoint we are extending.
4. 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.
5. An entry of extension service should also be present in PRODUCT_SERVICE_CTX_LEDGER to pick up the new APPID or other properties.
6. If CCA_NAME column contains NULL value, then endpoint override will be applicable across all components subscribed to respective ENDPOINT_KEY.

   Figure 9-36 Endpoint 1

   Description of "Figure 9-36 Endpoint 1"

   Figure 9-37 Endpoint 2

   Description of "Figure 9-37 Endpoint 2"

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