Over the last 12 months we’ve made some updates to our CDR API code internally. We’ve previously released the code as a ZIP file from our helpdesk.realworld.net.au website. To simplify updates, we’ve migrated the code in source form to GitHub. We’ve included build code to allow customers to produce a Docker Image, which is our preferred way to use it. You can get it at:
https://github.com/realworldtech/smile-cdr-api
How to use
To use, assuming you are using a Unix style CLI, with docker compose installed.
git clone https://github.com/realworldtech/smile-cdr-api.git
cd smile-cdr-api
docker-compose build app
You need to provide your API username, passsword and Master USN (which is provided by Real World) in the env.env file included as part of this code set.
cp env.env .env
Edit .env using your favourite text editor to enter the correct details.
Once you have done this, you can run the code set, which will by default retrieve CDR records for the last month and place a CDR file for each username in a directory inside the output directory.
To do this run:
docker-compose run --rm app
If you need a combined file for your billing system, you can create one after your content download by running
docker-compose run --rm app -cWhat has changed from the previous code releases
We have been internally using this version of the code for some months and providing to customers if they have encountered issues with the previously published versions of the code.
The changes from the previously published version specifically:
- address bugs relating to PHP on Mac OS High Sierra, where we noticed that SSL sessions would randomly be closed. We were able to replicate this on builds of PHP on Ubuntu and CentOS. The Docker image allows us to pin to package versions that are known to be working
- address issues with services that have been closed. Previous releases of the code would download the last usage period for a service, even if that usage period was before the billing period being downloaded. The updated code now checks to make sure that the billing period is current
- allow customers to combine usage data into a single file once downloaded by passing the “-c” option as reflected in the README.
What is next?
We’ve always been aware that customers would want to integrate this process as part of their billing cycles and systems. We’re looking at ways to make this available as a micro application that can be executed on demand.
In particular, we’re looking at options to speed up the execution. One option includes allowing billing data to be downloaded against an invoice from RWTS rather than against each individual service. This currently requires a user to know the Invoice Number they are trying to download against, which reduces the automation potential of the API.
We’re considering an option to allow the download of unrated CDR files without modifying the included source files.
We’ve been developing a SMILE API abstraction library in Python for the last 2 years. We’re expecting that we may migrate the code base across to Python at some stage in the future in line with our future development efforts.