Jobs Server

The jobs server is used in recurring transfer to execute every transfer job without impacting the main API performance.

This server do all the logic behind the scenes, it do the transfer, update the transfer job data, create new transfer jobs and more.

Recurring Transfer Endpoint

This endpoints is called by the Processor Lambda, and receives the job id. Here is where all the processing of the transfer happens.

Possible scenarios: If everything goes well, the transfer will be reflected in the BaaS of your selection, and you will see the job change its status to FINISHED. If something happened with the transfer, for example the account doesn't have enough money or another similar reason. The job will change its status to FINISHED but it will save the response of the BaaS in the recurring_transfer_provider_status table. If the BaaS is down, for example it responds a 500. the job status will change to RETRY, and will follow the flow again. See the flow in the functionality section. If it happens more times than the allowed (by default 3), it will change the job status to FAILED. You can change how many retries you want with a configuration with these attributes:

{
    "provider": "RECURRING-TRANSFER",
    "name": "Attempts",
    "value": "5"
}

You should only modify the value for the quantity of retries you want.

Backup and Delete process

The backup and delete process is a cron job in this job server that executes every day at midnight. It helps to clean the recurring_transfer_job and recurring_transfer_provider_status table because the former tends to fill up very quickly, and the data cleaned is backed up in a S3 bucket in case it's necessary.

Data saved

The data is saved as CSV as seen in the image, and it also saves the timestamp of the last backup. The first time this job is executed saves the timestamp even if it doesn't backup data, but the future executions doesn't save if it doesn't do a backup.

You can add 2 environment variables to manage this backup and delete job:

RT_BACKUP_BEFORE_MONTHS=6
RT_MONTHLY_BACKUP=12

With RT_MONTHLY_BACKUP you can put every how many months you want the job to execute, and with RT_BACKUP_BEFORE_MONTHS you can change the quantity of months before the current date to backup.

For example: A RT_MONTHLY_BACKUP of 12 and a RT_BACKUP_BEFORE_MONTHS of 6 will save every job before 6 month every year.