Notes
We started receiving fresh data for sales items and tax codes, which means that all of our data is now up to date. Our ETL process runs in stages between 4 and 8am and loads data that was exported from Workday on the evening of the previous business day. Contact us if you need more detail about the timeline.
Our new access request process for Madison is now in effect. The request form is mostly the same as before, but we now ask for a bit more detail about what types of data you need. This helps us route it to the correct data steward for approval. All new applications will need to specifically request research admin data if you need access to it. Existing applications won’t have their permissions altered.
This sprint we added a couple of user-requested filters to the awards endpoint. You can now filter by the ID of one of the co-investigators or co-principal investigators. Previously this was only available for the IDs of principal investigators. We’re using a slightly different approach for this on the backend – we’re using JSON data columns in MySQL to flatten the data and make it faster to run queries on related records.
We added an automatic step to purge the caching layer behind our FDM validation service every time ETL runs. A couple of sprints ago, we had to do this manually when we learned that it had stale data. This is now automatic, and FDM validation will always use only the most recent data.
We continued work on the infrastructure that will support the new Locations API. We’ve implemented our datastore in Amazon DocumentDB (a MongoDB-compatible document storage system), set up the framework for ETL, and configured API Gateway so that we can connect the API to Apigee, the software that runs the Developer Portal.
We fixed a bug that affected the leadership role assignee records related to cost centers. The ID field is a Worker ID (same as the emplid from HRS) and is always eight digits long, but they weren’t always showing with their leading zeros. This is fixed now, and Worker IDs there match the way they’re shown in the rest of the API.
A user’s request for clarification led us to find out more about the precise meanings of some of the attributes of awards, and we’ve added what we learned to the documentation page for awards on our website. We’ll continue to add details there as we learn them.
API changes
-
- The awards endpoint now supports two new filters:
coInvestigatorIdandcoPrincipalInvestigatorId - Bugfix: cost center leadership role assignee IDs are now always displayed with leading zeros
- The awards endpoint now supports two new filters: