Calculated fields: how to count unique interfaced applications

I am not 100% sure I am understanding the rules you outlined, but it seems you want the count of distinct applications which are consumers or providers of interfaces on the target application.

I suggest something like this (note that this version does not check the start/end dates on the relationships):

export function main() {
    var appIds = new Set();
    for (const relation of data.relConsumerApplicationToInterface) {
        appIds.add(relation.factSheet.id);
    }
    for (const relation of data.relProviderApplicationToInterface) {
        appIds.add(relation.factSheet.id);
    }
    var count = appIds.size;
    return count;
}

​@Paulo Vilar , ​@Thomas Schreiner, 

In my example, the target fact sheet type is the Application (not an Interface), and the target field for the result of the calculation is a field on the Application.

Calculations now allow you to reach through a relationship to look at the factsheet on the other end. From an Application, the relationship to Provided Interfaces is relProviderApplicationToInterface, and the relation to Consumed Interfaces is relConsumerApplicationToInterface (you can find by looking at the Application meta-model). The LeanIX docs talk about this (https://help.sap.com/docs/leanix/ea/calculations):

To reference fields on related fact sheets, use the notation relation.factsheet of a relation. For example, in a calculation for business capability fact sheets, you can access the functionalSuitability field on related applications with data.relBusinessCapabilityToApplication[0].factsheet.functionalSuitability.

So, in the calculation, data.relProviderApplicationToInterface and data.relConsumerApplicationToInterface are the arrays of interfaces related to the Application that is the target of the calculation. You iterate over each related interface array (using for, forEach or your preferred looping construct) and then look at the fact sheet at the other end of the relationship (i.e. data.relConsumerApplicationToInterface[0].factSheet is the first factsheet providing an interface to the target Application). Once you have the factSheet you can look at its fields. In this case, to count unique factSheets the best choice is to use factSheet.id.

The calculation adds the IDs for all the related factsheets into a Set which dedupes them, and then it returns the size of the Set (which is the total count of unique factsheets related to the Application via Provided and Consumed Interfaces.

Hi ​@geoffrey.lowney, have you tried this yourself? I thought that in a calculation you could only follow first-level relations, but once you arrived at the related fact sheet (in this case the interface), you could not traverse further. Do you mind sharing the code that allows you to traverse further from the interface to its consumer/provider applications?

Yes. I added a test field onto my Application factsheet (in our sandbox), and I created a calculation with the exact code I show in my original post. It apears works correctly (given my spot checking of results). I did this test in large part because ​@Paulo Vilar’s post got me thinking about other applications for this, and I wanted to confirm I knew how it all worked. 😀

As I sort of indicated, the ability of calculations to traverse through relationships is somewhat new. Looking back at the Product Updates emails, it looks like it was announced on June 13, saying

We've again extended the scope of calculations by letting you read fields from related fact sheets.

Hi ​@geoffrey.lowney Maybe I am missing something, but to me, it looks as if this code collects the unique IDs of all consumed and provided Interfaces of an application, but it doesn’t calculate how many applications are actually consuming those interfaces - which is a different question, because every provided interface can be consumed by many applications. For such a double aggregation (Provider App → many Interfaces → many Consumer Apps), I still only see my solutions mentioned above. 

Ah. You are correct. Honestly, I have been super busy this morning and didn’t get a chance to do real testing (and somehow I forgot that the .factsheet was going to be the interface). I guess in my case I would use PowerAutomate (only because we have it).

Thank you both. It worked by following ​@Thomas Schreiner proposed approach: hidden field and 2 level calculations. It was a AHA moment for me! Thank you ​@Thomas Schreiner