See also: JIRA link:

How to use the NONRTRIC Information Coordination Service (ICS)

The Basics

What is it (Data management and exposure) Service that manages data subscriptions. It separates data consumers from data producers (for different vendor). Data consumer doesn't need to be aware of where the data source.
Where is it: https://github.com/o-ran-sc/nonrtric-plt-informationcoordinatorservice mirror of https://gerrit.o-ran-sc.org/r/nonrtric/plt/informationcoordinatorservice
Historical names: Information Coordinator Service (ICS), Enrichment Information Coordinator.

Terminology:

• Information Type: Represents the types of data that can be produced by data producers and consumed by data consumers.

• Information Job: Represents an active data subscription by a data consumer, specifying the type of data to be produced and additional parameters for filtering.

• Data Consumer: Represents entities that consume data and manage data subscription jobs.

• Data Producer: Represents entities that produce data.

API offered in ICS:

• Data producer API: 

  • Information Type and Information Producer 

    • Producer CALLBACKS: GET healthcheck (supervision); Information Job Creation/Modification/Delete.

• Data consumer API:

  • Information Type Subscription Creation/Modification/Delete (REGISTERED/UNREGISTERED); Information Job (Creation/Modification/Delete) and GET Information Type 

    • Consumer CALLBACKS: POST Information Type Status: REGISTERED/UNREGISTERED invoked when a Information type status has been changed

• Service status API:

  • Returns statistics such as Number of Producers Types and Jobs

ICS Docker Image:

1. Building the docker image from source and run it on port 8083 http

...

2. Import the swagger.json in Postman (informationcoordinatorservice/api/ics-api.json) as an OpenAPI3.0
3. Replace the baseUrl with http://localhost:8083 (in the Data management and exposure variables), and change accordingly {{infoTypeId}} from :infoTypeId
Other variables will be :{{infoJobId }}/{{infoProducerId}}/{{infoTypeId}}/{{subscriptionId}} etc

ICS flow:

a) Create a type (PUT /info-types)
b) Create a producer (PUT /info-producers) {supports type for filtering}
c) Create a job (PUT /info-jobs) {consumer subscription}

...

{ "info_job_data_schema": { "topicName": "example_topic", "key": "example_key", "message": "example_message" }, "info_type_information": {} }

Onboarding a producer in ICS:

PUT {{baseUrl}}/data-producer/v1/info-producers/{{infoProducerId}}
Body:

...

In summary, both URLs facilitate communication between the service and external producers, enabling actions like starting and stopping jobs, as well as monitoring the health and status of the producers.

Giving the consumer a job definition:

PUT {{baseUrl}}/data-consumer/v1/info-jobs/{{infoJobId}}
Body:

...

1. Authorization check: POST to the Authentication Agent (from the starting config config/application.yaml )
2. Validation: The URLs are used only for URI validation
3. Consumer starts a job on the Producer POST producerCallbacks.startInfoSubscriptionJob->restClient.post(producer.getJobCallbackUrl(), jobCallbackBody(infoJob))  

ICS Callbacks Flow