2022-09-20 Architecture Meeting Minutes

Public Page

Date: Sep 20, 2022

Agenda

• Antitrust

• Network/Welcome

• Review Face to Face Accomplishments

• Review Jira Board

Meeting Minutes

• Antitrust Accepted

• Meeting minutes reviewed and Accepted

• Review of Face-to-Face Accomplishments

  • We learned as a practice that importing the JSON Schema is not enough.

  • Unbundled schemas re easier to read

  • Stoplight needs bundled objects when creating API

  • Unbundled did not have examples or able to expand objects

  • Open API needs URL and Security to work and we have to manually update examples

  • We added items to Jira to either work for the release or to work on in future releases. We need to focus on what we have to have for the first version, and we can look at the other jiras for the next release.

  • We had to make some schema changes to get the open API to work.

    • Stoplight does not like the Any of, so all of these had to be removed for the tool

      • We agreed that we would do this for the tool at this time, but need to look at what is going on and bring it to stoplight, so a Jira was created

    • We ran into the schema for the claim folder being too large, so stoplight would not create an example.

      • workaround was to create the schemas in XML spy and then copy it in the Stoplight Studio

      • we still need to do work on the examples

    • We had instances that we thought would break when some changes were made, but they remained valid, so need to look at the instances for valid and invalid and come up with more instances.

  • Mike did a demo

    • We are implementing a rest service for Chapter 16 of the BMS, Claim Save Folder.

    • The demo showed 5 different methods with the first being the pose.

    • The URLS were set up and then an endpoint called claims was created to do the post. The body of the message used vehicle, party and claim. This showed the bundled schema.

    • Stoplight allows you to add different responses, the 200 is for acceptance the 400 is for error message, the 401 is temptation error, 404 is not found and 500 indicates you have a server error and a 503 indicates the server is busy.

    • The other verbs, we can pass a claim number and retrieve the information and we can delete based on the claim number.

    • Postman is a tool that test the YAML file to test the API

  • The release for October 19 will include a few things for the BMS that was requested and then CAPIS. We prioritized the work on what an open AP spec for CAPIS would look like over more tinkering with the schema it is looking good. We are kind of there.

    • We have a schema that included parties, claim and vehicle

    • We can show how we developed this schema

    • We can make an open API Spec envisioning all the endpoints for Create, Read, Update and Delete

    • We have examples.

      • We are not calling a victory here at the 40-yard line, but I think this is what the committee had in mind.

  • We will be constantly changing the schemas as we move forward with other versions, this is much like how the BMS started.

  • Build and Batch validation is working

    • We have bundles folder that has each of the endpoint schemas and for each of those schemas we have an instance directory with valid and invalid instances.

    • We want to make the examples folder for each of those instances as well and run them though the batch validation.

  • Request for Paul to come up with a Claim example that would represent a workflow.

  • We can have multiple examples

  • Patch research

    • Dan does not like Arrays

    • Mike did research on the put and the patch and it says when you do a put you send the whole message, like doing on update on the object. If you do a patch you can send only certain properties.

    • The JSON Patch is a technology, and the patch that we are talking about is part of the HTTP specification

    • The patch uses the same schema

      • If you use the patch, you could just send the VIN and it would only update the VIN

        • If someone sends just the VIN, how is the schema we have now going to validate that. The patch with just a VIN number is not an entire object, its just an update to one field.

      • the put you send the whole message

      • Unlike the soap implementations we are doing today where you get the information about the assigment you are updating or deleting from the payload. In rest, the resource that you identified, so you know the claim it is by the endpoint that your hiding.

      • I guess you could say the schema for the patch is just an object and you don't say what any of the properties are and then you could code it to where whatever you see there, if it happens to match up with something, you change it or delete it. But I hope that's not the direction we're going in.

      • Tabling the conversation of patch for a later date.

  • Schema should not be by verb it should be by entity.

  • Post vs Put

    • The Put will replace everything that was previous, the delete will delete based on claim number in the URL

    • The Post initiates the claim and sends back a claim number

    • The Put can be a copy of the post and is intended to update whatever you send.

    • put is supposed to wholly replace what was created via the post. So if things are issing, they get deleted, and if they are changed they get updated.

    • So the big difference between there's two. Basically there's two ways to update an entity. You can either do a put or you can do a patch, and if you do a put, the expectation is is that you have everything that you're going to present a fully filled out new claim with whatever fields updated are updated the way that you want and with patch it's not that way. You only provide the ones that are going to be updated and the fact that they're missing doesn't mean that you're asking for them to be deleted.

• Andy’s work on scripting (Andy shared his screen)

  • Our workspace, and so you've got package dot Jason. And then right next to it, you've got package lock and notice that our package that JSON is relatively small, however, it's not, its a very large file. The package lock is very, very large, goes the covers a whole bunch of stuff, and so the idea here just in it's super high-level terms. The idea here is that when you create or when we use a package dot JSON file to manage dependencies, we list things in here that we need, such as AGV. You've heard us talk about that. There's been we've used this FSX extra. Everything in here.

  • It is aa dependency. It's listed as dependencies and if you look at that library, it has its own dependencies. So, if we were to go into a JV, if we look at these in the node directory, node modules and we go to ajv and look at its package dot JSON it has a whole bunch of dependencies.

  • The idea is anytime you make a change when you do an NPM install and you install new or updated stuff, then if you actually make code changes too then you definitely want to commit those. You know your package lock back. It's a check and balance basically.

• Up Next

  • Work on Examples

  • How can we use tags?

Up Next

• Antitrust

• Network/Welcome

• Work through examples of the OpenAPI document

• Discuss of PATCH Endpoint

Action items

Decisions

Participants

• Paulette Reed

• Andy Bober

• Paul Barry

• Dan Webster

• Mike Hastings

• Brad B

• Jeff Schroder

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