scheduling-bc

EXPERIMENTAL vNext Scheduling Bounded Context

The Scheduling BC within the Mojaloop Switch platform facilitates the scheduling of processes and events across multiple Business Components (BCs), allowing Client BCs to submit requests for reminders at specific times or schedules, while also providing management services for these reminders to both Client BCs and Switch Admins.

It contains the following functionalities :

• Accepting requests from Client BCs to create reminders for specific times or schedules.
• Maintaining a schedule of reminders received.
• Sending notifications of reminders to the appropriate Client BCs as scheduled times are reached.
• Providing management services for reminders, enabling Client BCs and Switch Admins to manage scheduled events efficiently.

See the Reference Architecture documentation scheduling section for context on this vNext implementation guidelines.

Contents

• scheduling-bc
  • Contents
  • Packages
  • Running Locally
  • Configuration
  • Logging
  • Tests
  • Auditing Dependencies
  • CI/CD
  • Documentation

Packages

The Scheduling BC consists of the following packages;

public-types-lib Public shared types. README

domain-lib Domain library types. README

implementations-lib Implementations library. README

scheduling-api-svc HTTP service for scheduling BC. README

event-handler-svc Event handler service for scheduling BC. README

command-handler-svc Command handler service for scheduling BC. README

Running Locally

Please follow the instruction in Onboarding Document to setup and run the service locally.

Configuration

See the README.md file on each services for more Environment Variable Configuration options.

Logging

Logs are sent to standard output by default.

Tests

Unit Tests

npm run test:unit

Run Integration Tests

npm run test:integration

Run all tests at once

Requires integration tests pre-requisites

npm run test

Collect coverage (from both unit and integration test types)

After running the unit and/or integration tests:

npm run posttest

You can then consult the html report in:

coverage/lcov-report/index.html

Auditing Dependencies

We use npm audit to check dependencies for node vulnerabilities.

To start a new resolution process, run:

npm run audit:fix

You can check to see if the CI will pass based on the current dependencies with:

npm run audit:check

CI/CD Pipelines

Execute locally the pre-commit checks - these will be executed with every commit and in the default CI/CD pipeline

Make sure these pass before committing any code

npm run pre_commit_check

Work Flow

As part of our CI/CD process, we use CircleCI. The CircleCI workflow automates the process of publishing changed packages to the npm registry and building Docker images for select packages before publishing them to DockerHub. It also handles versioning, tagging commits, and pushing changes back to the repository.

The process includes five phases.

1. Setup : This phase initializes the environment, loads common functions, and retrieves commits and git change history since the last successful CI build.

2. Detecting Changed Package.

3. Publishing Changed Packages to NPM.

4. Building Docker Images and Publishing to DockerHub.

5. Pushing Commits to Git.

All code is automatically linted, built, and unit tested by CircleCI pipelines, where unit test results are kept for all runs. All libraries are automatically published to npm.js, and all Docker images are published to Docker Hub.

Documentation

The following documentation provides insight into the scheduling Bounded Context.

• Reference Architecture - https://mojaloop.github.io/reference-architecture-doc/boundedContexts/scheduling/
• MIRO Board - https://miro.com/app/board/o9J_lJyA1TA=/
• Work Sessions - https://docs.google.com/document/d/1Nm6B_tSR1mOM0LEzxZ9uQnGwXkruBeYB2slgYK1Kflo/edit#heading=h.6w64vxvw6er4