3 of 3 people found this helpful
Only first order SIs will automatically be aged. The is documented here. To be a first order SI the pattern must trigger on one of following node kinds:
I read the documentation but didn't understand it until now. Thought that first order meant something else.
So is the proper way to use a removal block within the pattern or is there some way to use the setRemovalGroup to accomplish this?
We want to create a SI upon the existence of a directory regardless if the process is running or not. Also, if the directory is not found, the SI should be deleted right away.
Trigger used is os_class = "UNIX".
You could use either removal groups or a removal block.
Isn't it rather risky just checking the existence of a directory? You could end up with an empty directory reporting that the product is installed. If you really want to check would it not be better to at least check for the executable?
os_class is an attribute - not a node. If it is an inferred node it is easy to use a removal group.
Binary is run for version information after the directory is found.
Trigger is :
on host := Host created, confirmed where os_class = "UNIX";
Could you give an example how to use removal block and removal group? Can't find any removal block in any of the existing patterns.
We have a custom pattern which infers SI nodes, using another SI type as a trigger condition. Therefore, no age related attributes are populated for these custom SIs as per the documentation.
I've looked at the TKU patterns but cannot find an example of a removal block which I could use as a guide, to populate the age_count, last_update_success & last_update_failure attributes for our custom SIs. Does anybody have an example of such a removal block?
Anybody got a good example of a removal block for populating the age_count, last_update_success & last_update_failure attributes?
Why are you trying to make your second order SI behave differently to every other second order SI?
We're trying to populate the age attributes for this second order SI, as they would be if it were a first order SI.
Is it possible to do that for a 2nd order SI using a removal block?
Either way, would we have to use the attribute values from the triggering first order SI?
I don't understand why you want to implement age attributes for these.
Software Instance trigger
When patterns trigger on the creation or modification of other Software Instance nodes, the behavior is simpler. In this situation, the pattern must provide a key for each Software Instance node. The key is used to find an existing Software Instance node to update, or to create a new one. In both cases, the node is linked to the pattern with a maintainer relationship.
Software Instance nodes created as a result of Software Instance triggers are destroyed using the Cascade removal type; when the triggering Software Instance node is destroyed, the destruction is cascaded to the higher-level Software Instance node. See Cascade Removal.
Why it is not enough for you?
I interpreted the previous info in this post and the documentation, that the only way to populate 'ageing' related attributes for SIs inferred from things other than DiscoveredProcess, DiscoveredService, DiscoveredListeningPort & DiscoveredSoftware, was to use a removal block:
"If the SI is triggered on anything else, for example, a discovered file, then aging must be implemented in the pattern using a removal block."
The second order SI in question, is inferred from an old, custom pattern which I'm going to review internally with the relevant product SMEs, to determine if it's still needed/valid.
In the meantime, I'd like to know if it is possible to populate age_count, last_update_success & last_update_failure attributes for second order SIs? If so, will these values be the same as the related first order SI & how do you achieve it using TPL?
Thanks for confirming.
Can anybody provide an example or pointers on what the required removal block code would look like, for a 2nd order SI?
I would think it should work though I am unaware of anybody who has done it because that is not the expected model.
Any idea on the required removal block TPL synatx for one such attribute e.g. last_update success?
Would we have to assign the value derived from the same attribute on the related first order SI?