...
This article describes how a Meridix Studio installation is connected against a Telepo BCS installation both regarding retrieval of CDR (Call Detail Record) information through the Telepo Web API and how the catalog synchronization is handled. This is the default "off-the-shelf" way of handling the integration but the handling can be customized if a customer has special requirements.
...
- The Meridix installation hosted off-site in Microsoft Windows Azure (possibly load balanced between multiple servers in the Azure data center)
- Meridix Studio HTTP HTTPS Web API - Synchronization feature *
- Meridix-Telepo Catalog synchronization manager *
- Meridix-Telepo CDR retrieval manager client *
- Meridix Import Service - Handles CDR parser and data back-end import *
- The on-site Telepo BCS Management-node(s)
- The HTTP Web API - Administration features
- The on-site Telepo BCS Service-nodes(s)
- The HTTP Web API - CDR retrieval feature
* Is installed and run off-site.
...
The CDR data is made available for external systems by Telepo BCS through a HTTP HTTPS based API. To get the CDR data a HTTP HTTPS request is made against each of the services nodes management node CDR APIs. The request need to include a valid system ticket that is defined in the file /opt/servicenode/application/conf/cdr-pipelines.xml on each service the management node. (See Telepo document TelepoBCS_CDRs_3.6.xxxx.pdf section 7.2 regarding path etc). This service ticket will be appended to the HTTP HTTPS request that will return CDR information in the Response body as comma separated data (CSV).
Example of the HTTP HTTPS request URL that is used:
http://servicenodemn_ip/api/admin/cdrs?year=2013&month=03&date=21&t=system_token_for_servicemanagement_node
Meridix has an application that makes these calls to each of the servicenodes management node from which CDR should be retrieved. The only technical requirement is that the servicenode management node IP address is accessible from the Meridix server (off-site). The access can be setup as a IP rule or through an VPN connection into the sub net where the Telepo service nodes reside. It is not recommended to make the servicenode publicly management node publicly available from the outside.The servicenode IP used in the request should be the HA address of the service node because the Telepo system handles the routing to the correct server (Primary or Secondary).
Example of a valid section that defines the token in the cdr-pipelines.xml
| Code Block |
|---|
<system-tickets>
<token>fsafghgdsfhjgfdjhvcir67iujytedrsf7eu65</token>
</system-tickets> |
Meridix requires
Meridix needs to have access to each of the servicenodes management node IP addresses address and have valid system tickets for each of themit.
No Meridix software needs to be installed on-site.
...
API calls made against the Administration API needs to be signed with an system ticket (token and secret combination) that has access to the Administration APIs.
| Info |
|---|
This only applies to Telepo versions prior to 4.0 SP2 One limitation in the Telepo API is that the orgId that maps the CDR logs with the organization that the belong to is not available through the API but since Meridix need to know each organizations orgId to be able to know which CDR logs that belongs to a specific organization this information need to be supplied as well. This mapping information between an organization usually identified by the domain and the corresponding orgId (integer) is available in the Telepo database. A commonly used solution to this is that a custom script is setup that writes this mapping (domain->orgId) to a csv file that is made available on a FTP share on-site (accessible from Meridix) or uploaded to a Meridix FTP server. An alternative approach is that each customer manually need to have the org id added in the Meridix user interface. (Only needed for active customers). |
The management API ticket need the be granted the following rights (see yellow marks).
Meridix requires
Meridix needs to have access to the managementnodes management nodes administration API and have a valid system ticket (token and secret) with access to the Administration API methods. This is a read only operation from Meridix so changes are never pushed back to Telepo from Meridix.
No Meridix software needs to be installed on-site.
...
If a Telepo system contains separate end customers that has their organizations provisioned on separate servicenodes, for example if Company A owns the Telepo system but Company B has its own part of the system with a custom branding etc. and all Company B data is located on a specific servicenode multiple completely separate Meridix Studio installations can be setup and allow Company A and Company B to have separate Meridix installations. This is possible since the catalog synchronization has information about which servicenode a organization resides in and the Meridix catalog synchronization can be setup in a way so that Meridix installation A only synchronizes organizations that is located on servicenodes that belongs to Company A and the organizations that belongs to Company B is synchronized against Meridix installation B which will then only contain information about Company Bs organizations.
This give a Telepo provider that for example have multiple resellers with their own branding the possibility to have their own report system as well.
Summary
No Meridix software needs to be installed on-site, the only requirements is that the management-node and the servicenodes is accessible from the Meridix off-site server and that Meridix has valid tickets and tokens for each of the required API operations.
| Requirement | Reason | Notes |
|---|---|---|
| IP address to the Management node Administration API. With access rights from the Meridix off-site server. | To allow catalog synchronization (organizations, user ids, function numbers) To allow retrieval of CDR information (call logs) | Access can be granted through IP access rules or through a VPN connection. |
| API Ticket (token/secret) with rights to access the administration API methods. | To be able to sign the requests |
| . | |
| System token for |
| the management node. | To be able to make the CDR API calls. |
| Organization domain to org id mapping | To be able to add the missing mapping between the CDR logs and the catalog data. | This is optional since it can be handled manually but its recommended that its automated to minimize errors. |
The following information should to be supplied to Meridix.
| Type | |
|---|---|
| The management-node IP addresses HA, Primary and Secondary | IP addresses |
| System ticket | Ticket (token and secret |
| ) | |
| Information about mapping | (depends on customer preference) |
...