Need help with AML query to connect two independent ItemTypes via referencing item

Hi Angela,

AML itself doesn’t really have the joining capability you’d need here. A query definition would probably be the simplest approach to this type of query.

If you can’t use a QD in this scenario, I’d try creating a custom server method to use as an AML action. 

<Item type=“Part” action=“GetBomWarehouseData” id=“...” />

That approach would enable you to include any additional you need in the AML response.

Out of curiosity - do you have any constraints preventing you from using a Query Definition in this scenario? 

Hi Eli,

thanks for the ideas! I made some progress and at the same time you opened Pandora's box.

The original idea was that I reuse my custom "all-purpose-all-in-one view". It´s a single Method that renders the result of an AML query to a simple table in a pop-up window. See following example. It uses a AML query to collect all documents hidden in the multiple BOM levels:

That´s why I asked for the plain AML query - cause I wanted to use the same building technique to "save time" (worked well so far). 

As this kind of rendering is basically a simplified QD/TGV clone, there is of course nothing wrong with using the original QD/TGV combo. The resulting view is basically the same and QDs can deal with referencing items. Perfect!

Quote: Out of curiosity - do you have any constraints preventing you from using a Query Definition in this scenario? 

There were none - before I tested it. In my environment it doesn't work, but it´s not the fault of Innovator. It´s my federated data that I pull via an onGet query.

My current federation solution is optimized to display federated data in the client (including grid relevant functionality like filter options, paging, etc.). See: Best way to highlight (fully) federated data in grids and views? 

Now I learned that my federated data isn't perfect enough for AML queries. My "crafted" item properties mainly consist of id and keyed_name. With id and keyed_name they work as clickable links in grid and Forms, but they doesn't work in QDs.
I think we can tell the reason when we look a the data structure of similar ItemTypes (like Manufacturer Part with the Manufacturer item property). Typically item properties use a bit more data:

I am right now a bit unsure of what to do. 

- Use an additional server Method (as you suggested)
- Rework my federation solution so I can use QD?
- Make an additional federated view that already contains all the data?
- I also got some ideas from another community member that I don´t need to over engineer everything and there is nothing wrong in using more than one AML query to get the data.

I think I'll let the problem sit for a while and hope it resolves itself.  It´s a fun challenge, but it´s just there because my users are spoiled. In the past people would have been totally fine with an SSRS report for this kind of view.

Edit: In QD I right now get following error message when testing the query:  <faultstring>Item attribute 'itemTypeName' not set !</faultstring> . In only appear when my custom federated ItemType is included. For testing purposes I added various additional attributes, but couldn´t get rid of the error message.

I made some progress. I solved the original use case by making an additional SQL view. Not my favorite solution, but this way I was able to read the data with a much simpler AML query.

But this topic is still a rabbit hole regarding the query definition. 

I so far didn´t succeed in using my federated ItemType inside a QD. Even if I create a completely new QD with just the Federated ItemType I get the "<faultstring>Item attribute 'itemTypeName' not set !</faultstring>" error message.

And I think I know the reason. QDs work different than the Grid. Right know my federation onGet query is optimized for the classic "Grid - Relationship - Form" trinity. But QDs work different, as they support more additional functionality like levels and reverse properties. My Federated ItemType cannot work, cause it doesn't provide the data that a QD needs. I right now just return the regular item structure but QDs works a lot with references.

Eli Donahue Do you know if there is any information of the basic data structure a Query Definition uses when pulling data? It´s not an important topic right now, but I see a lot of fun use cases for these kind of queries. 

I can check with the PM and architect for QD to see if we have any info to share. Using federated data in QD’s certainly sounds like a helpful use case.

PS: “We have an item property at home” gave me a good laugh

Hi Eli,

here some update: The warehouse view was a big hit and people love it! In the meantime a second use case showed up and I identified a scenario where Federated Data in Query Definitions will become EPIC. 

-> Use Federated Data with the new Reporting Feature and show diagrams with federated data in the Dashboard!

Use case:

Let´s assume we produce electronic products, and each device is tested after manufacturing. The testing process involves various methods, with voltage and current measurements being commonly included. Typically there is a department responsible for these tests, which plans the tests and analyzes the results. For this purpose, there is dedicated hardware and software. 

In the phase of production ramp-up, additional stakeholders are interested in the test data as it provides valuable insights into the process and ensures everything is running as expected. Monitoring and analyzing the data closely allows any potential issues to be identified and resolved early, optimizing the production process.
But not everybody has access to the test software and database so using federation to display test certain data in Innovator is an elegant solution. 

I got the following request: 'Please provide this and that data so I can export an Excel file and generate charts.'

Yeah, the classic Excel approach. Of course, this is not how we handle it. Excel is not ideal because it only provides a snapshot of the data, lacks real-time monitoring, is prone to human error and struggles with large datasets.

One solution is to provide some diagrams and reports directly from the SQL Report Server. This works fine and people are happy. Of course the MS SQL Report Server only offers limited access control as it doesn´t honor the permission system of Innovator. But Query Definitions do!

This leads us to the new Aras Reporting features. The possibility to display charts in the dashboard would be the icing on the cake, cause people can have an instant live view to data of interest. In the simplest case, they just want to know how many products have been tested and how quickly. In other cases, they may need to monitor a specific component. These kind of view are perfect for  users who don't primarily work in the testing department, but still need certain data, such as quality managers, engineers, product managers, manufacturing planning,... 

So if Aras don’t have any plans for 2025 yet - go for it! :)