This interface provides the ability to publish a message 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 Post Submit and Status update integrations only.
As part of the New Business Post Submit and Status Update process, ALIP will receive a request, in ACORD XML format, from an external system. ALIP will process the request, update the information in ALIP and send back a response in the ACORD XML format to external systems. This interface will publish an event message onto an event queue, indicating the application state change, that the external system can listen to and consume.
| TR ID# | Technical Requirements |
| TR1 | ACORD v2.3 transaction type 1217 will be used to communicate between ALIP and external systems |
| TR2 | ALIP will trigger the event publishing as per the required configuration (current configuration – postsubmit and status update). |
| TR3 | ALIP will receive the entire application object with associated information, using which it will generate a message in the ACORD 1217 format and post it onto the event queue. |
| TR4 | The objects under the holding of the activity transaction will be in the format defined for each object type. |
| TR5 | Any type of failure in processing the received Publish Event request will be created as an Integration Failure in ALIP. |
| BR ID# | Business Requirements |
| BR1 | ALIP needs to publish an event to the ESB via the ALIP Event Queue for changes that occur in the ALIP system via integration (or front-end) |
| BR2 | This event publishing will be supported for new business trigger points viz. post submit and status update integrations. These will be extensible for use in the equivalent front-end processing as well. |
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 event publishing.
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 handle any other validation failure.
In case of any validation failures, the message will be sent to the error channel. for this interface, 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 handle any other validation failure. In case of any validation failures, the message will be sent to the error channel.
None
The complete application object will be published as part of the event.
The event information itself is not logged to ALIP core database.
No Message will be posted from the cycle or batch processing for any changes in status or for any other events.
N/A
| Request Parameters | Description | Mandatory | Allowed values |
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The Publish Event call is successful and generates an event in the event queue for published events | 1 | Success | Informational |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | Publish Event was unsuccessful due to system errors. | 1 | Internal Error | Fatal | Any system error including any API errors |
| #3 | Publish Event was unsuccessful due to missing mandatory tags | 2 | Validation Error | Fatal | Mandatory tags such as object ID, object type will be checked for. |