Daemon Config File

Introduction

The below shows the difference between the config file of a daemon written without the composer, and the config file of a daemon written with the composer.

Config.js

module.exports = {
	type: 'daemon',
	prerequisites: {
		cpu: '',
		memory: ''
	},
	serviceVersion: 1,
	serviceName: "myDaemon",
	servicePort: 4022,
	errors: {
		400: "Failed to connect to Database!",
		402: "Error fetching Entries!",
		407: "Error Loading Model!"
	},
	schema: {
		"myCustomJob": {
			"l": "My Custom Job"
		}
	}
};

module.exports = {
	type: 'daemon',
	prerequisites: {
		cpu: '',
		memory: ''
	},
	serviceVersion: 1,
	serviceName: "myDaemon",
	servicePort: 4022,
	errors: {
		400: "Failed to connect to Database!",
		402: "Error fetching Entries!",
		407: "Error Loading Model!"
	},
	schema: {
		"myCustomJob": {
			"l": "My Custom Job",
			"mw": __dirname + "/lib/mw/job.js"
		}
	},
	dbs: [
        {
            prefix: "test_",
            name: "myDatabase",
            model: "mongo",
            multitenant: false
        }
    ]
};

As you can see the change is very minimal.

The composer asks you provided it with a new configuration entry dbs so that it knows what models and databases it should initialized and give them to you.

The composer also asks you provide one middleware file per JOB and it will load it for you at run-time when this JOB executes and in that middleware you write the business logic.

Databases

The config.js that is passed to the composer contains a new entry called dbs. This entry is not required if you were to build a normal SOAJS microservice or daemon.

The dbs entry stands for databases and disposes of a list of databases that the daemon you want to launch will use.

In Addition, each database entry is associate with a model where the the driver needed for NodeJs to communicate with this database exists.

The composer will Initialize and load it and give it you so you can use it in the middleware files.

The table below explains the properties of this new entry.