Introduction

We are building a new version of the Dealer Reserve System that will support the Indirect Lending team and will be compatible with the new FISERV solution, called DNA.

This new system is named the Reserve Management System (RMS) and the main features that will be built will include:

Calculating Reserves - this is a "commission" that is paid to the dealer after they close on a sale and they use a Landmark loan to finance the sale
Calculating Chargebacks - this is the "refund" that the dealership owes back to Landmark if a loan is paid off early
Creating Billing and Payment notices (Statements) that meet compliance requirements

Getting Started

Our repo has two solutions: the UI and the API. The UI is built with server-side Blazor, based on the LCU Blazor base project.

Our API is built with WebApi and Entity Framework, .NET Core 3.1. It also uses Swagger tools to show and allow interaction with the endpoints.

We are using SpecFlow and xUnit for our API unit tests (see more information below). You should install the Visual Studio extension SpecFlow for Visual Studio 2019 to make SpecFlow easier to use in the IDE.

Build and Test

The SpecFlow NuGet packages will make sure the test files are created when building the solution.

#SpecFlow We are using SpecFlow for the unit tests in our API (SpecFlow Getting Started). SpecFlow allows us to set up the tests in the Gherkin language with Given - When - Then steps - these are the feature files. Each step is then linked to a method in a steps .cs file. The SpecFlow NuGet package compiles the feature file into a corresponding feature.cs file as part of the MSBuild process. This means that the feature.cs files do not need to be in the Git repo, and our .gitignore makes sure of that.

There is also a SpecFlow xUnit package that enables SpecFlow to be used with xUnit.

Another useful NuGet package that we are using with SpecFlow is Pickles.CommandLine. Pickles is a package that generates documents from Gherkin files. This is installed in our main project so that it will be installed on Azure DevOps. We then have a step in our YAML file that calls pickles.exe (from its location on the DevOps server) to generate these documents and put them in a folder called Specs in the ReserveManagementSystemApi project (.gitignore makes sure that these aren't commited to the repo). The Startup file for the Api looks for this folder, and if it exists, it will set up the folder as a static website, found in QA at RMS Specs. Now every time we build our API solution, the latest version of the feature files are used to create this documentation.

If you having trouble with the SpecFlow extension not working correctly (this can happen after it is updated), look at this link: Troubleshooting SpecFlow extension. The first section helped me fix this.

#CsvHelper We are using the NuGet package CsvHelper to import csv files. We configured this to have a header row which will match the properties of a model. (Currently one of our imports is still headerless, but we will most likely change that.) It also is configured to trim both fields and headers. This package is easy to use in that it doesn't let you import a file that has values that aren't the right type for the column (i.e. not a date for a DateTime column). It will also allow us to change the column order (when we have a header row), and mark some columns as optional.

This will soon be unnecessary because we will be getting new/updated loans or closed loans from DNA via the CoreApiWrapper

#CoreApiWrapper We have built endpoints in the CoreApiWrapper that connect to DNA and get the loans that we need. There is an import for new and updated loans with a date parameter that returns a list of all the loans that have been added or updated after the date passed in. There is a similar endpoint for getting all loans closed past a certain date.

We also have endpoints for exporting the reserve or chargeback information back to DNA. These currently are just placeholders for the future export.

#Notes about NuGet packages In the API, we have left all Entity Framework packages at version 3.1.17, instead of upgrading to 5 since that we aren't using .Net Core 5. We have also left Blazored Fluent Validation at 1.4.1 in both the UI and API since we had issues when upgrading to 2.0.1.