Public Page

2022-09-27 Architecture Meeting Minutes

Owned by Paulette Reed
Oct 04, 2022
4 min read

Public Page

Date: Sep 27, 2022

 

 

 

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

  • Network/Welcome

  • Work through examples of the OpenAPI document

    • Use of Tags

    • Discuss of PATCH Endpoint

    • Validating

  • Jira Board

Meeting Minutes

  • Antitrust Accepted

  • Meeting minutes reviewed and Accepted

  • Welcome

    • Alan Hemmi, Caliber is back up on the CIECA Board for Ashley Denison. Alan was at the CONNEX conference and was happy to meet several people from the Architecture Committee. Alan is the BP of IT and has been with Caliber for seven years. Background is with integrations throughout his career. Alan is happy about being able to help with the CAPIS project.

  • Work through examples of OpenAPI

    • Mike made changes for validating

    • Andy is not able to attend today so we can talk about Patch at later date, and we can discuss after everything else is decided.

      • Mike researched Patch and thinks that the capabilities of what we can do with patch can be better done with the PUT and using query light parameters to updated.

      • For validating the PUT, we would need at least 3 instances, one to add a license plate and one to add a vehicle location and one adding a phone number.

        • We create a claim with a POST and when we want to add a field with a PUT, do we have to put all the fields in the PUT that we do not want changed or just the things that we want to change?

          • PUT replaces what exist, so if you do not add something it will be deleted. However, Mike has the approach of using query parameters to do the changes. So with the query string you can basically provide the Claim Number of ID and it knows what claim you are updating and then you can provide an Xpath to the field that you need to update. This is very flexible approach and works like a PATCH.

    • Reviewed Previous meeting minutes

      • POST versus the PUT and this was some with Andy discussion and said the put will replace everything that was previous the delete will delete based on the claim number in the URL. So it looks at that claim number in the URL and it will replace everything. The post indicates the claim and sends back the claim number. The put can copy of the post and is intended to update whatever you send. The put is supposed to holy replace what has been created by the post.

      • PATCH seems to be useful

      • Andy has examples of Entegral uses the PATCH and think he can provide a better clarification.

    • AnyOf was removed and we thought we would have more validation errors. However, we only had 2 or 3 failures. This was due to the invalid folder that were called invalid because of missing required fields, but after the schema changed, they came up as valid. So that is the expected result. So we had to move the invalid test instances to valid test instances.

    • Mike did a Demo of the current CAPIS project

      • Mike added the response errors

        • 400 missing required information

        • 401 authentication error (endpoints not found)

        • 500 site

        • 503 server errors

      • Stoplight has a tool called Spectral. Basically, it's a linter, it's got rules, built-in rules, and that's how it comes up with warnings and the errors. Developers can use Spectra to add your own rules.

        • We can add rules based on our best practices. For example, the way we name tags. We could have a rule set to run against the YAML or JSON project file.

      • We can add data and have a mock server

    • Getting files from Stoplight to GIT

      • Go into edit and export the YAML file. And I've been exporting it as YAML and then bundled, and I do that so that I can check it back into. That's how I get it back into git.

  • Changes for Build Process Reviewed

    • Each endpoing is going to have a bundled schema. That is the most compact and useful things

    • We have a Big Comprehensive Dictionary of all the properties we are going to use and the second one with CIECA Code List, and then these endpoint schemas are never going to define a property, for example that a model is 36-character string or whatever, it will just reference the Dictionary that are handled with the bundling.

    • The API ‘npm build’ command bundles the schemas, it will go through the schema folder and write the bundled schemas. It creates the JSAON and the YAML.

    • When your build errors with a busy error, you need to close XML Spy to correct this error.

    • npm QA test runs the QA test. This will run through all the Valid and Invalid Test Instances.

    • BMS had npm test command.

Up Next

  • Antitrust

  • Network/Welcome

  • Work through examples of the OpenAPI document

Action items

Decisions

 

Participants

  • Paulette Reed

  • Paul Barry

  • Dan Webster

  • Mike Hastings

  • Jeff Schroder

  • Alan Hemmi

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH