Technical Sessions and Exercises

Materials added after session completes

Session 1 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
00:01:23 Tim Jennings We will conduct a full Q&A open forum near the end of today's call
00:31:38 Chadwick Can we get the link to the lab after the presentation today?
01:05:28 Matt Haubrich I'm not a developer so I can't really comment on the tool itself, but as we're talking I'm thinking about how we'll be able to gain value from this effort. It seems like we need to make sure we're properly communicated with stakeholders to make sure the implementation of these APIs is prioritized for each of the AASHTOware tools. Do we have (or need to have) communication tools aimed at those stakeholder to help everyone understand why we should put resources toward implementing this framework in each product? And do we have (or need to have) training resources for the developers?
01:43:33 Jason Dunlap How do we get on a list to future meetings?
Key Topics
             

Session 2 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
00:32:15 Mark Faulhaber will it support ADFS?
00:41:22 Daryl Bushika Will the security in the API respect the security already set up within the specific modules? For example, if I don’t have access to a record within AWProject, I shouldn’t have access in the API, and I should not have to set up all of that security again in the API. We have dozens of roles, thousands of users and millions of records.
01:00:04 Joseph Barut Does the API support desktop apps?
01:01:03 Matthew Ferris I'm eagerly awaiting the AW Connected Toaster
01:01:12 Ty Carlson I’m also curious about Daryl’s question, maybe it was answered and i missed it but when connecting to AW Project, does this API communicate via Odata?
01:02:29 Chadwick Becker Is API authorization policy or role based?
01:02:59 Ty Carlson So when this API is connecting, is it bypassing business layers and going against the database directly?
01:04:30 Chadwick Becker Ok, thanks.
01:08:03 Will Holmes To Clarify, Sedrick please confirm, AW Developers as their implement the API capabilities for the particular software will define how a request is handled. The open API will not bypass the software unless the AW Developer codes the API to bypass it. Yes?
01:12:12 Mark Faulhaber How do the developers get this implemented while they are also being expected to make 2 major upgrades to functionality? FHWA required changes are one of the upgrades.
01:13:10 Ty Carlson API/Business Layer: to clarify my comment previously, I would prefer any API “talk” to AW Project through the business layer. As long as that can happen we’re good. It sounds like it... but that’s a thing of beauty with AW Project is we don’t have to “build something 2x”.
01:16:39 Mark Faulhaber Here's a more specific question: "the BrM Task Force has to send out a solicitation for the FHWA required changes. Should/will that solicitation include the API work and converting the existing programs to consume the APIs?
01:18:22 Ty Carlson Just a comment here... in NE, we’re building an API currently and the identity used to transfer data with the API has to be a user within AW Project and have a role with appropriate access. In AW Project on the user/role set up we can specify a “Services Authority” which allows this access.... really handy in saving from the “building something 2x” part...
01:18:36 Ty Carlson (sorry to be stuck on the business layer thing :) )
Key Topics
                 

Special Topic - API Security, Managment Process

Process overview

The approach to creating an enterprise-caliber API involves a set of well-defined process and roles. There are distinct steps that first identify desired capabilities and then progress to a complete solution. These phases require an in-depth understanding of the longer-term objectives, how best to establish a solid foundation, as well as foresight in allowing for growth, adaptability, and flexibility. There are general or overarching aspects that have a broad scope. This will include performance, security, utility, and technical conventions. There are also very nuanced and niche aspects that have a very limited focus. In this regard, there is a considerable impact on the later use, adoption, and lifecycle roadmap for future utility. Lastly, as expected with most software engineering or development projects, a formal iterative sequence will underly the delivery usually seen through a versioning methodology. In this breakout text, we will take look at the process drivers as whole but focus on the overarching design concern of what makes up API security.

The API development process is not detached from a standard software project approach. One key difference, however, is that the preliminary research and analysis may be centered around an existing offering or suite of solutions already in place. In many ways, this will greatly accelerate and support the initial efforts. Having an established reference point does introduce a special type of drawback and risk. The objectives and benefits of producing the API may require a great deal of translation from the current concept in order to fulfill the end-use goals. Security and related access requirements will undoubtedly align, but additional needs will present during the API design phase.

read the full article as pdf...

Article1.pdf

Session 3 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
01:08:57 Ty Carlson Question: Will this be a hosted service? If yes, when this service communicates with our agency hosted applications will we need to work out ports or other configurations on our agency servers to allow the communication?
01:10:10 Ty Carlson Question: There are many data elements outside of the AASHTOWare realm of software that an agency utilizes. I think I heard you touch on this but can this service communicate with an agency data warehouse or other agency applications?
01:11:43 Daryl Bushika As far as the U in CRUD, will we be able to modify data thing AASHTOWare Project with this? Will this respect data security housed within AWP?
01:16:15 Michael Jenkins Do you have list of vendors have you met with and discuss thing with so far.
01:24:47 Michael Jenkins I.e. Bentley; AgileAsset; PeopleSoft
01:24:51 Michael Jenkins ok thanks
Key Topics
               

Session 4 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
01:01:23 Joe Bruewer Can you explain the process for determining the specific data that is provided via the API. For instance how did you determine what was sent in the SendCompletedProjectsPost. Is this just a starting point that can be modified as needed.
Supporting Files

2021-02-11_AASHTOWarePhase2-Session4.pptx

Key Topics
                 

 

Session 5 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
01:05:33 Joe Bruewer: Based on your comment to build once and use often would multiple agency specific integrations of an established Interface be managed by this single AASHTO API?
01:09:13 Jack Dartman: Thanks for today's session Sedrick.
01:09:46 Joe Bruewer: Thanks
Supporting Files

2021-03-25_AASHTOWarePhase2-Session5.pptx

Key Topics
               

 

Implementation Workgroup Session Supplement

Key Topics
           

Session 6 Content and Lab Exercise

Session Q&A, Comments
Index Participant Question/Comment
00:38:44 Mark Faulhaber: I see "guided Tour" slide
00:38:50 Susan Downing-Reed: I am not seeing the demo screens
00:54:50 Susan Downing-Reed: Where will the selection and definition of datasets be available?
01:06:59 Jack Dartman: Thank you for today's data integration information sharing.
01:09:48 Susan Downing-Reed: This is a one way API - inother words, it would not have the ability to insert data back into the impacted database?
01:15:03 Jim Ramsey: Thanks. Good job.
Key Topics
   

Implementation Overview - API Supplier (applies to contractors)

AW_Supplier from WSP USA on Vimeo.

Usage Overview - API Consumer (applies to API developers/partners)

AASHTOWare_Consumer from WSP USA on Vimeo.