Several ContentObjects per Incoming

[rowe42]

Status Quo

Currently we can only generate incomings in the DMS that contain one contentObject. The only exemption of that is the reuse-incoming feature, that places a contentObject inside an existing incoming depending on a pattern matching the incoming name.

Technically speaking we include exactly one PDF in each event that the dispatcher sends towards the following components like dms-service or dipa-service.

In order to have more than one contentObject per incoming we want to change that, so we don't need to fall back to the reuse-incoming feature.

Requirement

There should be more than one PDF possible in an event. The component picking up that event should process all containing PDFs in one go, producing an incoming with all PDFs of the event.

This requires the following changes for dispatcher:

• introduce a new pattern in dispatcher to to identify PDFs that belong together. In the example, it should be possible to identify example-1v3.pdf, example-2v3.pdf and example-3v3.pdf belonging together.
• pick up all PDFs belonging together in one go
• check whether the list is complete. In the example, there should be three files. If the list is not complete, but the newest file is already more than x hours/days (configurable) old (depending on the timestamp), there should be warning mail produced.
• check for an existing Metadata-JSON, if the usecase requires this. There will be only one Metadata-JSON for the set, which has the same filename except the suffix, in the example example.json.
• change the event structure such that it now contains a list of presignedURL-Links for the PDFs that belong together; the PDFs should be sorted within the list (i.e. 1v3, 2v3, 3v3).
• when receiving the answering event, it will also have the same list of presignedURLs. The corresponding PDFs need to be set to finished etc. as usual.

It requires the following changes for dms-service:

• be able to handle events with a list of presignedURLs for the PDF to process
• make the handling of PDFs belonging together configurable per usecase; reject an event with a list of presignedURLs for all other usecases
• extend the processing such that additionally to the calls to objectAndImportToInbox and incomingFromInbox for the first PDF there is also a call to PUT /incomings/{objAddress} for PDFs 2 up to n.
• use a single Metadata-JSON as before for fetching additional data for processing

Other components like dipa-service or invoice-service should reject events with more than one PDF.

Things to check:

• Can we make the change such that both the old and the new event structure can be handled in parallel? If not, how should we handle components that should NOT process events with more than one PDF? Should the check whether the list contains only one entry?
• What of the described functionality needs to go into handler-core instead?

Further details of the new feature can be found here (LHM-internal, German).

[simonhir]

check for an existing Metadata-JSON, if the usecase requires this. There will be only one Metadata-JSON for the set

Wasn't there a discussion about it being one per file?

make the handling of PDFs belonging together configurable per usecase; reject an event with a list of presignedURLs for all other usecases

Is there a reason why this should be checked on both sides and not just in the dispatcher?