A proxy server that acts as an Efiling Service Provider, connecting guided interviews to Efiling Managers on Tyler Technologies implementation of ECF 4.0
In order to handle having a single efile proxy server that can support multiple
different Tyler Jurisdictions at the same time, a fairly large refactor had to
be done. This refactor puts all of the Tyler endpoints behind a
"Jurisdictions/{jurisdiction_id}" endpoint, so we can have the same server
handle requests that go to IL and to MA. A lot of assumptions had to be changed,
and a lot of endpoints were changed as well.
The main env variable that changes is the TYLER_JURISDICTION var, which is now a
space delineated env var called TYLER_JURISDICTIONS.
A design choice that had to be made is the fact that there is still only one
TYLER_ENV per server (i.e. the server is either stage, test, or prod, but only
one at a time). If you try to spin up the same server with an existing database
for a different env, things will be weird, because the codes database is still
separated by "domain" (i.e. jurisdiction + env).
In order to handle having a single efile proxy server that can support multiple different Tyler Jurisdictions at the same time, a fairly large refactor had to be done. This refactor puts all of the Tyler endpoints behind a "Jurisdictions/{jurisdiction_id}" endpoint, so we can have the same server handle requests that go to IL and to MA. A lot of assumptions had to be changed, and a lot of endpoints were changed as well.
The main env variable that changes is the TYLER_JURISDICTION var, which is now a space delineated env var called TYLER_JURISDICTIONS.
A design choice that had to be made is the fact that there is still only one TYLER_ENV per server (i.e. the server is either stage, test, or prod, but only one at a time). If you try to spin up the same server with an existing database for a different env, things will be weird, because the codes database is still separated by "domain" (i.e. jurisdiction + env).
Fixes #79.