Accenture Life Insurance Platform (ALIP) will be enabled with an Interface to communicate with Informatica based Address Standardization and Validation API to validate and standardize the Address(es) entered by the users in the ALIP system. Informatica Address Verification is an online address validation solution to verify and validate United States and international postal addresses in real time. This interface can potentially be connected to any external service, provided the message format complies with the ALIP exposed schema.
This interface when invoked from business configuration or code in ALIP, will take the user entered Address(es) information as-is and send it to the Address Validation and Standardization API and wait for the response. The Response could be Errors associated with the Address sent or a standardized and verified address. This Interface upon receiving the Error or the standardized and validated Address, will return the response as-is to the calling Business process or code in ALIP, so that it can be appropriately handled for user display.
Business rules or code configuration can be done by client teams to invoke this interface from any ALIP UI page, which takes single or multiple Address as Input. Interface expects to receive a specific ALIP xml as input, which is defined in section 3.1.4.
Currently the interface exposed from Interface Exchange will not have any default ALIP UI configuration to test. Interface Exchange will test this via Business Configuration Rule Group test functionality in ALIP by setting the required details in the trigger block.
| TR ID# | Technical Requirements |
| TR1 | This interface enables only a “SINGLE_LINE” address format in the external service request.For single-line format, address is entered in the |
| TR2 | ALIP Integration can invoke Informatica based Address Verification and Standardization Interface through REST or SOAP mechanism. |
| TR3 | If SOAP or REST with basic auth is used to connect to external system, the basic auth credentials will remain same across all other SOAP/REST services using basic auth for that client. The authentication part is configurable based on client’s requirement, but currently this interface is tested with Basic Auth. |
| BR ID# | Business Requirements |
| BR1 | This interface allows connection to external Informatica request format based Address Standardization API as per business requirements listed below. Interface can also connect to any other Address Standardization external system which follows the same request/response structure. |
| BR2 | Within ALIP, this interface will be triggered by Business Configuration or code to standardize and validate the user entered address(es). This interface can be triggered from any page of ALIP UI which accepts single or multiple address as input, provided the ALIP XML follows the business configuration requirement mentioned in 3.1.4. |
| BR3 | Below is the end to end flow for Address Standardization API.This interface will use the ALIP addresses provided by the Business configuration or code and translate it to “SINGLE_LINE_FORMAT” request before sending it to Address Standardization API. Single line address format sends the address details in a single data element |
| BR4 | Below steps will be followed while converting input ALIP XML to Informatica based Request.The request prepared will use the Process mode value of “Batch” in the outgoing request from ALIP system to the external service. This is expected to be utilized by the external API to understand that request can have more than one address to be validated, standardized and returned. In the Request message ALIP interface will send two lines for each Address. One Line will be for the ISO-Alpha 3 Country Code and other line will be for the Address information. The address will be sent in the below format in the Request for both USA and Non-USA address. Below mentioned format will be configurable through business configuration. Interface will call a rule group to create below concatenated string from the input address details. “Line1 Line2 Line3; City State Zip”This interface will send user information in the Request. The value of the Login and Password will be managed in the properties file allowing to be updated as needed through process-server.properties. |
| BR5 | This interface will be able to receive more than one Address from the calling system(Business Configuration or Code) in ALIP and send those multiple addresses to external system in one single Request. |
| BR6 | This interface will wait for the response from external API after sending the Request. Despite sending multiple addresses in the input in a single request, this interface expects to receive only one response from external system. This interface will not expect to receive more than one response for one request and if the Request has had more than one address with it, then it is expected that the Single response coming back from Address Standardization API will have response to all those addresses but not just one or partial |
| BR7 | This interface will consider Integration failure for the below scenarios:If the external system connection is SOAP based and there is any error while connecting to external system, an Integration Failure will be created, and an error block with error message will be sent back to the calling Business process.If the external system connection is REST based, Integration failure will be created for Server (5xx series) or Client (4xx series) Errors.XSD Failures.If the Process Status for any one of the address in response starts with ‘I’, ‘N’, ‘W’, an error block will be added by Interface to that address. Even if one error block is present in response ALIP XML, it will be considered as Integration failure. |
| BR8 | In all business failures, Integration will log failure in Integration History along with converting the response to ALIP XML. Business configuration or code will be responsible check the error block and generate appropriate error message on UIOn receiving response from external system, Interface will check If the number of Addresses in the Response matches the number of Addresses present in the Request. If this condition is not met interface will add an error block in the ALIP XML, Business Configuration or code will use it to generate an error on ALIP UI. Even if one resulting Address has Process Status starting with ‘I’, ‘N’, ‘W’ (failure code) then Interface will add an error block to that specific address along with appropriate message(Refer Section 3.1.11 Process Status Table). ALIP business configuration or code will use this ALIP Response and generate an error on ALIP UI.Starting with ‘I’ indicates the address received in the Request is incorrect.Starting with ‘N’ indicates the address received in the Request is Not Processed.Starting with ‘W’ indicates Web Service Error.If the response does not contain any process status, Interface will add an appropriate error message(Refer Section 3.1.11 Process Status Table). ALIP business configuration will use this ALIP Response and generate an error on ALIP UI. |
| BR9 | If the address in input request is corrected or Verified by the external Address Standardization API , it returns Process status starting with ‘C’ indicating that the address in input request is corrected and starting with ‘V’ indicating that address in input request is verified. This interface will convert the incoming response to ALIP XML and pass it to calling business configuration. Business configuration will be responsible for the display of standardized address on ALIP UI and saving the response in ALIP DB. |
| BR10 | For multiple address scenario the Addresses returned in the Response by Address Standardization API should be in the same order of the Request that was sent. Even if there is no Address found, Address Standardization API will not skip the Address block so that the order is maintained in the Response. |
| BR11 | In case of ALIP response with partial success, e.g. A scenario where 3 addresses were passed in input and out of 3 addresses in response, only one contains Process Status starting with ‘C’ or ‘V’, and Interface has added error block for remaining 2 addresses due to any business failure. Business configuration or code will save and display the standardized address for address having Process Status starting with ‘C’ or ‘V’, it will also show error corresponding to remaining 2 addresses on ALIP UI. Integration History will log failure in this case. This scenario is not yet tested and can be tested only after Business Configuration or code integration. |
| BR12 |
In order to test this interface end to end, client teams will need to perform business or code configuration at their end to trigger the interface and to handle the response. Below is the detail for calling this interface.
If the address collected on the ALIP UI is a USA or non-USA address, Interface expects below information from calling process(Business Configuration or Code):
Address details as
If the address collected on the front end is a Non-USA address, then the ALIP will have Country, Line1, Line 2, Line 3 in separate fields and then the City, State and Zip in a single field. Below is a sample on how a Non-USA Address is entered in ALIP screens.
Below snippet shows how the ALIP XML will look like for Non - USA address.
Calling process will use above ALIP XML and provide below details to Interface for Non-USA address:
Address details as
Refer to below mapping sheet for the request elements interface expects as input from calling process and response elements it will send in response.
Request XML’s: Below are the sample Request ALIP XML’s which interface expects to receive from calling process.
Response XML’s: Below are sample response ALIP XML’s which interface will return to BC.
Below is the Business Configuration document for reference.
The following is the high-level description of the Address Validation process flow–
ALIP Business rules or code will trigger the Address Validation Integration point “ADDRESS_STANDARDIZATION” from ALIP UI. Integration expects the incoming request follows the request format mentioned in section 3.1.4 in order to process it.
Integration will pick up the Address Validation and Standardization Request.
Appropriate logging will be done in Integration History for the request and response. No unique Identifier will be used for logging. RefType will be “Client” and RefNum will be “ALIPClientID” for logging. If ALIP Client ID is not present in Trigger block while calling interface, Ref num will be set as -1.
Interface will call a rule Group category named “INT – Address Standardization Request Enrichment”, the rules from this category will create AddressComplete tag which is required by external system by concatenating the incoming address in below format for both USA and NON-USA address. Details are present in Section 3.1.4
Future clients can use above Category to add new rule group for any other required request preprocessing.
Interface will convert the output of above rule group to Informatica based API’s expected request format and pass it to the Address Standardization API after request xsd validation.
Once the response from external system is received, and response XSD validation is successful Interface will convert it to ALIP XML in the format mentioned in 3.1.4. For all failures Interface will create an error block in the response ALIP XML. Detailed samples are present in Section 3.1.4
Before passing the converted ALIP XML to calling process, Interface will call a category named “INT – Address Standardization Response Enrichment”. Rule group of this category can perform any required processing on response for future clients. As per current configuration this rule group is not performing any action.
Integration History will show success or failure based on the ALIP Response.
Calling process will be responsible to generate the error on UI based on error block in response ALIP XML. If no error block is present in response ALIP XML Calling process will display the standardized address along with saving its value in DB. Process Status details are mentioned in section 3.1.11 Process Status Table which will be used by Interface to populate Error Message based on Process Status.
Address Standardization API will perform Address validation and standardization externally. The standardized address will be displayed on ALIP UI.
Interface will not do any business validations for data being sent and received. Business workflow or code is responsible to take care of these validations and to send all the required request data expected by this interface.
ALIP Business Configuration processes or code will parse the Response provided by this API into appropriate format as per the Country of the Address present in the standardized and Validated Address Response.
External Address Standardization API will be able to return multiple addresses validated and standardized if multiple address is sent in the request.
It is assumed that the Address Standardization API will be able to detect the City, State even if those have White spaces in between i.e. “NEW YORK” when provided as a City value.
This interface expects, that the Address standardization API Response data elements remain consistent for all Countries so the mapping between external tags and ALIP tags won’t change based on Countries.
This interface will be tested with Mock Service if live service is not available.
Namespace part is configurable from property files and can be handled at client’s end for SOAP connection. If mentioned in property file, interface will append namespace to the request before connecting to Mock Service and remove the namespace before response xsd validation. If no namespace is specified, Interface will connect to external system without any namespace.
This interface expects ALIP XML as input in a specific format. Client teams will be responsible for business or code configuration at their end to pass the same XML as expected by interface. Similarly, the ALIP format in which the interface returns response to calling process is also defined. Refer to section 3.1.4 for details.
This interface cannot be tested end to end until relevant pieces of Business or Code Configuration is implemented. Business configuration will be handled at client’s end.
| Success | Success Scenario Description | Response expected from External System | Additional Comments |
| #1 | All Addresses present in the Request are successfully processed by External system. | In this case, the received Response will have Process Status starting with “V” or “C”. | 1) The Integration History will show Success status. 2) Interface will check the ProcessStatus and will not populate any error block in response ALIP XML.3) Business configuration or code will consume the ALIP XML and display the standardized data on UI . It will also save the Address details returned in response in ALIP DB.4) Process status will be saved in NV tableNote: Step 3 and 4 can only be tested after E2E integration of interface with calling process(BC or Code). Interface testing is limited to step 1 and 2. |
| Error | Error Conditions | Response expected from External System | Additional Details |
| #1 | An invalid Address is sent in the Request from ALIP to External System | External System will send Process Status as starting with ‘I’. | Integration History will show failure as it is business failure.Integration will read the Process Status value and add an error block in response ALIP XML.Business configuration or code will show corresponding error on UI and save Process Status in NV details table.Refer Process Status Table to check the Error Message associated with this statusNote: Step 3 and 4 can only be tested after E2E integration of interface with calling process(BC or Code). Interface testing is limited to step 1 and 2. Also from interface end there is no logic to check whether the address is invalid(e.g. Line 1 missing etc.). Interface assumes that live service will take care it. From mock service end any address can have Process Status as ‘I’. |
| #2 | An address was sent to request, but External System was not able to process it. | External System will send Process Status starting with ‘N’. | Integration History will show failure as it is business failure. E.g. Refer Process Status Table to check the Error Message associated with this statusNote: Step 3 and 4 can only be tested after E2E integration of interface with calling process(BC or Code). Interface testing is limited to step 1 and 2. Also from interface end there is no logic to check whether the address is invalid(e.g. Line 1 missing etc.). Interface assumes that live service will take care it. From mock service end any address can have Process Status as ‘N’. |
| #3 | An address was sent to request, but External System returned Time out, Not Allowed etc. | External System will send Process Status starting with ‘W’. | Integration History will show failure as it is business failure. E.g. |
| #4 | Technical Error Occurred while connecting to external system | External System will send status code as 500 or 400 | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. Refer section 3.1.4 for error sample.BC/code will display the error on ALIP UI |
| #5 | XSD Error Occurred. | External System will send response which does not complies to schema. | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. Refer section 3.1.4 for error sample.BC/code will display the error on ALIP UI |
| #6 | No Process Status is present in External System Response | External System will send a response with no Process Status | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. Refer section 3.1.4 for error sample.BC/code will display the error on ALIP UI |
| #7 | Number of Addresses in the Response does not match the number of Addresses present in the Request. | External System does not send all addresses in response | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. Refer section 3.1.4 for error sample.BC/code will display the error on ALIP UI |
| #8 | Any of the mandatory tags is missing in external service response. | External System does not send all mandatory tags in response | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. The error message will be as “One of the mandatory Address Element is missing in response.”BC/code will display the error on ALIP UI |
| #9 | Invalid Process status(anything apart from supported Process status as mentioned in section 3.1.10) is sent in external service response. | External System sends invalid process status in response | Integration History will show failure.ALIP XML with error details will be sent to Business configuration or code by Interface. The error message will be as “Invalid Process Status code returned in response.”BC/code will display the error on ALIP UI |
Below table lists the supported Process Status values along with the Error Description which interface will populate.
Process Status Table
| S. No. | Process Status Value | Detail | Error Message Added by Interface to Response ALIP XML |
| #1 | Starting with “C” or ‘V’ | Indicates the address received in the Request is correct and verified. | NA |
| #2 | Starting with ‘I’ | Indicates the address received in the Request is incorrect. | Request is Incorrect. |
| #3 | Starting with ‘N’ | Indicates the address received in the Request is Not Processed. | External System is not able to process the request. |
| #4 | Starting with ‘W’ | They will correspond to errors related to Time out, Not Allowed etc. | Web Service Error Occurred while processing the request |
| #5 | Process Status is not Present | NA | If the status message is populated by external system, interface will use the same message to display error. E.g. “Authentication not Successful”. If status message is not populated Interface will use error message “Request is not successfully processed”. |
An average response time of 3 seconds is assumed for this interface. Assumption is external system will also return the response within 3 secs.
In order to use the interface out of box, Steps mentioned in attached documents should be followed.