Claims - Support for mixed batches

[danielsveins]

IOBWS 3.0 defines a way to send a claim batch that can create, alter and cancel in the same method. According to these meeting nodes, from April 18th 2023, the banks do not see the need to support being able to create, alter and cancel in the same batch.

This matter should be revisited, either on the IOBWS 3.0 side or at RB.

[danielsveins]

It would be interesting so see from where the requirement to support mixed batches came from and the rationale behind it.

[Kristinn-Stefansson]

Meeting of TN-FMÞ-VH7-15 discussed this but could not establish the origin of the need for mixed batches. Could @siggauti comment on this? Also it was pointed out that this would be difficult to implement on the service backend as handling the difference between the real state of the entity and the indicated expectation from the client might end up creating problems when not explicitly in a separate action. Currently RB cannot support this, though that might change later on. For a long time there was support for this in the text file formats, that are still in use by clients but now need translation in the intermediary service backends of the Banks as RB does not accept them.

The next step would be to receive further input and suggestions from the wider community, and perhaps suggestions on the way to approach a solution from the backend implementors or even a PR.

[siggauti]

I do not recollect that need of create and alter batches in the same batch. I think the batches was merged from post /batches/create and post /batches/alter because it did not corrispond to Rest API standard. But the cancel and alter batches could be the same batch as it is defined in yaml. Cancel is only alter of status in claim.

[kristinnstefansson]

After requesting and gathering comments from the stakeholders, there was not requirment for business functionality to support multiple actions in batches. Also it is clear that currently the interfaces for the core system does not support these type of bulk operations. A future version might amend that but the council in charge of future roadmaps for the IH system at RB must be in charge of defining that as a feature. The PR submitted separates creation and updates, and the implementors must until supported return errors when updates intermingles alter and cancel operations.

There was a question raised around the use of alter vs merge. The decision after a deliberation was to use alter instead of merge, except when describing the actual JSON/OpenAPI functionality.

[Kristinn-Stefansson]

Marked as processed in line with agreement on TN-FMÞ-VH7-18