The /Orders endpoint - separating between own orders and public orders

[narve]

We have encountered an issue with the /Orders endpoint. It is needed both to

• view own orders (in order to e.g. validate/update/delete them, or to get the latest status (e.g. if they have been filled)
• view other orders

The second use case is a bit tricky, because different FMOs will have different policies regarding e.g.

• Which orders actors are allowed to see
• What information actors are allowed to see for other organizations' orders
• Whether those orders represent single orders or aggregated views

Furthermore, those two use cases are somewhat distinct and may have different requirements regarding e.g. required search parameters etc. The result could also be confusing if FMOs aggregate multiple orders into one publicly visible order.

We propose splitting those two use cases, to make it easier to understand how to use the endpoint, and easier/predictable to understand the answer. In other words, actors should either query only for their own orders, or for all orders (that are visible to them).

The result model might still be the same. Some fields will be hidden (NULL) in some cases, but actors should anticipate this anyway since different FMOs have different business rules.

We can do this in one of several ways: 1) Have two separate endpoints, e.g. /own-orders and /public-orders 2) Add a required search parameter, e.g. VisibilityType=Public or VisibilityType=Own 3) Add ownerOrganizationId as a search paramter, corresponding to Order.ownerOrganizationId.

For the third proposal, FMOs can choose to make the ownerOrganizationId parameter required or not, depending on business rules. In NODES it would probably be optional. Other FMOs may choose differently.

FMOs are required to either respect the parameter or to exept with a proper message if that search parameter is not supported. If the search parameter is required but not provided FMOs must return a proper exception stating that the parameter needs to be set.

@cdmNSIDE @ArnaudDebray what do you think?

[narve]

@cdmNSIDE @ArnaudDebray What do N-Side think of this PR? Do you prefer separate endpoints?

I think NODES is leaning towards separate endpoints, but will wait with changing the PR until I have heard from you.

[cdmNSIDE]

Hello Narve,

Concerning the ownerOrganizationId : it might be a good solution, but we should make clear in the API that the user may not receive all the information about an order if this order is not owned by his organization (i.e. the content of a private order may not be exactly the same one as a public order). I wonder also if this ownerOrganizationId should not be added in the trades or other resources (ex: is it useful for the baseline or meter readings?)

Concerning the 2 separate endpoints: ok, why not, even if we pushed up-to-now to limit the number of endpoints. Do you think we should also have 2 separate endpoints for the trades ?

How to you see the integration of those 2 solutions with the authentication / authorization process ?

[narve]

Good point about the trades, we have the same issue for those.

I will update the PR with a new endpoint and updated documentation. I suggest doing the trade-endpoint-split in a different PR once we agree on this one.

[narve]

@cdmNSIDE Please have a look at the updated PR and see if it is acceptable. We'll handle your other points in separate PRs .