Public Page
2021-02-9 Architecture Meeting Minutes
Public Page
CIECA 500 Westover Dr #11617; Sanford, NC 27330
Date
Feb 9, 2021
ANTITRUST STATEMENT
As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.
Agenda
Antitrust and Meeting minutes acceptance
Discuss Swagger Meeting
Continue to work on the CAPIS.
FNOL Use Case
Standardize Percentage definitions question (Becky)
Meeting Minutes
Antitrust Accepted
Meeting Minutes approved
Swagger
We have been researching the Swagger documentation to determine if CIECA would need a Team or an Enterprise License. This would be who can access and who needs to make changes.
Questions on how our members would get to the information.
Best recommendations on how to use with GitHub development
How do we want to continue to show our members the standards
Today we use Box, however, that is something that we see moving away from with the new direction of cieca.com.
Everyone in the meeting would like to be in the meeting with Swagger.
It was recommended to set the meeting in the same time frame as the meeting we already have.
CAPIS
The team was shown the new confluence page for Product Information that the CIECA staff is working on moving our services to. This concept will help people navigate through our services and find information.
The FNOL Page was created with the history documentation that Charley had created. It has information from the BMS, Appendix C and Implementation Guides, and even the Test instances.
The diagram is the same as Charley’s diagram, just in the new drawio format instead of Visio.
The XML FNOL add service page was reviewed quickly to show how each of the services could be its own page.
Post FNOL to be created in this committee to use for CAPIS project.
We named the page Post FNOL
Discussion about how to move forward and some possible guidelines
We need to stay consistent with the Open API Verbs, POST, Get, DELETE, and PUT. (Swagger documentation example was reviewed on how this looks in Swagger). https://petstore.swagger.io/
Andy showed some other tools that can be used to write YAMAL
Stoplight Studio tool https://stoplight.io/studio
Insomnia Designer https://insomnia.rest/download/
We reviewed the Schemas for FNOL and the test instances
We have several Trojan Horses in FNOL, these aggregates are huge and repeating values.
Claim Info
Admin Info
We just need an Address, we really don’t need Admin Info, so how will we break these large aggregates down?
If we can reuse names, that exist in the XML and the EMS, we should reuse the name to have a common naming process.
A number of our large aggregates, such as Admin Info, is optional
Can we create micro aggregates and do we need to start from the ground up?
A possible Guiding Principal would be when do we need to expand a message or create a new one?
Today we have messages that can be for Property, Vehicle or Glass. Would we need to split?
It is recommended that anytime there is a decision that we split, because the decisions is what made it hard to implement the JSON messages created from XML.
We need a naming convention to help keep the services easy to find.
Example Post Assignment Rental and Post Assignment Glass
We looked at the Richardson Maturity Model
Our messages was a request and response and we added the name Add, Cancel and Change to our XML services names.
The open API will use POST, PUT, GET, DELETE.
Verbs have different sizes, the PUT is normally the largest because it is creating an object, where the GET is small because it sends information to retrieve an object or list of objects.
We need to break down Admin Info and get the data types and aggregates that we need for FNOL in the next meeting.
Have a great week everyone!
Up Next
Antitrust and Meeting minutes acceptance
Continue to work on the CAPIS.
FNOL Use Case
Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.
Do we want to add a new section to the Architecture Guidelines for CAPIS guidelines or should we have a separate document?
Standardize Percentage definitions question (Becky)
Action Items
Decisions
Participants
@Paulette Reed
Paul Barry
Jeff Schroeder
Dan Webster
Andy Bober
Mike Hastings
Cindy Chapman
Aaron Daniele
Participants in the meetings are noted for your information. If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee