This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
A workflow provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
This section lists workflows that this Building Block must support. Other workflows may be implemented in addition to those listed.
The main prerequisite for Person-to-Building Block communication is that there is an existing Sender/Source Building Block with the following properties:
the relevant credentials and details about the Person/Citizen to be addressed with;
the content of the message and a reference to a communication channel (contact details) to be used;
additionally, the service discovery service at the Information Mediator Building Block needs to be active. Information Mediator Building Block publishes the list of available services of the Messaging Building Block to the source GovStack Building Block, i.e. Workflow.
A reference token should be carried throughout the communication session in order to save a point of reference for reverse communication back from the Person to the Building Block. In other words, the main prerequisite for Person-to-Building Block communication is the availability of a communication channel and a reference token.
This generic workflow is used to transfer messages between GovStack Building Block and the end user, Person. Data is submitted from a GovStack Building Block front-end application. This workflow shows a connection to GovStack Building Block (such as a government Health System Application) to convey a message that is associated with a real person.
This workflow requires interaction with the Information Mediator Building Block and a source GovStack Building Block, for example, a Health Care Service Building Block or registry Building Block.
The sequence diagram shows the flow of data between Building Blocks for this workflow.
Messaging Building Block accepts a message from GovStack publisher
Publisher Building Block or service conforming to the Messaging BB schema
Reject messages that do not comply with expected schema
Retrieve Person and Contact Channel Data from the incoming Message
Map retreived data with appropriate recipient
Technical mapping is an internal service of the Messaging BB
Publish Message through Communication Channel
Communicate Message Data and User ID to Communication Channel
Reject messages that do not comply with expected schema
Publish Status for the original sender
User and Message IDs with Delivery Status containing date and time
The Message's unique ID is preserved to keep up its status updated
Message sent through the communication channel / service provider
Text message and User ID
Reject messages that do not comply with expected schema
Retrieve Person and Contact Channel Data from the incoming Message
Map retreived data with appropriate recipient
Technical mapping is an internal service of the Messaging BB
Confirm message received
Message Delivery Data Structure following Communication Channel standards with Status
The Message unique ID is collected to keep up other statuses updated
Publish Status for the original sender
User and Message IDs with Delivery Status containing date and time
The Message's unique ID is preserved to keep up its status updated
The following diagram illustrates the internal processes of the Messaging BB to send messages received as external requests and sent via external service providers.
The following diagram illustrates the internal processes of the Messaging BB when providing status report for messages that have been passed on by external partners for further processing by the Messaging BB.