This Interface will provide the ability for ALIP UI to search for the client/party against an external Client management system for various client roles. ALIP Business configuration can invoke this search on any type of client role and define search parameters dynamically. The interface will send the search parameters to the external system per the input provided by business configuration. In the absence of search parameters from business configuration, the interface will invoke the search with default parameters.
This interface in ALIP will be invoked by Business Configuration Triggers and clients can define the ALIP UI search parameters per their need. Currently the interface exposed from Interface Exchange will not have any default ALIP UI configuration to test. Interface Exchange will test this via Rule Group test functionality in ALIP by setting the required search parameters in the trigger block.
This Interface is an outbound call and is independent of any product type in ALIP.
The Interface is implemented for the following role types:
Physician Search
The interface will invoke search against external system to search for all physicians based on the search criteria provided in the input request
Advisor Search
IAR (Invest Advisor Representative) /RIA (Registered Invest Advisor) Client Roles, search will be performed based on the CRD Number provided in the search parameters. This interface will send the CRD Number of RIA or IAR to look up these clients in the external system.
Upon getting the response from external system, the search results will be returned to the calling Business process to be presented on the screens for the user to make a selection.
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 Tx 301 “CRD Search transaction tc=301” shall be used to communicate with the external system. |
| TR2 | The interface provides the capability to execute a Rule group to perform any additional validations, during the interface execution if the input request in the trigger blockhas‘RequestEnrichmentValidationRule’ flag set to true. If there are any validation errors during the execution of this rule, interface willadd an error blockand return to the calling business process without invoking the external service.If there are no validation errors, the interface will continue further processing and invoke the external service. |
| TR3 | Save the Trigger details like search type into MessageHeader since we need this details during Response Processing. |
| TR4 | The interface willconvert the input ALIP xml sent by the Business Configuration to ACORD XML format as defined by the ALIP Party Search interface schema definition. Request Prepration XSL should prepare the ACORD Criteria Expression dynamically. |
| TR5 | The external system’s endpointURL to be used to perform the search should be configurable in a properties file. There should be only one endpoint url for all type of party search. |
| TR6 | The interface would call the External service to get the search results. |
| TR7 | The Interface will perform the XSD validation to check mandatory fields Last name and Full name on ACORD response received from external system. |
| TR8 | After successful XSD validation, the response will be transformed to ALIP’s canonical XML format. |
| TR9 | The interface provides the capability to execute a Rule group to perform any additional validations on the response received from the external system if ‘ResponseEnrichmentValidationRule’ flag is set to true. If there are any validation errors during the execution of this rule, interface willadd an error blockand return to the calling business process along with the search results received from the external system. ALIP Client business configuration will leverage the error block to take further action related to user display.If there are no validation errors, the interface will return the search results to the calling business process. |
| BR ID# | Business Requirements |
| BR1 | The Search Request willindicate ifthe call is originating from a ‘Pre-Issue Application’ or a ‘Post Issue Contract’, to enable the external system to perform any additional logic if needed in each of these scenarios. |
| BR2 | Interface will check for the mandatory fields in the response from external system for missing/empty tags (like Last Name, full name). If any values are missing, the interface will update the response to indicate mandatory data is missing.This transformed response is returned to the calling Business Configuration Rule. Business Configuration will generate the appropriate error message as per the client business requirements. |
| BR3 | The following additional processing is performed for Advisor Search responses received from the external system - The IAR Search Response is expected to have a ‘Relation’ block present which will specify a valid relationship between the IAR & RIA Client sent in IAR Search Request.Populate RelationshipValidFlag Tag as True if relationship block as per below XPATH exists between RIA and IAR./TXLife/TXLifeResponse/OLifE/Relation[OriginatingObjectID=RIA_Party_ID and RelatedObjectID=IAR_Party_ID and RelationRoleCode/@tc=10]If no RIA party block found or no relationship block foundas above then interface will set RelationshipValidFlag Tag toFalse, BC canuse this flag to perform any additional processing like generating a pre-issue requirement as per the client business requirements. |
Following is the high-level description of Party Searchintegration process:
ALIP business configuration rules will call the Party Search API using ALIP’s Invoke Integration Service.
The interface will invoke the Request enrichment rules if “RequestEnrichmentValidationRule” is set to ‘Yes’. Enrichment rule is supposed to perform validation on search parameters. If no error comes, interface will further transform the request xml from ALIP’s canonical XML format to ACORD XML format. If rule fails or error occurred, response will be send back to the invoking Business Configuration.
If “RequestEnrichmentValidationRule” is not set or set to ‘No’, interface will move to the next step in the flow.
The interface will transform the request xml from ALIP’s canonical XML format to ACORD XML format.
The PartySearch external service will be invoked with the ACORD message as the payload. Interface will be build and tested for both REST and SOAP.
The received Response from the external service will undergo XSD validation for correct XML structure. If the XSD validation fails or no results were returned or too many results returned, an error message will be returned to the triggering Business Configuration.
The received response will be transformed to convert the response message from ACORD XML format to ALIP’s canonical XML format.
Interface will invoke the Response enrichment rules if “ResponseEnrichmentRuleValidation” is set to ‘Yes’ and then the response will be returned to the invoking Business Configuration.
Any failure/error from the rule will be sent in alip xml to the invoking Business Configuration along with the search results.
if “ResponseEnrichmentRuleValidation” is not set or is set to ‘No’, search results will be returned to the invoking Business Configuration.
None
The interface will not do any business validations for data being sent and received from triggering business rules.
All the search criteria needs to be set by the triggering business rules in the trigger blocks as per the Data mapping sheet attached.
The communication between ALIP and external outboundservice will be ACORD v2.36XML/JSONmessage format.
This interface is not going to insert or update any records in ALIP core database, except the standard integration tracking tables.
Interface will perform search against the external system and return the results to the calling business process, client data save is not in the scope of this interface.
ALIP Business Configuration Rules will drive the UI functioningbased on the response data returned by the external service.
The interface would invoke the same end point URL for all the party search type.
Connectivity details to the external system are mentioned below.
The connection type for REST/SOAP is configurable for Accenture Dev team, and it will be a one time setting. Allowed values are REST and SOAP. Connection Type is set as below:
PartySearch.ExternalServiceType=REST
OR
PartySearch.ExternalServiceType=SOAP
In order to support SOAP connection SOAP Action and URL of external system is required. It is set as below in process-server.properties file.
PartySearch.SOAP.Auth=None
PartySearch.SOAP.Url
PartySearch.SOAP.Action
REST connection supports both XML and JSON content type with POST request. REST connection details are required as below. {IntegrationPoint}.REST.{RequiredDetails}.
PartySearch.REST.AuthReqd=Yes
PartySearch.REST.AuthType=OAuth
PartySearch.REST.ContentType=XML or JSON
PartySearch.REST.URL
PartySearch.REST.RequestType=POST
Oauth2Token.AuthParams=dfsfdhhkkj:gygyuujjlkkj (ClientSecretID:Pwd)
Oauth2Token.Url=http://vm-int1.navisys.com:8084/token
In case connection to the external REST and SOAP service fails API will retry to connect to service. This setting is also configurable as below. Default setting will be 3 retries.
SOAPConfigurableRetryCount=3
SOAPConfigurableBackOffPeriod=0
RESTConfigurableRetryCount=3
RESTConfigurableBackOffPeriod=0
API provides the abitity to connect to extetrnal system using namespace. If namespace is required to connect to external system below setting is required. If this setting is provided API will apply it to the external service request and remove the same once the external service response is received before passing it for further processing.
PartySearch.Namespace
The details of the Request and Response Data elements are provided in the embedded XLS.
Please refer to the below mapping sheet for the expected inputs from the invoking Business Configuration and expected output format from the interface.
The following are the default configuration provided out of IX for the Request and Response enrichment on the Advisor Party Search. Client teams have to define the appropriate validations as needed in to these Rule Groups.
Rule Category: INT – Party Search Request Enrichment
Rule Group: Validate Request Parameters
Rule: Validate CRD number
If CRD number in the request is blank, rule will set the error message “CRD Number can not be empty”.
Rule Category: INT – Party Search Response Enrichment
Rule Group: Validate Response Parameters
Rule: Validate Maximum number of records
If response has more than one client returned in the search result, rule will set the error message “Search result exceeded.”.
For example- below two business requirements to set error message if more than one search results found will be handled through response enrichment validation rules.
| RIA CRD Search:CRD Search for RIA Client Role is based on the CRD number of the RIA entered as a Search parameter.External system will send one RIA detail in response based on requested RIA’s CRD number.External system will send Error message if no matching RIA found.Ideally, one RIA result is expected in search response but if there are more than one RIA results present, then Response Enrichment Validation rulesshould mark this as Error. Integration would return all the results received from external system. Response enrichment validationrule has to validate the response result. |
| IAR CRD Search:CRD Search for IARClient Role is based on the CRD number of the IARenteredas well as RIA’s CRD number as a Search parameter.External system will send one IAR detail in response based on requested IAR’s CRD number and RIA’s CRD number.External system will send Error message if no matching IAR found.Ideally, one IAR result is expected in search response but if there are more than one IAR results present, then Response enrichment validation rule will mark this as Error. Integration would return all the results received from external system. Response enrichment rule has to validate the response result. |
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The PartySearch interface executed successfully. | 1 | Success | Informational | Multiple Party blocks for each Party details returned in success response |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Generic System Failure due to technical errors. | 500 | Internal Server Error | Fatal | 500 |
| #2 | XSD validation failure or field level mandatory failure or allowable value check failure | 200 | XSD Validation Error | Failure | PARTY_SEARCH_RESPONSE_XSD_FAILURE |
| #3 | Failure due to invalid request sent to REST Service API. | 400 | Bad Request | HTTP STATUS 400 | 400 |
| #4 | Not found failure sent by the REST Service API. | 404 | Not Found | HTTP STATUS 404 | 404 |
| #5 | Unknown method/ Method not allowed failure sent by the REST Service API | 405 | Method Not Allowed | HTTP STATUS 405 | 405 |
| #6 | Not Acceptable Failure returned by the REST Service API. | 406 | Not Acceptable | HTTP STATUS 406 | 406 |
| #7 | Unsupported Media Type failure returned by the REST Service API. | 415 | Unsupported Media Type | HTTP STATUS 415 | 415 |
| Timeout Error | NA | Timeout error | fatal | PARTY_SEARCH_CALL_FAILED |
|
| No Search results returned | 1 | No Search results returned | Informational | NO_SEARCH_RESULT |