For Client implementation, ALIP is required to send Event Notifications to Client endpoint whenever an existing Suspense is updated from within the ALIP user screens. Based on the success or failure of message receival, endpoint will return a Success or Failure code. Client endpoint will internally redirect event notifications to desired systems.
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 will be used to communicate. |
| TR2 | ACORD Tx 1217 “Activity Transmittal tc=1217” will be used for sending Event Notifications for Suspense Correction Request. |
| TR3 | ALIP will be Integrating with Client Service bus via Azure functions endpoint using REST/JSON Messaging for transmitting these Suspense Correction Triggers. |
| TR4 | In case of Successful transmittal of event, Client Azure functions endpoint will respond with a code of 200. |
| TR5 | A new Communication header will be created at the Suspense External Number level for each Message being sent out from ALIP to Client functions endpoint pointing to the new Integration point i.e., ‘Suspense Correction Event’. |
| TR6 | Communication header will be updated to Success or Failure per the Integration processing. If the Integration has failed, an Integration Failure is created in the system. |
| TR7 | Any Integration Failures associated with this Integration point should be retriable up to a maximum of 3 times using the Integration Failure Retry processing framework through a new Batch Job. |
| TR8 | Client endpoint will be configured to post messages to appropriate custom topic on service bus that handles these Suspense Correction Notification Events. |
| TR9 | With each outgoing message, ALIP will have to populate and send below REST Fields so functions endpoint can make use of these headers and use to associate them with the data posted to endpoint.TopicIdSubjecteventTypeeventDatedataVersiondata (this wrapper field populated with TxLifeRequest )Each Field’s details are part of the Data Mapping sheet. |
| TR10 | API will send ‘x-functions-key’ () into Request HTTP Header like Basic Authentication. e.g. x-functions-key:x-functions-key_value(shared by client team) |
| BR ID# | Business Requirements |
| BR1 | In ALIP, Business Configuration Rules will trigger this Interface by capturing updates on the below listed fields for an existing Suspense Record via ALIP User Screens.Contract NumberDeposit MethodGross Amount |
| BR2 | Business configuration process will invoke the Suspense Correction Notifications as soon as the corresponding event is saved. For example, on a Suspense Record, the Deposit Method is updated, without having to wait till the corresponding Suspense is Resubmitted to rules, as soon as the Event of Suspense Deposit Method change is detected, Suspense Correction Notification will be Triggered so that the Interface will be able to send those Notifications out to Client functions endpoint. |
| BR3 | If a Suspense record in ALIP does not have a Policy Number associated, this Interface in ALIP will still provide all the data elements as listed in section 3.13.8 below with their default/blank values. |
Any time an update occurs on the below listed fields for an existing Suspense from within ALIP user screens, Business Rules in ALIP will Triggers this Interface.
Contract Number
Deposit Method
Gross Amount
ALIP’s Core API will receive the posted message and process it per below steps.
For each invocation of this interface, a new communication header will be created at the Received Suspense External Number level for the “Suspense Correction Event” Integration point.
This interface will extract relevant Event information and Event Notification associated data and prepare an ACORD message to be sent to external system.
For Client implementation, below are details that will be sent out with each Suspense Correction Notification Message:
Suspense External Number
Policy Number
Deposit Method
Line of Business
Issuing Company
Gross Amount
Received Date
Upon getting needed data for the Event, this interface will send it over to Client functions endpoint in the REST/JSON format and wait for a Response.
After sending a request to Client functions endpoint, this interface will process the response per below scenarios.
If there is no response received from Client functions endpoint, then this interface considers it as a Timeout failure leading the Integration to be considered as a Failure. This will further create an Integration Failure in the ALIP system.
If the response is received with the response code other than 200, then this interface considers the integration as a Failure and updates communication header in ALIP to a Failure.
If a response is received with a response code of 200, then this interface considers the integration to be Successful and updates communication header to success and completes event notification process.
N/A
N/A
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Successfully sent Event Notification to Client functions endpoint | 1 | Success | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =1 |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Timeout | None | No Response received from Client functions endpoint | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5 |
| Failure | Any code other than 200 | Client functions endpoint returned a failure code to receive message |