{"id":227,"date":"2026-08-12T18:56:57","date_gmt":"2026-08-12T16:56:57","guid":{"rendered":"https:\/\/www.visualdomain.ch\/?p=227"},"modified":"2026-08-19T05:40:41","modified_gmt":"2026-08-19T03:40:41","slug":"beyond-jsonpath-query-declarative-object-graph-queries-in-vcf-aria-orchestrator","status":"publish","type":"post","link":"https:\/\/www.visualdomain.ch\/?p=227","title":{"rendered":"VCF \/ Aria Orchestrator JSONPath: Declarative Object Graph Queries"},"content":{"rendered":"\r\n
<\/div>\n\n\n

Introduction<\/h2>\n\n\n\n
\n\n\n\n

Querying JSON in VCF Operations Orchestrator and VMware Aria Automation Orchestrator often starts simple.<\/p>\n\n\n\n

Find an object by name.
Select an item from an array.
Read a property somewhere below the root.<\/p>\n\n\n\n

For small structures, a few property accesses or loops are usually enough. But infrastructure data rarely stays simple. Configuration models, API responses, deployment metadata, and inventory data quickly become deeply nested structures where the condition you are looking for may exist several levels below the object you actually want to return.<\/p>\n\n\n\n

Readers familiar with Java or C# may recognize a familiar programming model here. At a conceptual level, JSONPath has similarities to Java Streams or C# LINQ: instead of explicitly implementing iteration and condition handling, you describe which data should be selected and projected. The APIs and capabilities are different, but the underlying declarative way of thinking is similar.<\/p>\n\n\n\n

At this point, the traversal logic often starts to dominate the code.<\/p>\n\n\n\n

Nested loops, temporary arrays, existence checks, and multiple levels of if statements describe how to walk through the object structure instead of what should be selected.<\/p>\n\n\n\n

This is the problem I wanted to solve with an extended JSONPath implementation for VCF Operations Orchestrator and Aria Automation Orchestrator.<\/p>\n\n\n\n

The idea is simple:<\/strong>
Instead of manually traversing an object structure, describe the selection as a declarative query and let the query engine navigate the structure.<\/p>\n\n\n\n

Standard JSONPath already provides a powerful foundation for navigating and filtering JSON. But for some real-world automation scenarios I wanted to go one step further.<\/p>\n\n\n\n

What if a query could find a deeply nested object and then traverse back to its parent?<\/p>\n\n\n\n

What if that parent could be filtered again before continuing further up the structure?<\/p>\n\n\n\n

And what if the complete operation could still be expressed as one readable query pipeline?<\/p>\n\n\n\n

This turns JSONPath from a simple value selector into something that feels much closer to querying an object graph.<\/p>\n\n\n\n

The result is a dependency-free JSONPath Action designed for VCF\/Aria Orchestrator. It keeps RFC 9535 as the default query language while providing an optional extended mode with two additional concepts: a self-filter and parent traversal.<\/p>\n\n\n\n

Together, these extensions make both top-down and bottom-up queries possible without falling back to nested imperative loops.<\/p>\n\n\n\n

The complete implementation, documentation, and test suite are available on GitHub<\/a><\/strong>.<\/p>\n\n\n\n

This article does not try to reproduce the complete JSONPath reference or the project README. The goal is to show the problem with imperative object traversal, introduce the declarative query model, and demonstrate how nested filters, self-filtering, and parent traversal can make complex Orchestrator data structures significantly easier to query.<\/p>\n\n\n\n

A Real-World Deployment Example<\/h2>\n\n\n\n
\n\n\n\n

Consider a very simplified response returned by the VCF Automation deployment API.<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span>