Add filter for created / updated to Shells / Submodels

[alexgordtop]

What is missing?

With 3.2 we introduce createdAt / updatedAt to AdministrativeInformation.
In cases, where data needs to be synced between systems, a kind of changelog would be very valuable.
That would allow a sync between systems without the need for event based synchronization.

How should it be fixed?

Introduce an endpoint that returns Identifiables by creation or update timestamp.
Ether as separate endpoint or as part of the GetAll* endpoints.
Permission wise it could be easier to introduce a separate endpoint like "/shells/changelog" with parameter "updatedAfter" or "createdAfter".

• I have signed the required Developer Certificate of Origin (DCO) already.

[alexgordtop]

@FrankSchnicke @sebbader What are your thoughts on that?

[noppenberger]

@Rudra-sandeep @sebastiankb what do you think?
As aligned, Siemens will support that feature request. This will enhance crawling efficiency, reduce the costs, without the need of an additional implementation of a notification service like MQTT.

[mjacoby]

I understand the idea but I would argue that this feels like a fundamental paradigm shift in what an AAS/submodel is. Right now, at least to my understanding and I think the original idea, an AAS/submodel represents only the current state of an asset. Adding this notion of time would blur or even violate this paradigm as it would now represent the complete history in time of an asset instead of the current state.

Another aspect is that this would drastically increase the complexity of and/or requirements for implementation. At a time where we are also discussing creating minimized profiles for constraint devices as implementers are often already overwhelmed by complexity of the APIs this seem questionable.

I am not against this per se but as it seems like a major change on different levels I would argue this needs some in-detail discussion with strong use-cases and arguments.

[aaronzi]

Just to make sure that this is not missed in the discussion. There will be two new operations in 3.2 called GetAssetAdministrationShellVersionByIdAndDate and GetSubmodelVersionByIdAndDate(see #540). Does that already satisfy your feature request?

[alexgordtop]

@mjacoby Don't get me wrong - the feature uses only the two new attributes createdAt and updatedAt from the AdministrativeInformation. So no need for history.

It's more related to type information than to instance information.

Eventually changelog is the wrong name, that leads to your confusion. Recommendations are welcome!

@aaronzi No, these operations have the impact that @mjacoby is afraid of and are mostly relevant for DPP related systems.

I'm talking about a feature, that just tracks, when an object was created / modified to simplify the selection process in site-to-site synchronization use cases.

[mjacoby]

Thanks for the clarification @alexgordtop !
If I now understand correctly you want to be able to filter /shells by createdAt or updatedAt, e.g. GET /shells?createdSince={some date}. Please correct me if I am wrong.

If this is correct, my impression would be that this should be covered by the query language if not the case already.

However, I assume you want to have a dedicated API call or query parameter for that in case a server does not support query. If this is the case we are back to a rather fundamental question, namely for which functionalities to introduce explicit URLs and parameters and which we do not consider important enough to do so and refer to the query endpoint as solution.

Assuming my understanding of what you want to achieve is correct, I would not have any issues with adding a new profile to give this functionality an explicit URLs and/or query parameters but I would suggest to put the question how we handle these issues in general back on the next API working group agenda.

[BirgitBoss]

compare to #346 and #540

#346 - a high-priority Catena-X requirement -exactly requires the same: enable to find all entries entered after a specific data in time to avoid notification mechanisms etc.

[tfunken]

I agree with the statement of @mjacoby. Once the attributes createdAt / updatedAt are available you will be able to query for recently created / updated shells and submodels using the query language.

If you do not want to use the query language, we should discuss why and maybe review more accessible alternative query methods. But intoducing new endpoints for every query scenario will eventually crowd the API spec.

[gataka]

This could be also addressed by the event feed concept of: #557

It describes an API that can be used to poll events for different entities like Assets, AAS and Submodels.

[BirgitBoss]

see also queries as specified and required in #562

[BirgitBoss]

If this is correct, my impression would be that this should be covered by the query language if not the case already.

Once the attributes createdAt / updatedAt are available you will be able to query for recently created / updated shells and submodels using the query language.

it is not yet covered, see #551 (comment)
The query language by purpose up to now only supports a subset of the metamodel and API data types.