This Interface provides the ability to get either Face Amount or Premium Amount for a given payment frequency based on Type of Calculation set in the request.The API makes seperate outbound calls for each request based on type of calculation.The client web service details would be same for Face/Premium calls. ALIP creates a request in ACORD format, send it to external client system and process the ACORD response back to ALIP canonical.
Based on “Type of Calculation” set in the incoming request the interface determines if the request is for “Face Amount” or “Premium Amount”
If the request is processed successfully, API returns Face or Premium Amount returned in the success response from the external system.
If the request fails, this API returns appropriate error or failure message in the response
This Interface is configured for product type Universal Life, Whole Life, Term Life in ALIP and Fully Underwritten Application Types.
| TR ID# | Technical Requirements |
| TR1 | ACORD Tx 111 “Illustration Submission transaction to=111” is used to retrive the Face/Premium Amount from the external system.ALIP connects to external service via REST or SOAP using BASIC AUTH. |
| TR2 | ACORDv2.39 is used to communicate with the external system. |
| TR3 | The interface converts ALIP xml sent by Business Configuration to ACORD XML format and post to the external system |
| TR4 | The external client service url can be configured in properties file |
| TR5 | In case of successful webservice call, the ALIP interface converts the returned ACORD Response to ALIP xml format and send it back to the calling Business Configuration. |
| TR6 | The failure scenarios are as given below -HTTP_STATUS_200 with TXLife/TXLifeResponse/TransResult/ResultCode = “5”.This is a business error, returned from the external system.ALIP interface will capture the Error Message from the TXLife/TXLifeResponse/TransResult/ResultInfo/ResultInfoDesc XML path in the Response and send it to the calling Business Rules in ALIP.HTTP_STATUS_4XX: Inteface captures the error message from ‘error.message’ from the error response and sends it to the calling Business Rules in ALIP.HTTP_STATUS_5XX: ALIP server will automatically retry the REST Service 3 times. Post that, ALIP will capture the error message from error response and send it to the calling Business Rules in ALIP.XSD Validation: ALIP server will validate the response against xsd and if failed will capture the reason of failure.The corresponding Error is logged as an Integration Failure and the message is saved in the Integration Failure logging table. |
| BR ID# | Business Requirements | Interface Design Traceability | Test Case Traceability |
| BR1 | The interface can be pluged in ALIP business configuration as per client requirements with appropriate triggers to call the API.(Refer Section 4)Example:- Application Entry process. | ||
| BR2 | Based on Type Of Calculation in the input request the API will either receive Premium amount or Face amount in response from client web service. | ||
| BR3 | The external webservice will respond with calculated single Face or Premium Amount value based on the Business rule call during Business process.If look up table is enabled for single face then this interface call external system to calculate single face amount.If look up table is enabled for premium amount then this interface call external system to calculate premium amount. | ||
| BR4 | The webservice response received with HTTP_STATUS_200 and ResultCode = “1” and “2” is considered as Integration Success. The ResultInfoDesc content of the response in case of ResultCode = “2”, is passed to the calling Business Rules in ALIP |
None
Two different URI Mock services are used to retrieve Face or Premium Amount for testing purpose, this can be replaced with live client services. Client services should follow the same request/response structure as to use the interface out of box.
The interface does not do any business validations for data being sent and received. Interface performs only XSD validation for the request/response sent and received from external system.
The interface is expected to receive entire ALIP Application data in the canonical format when triggered from ALIP Business Process.
This interface does not persist Face or Premium Amount value in ALIP. Client Business process is responsible to process the data further.
The interface expects single FaceAmount or PremiumAmount in response from the client service.
The OLife block as part of Response block is ignored by the interface and only TransResult and IllustrationResult-Vector block is consumed in response.
Two different external client webservice configured urls are used to retrieve the Face / Premium Amount , the Type Of Calculation in the incoming request set from ALIP Business trigger is used for mapping ALIP to ACORD.
For REST based external service “Content-Type” of response should be part of header information.
Example: application/xml , application/json etc.
If content type is not set in the header it is defaulted to application/json.
Currently this interface Business trigger is configured for Term Life, Whole Life, Universal Life -Fully Underwritten Product for Integration Test. This interface can be extended to custom client products.
If there is a need to send additional Riders/Relations and products in the request, then clients have to enhance/customize the interface.
Two different URI Mock service are be used to generate Face or Premium Amount for testing purpose, this can be later replaced with client specific service. Client service should follow the same request/response structure as of mock to use the interface out of box
The details of the Response Data elements are provided in above embedded XLS.
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The Interface call was successful with Face Amount being returned in the output. | 200 | Success | HTTP STATUS 200 | Integration History shows a record with Success status. The response messgage is described in section 3.1.11 Sample Response |
| #2 | The Interface call was successful with Face Amount and Additional Information returned in the output. | 200 | Success | HTTP STATUS 200 | Integration History shows a record with Success status. The response messgage as described in section 3.1.11 Sample Response |
| #3 | The Interface call was successful with Premium Amount being returned in the output. | 200 | Success | HTTP STATUS 200 | Integration History shows a record with Success status. The response messgage as described in section 3.1.11 Sample Response |
| #4 | The Interface call was successful with Premium Amount and Additional Information returned in the output. | 200 | Success | HTTP STATUS 200 | Integration History shows a record with Success status. The response messgage is described in section 3.1.11 Sample Response |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Generic System Failure due to technical errors. | 100 | Internal Error | Fatal | |
| #2 | XSD validation failure or field level mandatory failure or allowable value check failure or value is not valid. | 100 | XSD Validation Error | Failure | |
| #3 | The Interface call was NOT successful because Validation Message returned in the output | 200 | Failure | HTTP STATUS 200 | Integration History shows a record with Failed status.The response messgage is described in section 3.1.11 Error Response |
| #4 | The Interface call was NOT successful because of bad request sent to the external Web Service API. | 400 | Bad Request | HTTP STATUS 400 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #5 | The Interface call was NOT successful because of Invalid Client exception occurred in the REST Service API. | 401 | Invalid Client | HTTP STATUS 401 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #6 | The Interface call was NOT successful because of Not Found exception at the REST API end. | 404 | Not Found | HTTP STATUS 404 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #7 | The Interface call was NOT successful because invoked Method is Not Allowed in the REST Service API. | 405 | Method Not Allowed | HTTP STATUS 405 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #8 | The Interface call was NOT successful because Request is not acceptable by the REST Service API. | 406 | Request Not Acceptable | HTTP STATUS 406 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #9 | The Interface call was NOT successful because of unsupported mediatype sent in the request. | 415 | Unsupported media Type | HTTP STATUS 415 | Integration History shows a record with Failed status. The response messgage is described in section 3.1.11 Error Response |
| #10 | The Interface call was NOT successful because of Internal Server Error of the server which is hosting the REST Service API. | 500 | Internal Server Error | HTTP STATUS 500 | ALIP interface makes 3 Retry attempts and post that Integration Failure is logged in ALIP and the Integration History shows Failed status. The response messgage is described in section 3.1.11 Error Response |