What is wrong with AQL?

[Antonia]

( (objectTypeID = 194 AND objectId = 686) OR (objectTypeID = 236 AND objectId NOT IN (20700, 72507, 71333, 20683, 20765, 20757)) ) AND "Hardware-Status" = "aktiv"

So:

The object is of type ID 194

AND it has object ID 686

AND the hardware status is “active”

Then a Ticket should be created, every second tuesday. (this is from a rule)

And also the object is of type ID 236

AND the object ID is NOT in the list (20700, 72507, 71333, 20683, 20765, 20757)

AND the hardware status is “active”

I wanted to link the different object type IDs, i.e., 236 and 194.

So in 194, a ticket should only be created for ID 686. And in 236, a ticket should be created for every asset except those included in this list/enumeration. And all assets should have the hardware status “active”; otherwise, no ticket should be created.

When I split the AQL in two requests it is working, but I have to go in to the different object types..

Could it be that I have to create two rules because there are two different object type IDs?

[Tuncay Senturk _Snapbytes_ · Accepted solution]

Hi @Antonia 

As far as I understand, you created a rule per object type with id = 194 (server). If so, yes, the rule scope is one object type and it does not include the id = 236 (virtuelle server).

So, because the automation context is tied to one object type, you can't combine 194 and 236 in a single AQL branch. I assume you need to split them. I am not sure if you keep a single automation but use two "for objects" branches.

[Antonia]

Hi @Tuncay Senturk _Snapbytes_

can you please look over this rule:

Is that correct with the branches? Or do I now have to insert the lookup version and the action into each branch?

[Tuncay Senturk _Snapbytes_]

Hi @Antonia 

Your two AQL branches are right, but the lookup + create issue block in Group 3 is in the wrong place.

Everything inside a For AQL branch runs once for each matching asset. As soon as the branch ends, the rule context goes back to the trigger.

So, in your current rule,

branch 1 finds objects with typeId 194 but does nothing with them. SImilarly, branch 2 finds id:236 objects.

You need to move (or copy) the per-asset actions inside each branch. 

Branch 1 (Servers):
For AQL (objectTypeId = 194 AND objectId = 686 AND "Hardware-Status" = "aktiv")
-> Lookup work items
-> If {{lookupIssues.size}} = 0
-> Create issue

Branch 2 (Virtuelle Server):
For AQL (objectTypeId = 236 AND objectId NOT IN (...) AND "Hardware-Status" = "aktiv")
-> Lookup work items
-> If {{lookupIssues.size}} = 0
-> Create issue

It's similar with creating two rules (each with its own AQL + lookup + create) , different perspectives

[Antonia]

Hi @Tuncay Senturk _Snapbytes_

thank you, but somehow the rule does not work:

So both AQL queries are correct. When I filter the assets using AQL, I always get results. I have now created another smart value after the lookup to check whether a ticket already exists so that no duplicate tickets are created. Maybe that's the reason, but actually it's not. There are no duplicates now because the rule has never been executed correctly.

[Tuncay Senturk _Snapbytes_]

Thanks for the screenshots, It's a tough one.

From your screenshots, I want to make sure:

your compare two values condition on the date may block the whole run,

In your earlier setup you had conditions like: {{now.day}} > 7 and {{now.day}} < 15. And your audit shows runs on 15th , so the {{now.day}} < 15 condition is false. Either remove those conditions, or change them to include  (<= 15)

Additionally,

if {{lookupIssues.size}} equals 0
And {{lookupIssues}} does not equal {{lookupIssues.summary}}

the second check does not make sense. Delete the second "And: compare two values" completely. Your duplicate check is already correct.

[Tuncay Senturk _Snapbytes_]

Sorry but when I read my comment after submitting, I wanted to add this, the quickest proof

• temporarily remove all top-level conditions 
• in each branch, keep only:

  • For AQL

  • Lookup work items

  • If {{lookupIssues.size}} = 0

  • Create issue

• Manually run the rule once.

• If it still doesn’t create issues, add a Log action inside the branch (right after “For AQL”) with: Found asset: {{object.Key}}

If it prints but no issue is created, the lookup JQL or permissions are the problem.

If the log never prints, then it means the branch isn’t iterating at all.

[Antonia]

Hi @Tuncay Senturk _Snapbytes_

thank you very much for your help. It's mostly working now.

The only problem I have now is that not all work items have an assignee set, even though the corresponding field in the asset is filled in. This only happens with tickets where only one person is listed in the corresponding field. Why do there have to be at least two people listed? It's fine if there is only one person listed in the “Patchverantwortlicher” field. Maybe you have an idea...

 

[Antonia]

So the assignee should always be the very first one in this field, but if there is only one in it, then that person should become the assignee.

[Tuncay Senturk _Snapbytes_]

When your Assets attribute contains more than 1 user, Automation treats it like a list, so: {{object."Patchverantwortlicher".get(0)...}} works

But when it contains exactly 1 user, it treats it like a single object (not a list). so .get(0) fails.

You can try using asList.first as the below. I am not sure if it will work but I'd give it a try.

{{object."Patchverantwortlicher".asList.first.accountId}}

ps in your screenshot, your attribute seems like a nested structure (you are doing ...get(0)."User Typ" ), then you can try something like

{{object."Patchverantwortlicher".asList.first."User Typ".accountId}}

[Antonia]

Hi @Tuncay Senturk _Snapbytes_

Unfortunately, it doesn't work, but thanks.