This page lists requirements for installing Smile CDR. This applies only to self-hosted versions of Smile CDR. If you are using a cloud-hosted version then this page does not apply.
Note that these are the requirements that are known to work with Smile CDR. If you have other requirements in mind, they may work as well. Please contact us to discuss other options.
The following list defines the minimum server requirements for a server hosting Smile CDR. Smile CDR may be configured in a 1-node cluster if high availability is not needed, but 2+ nodes are recommended for better reliability.
Smile CDR is supported for use against one of the following distributions of Java:
Smile CDR will run against a simple JRE (compiler tools are not required in order to use Smile CDR) but the JDK comes with many tools which can be useful for troubleshooting issues (e.g. jstack, jmap, etc.)
Smile CDR may also work correctly against other distributions of Java (OpenJDK, IBM JDK) but these are not well-tested and are not recommended. Note that you can skip the Smile CDR minimum Java version check by adding the argument
-Dskipjavaversioncheck=true to your
Smile CDR requires a relational database to use as a store for system data, such as configuration. A relational database or non-relational database can be used to store FHIR resource information.
The following database platforms are supported:
Smile CDR also supports the following embedded database platforms, generally used for testing:
The following database platforms are supported:
Listed database versions have been tested and certified to work with Smile CDR. We have every expectation that more recent versions, particularly point versions will work seamlessly with Smile CDR. We do encourage that non-listed RDBMs versions be tested in a non-production environment prior to going into production. As part of our standard professional services engagement we are happy to provide that testing or to suggest a testing methodology.
Smile CDR is a full featured HTTP server and is capable of directly serving client HTTP requests. It is not necessary to pair it with other network infrastructure. However, there are several other network technologies that can be combined with Smile CDR in order to achieve specific architectural goals.
The following three examples list potential network infratructure components that can be paired with Smile CDR. Note that these are not completely separate concepts: A single piece of software (or hardware) may actually perform any or all of these functions.
Smile CDR clustering (i.e. of FHIR/REST endpoints, Web UIs, etc.) can be set up in a horizontal fashion using a variety of topologies. These include Acitve/Active and Active/Passive setups.
When configured in a typical Active/Active configuration, incoming HTTP requests may be distributed in a completely arbitrary (e.g. round-robin) or a predictable way (e.g. sticky-session). Smile CDR clustering makes no assumptions that multiple requests belonging to the same user session or OAuth2 token will be delivered to the same physical endpoint, so clustering can be easy to set up.
Load Balancers may be a purely software software solution such as NGINX or may be a hardware or cloud infrastructure device.
A common configuration option is to place a reverse proxy such as NGINX or Apache HTTPd (with mod_proxy). The use of a reverse proxy typically fulfills one or more of the following functions:
Serving Default Ports: Smile CDR should not be run as root, meaning that on a Unix system it is unable to bind ports 80 or 443. Using a software proxy allows Smile CDR endpoints to be visible on these default HTTP/HTTPS ports.
TLS Termination: It is possible to configure Smile CDR to serve TLS (i.e. https), but it can sometimes be beneficial to use a software proxy to serve TLS "in front" of Smile CDR. This is because a dedicated software proxy can typically restart effectively instantly, meaning that certificate changes can be performed without any noticeable downtime. This is especially useful when using short-lived certificates, such as those isused by LetsEncrypt.
Endpoint Consolidation: Smile CDR serves each endpoint module on a separate port. Using a software proxy allows multiple endpoints to be served on a single port using different root paths to separate them. See Specifying a Custom Context Path for more information.
API Gateways are popular tools in modern RESTful architectures. An API gateway typically provides several functions. Some of these functions can be provided natively by Smile CDR, meaning that a separate gateway is not necessary. Other functions require the use of a dedicated gateway.
Smile CDR can handle authentication and authorization of users entirely within its own security layer. The security services, including the OAuth2/SMART services are designed to be aware of FHIR data and REST patterns, meaning that Smile CDR can provide a nuanced security implementation that would be difficult or impossible to design using a standard API Gateway alone.
Smile CDR can be paired with a Gateway product however. This pairing can involve the Gateway handling user the authentication and authorization. This pairing can also put authentication and authorization decisions in both layers (i.e. in both the Gateway and in Smile CDR) for a defense-in-depth strategy.
Smile CDR can also be configured to keep detailed metrics on service utilization and performance. There are advantages however in maintaining an external monitoring tool that can raise alarms when key performance metrics fall below predetermined thresholds.
Smile CDR does not currently have the ability to manage API keys.