Description
Since PDFs for the forms are created asynchronously, we cannot immediately create a transmission when we see a Submitted-event in instances events, as the dataelements for the forms (ref-data-as-pdf) are added later. Currently these are just ignored.
So when a FormSubmitted-event is found, we need to check that there is a ref-data-as-pdf data element added within a short amount of time (5 minutes?) of the Submitted-event. If not, we need to requeue the message, trying again within a few seconds. This should be repeated up to 2 minutes, at which point we should DLQ the message.
Or something else - this should be discussed with studio/apps.
One idea:
- If we can derive what PDFs will be created beforehand alongside their names, we can immediately add a transmission with the attachments, and point to a proxying endpoint in the adapter, which can check if the PDF has been made, and if not, return av 503(?) with a retry-after
Another:
- The URL can include a sentinel value ("?notdoneyet" or simliar) that AF can check for that indicates that the PDF is not yet available. When it does, the adapter can ninja-remove the flag.
Additional Information
We need to find out whether the adapter can acertain the number of expected PDFs, and then retry until that number of ref-data-as-pdf dataelements have appeared on the instance.
We also need a way to acertain which dataelements belong to a particular FormSubmited event.
Description
Since PDFs for the forms are created asynchronously, we cannot immediately create a transmission when we see a Submitted-event in instances events, as the dataelements for the forms (ref-data-as-pdf) are added later. Currently these are just ignored.
So when a FormSubmitted-event is found, we need to check that there is a ref-data-as-pdf data element added within a short amount of time (5 minutes?) of the Submitted-event. If not, we need to requeue the message, trying again within a few seconds. This should be repeated up to 2 minutes, at which point we should DLQ the message.
Or something else - this should be discussed with studio/apps.
One idea:
Another:
Additional Information
We need to find out whether the adapter can acertain the number of expected PDFs, and then retry until that number of ref-data-as-pdf dataelements have appeared on the instance.
We also need a way to acertain which dataelements belong to a particular FormSubmited event.