Replacing AL3 with XML Download

Topics: AL3 to XML, Messages, Transaction Specification
Developer
Apr 5, 2016 at 4:44 PM
Edited Apr 5, 2016 at 7:36 PM
Is anyone doing work to replace AL3 with XML?
Any projects?
Any experiences?
How about Realtime?

FYI, we are currently doing PAS native download, realtime on demand, but nothing that is worth sharing. We are looking at the next iteration of download and would like to avoid the AL3 and IVANS path.

Our preference I think would be to use the same XML 2+ upload transaction, to reverse direction, in a resourceful manner.
Developer
Apr 20, 2016 at 11:01 AM
We've received several inquiries expressing interest in replacing AL3 with XML for policy download. This is the primary reason the XML 2.0 WG included FullImageNotify messages in the suite that survived the transition from 1.30 to 2.0.

Does anyone have any ideas about how we can make this a reality? Obviously, a carrier and an agency system need to agree to do it - but can we gain broader acceptance, and come up with a plan and a timeline?
Coordinator
Apr 20, 2016 at 3:16 PM
There are a couple of ways we could do this.
  1. Create a 2.0 Message using the Master Message and the cycle business purpose type code. These messages would have the request response and be defined via a transaction specification.
    1. ACTION ITEMS FOR THIS
      1. Choose current AL3 Message
      2. Refactor using XML 2.0 Master Message
      3. Create Cycle Business Purpose Type Code
      4. Create a Transaction Spec Schema to validate message
      5. Provide XSLT to map from AL3 to message and back
    2. PROS WITH THIS APPROACH
      1. Uses same aggregates as existing messages
      2. Can be used in similar use cases as existing messages..... Even with MAIL BOX
      3. Could be used with a Webservice
      4. Development would be just busy work not much design.
    3. CONS WITH THIS APPROACH
      1. Not compatible with a restful approach
      2. Not functional with JSON or other types of modern object transformation.
      3. Same message There maybe a better way to articulate this type of transaction with XML.
        1. Do we need to rethink the messages and use case?
        2. For example AL3 is meant to be done with in batch. Could the new messages be refactored to be pushed or pulled in realtime.
        3. Carrier could send a list of headers of messages to the "Cloud based" Management system or Transmission vendor with minimal information. And the agent / workflow could request the detailed information at later time.
  2. Create a Resource based transaction that could be easily transferred with a push or pull transaction using restful type messaging.
    1. ACTION ITEMS WITH THIS APPROACH
      1. Develop new resources
      2. Develop new use cases / processes that would replace the existing processes
      3. Document with a "transactionspec" or API ussage documentation
      4. Develop XSLT's to transform the AL3 message to the new resource message.
    2. PROS and CONS WITH THIS APPROACH
      1. Pros and cons are almost reverse of the above.
      2. PRO - PLURALS simpler easier to read messages.
I think ACORD could provide the Transformation to and from for members. This would also encourage membership. In my opinion we need to think out of the box to not just refactor the old message with a mailbox approach but actually make it a best of bread transaction to envision the way the same work can get done more efficiently. Improving workflow and user experience.

I think Agent management systems should use Carriers as a datasource and doing it resourced based would encourage that type of development.