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? |
Supporting Files
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 :) ) |
Supporting Files
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...
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 |
Supporting Files
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
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
Key Topics
Implementation Workgroup Session Supplement
Supporting Files
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. |
Supporting Files
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.