Return value of the /lookup/shells Method

[MMuellerMitsubishi]

What?

For the /lookup/shells Method I can give as input a list of Asset IDs. The return value is just a list
of strings (the AAS IDs).
How do I know which of the AAS IDs belongs to which of the Asset IDs. Is the order of the returned AAS ID guaranteed to be ordered in the same order than the Asset IDs?

Further, I think that for one Asset ID there could be two AAS ID exists. E.g. the Component Vendors has an AAS for this Asset ID and the machine builder has his own AAS for the same asset.
How would this situation look like in the return value?

How?

The return value should be a list of tuples showing Asset ID and corresponding AAS ID.

[arnoweiss]

The set of assetIds is logically AND-connected. So if you pass two assetIds, only the aasIds of those Twins are returned that have both in their globalAssetId or specificAssetIds. That can be, as you correctly state, a set of aasIds which is represented in the api-spec already.

If you want to OR-connect multiple assetIds, you'd need multiple requests.

There is currently work ongoing to complement the API you're referencing. Adding a mechanism to achieve this OR-connection between assetIds might be a nice feature.

What do y'all think?
@sebbader-sap @BirgitBoss

[sebbader-sap]

Sounds to me like we need a query language.

[arnoweiss]

So you view this request as out of scope for the next minor release (and thus of the behavior of POST /shellsByAssetLink)?

[MMuellerMitsubishi]

I see. I thought that would be an OR-connection between those assetIds to be able to use this functions to retrieve several aasIds for the assetIds in one call.
I think having such OR-connection would be beneficial but not urgent.

[CB4SAP]

I agree to this requirement. It would be great to query with multiple non-disjunct value tuples.

[sebbader-sap]

So you view this request as out of scope for the next minor release (and thus of the behavior of POST /shellsByAssetLink)?

I don't see the capacity in the group, so no, I don't think it's possible for 3.1.0

[sebbader-sap]

This finding was discussed in the API group today. As it can't be integrated into the current API Operation without breaking changes, it's not in scope for the currently prepared bugfix and/or minor release of V3. Therefore, the discussion is postponed for now.

[sebbader-sap]

Actually, my previous statement especially on the part "...without breaking changes..." is not correct. There are indeed possibilities to bring it in in a non-breaking extension.

[arnoweiss]

The upcoming v3.1 is a minor version. That means that adding optional calls is possible. If there is an optional POST /lookup/shellsByAssetLink that takes a JSON-body holding a query, that body could look like this:

{
  "operator": "AND",
  "assetLinks":[
    {
      "key":"globalAssetId",
      "value": "myGlobalAssetId"
    },
    {
      "key": "customerPartId",
      "value": "Goat-666"
    }
  ]
}

Possible operators could be AND, OR, XOR. The AND operator is how the list in GET /lookup/shells?assetIds=myencodedassetids currently behaves. The OR operator however (as discussed above) could significantly reduce HTTP traffic in scaled search scenarios.

But then again, you could argue that it makes more sense to just write a GraphQL mapping...

[g1zzm0]

The topic was officially discussed in the committee in charge and postponed to a future version. The development of a suitable query language is a huge topic, and it was felt to be unconstructive to reintroduce this feature in different places only to remove such quick and dirty workarounds later.

[arnoweiss]

The same holds true an optional /lookup/shellsByAssetLink with the same feature-set as the defunct /lookup/shells as it's currently planned. Or the Bulk API. That may get replaced by a "query language" eventually too. However, I don't see that happening in the next three years. Perhaps ever.

How @sebbader-sap argued it, the decision was based on the false assumption that adopting this feature would cause an incompatible change. That's why I chipped in again. If the working group wants to discuss it again is up to the working group.

[g1zzm0]

The decision was not made on the basis of backwards compatibility, but whether the feature is intended for the current version or not.

[BirgitBoss]

See also #204 for RQL-query