The CMS Enterprise Data and Analytics Repository (CEDAR) is a collection of APIs and databases that serve to collect and store data that describes CMS Business Processes and applications.
The CEDAR web UI (where you can view documentation, try out APIs, and browse data in Alfabet). It can be accessed from the following URLs for each environment
In order to browse the CEDAR UI you'll need to meet a few prerequisites:
- A running connection to the CMS VPN
- Edits to your local Root certificates
- The following edits to your hosts file
10.138.78.45 cedarimpl.cms.gov aris.cedarimpl.cms.gov alfabet.cedarimpl.cms.gov webmethods-apigw.cedarimpl.cms.gov webmethods-apiportal.cedarimpl.cms.gov www.cedarimpl.cms.gov aris.cedarimpl.cms.gov alfabet.cedarimpl.cms.gov webmethods-apigw.cedarimpl.cms.gov
10.245.38.21 www.cedar.cms.gov cedar.cms.gov aris.cedar.cms.gov alfabet.cedar.cms.gov webmethods-apigw.cedar.cms.gov webmethods-apiportal.cedar.cms.gov
The webMethods API Portal is where you can view CEDARs API documentation, and is probably the most useful tool for developers. You will need to be on the VPN to access the portal. Once you're there, you can click "API Gallery" at the top of the page to view the details of each CEDAR API.
To obtain the latest swagger file, click into the desired API (for example, CEDAR Core API) from the API Gallery, and navigate to "API Documentation" on the left.
Download the file ending _swagger.json, place in the corresponding directory in the easi-app. In this example, place the file in pkg/cedar/core/ and rename to cedar_core.json.
Alfabet is the backend API that stores the data that CEDAR pulls from. EASi does not integrate directly with Alfabet, but uses CEDAR as a proxy to Alfabet.
However, you can click Alfabet on the main CEDAR UI page to see the Alfabet UI, which lets you browse the data in Alfabet. Do NOT modify any data directly in Alfabet.
The CEDAR API can be slow when responding to http requests, so a cache-enabled proxy is used to expedite data-retrieval. The proxy is an nginx server with rules applied for caching requests and purging cached responses. This proxy is managed by the EASi team and all of the EASi API calls are made to the proxy which then communicates with the CEDAR API as necessary.
Within the EASi API, the calls that are made to the CEDAR APIs are defined by code generated by go-swagger. However, in order to not have changes to the CEDAR API documentation break EASi, a "translated client" is usually created for each CEDAR API that wraps the generated code with our own, tested client. An example of this is the pkg/cedar/intake/client.go file.
The Go code is generated by a tool called go-swagger. This is a different tool from the Go generator in swagger codegen, and is a standalone tool. How we use this tool (and what version) is documented here.
For CEDAR Core, this tool is not executed as part of any build process, and should be run manually when new swagger files are added. From the pkg/cedar/core directory:
swagger generate client -f cedar_core.json -c ./gen/client -m ./gen/models
The CEDAR Intake Swagger file requires a bit of preprocessing before code generation. When the Swagger file is updated, put it in pkg/cedar/intake/cedar_intake.json, then run scripts/generate_cedar_clients to preprocess it and regenerate code. See the intake folder's README for more information.
.envrc.local will need to define environment variables for connecting to and authenticating with CEDAR. Add the following:
export CEDAR_CORE_MOCK=false
export CEDAR_INTAKE_ENABLED=true
export CEDAR_API_URL="webmethods-apigw.cedarimpl.cms.gov"
export CEDAR_API_KEY=[insert IMPL API key from 1Password here]
export CEDAR_CORE_API_VERSION=2.0.0
Additionally, if you're using the openconnect-tinyproxy VPN container for selective proxying, add the following to your .envrc.local file to instruct Go to use the proxy:
export HTTP_PROXY=http://localhost:8888
export HTTPS_PROXY=http://localhost:8888