Filter data source by AQL in Assets

[Ivan Duvakin]

I have a list of Users imported from AD and I want to import over users from SCCM, and I don't want SCCM to create new objects but only add attributes to the existing ones.
The existing and imported objects have the same SID (from AD) and Id (from SCCM) fields.
How can I filter the received objects from SCCM import by referring to the existing objects and compare the received Id attribute with the existing SID attribute?

[Gikku]

@Ivan Duvakin  From what I understood from the requirement, the ID from SCCM should be compared with the 'SID' attribute already existing for the user records. If in that case, you should set the data pointer 'id' as the identifier (check the box on the left) instead of the 'Name' and map it against the existing SID attribute. You don't have to import the value twice. 

This way you are telling the importer to run a search for the 'id' values coming from SCCM to find a matching record and if so, update the rest of the values as defined against the attribute mapping. If not, create a new record.

[Ivan Duvakin]

The problem is that SCCM contains garbage user type objects, and I need to make sure that importing from SCCM does not create new objects. That is, the input needs validation that the incoming SCCM ID parameter already exists in the Employee object type and matches at least one of the SID attributes.

In general, is it possible to specify filtering with not a static value, but some attribute from already existing ones?
It would be interesting to see an example of syntax, I would be grateful.

[Gikku]

If you want to filter that way, you will have to copy the values of all the existing SID attributes and add to the 'Filter data source by AQL' in the format 
SID IN (value1, value2, etc..) which might not be feasible depending on the number of values that you want to compare.

You can try an alternate approach that you let the SCCM import to create unwanted entries also but then use an automation 'Object created' rule to consider them as garbage, probably through a status field, so that you can exclude those entries from your search and configurations but still let you import the required data. The entries imported through SCCM source can have a custom flag to identify the ones created via this import.

[Ivan Duvakin]

Thanks Gikku for the clarification!
At the moment I have the following idea:
Create an automation for created objects of type User, if SID is empty, then execute a script to delete records with empty SID attribute.
The only thing left is to write a script in Groovy)