This interface provides the ability to publish events for all the suspense disbursement activity that happens within ALIP on an event queue.An integration Listener will then post the events from the event queue to an external system using REST or SOAP methods/protocol which is configurable on the interface.The level of security support provided for the external service is also configurable and can be set to OAUTH2, basic authentication or no authentication.
This Interface is applicable for all products in ALIP. The triggering criteria is met only when a suspense is successfully disbursed in ALIP. The interface will provide details for Suspense Payee/s and if the suspense is on a policy, it will also provide data elements of policy owner, policy joint owner, policy annuitant/insured and policy joint annuitant/insured.
| TR ID# | Technical Requirements |
| TR1 | ACORD v2.3 transaction type 1217 will be used to communicate between ALIP and external systems |
| TR2 | ALIP will trigger the event publishing as per the required configuration (current configuration – suspense disbursement events for successfully disbursed suspense). |
| TR3 | An integration listener will be developed off the event queue to read and post thethe messages to an external system. Posting mechanisms will be supported using RESTusing corresponding authentication mechanisms, as per the configuration. OAUTH2 authentication mode is supported for REST calls. |
| TR4 | Any type of failure in processing the received event request, will be created as an Integration Failure in ALIP. |
| BR ID# | Business Requirements |
| BR1 | When a suspense is successfully disbursed from ALIP UI disbursement event needs to be triggered. |
| BR2 | ALIP needs to publish the event message to an event queue for these suspense disbursements. |
| BR3 | The interface should also provide the additional functionality to post event message to an external system using using the configured method/protocol and the security mechanism. |
| BR4 | ALIP also allows to add multiple payees to one payment and generate multiple disbursement records.One disbursement event should be sent for all the disbursements as opposed sending individual disbursement events. |
| BR5 | If the external service is unreachable or any exception is thrown while invoking the service, the interface will log an Integration Failure in the ALIP database. |
| BR6 | The interface should also return ACORD data elements for the below policy roles:OwnerJoint OwnerAnnuitant/InsuredJoint Annuitant/Insured |
Suspense page on the UI can be used to disburse a new/pending suspense. On successful disbursement of the suspense, the Publish events interface is triggered.
The Suspense workflow execution and the Publish events interface execution will work asynchronously to each other as this is a ‘fire-and-forget’ interface.
This workflow includes appropriate business configuration to set up the event triggers that trigger the interface that sends an event message for this suspense.
A message is posted to the ALIP request queue, from the workflow that needs to trigger the event publishing.
The interface identifies the type of event viz. application, disbursement transactions, disbursement suspense etc. and invokes the appropriate logic.
It handles the loading of the needed suspense information pertaining to the triggered suspense, via necessary API calls, and transforms the message from ALIP canonical to ACORD format. ACORD Transaction Type 1217 is used.
It then uses XSD to validate the XML to ensure that the mandatory elements are present in the XML, and that it is as per the allowable values for the respective elements.
In case of any validation failures, the message is sent to the error channel for this interface. In case of successful validation, the message is posted to the event queue.
An integration listener reads the message from the event queue and posts it to a configurable end point using REST and OAUTH2. Other modes of configuration e.g.SOAP are also available. This makes the event message directly available for clients not intending to listen to the ALIP event queue for messages.
This interface provides an event to external system when a suspense is disbursed.
The Base suspense page and base suspense disburse functionality are in scope for this interface.
The Disbursement Events will be sent out to a common external service.
ALIP’s processing ends after successfully posting to the end point.
Elements will be sent empty if they have no values within ALIP for the respective suspense.
One message per each suspense disbursementis sent. The order of messages is not guaranteed.
Connectivity details to the external systems are highlighted below.
The connection type for REST is configurable for Accenture Dev team, and will be a one time setting. Allowed values are REST but it can support SOAP as well by setting up some new properties. Connection Type is set as below:
SendMessageToExternalSystem.ExternalServiceType=REST
REST connection supports OAauth2 authentication as well, if it is not required it can be turned off. If required token generation details will be required as below. It supports only content type as application/json.
Oauth2Token.AuthParams=0oacwixpbxdbt9Q8Y0h7:TQZZ7BK2f-RL1oMskguRqnpJuqphbZrAvwQnE_JZ
Oauth2Token.Url=https://dev-115057.oktapreview.com/oauth2/default/v1/token?grant_type=password&username=SUPERVIS&password=123456&scope=openid
REST connection supports both XML and JSON content type with POST request. REST connection details are required as below. IntegrationPoint.REST.{RequiredDetails}.
SendMessageToExternalSystem.REST.AuthReqd=Yes
SendMessageToExternalSystem.REST.AuthType=OAuth
SendMessageToExternalSystem.REST.ContentType=XML or JSON
SendMessageToExternalSystem.REST.Url=http://localhost:8089/v1/transaction/disbursement
SendMessageToExternalSystem.REST.RequestType=POST
N/A
Please note that any suspense disbursements that fail during processing will not invoke the interface at all.
For any disbursement events that couldn’t be sent out, either due to an ALIP issue or external system can’t be reached or authentication or handshake fails, will result in integration failures. These failures will need to be investigated by ALIP Production support.
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Successfully disburse a suspense | 1 | Success | Informational | Once the suspense disbursements are processed, and after the Suspense workflow is processed, expect a disbursement event in the ALIP Event Queue. Once the listener picks up, a post will occur to the external service.Integration history should reflect successful integration. |
| #2 | Suspense Disbursement incomplete or failed. | 1 | Success | Informational | No event will be sent out. Once the suspense is disbursed successfully, results for scenario #1 is expected. |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Disbursement Event was unsuccessful due to missing mandatory tags | N/A | Validation Error | N/A | |
| #2 | Suspense disbursement event posting to the external service was not successful due to the external system being unreachable or returns a 5xx series error (for cases where the external system’s webservice uses REST OAuth2) | N/A | Connectivity Error | N/A | |
| #3 | Suspense disbursement event posting to the external service was not successful due to a 4xx series error from external system (for cases where the external system’s webservice uses REST OAuth2) | N/A | Processing Error | N/A | |
| #4 | Suspense disbursement event posting to the external service was not successful OAuth token generation error from external system (for cases where the external system’s webservice uses REST OAuth2) | N/A | Connectivity Error | N/A |