The ml api adapter is a series of services that facilitate clearing and settlement of transfers between DFSPs, including the following functions:
- Brokering real-time messaging for funds clearing
- Maintaining net positions for a deferred net settlement
- Propagating scheme-level and off-transfer fees
The following documentation represents the services, APIs and endpoints responsible for various ledger functions.
This package is available as a pre-built docker image on Docker Hub: https://hub.docker.com/r/mojaloop/ml-api-adapter
You can also build it directly from source: https://github.com/mojaloop/ml-api-adapter
However, take note of the default argument in the Dockerfile for NODE_VERSION
:
ARG NODE_VERSION=lts-alpine
It is recommend that you set the NODE_VERSION
argument against the version set in the local .nvmrc.
This can be done using the following command: npm run docker:build
Or via docker build directly:
docker build \
--build-arg NODE_VERSION="$(cat .nvmrc)-alpine" \
-t mojaloop/ml-api-adapter:local \
.
See the Onboarding guide for running the service locally.
The ml api adapter has many options that can be configured through environment variables.
Environment variable | Description | Example values |
---|
For endpoint documentation, see the API documentation.
Logs are sent to standard output by default.
Take a look at the package.json
file for a full list of the tests available.
npm run test:unit
# start docker-compose dependencies
docker-compose up -d
# wait for docker compoments to start
npm run wait-4-docker
# run the integration tests locally
export ENDPOINT_URL=http://localhost:4545/notification
npm run test:int
If you want to run functional tests locally utilizing the ml-core-test-harness, you can run the following commands:
docker build -t mojaloop/ml-api-adapter:local .
npm run test:functional
By default this will clone the ml-core-test-harness into $ML_CORE_TEST_HARNESS_DIR
.
See default values as specified in the test-functional.sh script.
Check test container logs for test results into $ML_CORE_TEST_HARNESS_DIR
directory.
If you want to not have the ml-core-test-harness shutdown automatically by the script, make sure you set the following env var export ML_CORE_TEST_SKIP_SHUTDOWN=true
.
By doing so, you are then able access TTK UI using the following URI: http://localhost:9660.
Or alternatively, you can monitor the ttk-func-ttk-tests-1
(See ML_CORE_TEST_HARNESS_TEST_FUNC_CONT_NAME
in the test-functional.sh script) container for test results with the following command:
docker logs -f ttk-func-ttk-tests-1
TTK Test files:
- Test Collection:
$ML_CORE_TEST_HARNESS_DIR/docker/ml-testing-toolkit/test-cases/collections/tests/p2p.json
- Env Config:
$ML_CORE_TEST_HARNESS_DIR//docker/ml-testing-toolkit/test-cases/environments/default-env.json
Configuration modifiers:
- ml-api-adapter: ./docker/config-modifier/ml-api-adapter.js
We use audit-ci
along with npm audit
to check dependencies for node vulnerabilities, and keep track of resolved dependencies with an audit-ci.jsonc
file.
To start a new resolution process, run:
npm run audit:fix
You can then check to see if the CI will pass based on the current dependencies with:
npm run audit:check
The audit-ci.jsonc contains any audit-exceptions that cannot be fixed to ensure that CircleCI will build correctly.
As part of our CI/CD process, we use anchore-cli to scan our built docker container for vulnerabilities upon release.
If you find your release builds are failing, refer to the container scanning in our shared Mojaloop CI config repo. There is a good chance you simply need to update the mojaloop-policy-generator.js
file and re-run the circleci workflow.
For more information on anchore and anchore-cli, refer to: