NetXMS Support Forum

В русском канале https://t.me/netxms_ru есть @me_is_nem0, он занимался драйверами для девайсов специфичных для РФ, попробуйте с ним пообщаться.

Даб там в логе Cannot compile report /var/lib/netxms/nxreportd/definitions/WAN-int-1.0.1/main.jrxml
 net.sf.jasperreports.engine.JRException: org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 232; cvc-complex-type.3.2.2: Attribute 'uuid' is not allowed to appear in element 'jasperReport'.

Так что да, директория создалась, но скомпилироваться он не смог и поэтому его и в списке нет.

Я забыл упомянть выше, что нужна версия Jasper Studio 6.20.5 или младше. Тут похоже что версия более новая.

Я в принципе у claude такие вещи спрашиваю, вот его ответ по этой ошбике:
The error is a JRXML schema validation failure: the bundled JasperReports library in nxreportd is validating against an XSD that does
   not allow uuid on the root <jasperReport> element. This usually means the JRXML was produced by a Jaspersoft Studio newer than the
  JR runtime on the reporting server.

  A couple of options to unblock the deploy:

  1. Quick fix — open main.jrxml and delete the uuid="..." attribute from the <jasperReport ...> root tag, then rebuild. If validation then
   complains about uuid on a nested element (e.g. <band>, <textField>), strip those too. A one-shot scrub:
  sed -i 's/ uuid="[^"]*"//g' src/main/resources/main.jrxml
  2. Real fix — design the report in a Jaspersoft Studio version aligned with the JR library shipped with this NetXMS server. The two
  sample JRXMLs in this repo are produced with Jaspersoft Studio 6.16/6.19 (JasperReports Library 6.x), and they're known to deploy.
  Anything noticeably newer (7.x / 9.x) will emit XML features the server's older XSD rejects.

  For context: the samples in this repo (users/src/main/resources/main.jrxml and user-input/src/main/resources/main.jrxml) do carry
  uuid on <jasperReport> and deploy fine, so the user's server is matched to a stricter/older XSD than the one the samples were
  validated against — confirming the version-mismatch diagnosis. Designing with Studio 6.16–6.19 is the safest path.

Same happens on Ubuntu 26, created issue: https://github.com/netxms/netxms/issues/3250

Are you running Qwen locally? Under what tool?

The "XML tool call" output is what Qwen models emit at the raw model layer. Almost all production inference servers convert that into standard OpenAI JSON tool_calls before returning the response — so Qwen normally works fine with NetXMS if the inference server is configured to parse tool calls. For example:

- Ollama — works out of the box for Qwen models that ship with a tool-call template in their Modelfile. Point NetXMS at the Ollama provider and it will receive normal JSON tool_calls.
- vLLM — requires starting the server with --enable-auto-tool-choice --tool-call-parser hermes (or qwen3_coder for the newer parser). Then the OpenAI-compatible endpoint returns JSON tool_calls.
- SGLang / llama.cpp server — similar flags exist.

Which exactly is your NetXMS version?

Great, thanks for the update

Hi Filipp,

that patch solved the problem. Everything is now in the same language!

Thanks!
Detlev

Dear Support Team,
I'm writing to seek technical support for two issues with the network topology functions.
When I right-click a node, select Topology maps, and choose Layer 2 topology or other topology types, the displayed topology coverage is far too large. It appears that the discovery scope is not restricted by the parameter Topology.DefaultDiscoveryRadius, which is currently set to 5.
Regarding the Network Map feature: when using MSTP links with ISP communication devices deployed between two end nodes, the system sometimes fails to recognize the connection relationship between the two terminal nodes. We presume this issue results from improper configuration of the intermediate ISP-side devices.
We sincerely hope you can offer relevant solutions and troubleshooting suggestions. Thank you very much for your help!
Best regards！

Hello NetXMS Development Team,
 
I have a question about the AI tool invocation format of NetXMS.
 
I heard that NetXMS currently only accepts AI tool calls developed based on standard JSON format, and it cannot work properly with models that adopt XML format for tool calling.
 
The Qwen3.6 series large models use XML format to implement tool invocation. I would like to confirm whether NetXMS is indeed incompatible with XML tool calling mode right now.
 
Besides, I sincerely hope that you can add support for XML format AI tool calls in subsequent version updates. This optimization will bring great convenience for users applying Qwen3.6 and other XML-based AI models.
 
Thank you very much for your time and support!

Just closed issue 3023 (former NX-2821) - will be part of release 6.2.0.