Inbound Message Flow¶
These components are involved in the flow of messages from one Government to another. Specifically, the receiving side of the equation.
There is one of these workers for each distinct channel.
They are like listening posts. They observe every message on the channel, filter out the ones that originate from this jurisdiction, and send the rest to the Private Message API for processing.
This way the rest of the system can know about new messages, and does not need to know about the configuration of channels.
Private Message API¶
When a message is sent by another jurisdiction to this one, the Channel Observer component associated with that channel uses this private API to process the mesaages.
This is where many channels funnel into the one system.
The implementation is /intergov/apis/message_rx_api
The specific business logic code is in the class EnqueueMessageUseCase in the file /intergov/use_cases/enqueue_messages.py.
This worker process is a “spider” in the same sense of the word as used to describe the things that search engines use to maintain their index of web pages.
Unlike a search index spider this does not fetch web pages. It fetches the objects (files, documents, etc) that are the subject of G2G messages.
This component assumes the other Government is providing an interface that conforms with the edi3 Document API spec.
Iterate over the RetrieveAndStoreForeignDocumentUseCase.
RetrieveAndStoreForeignDocumentsUseCase(jurisdiction, object_retrieval_repo, object_lake_repo, object_acl_repo)¶
Processes single request from the queue to download some remote document.
The process is recursive. If an object has sub-objects, add more jobs to download them later.
returns None if the object has already been downloaded
returns True in case of success
raises exceptions for errors