This interface provides the ability to send outbound message to client downstream systems for changes that occur for a selected application within ALIP, via integration.
This Interface is applicable for all products in ALIP, and currently made available for Application Status update only.
ALIP business process will trigger 103 Outbound interface during the Application Status Change process, ALIP will receive a request, with Application Id, EventType and Source . The interface will Load the Application Details based on the Application Id and convert the ALIP request to 103 ACORD format which will be send to Downstream webservice. The downstream webservice will send an acknowledgement along with Response Elements on receiving the 103 Request successfully. ALIP will update the application data based on the response elements.
| TR ID# | Technical Requirements |
| TR1 | ACORD 2.36 format to be used to communicate to external Client web services.External Client Web Service will send back a status response to ALIP |
| TR3 | In the event of ALIP being unable to establish a connection with the Client Web service, it will retry 3 times and mark the response as failed if no response is received even after 3 retries. This retry count is configurable. The Failed status would be displayed on the ALIP Integration History page. |
| TR4 | ALIP Business process will trigger the interface for Application Status change only. Currently configured for Product Level Term , Simplified Issue |
| TR5 | Ability for client to configure the customize format for Request Type before making a external webservice. This is based on the client webservice pattern to accept the request format |
| TR7 | Ability for client to configure additional processing based on the acknowledgement response received from the webservice call. |
| TR8 | ALIP will save the TransrefGUID of the request with the requirement. Only the latest GUID per requirement will be saved. |
| BR ID# | Business Requirements |
| BR1 | ACORD 103 is used to communicate with client external webservice. |
| BR2 | ALIP Interface Exchange provides the ability to send Application data to client webservice to update client downstream systems. |
| BR3 | ALIP updates Application Data based on the response data received in response. |
| BR4 | For every Trigger type, the complete 103 will be sent (not just the trigger type data e.g. Owner data only for Owner Data Change). |
| BR5 | ALIP will save the TransrefGUID of the request with the requirement. Only the latest GUID per requirement will be saved. TransrefGUID needs to be saved to database for each request. |
| BR6 | If any case level requirement created for 103 outbound that will be marked as ‘Ordered’. Once the outbound 103 request handshake is successful, external service will send a synched successful acknowledgement. If the handshake failed, the requirement status will be not be changed. |
The attached Security Guidelines are adhered to by the interface:
| SR ID# | Security Requirements | Interface Design Traceability | Test Case Traceability |
| #1 | [IDD Section Reference] | [Test Case Reference from IDD] |
As part of making the integrations configurable, system run through below business rule groups and look up tables for processing the request. If/when there are any changes to what is being managed in these rule groups and look up tables, a configurator needs to change these as desired.
INT - Populate Base Coverage Rate Class: this rule group is designed to populate the Base Coverage details.
INT - Loop for Base Coverage: this rule group is designed to iterate the ‘INT - Populate Base Coverage Rate Class’ for every package.
INT - Populate Rider Information: this rule group is designed to populate the Rider and benefit Information.
INT - Loop for Rider Coverage: this rule group is designed to iterate the ‘INT - Populate Rider Information’ for every Rider.
INT - Loop for Benefit Coverage: this rule group is designed to iterate the ‘INT - Populate Rider Information’ for every Benefit.
INT Populate LifeCovOptType: this Lookup table is leveraged to populate Life Coverage Option details based on the request.
INT - Populate BaseOptionType: this Lookup table is leveraged to populate Base Option details based on the request.
INT - Populate LifeCovType: this Lookup table is leveraged to populate Life Coverage details based on the request.
INT - Populate TableRate: this Lookup table is leveraged to populate Table rate based on the request.
INT - Populate Duration: this Lookup table is leveraged to populate Duration based on the request.
INT - Populate UWClass: this Lookup table is leveraged to populate Underwriting class based on the request.
INT - Populate TobaccoPremium: this Lookup table is leveraged to populate Tobacco Premium based on the request.
The following is the high-level description of the 103 Outbound flow–
The workflow that triggers the event publishing, will include the appropriate business configuration to set up the event triggers and invoke the integration point.
A message would be posted to the ALIP request queue, from the workflow that needs to trigger the 103 Interface.
ALIP will transform the message to canonical format, and then will look for the event type, application ID for the publish event request. It will load any data that needs to be loaded from the database along with the user who updated the object and the timestamp when it was updated to ACORD format using appropriate XSLs.
It would the validate the XML with appropriate XSDs which will ensure that the mandatory elements are present in the XML, verify that the data in the XML, is as per the allowable values for the respective elements, and also handle any other validation failure. In case of any validation failures, the message will be sent to the error channel.
On successful xsd validation the interface will post the 103 ACORD message to Client Secured Webservice and receive acknowledgement along with response elements.
In the event of failure to hit the webservice call , the interface will retry for configurable number of times and log a failure message if it exceeds beyond the retry count.
On successful acknowledgement, interface will convert the response to ALIP canonical and update the ALIP data bases on response elements using ALIP API.
No Response is sent back from ALIP, on completion of the processing.
N/A
Interface supports SOAP/REST message to communicate with client webservice.
The client can override the communication method with end client based on the webservice consumption using the configurable plugin.
The ALIP Business Trigger scope is for Product Term Life, Simplified Issue. Client can configure for extended Products.
The current scope of interface is Application Status change and not for Active Contracts.
The details regarding the fields sent from ALIP and the corresponding tags in ACORD 103 and ACK message are maintained in the Mapping document attached further below.
Request Elements
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The 103 Outbound Interface will be Sucessfully Processed and the ALIP data updated sucessfully | 1 | Success | HTTP STATUS 200 |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The 103 Outbound Interface received invalid acknowledgement from webservice service | 100 | . | ||
| #2 | 103 Outbound was unsuccessful due to xsd validation failure | 2 | Validation Error | Fatal | |
| #3 | 103 Outbound was unsuccessful due to system errors. | 1 | Internal Error | Fatal | Any system error including any API errors |
| #4 | 103 Outbound was unsuccessful due invalid carriercode | 400 | Not-Found-Exception | Fatal | |
| #5 | 103 Outbound was unsuccessful due invalid service not available | 500 | Internal-Server-Error | Fatal |