This interface provides the ability to publish events for all the transaction 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 and OAUTH2.
This Interface is applicable for all products in ALIP. It has been currently made available for following list of transactions, however it can be configured to support additional transactions as per client requirements.
Free Look Cancel
Systematic Withdrawal
Withdrawal
Cash Surrender
Death Benefit
Required Min Dist
Partial Death Benefit
t
Events for these transactions have been currently configured to trigger on Processed, Reversed & Reverse/Recreate cases.
The interface will provide data elements of policy owner, policy joint owner, policy annuitant/insured and policy joint annuitant/insured as per the mapping sheet in 3.1.10.
| 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 – transaction disbursement events for configured transaction list and statuses listed in the overview section). |
| 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 transactions mentioned below are processed, reversed, reversed & recreated, disbursement event needs to be triggered. Below are the transactions that will have disbursements:Free Look CancelSystematic WithdrawalWithdrawalCash SurrenderDeath BenefitRequired Min DistPartial Death Benefit72t (SEPP) |
| BR2 | ALIP needs to publish the event message to anevent queue for these transaction disbursements, irrespective of whether they are processed real time or batch. |
| BR3 | The event message should be posted to an external system using REST/OAuth2.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. |
| BR4 | The interface should also return ACORD data elements for the below policy roles:OwnerJoint OwnerAnnuitant/InsuredJoint Annuitant/Insured |
Transactions needing an event trigger,have been configured to generateentries needed for the ‘Run Transaction Workflow’ job to execute. ALIP Process Server during transaction processing, will generate these entries.
Run Transaction workflow batch process would need to be scheduled to run periodically. This job will trigger the Transaction Background Workflow for every transaction.
This workflow includes appropriate business configuration to set up the event triggers that trigger the interface that sends an event message for this transaction.
For other statuses, relevant workflows for the Transaction Reversal/Recreate processes will be responsible for needed event interface triggering.
A message is posted to the ALIP request queue, from the workflow that needs to trigger the event publishing.
The interfaceidentifies the type of event viz. application, disbursement transactons etc. and invokes the appropriate logic.
It handles the loading of theneeded transaction information pertaining to the triggered transaction, via necessary API calls, and transforms the message from ALIP canonical to ACORD format. ACORD Transaction Type 1213 is used.
It then uses XSD to validate the XMLto 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 disbursement transaction is processed.
It is assumed that ‘Run Transaction Workflow’ job can be employed to trigger the event upon processing the disbursements that are based out of transactions. Other transaction workflows for reversal/recreate handle needed triggers for these statuses.
ALIP’s processing ends after successfully posting to the end point.
Some data elements may not be sent if they have no values within ALIP for the respective transaction.
One message per each disbursement transaction is sent. The order of messages is not guaranteed.
Product team needs to configure all the disbursement transactions to have ‘Run Workflow’ executed.
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=parag.mirkar%40gmail.com&password=New%401okta&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/transaciton/disbursement
SendMessageToExternalSystem.REST.RequestType=POST
N/A
Please note that any transaction records that fail to process during Run Transaction Workflow will be left in Pending Status. This will result in failing the Run Transaction workflow batch job. Those failures will need to be investigated by ALIP Production support.
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 | Create a Disbursement Transaction and have it processed or reversed or recreated. | 1 | Success | Informational | Once the transactions are processed, and after the Run Transaction 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 | Create a Disbursement Transaction in an incomplete or failed or non processed state. | 1 | Success | Informational | No event will be sent out. Once the transaction is completed and processed, 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 | Transactiondisbursementevent posting to the external service was not successful due to the external system being unreachable (for cases where the external system’s webservice uses REST OAuth2) | N/A | Connectivity Error | N/A | |
| #3 | Transactiondisbursementevent posting to the external service was not successful due to the token generation failing (for cases where the external system’s webservice uses REST OAuth2) | N/A | Authentication Error | N/A |