Systems Developer

Project: The Farm Phosphorus Reduction Planner (FarmPREP) is an innovative web application that streamlines data inputs and outputs to USDA-NRCS's complex Agricultural Policy/Environmental eXtender (APEX) model to provide accurate results for phosphorus loading from agricultural fields. FarmPREP combines the integrity of the APEX model with a more efficient user-interface to determine phosphorus loading in Vermont. FarmPREP is fully functional, free for users, simple to use, and has been calibrated to common agronomic practices in Vermont. FarmPREP was created by and is currently maintained by a contractor. Shapefiles of fields are uploaded or drawn in FarmPREP directly for each farm. Crop management inputs for each field (e.g., crop rotations, tillage, nutrient applications, conservation practices and optional soil and manure test results) are combined with geospatially determined soils, slope and climate data to determine edge of field phosphorus loss through sheet and rill erosion. APEX runs simulations for the inputs over a 30-year period to account for climate variability and FarmPREP outputs the annual average phosphorus load (lb P/ac/yr). Users can also specify target phosphorus reductions and FarmPREP will model the top 10 practice/management changes per field to achieve the target. Results from multiple scenarios can be viewed together for comparison. The Vermont Agency of Agriculture, Food & Markets (VAAFM) previously received funding to modify the FarmPREP software to be utilized for VAAFM's Vermont Pay-For-Performance(VPFP) program, which pays farms on a pound per acre basis of phosphorus loss modeled in FarmPREP. VPFP has been utilizing FarmPREP for the last 5 years and is entering its next 5- year phase, which entails FarmPREP modification as the VPFP program evolves. A complete task list is provided below. Current Environment of FarmPREP: FarmPREP is a custom-built tool that combines web-based technology and the United States Department of Agriculture (USDA) Agricultural Policy Environmental eXtender model (APEX)(Steglich et al., 2016). FarmPREP runs using a hybrid N-tier configuration of virtual servers, at Amazon AWS, that includes a web server, middleware (API) server, a separate model API server, and a PostGreSQL database server, as well as a Docker container system executed on AWS Fargate. All of the servers are operated with a commercially supported Linux-based OS, and, aside from the Esri ArcSDE components in the PostGreSQL database, use open-source software. Of the four servers in the FarmPREP deployment, each plays a different role, and separates duties so that the system can be more resilient and scalable.• Web Server: The web server is used to run the Apache web server service that responds to requests from the internet for FarmPREP. The server has 2 virtual CPUs, is assigned 1gb of RAM, and has 20gb of storage.• Main API Server: The API server runs a custom-built NodeJS based middleware ReST API that allows the HTML/Javascript running in the user's web browser (the front end) to connect to and interact with the database on the backend. The server has 2 virtual CPUs, is assigned 2gb of RAM, and has 20gb of storage.• Database Server: The database server runs a standard instance of PostGreSQL that can only be connected to by the API servers. The PostGreSQL database is enabled with ArcGIS Enterprise Geodatabase functionality (formerly known as ArcSDE) as well as PostGIS functionality. The database server currently runs PostGreSQL v12 with ArcGIS Enterprise Geodatabase components at v10.9.1. The server has 8 virtual CPUs, is assigned 15gb of RAM, and is assigned 250gb of storage.• mPipe API Server: A second API server, called the mPipe server, is responsible for managing the APEX model running process. This server runs a custom NodeJS ReST API, like the Main API Server, but also takes on communication with the AWS Fargate service, as well as running various Python scripts. The server has 2 virtual CPUs, is assigned 8gb of RAM, and has 20gb of storage. The four servers are setup and held inside of a Virtual Private Cloud that enables them to communicate with each other using private IP addressing, while exposing only the web and API servers to the internet via ports 80 and 443 (where port 80 in the application kicks the user over to use port 443 to enforce SSL use). APEX Containers: Separate from the servers is the containerized APEX system. A Docker container template has been created for Farm-PREP that runs the Linux compiled APEX model. The container is pre-packaged with much of what it needs to run the model. However, every time a container instance is created from this template, it is given input parameters that inform the container on how to customize the APEX run based on user inputs and field-specific information. Once the container instance starts running it uses a unique ID and connects back to the main PostGreSQL database to fetch these details for the APEX run. Python scripts are run on the container instance to generate site/user specific input files that APEX needs before it is executed. Once APEX is run, the resulting outputs are returned to the database, and the output files are compressed into a single file that is uploaded to AWS before the container instance stops running and disappears. The containers are executed inside of AWS Fargate, which allows the system to run thousands of container instances simultaneously, if necessary (or sometimes just run 1 or 2 instances), therefore enabling a massive time savings from running the APEX model runs sequentially. The following technical requirements for each of the primary components of FarmPREP are listed below.• Front-end: o HTML5 o SCSS o Esri ArcGIS Javascript API o Angular• Middleware Main API & mPipe API: o NodeJS o Linux• Backend: o PostGreSQL/PostGIS o Linux o Apache2• APEX: o The APEX model's code is maintained by Texas A&M o Docker o Python o Linux o AWS S3 Amazon Web Service (AWS) ECS/ECR & Fargate Authentication 1. Login is routed through the State's central identity provider login page—Okta for external users, Entra for internal users—ensuring state-approved authenticators and user experience. 2. Authentication for both internal and external users is handled via SAML 2.0 or OIDC only, and in conformance with their respective standards. 3. Authentication is validated in DEV and TEST environments, in addition to PROD, when directed by the State. 4. Applications serving both internal and external users support two identity providers with separate URLs. Where an application cannot support two providers, the State may agree to handle routing through a single IDP upon request. 5. Applications dependent on internal/external user status can reliably determine that status from OIDC claims or SAML attributes.