Updating documentation to reference the HELM chart

This service is an **OSL controller** which acts as a **CAPIF 3GPP API Invoker Management layer**. In a nutshell it:

- Registers and manages multiple CAPIF invokers each one registered as Resource Specification in OSL Resource Specification catalog under category invoker.capif.osl.etsi.org.

- Talks to a CAPIF Core component (e.g. https://capifcore.org:443)

- Registers and manages multiple CAPIF invokers, each one registered as a Resource Specification in the OSL Resource Specification catalog under the category invoker.capif.osl.etsi.org.

- Comminicates with a CAPIF Core component (e.g. https://capifcore.org:443)

- Uses ActiveMQ for internal messaging (e.g., TMF catalog operations, orchestration invocations, etc)

- Can automatically onboard Invokers, and manage certificates (via public/private keys)

-   This allows external configuration of multiple API Invokers.

Currently application.yaml onboards two example invokers with self-signed certificates. In general the 

Currently application.yaml onboards two example invokers with self-signed certificates. In general the `capif:` section in `application.yaml` configures the Spring Boot application  to:

    capif:

 section in `application.yaml` configures the Spring Boot application  to:

- Register as an API Invoker with a CAPIF Core

- Use secure credentials (optional keys)

- Periodically refresh tokens

- Discover available APIs

- Define which invokers to onboard

> The configurable `application.yaml` properties are also exposed through the [respective HELM Chart](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.capif.invoker/-/tree/main/helm?ref_type=heads).

----------

## 📤 **Using the OSL CAPIF invoker service**

From the above example configuration, we will get registered in our OSL Resource Specification catalog two invokers: exampleInvoker and exampleInvoker2.

You may deploy the OSL CAPIF service:

- Locally (intended for development): Following the above example configuration

- via HELM (intended for deployment): Downloading the [HELM chart](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.capif.invoker/-/tree/main/helm?ref_type=heads), editing the `values.yaml` in a similar manner, and installing the chart

Regardless the intention, the deployment will register two invokers, i.e., exampleInvoker and exampleInvoker2, as OSL Resource Specifications.

Use them as Resource Specification(s) assigned in a Resource Facing Service. 

You may utilize them as Resource Specification(s) assigned in a Resource Facing Service to design and order CAPIF-enabled services. 

### 📦 **Resource Specification Characteristics**

-   Value types are all **TEXT**.

The above Resource Specification Characteristics will be also exposed as Service Specification Characteristics.

The above Resource Specification Characteristics will also be exposed as Service Specification Characteristics when you relate the Invoker Resource Specification with a Service Specification.

Then you can insert this  Resource Facing Service Specification as a related Service Specification in a Customer Facing Service Specification. 

To properly expose the designed Service Specification, you may need the to relate the created Resource Facing Service Specification with a Customer Facing Service Specification. 

Here is an example rule that will get the latest Bearer and perform an API invocation (POST in this example) to an API provider register in the CAPIF server.

Following, there is an example rule that will get the latest Bearer and perform an API invocation (POST in this example) to an API provider register in the CAPIF server.

![enter image description here](lcm_rule.jpg)