...

This is from a customer perspective and only sub-systems that partake in the integration process is included

• The Meridix installation hosted in off-site in Microsoft Windows Azure (possibly load balanced between multiple servers in the Azure data center)
  • Meridix Studio HTTP Web API - Synchronization featurefeature *
  • Meridix-Telepo Catalog synchronization managermanager *
  • Meridix-Telepo CDR retrieval manager *
  • 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 integration consists of two separate parts where one part handles the synchronization of the catalog data from the Telepo BCS platform and the other part handles the retrieval and importing of CDR data from the Telepo BCS platform to the Meridix data back-end. Each of these parts is described in the following sections:

CDR Retrieval

The CDR data is made available for external systems from by Telepo BCS through a HTTP based API. Where To get the CDR data a HTTP request is made against each of the services nodes CDR APIAPIs. The request need to include a valid system token ticket that is defined in the file /opt/servicenode/application/conf/cdr-pipelines.xxml on each service node. (See Telepo document TelepoBCS_CDRs_3.6.xxxx.pff section 7.2). This service token ticket will be appended to the HTTP request that will return CDR information in the Response body as comma separated data (CSV).
Example of the HTTP request url URL that is used:

http://service_nodeservicenode_ip/api/admin/cdrs?year=2013&month=03&date=21&t=system_token_for_service_node

Meridix has a an application that makes these calls to each of the service nodes servicenodes from which CDR should be retrieved. The only technical requirement is that the service node servicenode 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 subnet sub net where the Telepo service nodes reside. It is not recommended to make the service node servicenode publicly available from the outside.

The service node 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).

...

Meridix needs to have access to each of the service nodes servicenodes IP addresses and have valid system token tickets for each of them.
No Meridix software needs to be installed on-site.

Catalog synchronization

Meridix is used as a slave catalog to the (master) Telepo catalog and synchronizes changes made in Telepo at a defined interval (usually once every 24 hours, but can be done more often if required). The information that Meridix loads from Telepo is used in a read only way i.e. changes is never published from Meridix back to Telepo.

...

This information is exposed by Telepo through their Web API and multiple calls need to be made against the API to get all the required information. This is also handled by an off-site Meridix software that uses the Administration API part on the Management management-node. Since only the User API is by default publicly available on a Telepo installation the off-site Meridix server need to have access to the HA address of the management node.

...

Meridix needs to have access to the management nodes managementnodes 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 no changes are ever never pushed back to Telepo from Meridix. 
No Meridix software needs to be installed on-site.

Multiple Meridix Studio installations for one or multiple Telepo service nodesservicenodes

If a Telepo system contains separate end customers that is has their organizations provisioned on individual service nodes 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 service node servicenode multiple completely separate Meridix Studio installations can be setup and give allow Company A and Company B to have separate Meridix installationinstallations. This is possible since the catalog synchronization has information about which service node servicenode a organization resides in and the Meridix catalog synchronization can be setup in a way such so that Meridix installation A only synchronized synchronizes organizations that is located on service nodes 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 customers ( 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.

...

No Meridix software needs to be installed on-site, the only requirements is that the Management management-node and Service nodes need to be the servicenodes is accessible from the Meridix off-site server and that Meridix has valid tickets and tokens for each of the required API operationoperations.
 

The following information should to be supplied to Meridix.