{"id":2052,"date":"2024-10-22T14:30:31","date_gmt":"2024-10-22T13:30:31","guid":{"rendered":"https:\/\/thomas-kopton.de\/vblog\/?p=2052"},"modified":"2024-10-22T16:18:50","modified_gmt":"2024-10-22T15:18:50","slug":"vmware-aria-operations-integration-sdk-part-2-demo-project","status":"publish","type":"post","link":"https:\/\/thomas-kopton.de\/vblog\/?p=2052","title":{"rendered":"VMware Aria Operations Integration SDK – Part 2 – Demo Project"},"content":{"rendered":"\n

In the first post<\/a> on the topic of VMware Operations Integration SDK<\/strong>, I showed how I prepared my development environment and how a demo project is created using the triad of mp-init<\/code>, mp-test<\/code>, and mp-build<\/code>.<\/p>\n\n\n\n

In this post, we’ll take a closer look at which files a simple, REST API-based project<\/strong> consists of, as well as how the structure of the actual app (Python code) looks like.
Using the example of my SmartHome central unit, I will show how the demo code needs to be adapted to build a simple, functional, and expandable Management Pack.<\/p>\n\n\n\n

Project Initialization<\/h5>\n\n\n\n

As already shown in the first part, a project begins with us calling mp-init<\/code> and thereby creating the project structure. Of course, we enter appropriate values for names, description, etc. After all, it should become a proper Management Pack.<\/p>\n\n\n\n

\"\"<\/a>
Figure 01: mp-init SDK command.<\/em><\/figcaption><\/figure>\n\n\n\n

At this point, we have created our project structure, and we’ll now quickly take a look at it. The next screenshot shows the folder and files two levels down of the project folder creates by mp-init<\/code>.<\/p>\n\n\n\n

\"\"<\/a>
Figure 02: Folder structure and files after new project initialization.<\/em><\/figcaption><\/figure>\n\n\n\n

The files outlined in red<\/mark> are the ones we will need to modify during the development of the Management Pack. It’s obvious that we will be working with the Python files, but the adapter_requirements.txt<\/code> will also be adjusted so that we get all the necessary libraries for our own code included. The connections.json<\/code> contains all the data needed for the development environment to actually communicate with a real endpoint when mp-test<\/code> is called, in this case with my SmartHome central unit.<\/p>\n\n\n\n

Adapter Logic<\/h5>\n\n\n\n

Broadly speaking, and this is indeed sufficient for a basic framework, we can summarize the necessary work steps in three points:<\/p>\n\n\n\n

    \n
  1. Modify the adapter definition<\/strong> to add fields for connecting to the SmartHome endpoint.<\/li>\n\n\n\n
  2. Modify the test method <\/strong>to create a SmartHome connection and run a test query.<\/li>\n\n\n\n
  3. Modify the collect method<\/strong> to collect objects, metrics, properties, and relationships.<\/li>\n<\/ol>\n\n\n\n
    Adapter Definition<\/h6>\n\n\n\n

    The adapter definition, typically implemented in the get_adapter_definition()<\/code> method, which is later on reflected in conf\/describe.xml<\/code> file of the Management Pack, serves several crucial purposes, like:<\/p>\n\n\n\n