Dais Integration with Existing Underwriting Workbench and a Service Bus
This guide illustrates a possible integration between Dais, an underwriting workbench, and a service bus. The message routing and outbound notifications shown here require configured integration actions; submitting an API event does not create a service-bus connection by itself.
The integration process includes three main components: Rating, Issuance, and State change.
Rating: The process starts with an Underwriting workbench that sends a Rating Request to the Internal message queue in JSON format. Subsequently, the Rating Request is forwarded from the Internal message queue to Dais. For GET_QUOTES, set
forceSync: trueto receive results from supported rating actions inmetadata.quotes, or use the quote retrieval API to obtain results by trigger request ID. See GET_QUOTES for execution and completion handling. Your integration publishes the returned rating results to the internal message queue, either from the API response or through a configured outbound action. Finally, the 'Rate' is passed on to the Underwriting workbench via the Internal message queue polling mechanism.Issuance: The second sequence begins with the Underwriting workbench sending an Issuance Request in JSON format to the Internal message queue. This is then relayed to Dais. Following this, Dais sends policy data back to the Internal message queue in the JSON format. This policy data is then relayed to the Underwriting workbench via the Internal message queue polling mechanism in the JSON format.
A note at this stage highlights any transformations needed. Once the policy data is processed and transformed, if necessary, the Internal message queue forwards that data to the associated Data Warehouse for storage.
- State change: The third sequence is the most straightforward and involves just a single operation. In this process, Dais sends a State Change Notification, including the payload in JSON format, to the Internal message queue. This notification is for notifying the queue about any changes in the state.
Define correlation identifiers and completion handling for each message exchange. A trigger response alone does not confirm that every asynchronous action or external system has finished.
