Search Knowledge Base by Keyword
Lenovo XCLarity
Overview
Lenovo XClarity Administrator is Lenovo’s centralised hardware management appliance. It runs as a virtual appliance inside the data centre and takes ownership of Lenovo ThinkSystem and ThinkAgile servers, Flex System chassis and the components mounted in them. Once an endpoint is managed, XClarity keeps a live inventory of it: machine type and model, serial number, firmware levels, health and power state, and the rack, chassis and bay it physically occupies. It also holds the firmware compliance policies and the configuration patterns used to drive settings onto the hardware.
The ReadyWorks connector talks to the XClarity Administrator REST API. It offers one authentication method, HTTP Basic with a username and password, sent against the API Domain you supply. Every shipped job is a plain GET against a single XClarity inventory resource (/nodes, /chassis, /switches and so on), and the JSON that comes back is written to a staging table named with an lxca_ prefix. There is no token exchange and no session to maintain, so each job authenticates and reads in one pass.
In a ReadyWorks context this supplies the physical layer beneath everything virtual. Node, chassis and switch inventory gives you serial numbers and warranty identifiers for refresh and decommission planning, the compliance jobs tell you which managed devices are running firmware below their assigned policy, and the cabinet view places each device in a rack so a data centre move or a rack power event can be scoped to the workloads it touches. Joined to a hypervisor connector, it lets you trace a virtual machine down to the Lenovo node and chassis carrying it.
The connector is declared bidirectional and the outbound job form is enabled, but no outbound templates ship with it. As delivered it is an inbound feed. Sending anything back to XClarity means authoring an outbound job yourself.
NOTE: All 18 inbound templates ship with Enabled set to No. Nothing runs until you review each job and turn on the ones you want.
Connector Properties
| Property | Value |
|---|---|
| Identifier | LENOVO XCLARITY |
| Name | Lenovo XClarity |
| Description | Connector for processing Lenovo XClarity data. |
| Job Types | Both Inbound and Outbound |
| Order | 90 |
| Enabled | Yes |
| Locked | Yes |
| Block Update | No |
| Single Authentication | No |
| Windows Only | No |
| Connector Version | 2025-11-18 |
| Hooks | None |
| Additional Job Fields | None |
| Image | ![]() |
Authentication Methods
The connector offers a single authentication method. XClarity Administrator accepts HTTP Basic credentials directly on its REST API, so no separate token call is needed.
| Method | Identifier | Base Method | Script | Order | Enabled | Config Fields |
|---|---|---|---|---|---|---|
| Basic Authorization: Username / Password | LENOVO XCLARITY_e5d63e15ae |
JSON Rest API_user |
json_rest_api.php |
70 | Yes | 5 |
NOTE: Both the authentication call and the data calls run with certificate verification disabled (SSL_VERIFYHOST and SSL_VERIFYPEER are off). XClarity appliances are normally deployed with a self-signed certificate, so this is what makes the connection work out of the box. If you have replaced the appliance certificate with one issued by a trusted CA, the connector still will not validate it.
Method 1: Basic Authorization: Username / Password (LENOVO XCLARITY_e5d63e15ae)
Connect to a GET method API with a username / password
Sends an Authorization: Basic header built from the username and password saved on the connection, Base64 encoded at run time. Use a dedicated XClarity user account with a read-only or supervisor-equivalent role that has visibility of every managed endpoint, since the inventory jobs return only what that account is authorised to see. The same header is used on every call, so there is no session to expire mid-run.
Connection Configuration Fields (5)
| Order | Label | Type | Required | Default | Max Len | Tooltip |
|---|---|---|---|---|---|---|
| 10 | API Domain | text | Yes | 255 | Enter API domain of the Connection | |
| 30 | Server Temporary Working Path | text | Yes | storage/etl5 |
255 | Enter path where temporary files are stored during data processing (exclude starting and ending backslash) |
| 40 | Username | text | Yes | 1024 | Enter username of the Connection | |
| 50 | Password | password | Yes | 64000 | Enter password of the Connection | |
| 250 | Additional Job Fields | fields_list | No | Enter list of additional fields to add to staging data for all jobs |
Authentication Configuration
Headers sent on the authentication call:
| Header | Value | Base64 |
|---|---|---|
Content-Type: |
application/json |
Off |
Authorization: Basic |
%user_name%:%user_pass% |
On |
cURL options:
| Option | Authentication Call | Data Calls |
|---|---|---|
USERAGENT |
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 |
Same |
SSL_VERIFYHOST |
false |
Same |
SSL_VERIFYPEER |
false |
Same |
RETURNTRANSFER |
true |
Same |
FOLLOWLOCATION |
true |
Same |
FAILONERROR |
true |
Same |
Inbound Job Fields Enabled (44)
The inbound job form exposes the standard REST job fields: endpoint, return data node, pagination, three levels of enumeration, and the staging table the response lands in.
| Order | Label | Type | Required | Default | Tooltip |
|---|---|---|---|---|---|
| 10 | Job Description | text | Yes | Enter description of the Job | |
| 20 | Job Schedule | lookup | Yes | Daily | Select frequency Job should run |
| 30 | Enabled | radio | Yes | Yes | Choose if Job is enabled |
| 40 | Use Unparsed Data | radio | No | No | Choose if you wish to parse the incoming data, or leave it in its raw format |
| 50 | Log Raw API Calls | radio | Yes | No | Choose if raw API calls are logged |
| 70 | Destination Table | text | Yes | Enter name of the destination table | |
| 80 | Data Identity | text | No | Enter identity of the Job | |
| 120 | Append New Data to Existing Tables | radio | No | No | Choose if new data will append to the existing destination table, or will create a new destination table |
| 130 | Fields to Index | text | No | Enter fields to index | |
| 170 | Method Type | select | Yes | GET |
Select method type of the Job |
| 190 | API End Point | text | No | Enter API end point of the Job | |
| 200 | API Data Parameters | fields_list | No | Enter API data parameters of the Job | |
| 210 | Body Data Sending Method | select | Yes | JSON Encoded Data | Select method for sending the body data |
| 220 | Raw JSON Body Data | textarea | No | Enter the raw JSON body to send. Do not use body selections in the API Parameters if this is used. | |
| 230 | API Return Data Node | text | No | Enter API return data node of the Job | |
| 250 | Pagination Type | select | No | None | Select request paging type of the Job |
| 270 | API Pagination Node | text | No | Enter API pagination node of the Job | |
| 280 | Pagination Offset Start | text | No | Enter request paging offset start of the Job | |
| 290 | Pagination Limit | text | No | Enter request pagination limit of the Job | |
| 300 | Pagination Termination Node | text | No | Enter request paging termination node and value of the Job | |
| 310 | Maximum API Calls | text | No | Enter maximum number of API calls for the Job to make | |
| 320 | Enumeration 1 Type | select | No | None | Enter enumeration level 1 type |
| 330 | Enumeration 1 ETL Job | lookup | No | Select ETL job for the enumeration values | |
| 340 | Enumeration 1 Data Type | data_type | No | Select the data type and fields for enumeration 1 values | |
| 350 | Enumeration 1 Keys End Point | text | No | Enter enumeration 1 keys end point of the Job | |
| 360 | Enumeration 1 Node | text | No | Enter enumeration 1 node of the Job | |
| 370 | Enumeration 1 Fields | fields_list | No | Enter enumeration 1 fields of the Job | |
| 380 | Enumeration 2 Type | select | No | None | Enter enumeration level 2 type |
| 390 | Enumeration 2 ETL Job | lookup | No | Select ETL job for the enumeration 2 values | |
| 400 | Enumeration 2 Data Type | data_type | No | Select the data type and fields for enumeration 2 values | |
| 410 | Enumeration 2 Keys End Point | text | No | Enter enumeration 2 keys end point of the Job | |
| 420 | Enumeration 2 Node | text | No | Enter enumeration 2 node of the Job | |
| 430 | Enumeration 2 Fields | fields_list | No | Enter enumeration 2 fields of the Job | |
| 440 | Enumeration 3 Type | select | No | None | Enter enumeration level 3 type |
| 450 | Enumeration 3 ETL Job | lookup | No | Select ETL job for the enumeration 3 values | |
| 460 | Enumeration 3 Data Type | data_type | No | Select the data type and fields for enumeration 3 values | |
| 470 | Enumeration 3 Keys End Point | text | No | Enter enumeration 3 keys end point of the Job | |
| 480 | Enumeration 3 Node | text | No | Enter enumeration 3 node of the Job | |
| 490 | Enumeration 3 Fields | fields_list | No | Enter enumeration 3 fields of the Job | |
| 500 | Pause Enumeration | text | No | Enter values for pausing enumeration every X calls for Y seconds | |
| 510 | Kill Enumeration on Error | radio | No | No | Choose to stop the enumeration loop on an error or continue processing the loop |
| 520 | Additional Fields | fields_list | No | Enter list of additional fields to add to staging data | |
| 550 | Retry Pause | text | No | Enter values for retrying a failed API connection. Retry X times, waiting Y seconds between each try, with an API timeout of Z seconds. | |
| 560 | Order | text | Yes | Enter order of the Job |
Outbound Job Fields Enabled (13)
| Order | Label | Type | Required | Default | Tooltip |
|---|---|---|---|---|---|
| 10 | Job Description | text | Yes | Enter description of the Job | |
| 30 | Enabled | radio | Yes | Yes | Choose if Job is enabled |
| 50 | Log Raw API Calls | radio | Yes | No | Choose if raw API calls are logged |
| 170 | Method Type | select | Yes | GET |
Select method type of the Job |
| 180 | Data Sending Method | select | Yes | JSON Encoded Data | Select method for sending the outbound data |
| 190 | API End Point | text | No | Enter API end point of the Job | |
| 200 | API Data Parameters | fields_list | No | Enter API data parameters of the Job | |
| 210 | Body Data Sending Method | select | Yes | JSON Encoded Data | Select method for sending the body data |
| 260 | Return Data Fields List | fields_list | Yes | Enter return data fields of the Job | |
| 530 | Outbound Fields List | fields_list | Yes | Enter outbound fields of the Job | |
| 540 | Ignore Empty Outbound Fields | radio | No | Yes | Ignore, and do not include, any outbound fields that are empty and have no data |
| 550 | Raw JSON Outbound Template | textarea | No | Enter the raw JSON outbound template to send. This will replace any automated structures defined in the outbound fields. | |
| 560 | Order | text | Yes | Enter order of the Job |
Inbound Job Templates (18)
Eighteen inbound templates ship, one per XClarity Administrator inventory resource plus a blank scaffold. All of them are GET calls on a Daily schedule, and all of them ship disabled. None sets a return data node, so the whole JSON document is parsed and the top-level collection becomes the rows of the destination table.
| # | Job Description | Destination Table | API End Point | Enabled | What It Pulls |
|---|---|---|---|---|---|
| 1 | Cabinet | lxca_cabinet |
/cabinet/view |
No | The rack and cabinet layout XClarity holds: each defined cabinet, its height in rack units, and the chassis, rack-mounted servers and switches placed in it with their unit positions. This is what gives a device a physical location rather than just an identity. |
| 2 | Canisters | lxca_canisters |
/canisters |
No | The canister modules installed in managed storage enclosures, with slot position, part and serial number, firmware level and operational state. |
| 3 | Chassis | lxca_chassis |
/chassis |
No | Flex System chassis inventory: chassis model, serial number, management IP, overall health, and the bay map showing which node, switch or power module occupies each slot. |
| 4 | CMMs | lxca_cmms |
/cmms |
No | The Chassis Management Modules that manage each Flex System chassis, with firmware level, network address, and whether the module is acting as primary or standby. |
| 5 | Compliance Policies | lxca_compl_pol |
/compliancePolicies |
No | The firmware compliance policies defined in XClarity: the policy name, the device types it applies to, and the firmware levels it pins each component to. |
| 6 | Compliance Policies Applicable Firmware | lxca_compl_pol_appl_fw |
/compliancePolicies/applicableFirmware |
No | The firmware packages currently available in the XClarity repository that can be selected into a policy, listed per device type. Use it to see what a device could be moved to, as opposed to what it is on now. |
| 7 | Compliance Policies Compare Results | lxca_compl_pol_cmp_res |
/compliancePolicies/compareResult |
No | A device-by-device comparison of installed firmware against the policy assigned to that device, showing the compliance verdict and the component levels behind it. |
| 8 | Compliance Policies Persisted Result | lxca_compl_pol_pers_res |
/compliancePolicies/persistedResult |
No | The stored result of the last compliance evaluation per device. It returns the same shape of verdict as the compare job without forcing XClarity to recompute, which makes it the cheaper of the two to run on a schedule. |
| 9 | Fans | lxca_fans |
/fans |
No | Cooling fan modules across managed chassis and servers, with slot, part and serial number, speed and health state. |
| 10 | Fan Muxes | lxca_fan_muxes |
/fanMuxes |
No | Fan mux modules, the logic and power distribution boards that drive the fan zones in a chassis, with slot, part number and state. |
| 11 | Nodes | lxca_nodes |
/nodes |
No | The core inventory job. Every server XClarity manages, with machine type and model, serial number, UUID, host name and management IP, processor and memory configuration, installed firmware levels, power and health state, and the chassis and bay the node sits in. |
| 12 | Patterns | lxca_patterns |
/patterns |
No | Server configuration patterns, the reusable templates XClarity uses to push UEFI, boot order, management controller and adapter settings onto hardware, including which pattern targets which device type. |
| 13 | Power Supplies | lxca_power_supplies |
/powerSupplies |
No | Power supply units across managed chassis and servers, with slot, part and serial number, wattage rating and operational state. |
| 14 | Profiles | lxca_profiles |
/profiles |
No | Server profiles, the instances of a configuration pattern that have been assigned to a specific node or bay, with the assignment state and the pattern each one derives from. This is how you tell what settings a given node is actually meant to be running. |
| 15 | Scalable Complexes | lxca_scalable_complex |
/scalableComplex |
No | Multi-node scalable systems, showing which physical nodes are joined into a single scalable complex and how they are partitioned. |
| 16 | Storage | lxca_storage |
/storage |
No | Managed storage enclosures and arrays, with model, serial number, controller detail and drive bay population. |
| 17 | Switches | lxca_switches |
/switches |
No | Managed network switches, both Flex System embedded switches and rack switches, with model, serial number, firmware level, management address and port inventory. |
| 18 | Rest GET API | api_data |
Not set |
No | A blank scaffold with no endpoint set, writing to a generic api_data table. Copy it when you need to pull an XClarity resource that has no shipped template of its own. |
Job Template Configuration
Settings Common to All Eighteen Templates
| Setting | Value |
|---|---|
| Order | 10 |
| Enabled | No |
| Job Schedule | Daily (15 1 * * *) |
| Allow Empty Table | Yes |
| Append Files to Same Destination Table | No |
| Append New Data to Existing Tables | No |
| Use Unparsed Data | No |
| Convert UUID-Keyed Objects to Rows | No |
| Ignore XML Attributes | No |
| Log Raw API Calls | No |
| Method Type | GET |
| Body Data Sending Method | JSON Encoded Data |
Settings That Vary by Template
| Template | ID | Destination Table | Data Identity | API End Point |
|---|---|---|---|---|
| Cabinet | 88 | lxca_cabinet |
/cabinet/view |
|
| Canisters | 89 | lxca_canisters |
/canisters |
|
| Chassis | 90 | lxca_chassis |
/chassis |
|
| CMMs | 91 | lxca_cmms |
/cmms |
|
| Compliance Policies | 92 | lxca_compl_pol |
/compliancePolicies |
|
| Compliance Policies Applicable Firmware | 93 | lxca_compl_pol_appl_fw |
/compliancePolicies/applicableFirmware |
|
| Compliance Policies Compare Results | 94 | lxca_compl_pol_cmp_res |
/compliancePolicies/compareResult |
|
| Compliance Policies Persisted Result | 95 | lxca_compl_pol_pers_res |
/compliancePolicies/persistedResult |
|
| Fans | 96 | lxca_fans |
/fans |
|
| Fan Muxes | 97 | lxca_fan_muxes |
/fanMuxes |
|
| Nodes | 98 | lxca_nodes |
/nodes |
|
| Patterns | 99 | lxca_patterns |
/patterns |
|
| Power Supplies | 100 | lxca_power_supplies |
/powerSupplies |
|
| Profiles | 101 | lxca_profiles |
/profiles |
|
| Scalable Complexes | 102 | lxca_scalable_complex |
/scalableComplex |
|
| Storage | 103 | lxca_storage |
/storage |
|
| Switches | 104 | lxca_switches |
/switches |
|
| Rest GET API | 105 | api_data |
api_data |
Not set |
NOTE: The compliance jobs overlap deliberately. Compliance Policies gives you the policy definitions, Compliance Policies Compare Results and Compliance Policies Persisted Result give you the per-device verdicts, and Compliance Policies Applicable Firmware gives you the upgrade targets. Enable the persisted-result job for routine reporting and reserve the compare job for on-demand checks.
Outbound Job Templates (0)
No outbound templates ship with this connector. The outbound job form is enabled, so you can author your own, but nothing is written back to XClarity by default.

