To install NodeJS dependencies, execute in the accounting-proxy folder:
npm install
All the Accounting Proxy configuration is stored in the config.js file in the root of the project folder.
In order to have the accounting proxy running there are some information to fill:
config.accounting_proxy: the information of the accounting proxy itself.https: set this variable to undefined to start the service over HTTP.enabled: set this option to true to start the service over HTTPS and activate the certificate validation for some administration requests (see Proxy API).certFile: path to the server certificate in PEM format.keyFile: path to the private key of the server.caFile: path to the CA file.
port: port where the accounting proxy server is listening.
{
https: {
enabled: true,
certFile: 'ssl/server1.pem',
keyFile: 'ssl/server1.key',
caFile: 'ssl/fake_ca.pem'
},
port: 9000
}
config.database: database configuration used by the proxy.
type: database type. Two possible options:./db(sqlite database) or./db_Redis(redis database).name: database name. If the database type select is redis, then this field select the database (0 to 14; 15 is reserved for testing).redis_host: redis database host.redis_port: redis database port.
{
type: './db',
name: 'accountingDB.sqlite',
redis_host: 'localhost',
redis_port: 6379
}
config.modules: an array of supported accounting modules for accounting in different ways. Possible options are:call: accounting incremented in one unit each time the user send a request.megabyte: count the response amount of data (in megabytes) and add to the actual accounting.millisecond: count the request duration (in milliseconds) between the request sending and the response receiving from the service.
{
accounting: [ 'call', 'megabyte', 'millisecond']
}
Other accounting modules can be implemented and added here (see Accounting module ).
config.usageAPI: the information of the usage management API where the usage specifications and the accounting information will be snet.host: API host.port: API port.path: path for the usage management API.schedule: defines the daemon service schedule to notify the usage accounting info. The format is similar to the cron tab format: "MINUTE HOUR DAY_OF_MONTH MONTH_OF_YEAR DAY_OF_WEEK YEAR (optional)". By the default, the usage notifications will be sent every day at 00:00.
{
host: 'localhost',
port: 8080,
path: '/DSUsageManagement/api/usageManagement/v2',
schedule: '00 00 * * *'
}
config.resources: configuration of the resources accounted by the proxy.contextBroker: set this option totrueif the resource accounted is an Orion Context Broker. Otherwise set this option tofalse(default value).notification_port: port where the accounting proxy is listening to subscription notifications from the Orion Context Broker (port 9002 by default).
{
contextBroker: false,
notification_port: 9002
}
config.api.administration_paths: configuration of the administration paths. Default accounting paths are:
{
api: {
administration_paths: {
keys: '/accounting_proxy/keys',
units: '/accounting_proxy/units',
newBuy: '/accounting_proxy/newBuy',
checkURL: '/accounting_proxy/urls',
deleteBuy: '/accounting_proxy/deleteBuy'
}
}
}
config.oauth2.roles: configuration of the OAuth2 roles. Default roles are:
{
oauth2: {
roles: {
admin: '106',
customer: '',
seller: ''
}
}
}
The Accounting Proxy can proxied Orion Context Broker and other components by changing some configuration parameters.
The Accounting Proxy supports Context Broker monitoring (API v1 and API v2). In order to configure the Accounting Proxy working with Orion Context Broker, configure the resources section of config.js file in the root of the project folder.
contextBroker: settruethis parameter.notification_port: port where the accounting proxy server is listening to subscription notifications.
{
contextBroker: true,
notification_port: 9002
}
In order to configure the Accounting Proxy working with other components just set to false the contextBroker option in theconfig.js:
contextBroker: setfalsethis parameter to disable the Context Broker accounting.- The rest of information in
config.resourcesis unnecessary in this case.
The authentication process is based on OAuth2 v2 tokens. The Accounting-Proxy expects that all the requests have a header x-auth-token containing a valid access token from the IDM or a authorization header containing bearer "token" where token is a valid access token from the IDM.
If the authentication process success, the Accounting-Proxy check the authorization. The Accounting-Proxy expects that all the requests have a header X-API-KEY containing a valid API-KEY corresponding to the requested service.
If the user is an administrator of the service, the administrator request must omit the "X-API-KEY" header. After the administrator request is authenticated, the request will be redirected to the service and no accounting will be made.
The accounting proxy supports accounting based on different units and there is a module for each accounting unit. Developers can implement their own accounting modules (see section Development). By default, all Accounting Proxy instances have three accounting modules:
call: accounting value incremented in one for each call to the service. If the Context Broker option is enabled, the accounting value will be incremented in one for each Context Broker notification.megabyte: accounting value incremented based on the amount of data (in megabytes) retrieved from the service (in megabytes). If Context Broker option is enabled, the accounting value will be incremented based on the amount of data (in megabytes) sended by each Context Broker notification.millisecond: accounting value incremented based on the request time (in milliseconds). If Context Broker option is enabled, the accounting value will be incremented based on the notification time (in milliseconds).
After installation, just execute:
node accounting-proxy
In order to manage servicies, use 'cli' tool. The available commands are:
-
./cli addService [-c] <publicPath> <url> <appId> <httpMethod> [otherHttpMethods...]: binds the public path with the url specified, the application ID (all request with an access token from a different application will be rejected) and the http method(s) specified. The public path valid patterns are the following:-
/publicPath: only the first part of the path. -
/this/is/the/final/resource/path?color=Blue&shape=rectangular: the complete resource path (absolute path). In this case, the proxy will use this path to make the request. Use this type of public paths to register URLs with query strings. For instance, a public path such as/public/pathis not valid. -
Options:
-c, --context-broker: the service is an Orion Context broker service (config.contextBrokermust be set totrueinconfig.js).
-
-
./cli getService [-p <publicPath>]: returns the URL, the application ID and the type (Context Broker or not) of all registered services.- Options:
-p, --publicPath <path>: only displays the information of the service specified.
- Options:
-
./cli deleteService <publicPath>: deletes the service associated with the public path. -
./cli addAdmin <userId>: adds a new administrator. -
./cli deleteAdmin <userId>: deletes the specified admin. -
./cli bindAdmin <userId> <publicPath>: adds the specified administrator to the service specified by the public path. -
./cli unbindAdmin <userId> <publicPath>: deletes the specified administrator for the specified service by its public path. -
./cli unbindAdmin <userId> <publicPath>: deletes the specified administrator for the specified service by its public path. -
./cli getAdmins <publicPath>: displays all the administrators for the specified service.
To display brief information: ./cli -h or ./cli --help. In order to get information for a specific command type: ./cli help [cmd].
Proxy's api is in port 9000 by default and root path /accounting_proxy/...
Used by the store to notify a new buy. If the accounting proxy has been started over HTTPS, these requests should be signed with the Store cert; otherwise, they will be rejected.
{
"orderId": "...",
"productId": "...",
"customer": "...",
"productSpecification": {
"url": "...",
"unit": "...",
"recordType": "..."
}
}orderId: order identifier.productId: product identifier.customer: customer id.url: base url of the service.unit: accounting unit (megabyte,call, ...).recordType: type of accounting.
Used by the store to notify a deleted buy. If the accounting proxy has been started over HTTPS, these requests should be signed with the Store cert; otherwise, they will be rejected.
{
"orderId": "...",
"productId": "...",
"customer": "...",
"productSpecification": {
"url": "..."
}
}orderId: order identifier.productId: product identifier.customer: customer id.url: base url of the service.
Used by the store to check if an URL is valid. This requests require the "authorization" header with a valid access token from the IdM and the user must be an administrator of the service. If the accounting proxy has been started over HTTPS, these requests should be signed with the Store cert; otherwise, they will be rejected.
{
"url": "..."
}Retrieve the user's API_KEYs in a json. This requests require the "authorization" header with a valid access token from the IdM.
[
{
"apiKey": "...",
"productId": "...",
"orderId": "...",
"url": "..."
},
{
"apiKey": "...",
"productId": "...",
"orderId": "...",
"url": "..."
}
]Retrieve the supported accounting units by the accounting proxy in a JSON. This requests require the "authorization" header with a valid access token from the IdM.
{
"units": ["..."]
}Accounting modules in the acc_modules folder should be implemented following the next code:
/** Accounting module for unit: XXXXXX */
var count = function (countInfo, callback) {
// Code to do the accounting goes here
// .....
return callback(error, amount);
}
var getSpecification = function () {
return specification;
}The function count receives two parameters:
countInfo: object with the following information:
{
request: { // Request object used by the proxy to make the request to the service.
headers: {
},
body: {
},
...
},
response: { // Response object received from the service.
headers: {
},
body: {
},
elapsedTime: , // Response time
...
}
}
callback: function, which is use to retrieve the accounting value or the error message. The function has 2 parameters:error: string with a description of the error if there is one. Otherwise,null.ammount: number with the amount to add to the accounting.
The function getSpecification should return a javascript object with the usage specification for the accounting unit according to the TMF635 usage management API (TMF635 usage Management API).
Finally, add the name of the developed accounting module to the config.modules array in the config.js file (the accounting module name is the name of the file, e.g. megabyte and megabyte.js) and restart the Accounting Proxy.
To run tests type:
npm test
File test/config_tests.js contains the configuration for the integration tests:
databases: defines databases used by integration tests. Possible options are:redisandsql.redis_database: by default integration tests use 15.redis_host: redis host for testing.redis_port: redis port for testing.accounting_proxy_port: port where the accounting proxy will run for testing.test_endpoint_port: port where the mock services will run for testing.
{
databases: ['sql', 'redis'],
redis_database: 15,
redis_host: 'local_host',
redis_port: 6379,
accounting_proxy_port: 9010,
test_endpoint_port: 9020
}
Test reporter generates a directory ./coverage with all the coverage information (coverage reporter is generated by Istanbul) and a xunit.xml file in the root directory of the project.
Last updated: _20/09/2016