-
Notifications
You must be signed in to change notification settings - Fork 19
External Data: where and why
I've had similar conversations recently about what data Caseflow stores, where and why. So I thought it worth trying to articulate the motivating philosophy and patterns I've observed for Caseflow. Note that these are my observations only, I haven't talked with any DS folks or anyone else who might have been present Way Back In The Day when these patterns first started to emerge. But hopefully writing this down can help crystallize my thinking and help others. Feel free to thread/clarify/question these.
- Prioritize data integrity and performance, in that order.
- Store the least amount of data possible in the Caseflow database.
- If the data originates in an upstream service (BGS, VBMS, VACOLS) prefer storing only a pointer to that data in the form of a
reference_id
of some kind. I.e. think of the entire VA data structure as a normalized database. - The only reasons to store upstream data in Caseflow are to improve performance or overall data integrity. Note that duplicating data and data integrity are naturally opposing motivations, so tread carefully.
- If you must store the upstream data in Caseflow, prefer caching over long-term storage in Caseflow db.
- If you must cache, prefer per-object caching (memoization) over Redis. This is where data integrity and performance should be weighed against one another. Be clear with yourself about what problem it is you are trying to solve.
See background reference discussion: https://github.com/department-of-veterans-affairs/caseflow/issues/5484
The BGS external API service is most specific.
- All Veteran profile records (name, DOB, file number, SSN, contact/address)
- POA records (name, address)
- Veteran record permissions (sensitivity)
- People records (Veterans, claimants, participants and others)
- Claims (End Products) are read from BGS
- Ratings, Rating Profiles, and Rating Issues
The VBMS external API service is most specific.
- Efolder (document artifacts for Veteran cases)
- Establishing claims (End Products, Contentions, etc for Intake)
The project uses URI and HTTPI to do REST calls
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- Appeals Consumer
- Caseflow Reader
- Caseflow eFolder
- Caseflow Hearings
- Caseflow Certification
- Caseflow APIs
- Appeal Status API
- Caseflow Dispatch
-
CSUM Roles
- System Admin
- VHA Team Management
- Active Record Queries Resource
- External Integrations
- Caseflow Demo
- Caseflow ProdTest
- Background
- Stuck Jobs
- VA Notify
-
Caseflow-Team
- Tier 4
- Bat Team
- Technical Documentation
- Backend Code Patterns
- Backend Working Group
- FACOLS, VACOLS DB Schema
- Asyncable Models
- External Data: where and why
- Data Fetching Scripts
- Caseflow Data Model and Dictionary
- User Access Permissions
- Controller Schemas
- Constants
- Frontend Best Practices
- Accessibility
- How-To
- Debugging Tips
- Adding a Feature Flag with FeatureToggle
- Editing AMA issues
- Editing a decision review
- Fixing task trees
- Investigating and diagnosing issues
- Data and Metric Request Workflow
- Exporting and Importing Appeals
- Explain page for Appeals
- Record associations and Foreign Keys
- Upgrading Ruby
- Stuck Appeals
- Testing Action Mailer Messages Locally
- Re-running Seed Files
- Rake Generator for Legacy Appeals
- Manually running Scheduled Jobs
- System Admin UI
- Caseflow Makefile
- Upgrading Postgresql from v11.7 to v14.8 Locally
- VACOLS VM Trigger Fix M1
- Using SlackService to Send a Job Alert
- Technical Talks