M
Mark Tarry
When defining an aggregate property, we're able to specify both:
  1. pathFilter
    which controls which entities are included in your aggregation calculation based on their relationship path from the source entity
  2. query
    which is applied to all entities on the target blueprint
I'm proposing an enhancement whereby we can specify a JQ filter (
query
-like) which is applied to a mid-path blueprint on a multi-hop relation.
For example:
Blueprints:
_team --owns-> service --involved_in-> incident
Aggregation: (on
_team
) which counts the total incidents for the last 90d, across all
service
s they own.
As with all metrics, this is to highlight potential problem areas the team may want to invest time in.
Now lets say our
service
blueprint included a
status
property - an enum of
Active
/
Decommissioned
. Allowing us to retain the valuable data we've collected on any
service
after it's been torn down. This also acts as a lever for filtering in/out such
service
entities.
We could have the aggregate count all incidents across all services. But what's the point in the team investing time on a service we've already decommissioned? We'd rather have the aggregate
filter out
any
service
entity with
status=Decommissioned
, and then count all related
incident
entities.
Workaround
you could mirror the
status
value onto the
incident
blueprint, and then use
pathFilter + query
. However this only works if the (direction of) relationships can support the mirror property. It's not always viable.
Those using Terraform are potentially more restricted: https://roadmap.port.io/ideas/p/terraform-pulumi-add-relation-resource