Skip to content

1. Appendix: Conversion from the xApp Framework to the xApp Library

Due to the kind of big changes between the different versions of the xApp Framework/Library, this appendix handles how to convert between them.

1.1 xApp Configuration

The xApp Configuration has undergone a big change from the previous version of the xApp framework. The xApp Configuration was generated by the xApp helm Chart, by generating the xapp-configuration.json. In the new xApp Framework, the developer is in charge of creating the xapp_metadata.json file, which contains metadata and configuration options, including their default values. Only when you need to change the configuration from their default values, you can use the xApp helm Chart values.yaml to do so. This is explained in the following subsection.

The developer needs to copy all the configuration options that were defined in the xApp Helm Chart values.yaml under the xappConfig key, to the xapp_metadata.json, keeping in mind the xapp_metadata.json format, which can be seen in the xApp Metadata section.

The xapp_endpoints.json configuration file is generated by the xApp Helm Chart. Its content can bee seen under the xappEndpoints key in the xApp Helm Chart values.yaml. These are the normal dRAX RIC endpoints required for the xApp Framework to work properly. In case you need to add other endpoints, you can check the xApp Endpoints section.

1.2 xApp Helm Chart

We recommend that you pick up the new xApp Helm Chart from the xApp Framework repository, in the example folder. Then, edit the values.yaml file as follows.

  1. The image key: As with the previous version, edit the image key to point to your own xApp Core Docker image, including the repository and tag fields under image. There is no particular change here, but we note it as a general change required.
  2. The xappConfig key: You will notice a change in the way we define the xApp Configuration options. First of all, part of the previous configuration options are moved to the xapp_endpoints.json, explained earlier. The rest of the configuration options are moved to xapp_metadata.json. The xapp_metadata.json also holds the default values of the xApp Configuration options. The new xappConfig key in the values.yaml is to change those config options on deployment time only if needed. Hence, by default the xappConfig is set as an empty list. If you need to change the default values, not that the xappConfig is now a list instead of a dictionary. For example, what was previously:
xappConfig:
  - name: 'LOG_LEVEL'
     type: int
     value: 20

Is now:

xappConfig:
  LOG_LEVEL: 20

1.3 Main code

In previous versions, the xApp Framework required the developer to modify the run function inside the processor.py file:

def run(settings, in_queue, out_queue, data_store):
    while True:
        msg = in_queue.get()
        data  = msg['data']
        topic = msg['topic']
        # handle data

In the xApp library this can be rewritten as

If __name__ == "__main__":
    builder = xapp_lib.XAppBuilder("..", absolute=False)
    builder.metadata("core/xapp_metadata.json")
    builder.endpoints("config/xapp_endpoints.json")
    builder.config("config/xapp_config.json")
    builder.readme("README.md")
    builder.restapi(
        [
            ("/api/", restapi.MainApiHandler),
            ("/api/actions", restapi.ActionsHandler),
            ("/api/request", restapi.RequestHandler),
        ]
    )
    xapp = builder.build()

    while True:
        (topic, data) = xapp.kafka().json().recv_message()
        # handle data

1.4 Actions

Most of the functionality from action_taker has been moved to actions, and requires an xapp.nats() as first argument instead of a queue:

actions.handover_command(xapp.nats(), handover_cells)

The structure of the other arguments hasn’t changed.

1.5 xApp API

The xApp API has a small change. You can check the restapi.py example file in the xApp Framework _example _folder. As you can see, we now pass the xapp parameter for access to the xapp class. We also now don’t start the Tornado API in the restapi.py file. We explain how custom xApp API can be added in the Adding an endpoint behind the /api section.

As can be seen, the xApp API is created now with the xApp Builder:

builder.restapi([
  ("/api/", MainApiHandler),
  ("/api/actions", ActionsHandler),
  ("/api/request", RequestHandler),
])

Hence the previous xApp API endpoints you have to define in the xApp Buidler.

Next, in the restapi.py, you can change the in_queue parameter to the xapp parameter, as seen in the restapi.py example. Then, when sending a message from the xApp API to the main xApp, we used to do:

self.in_queue.put("Message from restapi main handler")

Which is now:

self.xapp.insert_message("Message from restapi main handler")