2 Rest Endpoints

MC2 provides various multi-tiers Rest endpoints for various interfaces such as generic load, extract, health check, etc. That means, per rest request from IIS frontend, it will route through multiple endpoints to complete a rest request.

Endpoints can be accessed from the following interfaces:

• IIS Frontend (for Eagle V17+ only) 
• MC2 backend

// pic of multi-tiers endponts

MC2 Rest API quick access guide

Starting from Eagle V17, MC2 provides varsome quick ways to diagnose and validate if all configuration is accurate and rest services are up and running.

• Validate by access provided URLs from browsers or tools such as browser, curl command line, etc.
• Check the health check responding Rest status 

Web Server Frontend URLs (for Eagle V17+ only)

URLs provides from webserver frontend are:

http://{webserver}/eagle/v2/api-doc

https://{webserver}/mc2/swagger-ui.html or http://{webserver}/mc2/swagger-ui.html

or more extract specific URLs such as:

https://{webserver}/eagle/v2/accounting-basis?streamName=eagle_ml-2-0_default_out_extract_service&outputFormat=json"

for OLAP

App Server Backend URLs

Following URLs also available from backend directly:

http://{webserver}:{rest_port}/eagle/report/v1/adhocReport/correlationId?statusonly=1

Troubleshooting guide

Due to the multi-tiers nature, when encounter any failure when access MC2 Rest API, it needs to diagnose endpoint by endpoint of each API route.

URL's below can be one of the quick way to validate if the rest endpoints is actively listening to request:

Configuration and Setup

IIS Frontend (... list the url ...)

Reference ... for the configuration guide

MC2 backend (....)

Reference ... for the configuration guide

Runtime

IIS Frontend (... list the url ...)

Reference ... for the configuration guide

MC2 backend (....)

Reference ... for the configuration guide

Direct backend access

API Setup and Access

1. Is the URL correct?

   Make sure you're using the correct URL with the HTTPS protocol and the correct POD number:

   https://restapi{PODnumber}.jasper.com/rws/api/v{apiVersion}/

   Check with your operator if you're unsure about the POD number.

2. Is the API license key valid?

   Each user has a unique license key that you can find in the user profile (click the Show REST API key button to see it) or at the top of each REST API function page in the Knowledge Base. Users in the same account cannot share API keys.

3. Is the authorization header valid?

   Ensure that you followed the 3-step process for creating a valid authorization header: (1) concatenate the user name and API key (separated by a colon) (2) encrypt the resulting string using Base64 (3) set the authorization header value to "Basic" followed by the encoded string.

4. Does the API user have feature access?

   To validate feature access, log into CC/SM using the API user and try to access the same feature in the web interface. (Remember the CC/SM password is different from the API key.) If you can make the feature work in the web interface, you can make it work via API.

   You may need to use multiple user roles as there is no single role that will guarantee access for all API function calls. Cisco Jasper recommends creating a dedicated user or group of users whose sole purpose is to execute API functions. For more information about user roles and access, see REST API/Role Matrix .

5. Is the SSL certificate valid and included in your trusted store?

   The REST APIs support the HTTPS protocol (not HTTP). The Cisco Jasper API server uses an SSL certificate signed by Symantec, a well-known Certificate Authority (CA), to handle HTTPS access. We recommend that you include the Symantec Root Certificate in your trust store (this is included by default on many platforms) and use a CA-based chain of trust, rather than hard coding the Cisco Jasper certificate in your API code.