Product Documentation

Openmix

Openmix Applications

Openmix Quickstart applications are load balancing and traffic management applications that provide real-time traffic routing to the best provider based on a set of rules.

The applications are processed for each request made to Openmix and a routing decision is made based on the specified logic. A customer may have one application for one type of content that has high business value, and a different application for content that has a lesser value that should be routed differently.

When an application is invoked, a decision is made i.e. a single request is sent to one of Citrix’s load-balancers. For DNS, it is a single DNS request to the DNS load-balancers. For HTTP, it is a GET or HEAD request to the Openmix HTTP endpoint.

The following apps are currently available through the Intelligent Traffic Management Portal.

  • Static Routing
  • Failover
  • Round Robin
  • Optimal Round Trip Time (ORTT)
  • Throughput

Openmix Custom JavaScript applications are used by specialized Openmix servers to respond to DNS or HTTP requests based on the logic in the scripts. Deployment of the scripts is done via the customer portal where the app is configured and published. For more information on the ability to create your own JavaScript scripts, please refer to the information at our Developer Exchange.

Before you go ahead with setting up the apps, it is important to understand the following concepts:

Availability Threshold

The availability threshold is the minimum availability score that a platform should meet in order to be considered for routing. The default minimum availability threshold for all applications is 80%. However, you can modify this percentage and set it to a value that is appropriate for your location, network availability, and reliability.

Note: If no platform meets this minimum Availability threshold (the default of 80%, or the value that you set), random routing is done for Round Robin, ORTT and Throughput applications.

Fallback

The fallback response is usually returned if the Openmix application does not run successfully for whatever reason; or if Sonar confirms that there are no available platforms. Therefore, a valid fallback CNAME/A/AAAA record or IP (or path in case of HTTP) must be specified with which Openmix can respond. This fallback URL or CNAME record may or may not be for a platform that is pre-configured in Openmix. Fallback sometimes occurs during the following scenarios as well:

  • When there is a switching between versions of your application, i.e. when you upload and publish a new script, it may lead (but not always) to a very brief (milliseconds) time period of fallback as the new script is being initialized after the old one is removed.
  • If ever there is an overload (which rarely happens), Openmix responds with the fallback CNAME/A/AAAA since fallback offsets the load on the service.

For fallback, you must enter a valid hostname (CNAME/A/AAAA record) or IP address in case of DNS, and a valid URI (it can be of the form, scheme:[//host[:port]][/path][?query][#fragment]) in case of HTTP.

TTL

In Openmix, the DNS Time to Live (TTL) for the application tells resolvers how long they should keep the decision before asking Openmix again. The TTL is basically used to:

Control the volume of traffic an Openmix app gets, and Control how sensitive an app should be to changes in the data that it acts upon. The default TTL is 20 seconds. Although you can modify this value, it is not recommended to do so. If you lower the TTL you get more volume and more real-time DNS queries. But it may lead to added costs and lower performance (because DNS queries take time on the client). Therefore, it is best not to change the default value of TTL.

Weights (Used for Round Robin)

You can assign weights for the prioritization and selection of each platform globally and/or by market or country.

For example, say you have three platforms selected for your application - P1, P2, and P3. You give them the weights: 60, 50, and 10 respectively. The Round Robin app converts these values to percentages such that, P1=50%, P2=42%, and P3=8% (which now add up to a 100%). This means that approximately 50% of the time, users would be routed through P1; approximately 42% of the time through P2; and approximately 8% of the time through P3.

The weights you give to the platforms do not have to add up to 100. They can be any integer between 0 and 1,000,000. The weights given to the platforms when converted to percentage (by the app in the back-end), will add up to a 100%. If all selected platforms are given the same weight, traffic will be evenly distributed across them over time. If you have only one platform, then that one will be used 100% of the time, regardless of the weight you give it.

Weights are only used for platforms that are considered to be available according to Radar and Sonar availability checks, depending on the configuration of the application. Unavailable platforms will cause the distribution to not match the configured weights. For example, if P1 is weighted 100 and P2 is weighted 0 but P1 fails the Radar Availability check, all traffic will be sent to P2.

Handicap (Used for ORTT and Throughput)

The Handicap is a percentage value that can be applied to a platform to modify the radar scores for RTT and throughput i.e. artificially increase the response time (in milliseconds) or decrease the throughput (in kbps). Increasing or decreasing these values will bring down the performance of the platform such that the likelihood of it being picked will become lower. Handicaps can be added to platforms globally, or separately for specific markets and/or countries. It is useful in cases where, for example, one platform is expensive (maybe in a specific market/country) and you want to reduce the likelihood of it being picked when an equivalent provider is close enough in terms of performance. So you put in a Handicap value (in percentage) that acts as a multiplier to increase the value of response time or decrease the value of the throughput, as a result, lowering the probability of that platform being picked.

This is roughly how Handicap works in the back-end:

  • Platform RTT with Handicap applied = RTT (Round Trip Time in milliseconds) *( 1 + Handicap) or
  • Platform Throughput with Handicap applied = (Throughput in kbps) *( 1 – Handicap)

Note: The RTT and Throughput values for the platform are scores from Radar data. The following table shows how Handicap effects the two platforms - P1 and P2. And how the Handicap decreases the likelihood of P1 being picked.

  P1 P2
RTT without Handicap 50 milliseconds 60 milliseconds
RTT with 50% (0.5) Handicap for P1, and 0% (0) for P2 50(1+0.5)= 75 milliseconds 60(1+0)= 60 milliseconds
Throughput without Handicap 3000 kbps 2800 kbps
Throughput with 50% (0.5) Handicap for P1, and 0% (0) for P2 3000(1-0.5)= 1500 kbps 2800(1- 0)= 2800kbps

Filtering, Ranking, and Selection Workflow

Sample Flow diagram for Throughput App

Sample Flow diagram

Platform Selection Criteria

Openmix Quickstart apps use the following criteria as 1st, 2nd and 3rd level filters to rank and select the best platform.

Filtration Level Selection Criteria ORTT Throughput Round Robin Failover Static Routing
1st level Sonar Availability Check (if enabled) X X X X X
2nd level Radar Availability Check (if enabled) X X X X X
3rd level Weights (user defined) NA NA X NA NA
3rd level Round Trip Time (in milliseconds) X NA NA NA NA
3rd level Throughput (in kbps) NA X NA NA NA

Reason Code Reporting

Reason codes are a way of providing visibility into why the app made the decision it did, and also knowing what parts of the app’s code was executed. During execution, an app can add something to the reason code field at any time. Reason codes mean different things for each Quickstart App. There may be some commonality between reason codes for each app, but it is not comprehensive.

These are the reason codes for the Quickstart Apps:

App Reason Code Logic  
Static Routing Routed by static app A single specified platform is always selected.  
Round Robin Routed by weighted round robin with Radar availability All platforms that meet the availability threshold are first chosen. On those platforms, round robin distribution methodology is applied. For example, if platforms P1, P2 and P3 meet the availability threshold —the first request is routed to P1, second to P2, third to P3, fourth to P1 again, and so on.  
    Routed to fallback due to zero weight If all the platforms have been given zero weight, then fallback is returned. For example, if all platforms have been set to a zero weight in China and a DNS/HTTP request comes from China, none of the platforms will be eligible for selection due to a zero weight. A fallback is returned in this case.
    Routed by weighted round robin Routed based on round robin distribution methodology. Here, there is no availability threshold specified so the first level of filtering based on availability doesn’t happen.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.
ORTT Routed based on Radar HTTP availability data All platforms that meet the availability threshold are first chosen. Out of these platforms, the platform with the lowest RTT value is chosen.  
    Routed to fallback due to sonar availability Sonar says that the platform is down, therefore it is routed to fallback.
    Routed to fallback no available platforms None of the platforms specified in the app have Radar Availability at or above the availability threshold.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.
Throughput Routed based on Radar http_kbps and Availability All platforms that meet the availability threshold are first chosen. Out of these platforms, the platform with the highest throughput in the case of http_kbps is chosen.  
    Routed based on Radar http_kbps data The platform with the highest throughput in the case of http_kbps is chosen.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.

Openmix Quickstart Applications

  1. Log in to the Intelligent Traffic Management Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. If you are configuring your Openmix app for the first time, you will see the Get Started page, when you click Openmix > Application Configuration.
  4. To configure a new app, either click the Get Started button or the Add button on the top right corner of the page. If Openmix apps have been configured previously, you will see a list of apps on this page.

The following sections will walk you through the process of configuring Openmix apps in the portal.

Static Routing

This type of application does not use any evaluative logic to decide which DNS response should be provided to the end-user. The app always selects a single platform here, specified by the user. Therefore, only a single DNS CNAME or IP address response is utilized by the app.The Static Routing application can be configured through the portal on the Application Configuration page.

Note: Before configuring your application, ensure that your platforms are first configured. See Platforms page for platform configuration.

  1. Navigate to Openmix > Application Configuration.
  2. Click on the Add button on the top right

The Basic Information dialog box opens.

Basic Information

Follow these steps to enter Basic Information:

  1. For Protocol, select DNS or HTTP from the dropdown.
  2. For Application Type, select Static Routing. Or if you’re configuring another type of app, select it from the dropdown list.
  3. Give a Name to your application (required field); add a Description (optional field); and a Tag (optional field).
  4. Click Next for Configuration.

Configuration

To configure the app, do the following:

  1. Select the associated platform from the Platform dropdown. This will be the platform you set up within the Platforms page, representing the CDN, Cloud, or Data Center.
  2. Enter a CNAME/A/AAAA record (for DNS) or URL (for HTTP). The DNS CNAME or HTTP URL for the selected platform must point to a valid IP address or hostname.
  3. For CORS, (in case of an HTTP protocol) select None, All or Custom for CORS. CORS allows you to control access to your site from other sites. You can either completely restrict access to your site from other sites (by clicking None), allow access from all other sites (by clicking All), or allow access only from specific sites (by clicking Custom).
  4. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds but it can be overridden.
  5. Click Complete .
  6. In the confirmation pop-up click Done or Publish to see your app listed in the Openmix applications page. If you click Publish, your app will go live instantly and have a green status. This means that the application is currently in production. If you click Done, your app will still be listed on the applications page but it will be unpublished, and the status will be red.

Failover

The Failover application supports a simple routing logic where a platform is chosen based on its place in line, and its availability. The customer can create a failover chain that will decide which platform to select first, second, and so on. This failover chain can be created to work globally and/or for individual markets and countries.

The Failover application can be configured within the portal on the Application Configuration page.

Note: Before configuring your application, ensure that your platforms are configured first. Refer to the Platforms page for platform configuration.

  1. Log in to the Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. Click on the Add button on the top right to get to the New Openmix Application, Basic Information dialog box.

Basic Information

  1. Select DNS from the Protocol dropdown.
  2. From the Application Type dropdown, select Failover.
  3. Give a Name (required field) to your application; add a Description (optional field); and a Tag (optional field).
  4. When done, click Next.

Failover Basic Information

Configuration

  1. In the Configuration dialog box, select the Availability Threshold checkbox. The Availability Threshold has a default value of 80%. This means that a platform must have availability score at least as high as this threshold in order to be considered for routing.
    • If you want to modify the default availability threshold, just type in a new value to replace the default.
    • If no platform has an availability score that is equal or greater than the specified threshold, then the fallback (CNAME/A/AAAA or IP address) is used.
    • If the checkbox is unselected then the platform assumes a zero availability threshold. This means that there will be no Radar availability check on this platform.
  2. Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  3. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds. You can override this value if required.

Failover Configuration

Platform Information

  1. In the Platform Information dialog box, select a Platform from the dropdown list.
    • You can select multiple platforms using the Add Platforms button. The idea is to select all available platforms applicable for global and geo (markets and countries) routing.
    • The platforms on this list are those that you set up in the Platforms page (within the portal), representing your CDN, Cloud, or Data Center.
    • All Openmix apps require an associated platform to be set up beforehand. If you don’t find a platform in the dropdown list, you can set it up in the Platforms page within the portal.
  2. Enter the CNAME/A/AAAA record for the platform.
  3. Ensure that the Enabled checkbox is selected (indicating that the platform is enabled) before moving to the next step.
  4. If Sonar is configured and you want to use Sonar data to help in the initial decision making process, make sure to click the Use Sonar for Platform Availability checkbox. Note: The Sonar checkbox appears only if Sonar is enabled for that platform.
  5. Click Next for Location Configuration.

Location Configuration

  1. In the Location Configuration dialog box, select the required platforms for Global routing.
    • Global indicates that you are setting up a chain of platforms for global routing.
    • When you click inside the Global field, a dropdown list displays all the platforms you selected in the Platform Information step.
    • Select the required platforms from the list for availability-based global routing.
    • The order in which you place the platform names in this field will determine the priority for their selection i.e. they will be selected from first to last based on availability. For example, if the first platform on your list is unavailable, the second will be selected and so on. If none of the platforms on the list are available, then fallback will be used.
    • You can drag and drop the platform names to change their order of priority.
  2. Click on Markets & Countries if you would like to set up platforms for local geo routing.
    • When you click inside the Markets & Countries field, the dropdown list displays all the platforms you selected in the Platform Information step.
    • Select platforms for local geo routing, separately for each geo (market/country).
    • The order in which you place the platform names in this field will determine the priority for their selection i.e. they will be selected from first to last based on availability. For example, in China, you may want to use the China POP first, and only if that is not available, you would want your Singapore POP to be used, which you would place next in line, and so on.
    • You can drag and drop the platform names to change their order of priority.

    Failover Location Information

  3. Click Complete, to finish configuring your app.
  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix page.
    • If you click Publish, your app will go live instantly and have a green status. This means that the application is currently in production.
    • If you click Done, your app will still be listed on the Openmix page but it will be unpublished, and the status will be red.

Round Robin

This application follows a typical Global Server Load-Balancing methodology of Round Robin, where each CNAME alternates being returned to end-users, as DNS requests are made. It uses Sonar data (if Sonar is enabled) and Platform Availability threshold to evaluate the best platform for the requesting user at that point in time. Each platform is selected based on the Round Robin distribution methodology. For example, if platforms P1, P2 and P3 meet the availability threshold —the first request is routed to P1, second to P2, third to P3, fourth to P1 again, and so on.

To configure a new Round Robin app, click the Add button on the top right corner of the Openmix page. The Basic Information dialog box opens up.

  1. Log in to the Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. Click on the Add button on the top right to get to the New Openmix Application, Basic Information dialog box.

Basic Information

  1. In the Basic Information dialog box, select DNS as the Protocol for Round Robin.Note: For the Round Robin app, routing is available only via a DNS CNAME.
  2. Select the Application Type from the dropdown. Give the app a Name (required field), a Description (optional field), and a Tag (optional field).
  3. Click Next for Configuration.

Configuration

  1. The Availability Threshold has a default value of 80%. To modify this value, just type in a new value to replace the default.
  2. Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  3. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds but this value can be overridden if required.
  4. Click Next for Platform Information.

Platform Information

  1. Select a platform from the Platform dropdown menu. Note: All Openmix apps require an associated platform set up beforehand. If you don’t find a platform in the dropdown menu, you can set it up in the Platforms page within the portal.
  2. Select additional platforms by clicking the Add Platform button.
  3. Enter a CNAME or an A/AAAA record or IP (in case of DNS), or URL (in case of HTTP) for this Platform. It must be a valid URL, hostname, or IP address. It can be of the form: scheme:[//host[:port]][/path][?query][#fragment].
  4. Ensure that the Enabled checkbox is selected (indicating that the platform is enabled) before moving to the next step.
  5. If Sonar is available, and you want to use Sonar data to help in the initial decision making process, make sure to click the Use Sonar for Platform Availability checkbox.
  6. Click Save to go to Step 4 to assign appropriate weights for each platform.

Location Configuration

  1. Assign Weights for the prioritization and selection of each platform globally and/or by market or country.
  2. To assign platform weights separately for market or country, enter the name in the Markets & Countries search box and choose from the dropdown list.
  3. Click Complete for your application to be created.
  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix page. If you click Publish, your app will go live instantly and have a green status. This means that the application is currently in production. If you click Done, your app will still be listed on the Openmix page but it will be unpublished, and its status will be red.

Optimal Round Trip Time (ORTT) App

The ORTT app uses Radar Response Time, Sonar data (if Sonar is enabled) and the Platform Availability threshold to evaluate the best platform for the requesting user at that point in time. The availability threshold is the minimum availability (80% is the default value) that the platform should meet in order to be picked. In addition, the ORTT app also uses a Handicap value that can be included globally and/or locally (for specific markets or countries) in order to allow customers to influence how end-users are routed.

The first three steps – Basic Information, Configuration, and Platform Information, are entered in the same manner as the other apps.

Follow these steps to configure location information and enter values for Handicap for each platform, globally, or by location/market.

Location Configuration

  1. In the Location Configuration dialog box, enter a value for Handicap for one or all of the platforms selected. You can enter a handicap value between 0 and 6000. The use of the handicap is to manually lower the chances of a particular platform being picked for routing, when there are better platforms available, in terms of cost or convenience for example. The more the handicap value, the lesser the chance of the platform being picked. You can deselect a platform if required by turning off the Platform Selection button.

  2. Click on Markets & Countries to select a particular market or country from the list and enter Handicap values separately for each of the associated platforms.

  3. Click Complete, to finish configuring your app.

  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix applications list page. If you click Publish, your app will go live instantly and have a green status. This means that the application is currently in production. If you click Done, your app will still be listed on the Applications page but it will be unpublished, and its status will be red.

Throughput

The Throughput app selects the platform based on Sonar data (if Sonar is enabled), highest throughput (using Radar data), and platform availability threshold (which is 80% by default). In addition, this app allows you to add a Handicap value to decrease the throughput for specific platforms and influence how end-users are routed. This optional Handicap value can be assigned globally and/or locally (for specific markets or countries).

The first three steps – Basic Information, Configuration, and Platform Information, are entered in the same manner as the other apps. The Location Configuration is entered in the same way as in the ORTT app.

When you’re done, click Complete to return to the Openmix applications list page. Finally, click Publish to publish your application when you are ready to go live.

Status of the application

The status of the app shows its current configuration.

  • Red stands for unpublished. When you complete configuration, if you click Done, your application will be listed in the applications page with a red dot, denoting that it has not been published yet.
  • Green stands for published. If you click Publish your app will go live instantly, and be denoted with a green dot which means that the application is currently in production.
  • Yellow stands for latest version unpublished. The yellow dot indicates that the application was created and edited, and the last modified settings are not yet published.

Managing Quickstart Applications

You can manage Openmix applications (editing, duplicating, deleting, and testing); and also view reports, view source and view the application’s version history using the top tabs within the application manager panel. Click on your application in the Openmix applications list page to expand the application manager.

Managing Openmix Applications

View Report

View Report takes you to the Openmix Decision Reports page where you will be able to view the trend of Openmix decisions for each of your applications, platforms and geographies.

Edit

To edit your Openmix app, simply click the Edit icon on the top of the application manager panel. You can also perform individual edits separately for basic information, configuration, platform, or location information by clicking the Edit buttons within the panel as shown in figure. When you finish editing, click Done, to list the app with an unpublished status (for more edits later), or click Publish to go live instantly.

Duplicate

Click Duplicate to replicate the configuration of the current application and save it with a new name.

Delete

Click Delete, to remove applications that you no longer need.

Publish

Click Publish to directly publish the application from the Openmix application manager. This option will be visible only if the app is not yet published.


Openmix Custom JavaScript Applications

Openmix JavaScript applications are apps with fully customizable Java scripts that you can create, configure, test, and publish using the UI in the ITM (Intelligent Traffic Management) portal.

Note: This guide does not cover the actual creation of the custom script (syntaxes, variables etc.). For more information on creating custom JavaScripts, please refer to the Developer Exchange.

  1. Log in to the ITM portal.
  2. From the left navigation menu, go to Openmix.
  3. Choose Application Configuration.
  4. To configure a new Openmix app, click the add icon on the top right corner.
  5. Select Custom JS App.
  6. The Openmix Application Configuration page opens.

Add Custom JS App

Basic Information

  1. Application Name: Give a name to your app.
  2. Description: Give the app a description or add a release note here. This is an optional field.
  3. Tags: Enter an appropriate tag, if required. Tags help to identify and organize your app. This is an optional field.
  4. Fallback: Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  5. Protocol: Select DNS or HTTP as the protocol.
    • DNS: If you select DNS, a TTL value must be entered.
      • TTL: Enter a DNS Time to Live for the application. 20 seconds is the recommended value.
    • HTTP: If you select HTTP, you have the option to enable Secure Access.
  6. Secure Access: If Secure Access is enabled, the HTTP API must require an Oauth access key from the client when being called. Refer to Securing Openmix HTTP API to learn more.

    Note: With secure access is enabled, a lock icon will be displayed next to the app name in the list of apps on the Openmix front page.

Basic Info

Platforms

  1. Choose a platform from the Platforms drop down list. This is the platform you set up within the Platforms page, representing your CDN, Cloud, or Data Center. You can select multiple platforms and enable them to be available for the app.

    You can also select a community platform that has not yet been setup in your account. If you select a platform that has not already been setup in your account, you have the the option of configuring it here, on the fly. Just select the platform from the list of community platforms and confirm that you want to configure it.

    Platform Confirmation

    It will be added to your account and listed on the Platforms page.

  2. Enter a CNAME/A/AAAA record (for DNS) or URL (for HTTP). The DNS CNAME/IP or HTTP URL for the selected platform must point to a valid address or hostname.

  3. Platforms are enabled by default. To disable a specific platform, click the toggle switch under Enabled.

  4. Click the trash icon under Actions to remove the platform.

Add Platform

Custom JavaScript

Once you enter the configuration information, you can upload your custom JavaScript.

  1. Click the Choose File button and select the JavaScript file that you want to upload. You can upload a new file to overwrite an existing one at any time.

  2. Click Save & Test to save your application.

    Note: The application is automatically tested using an application checker when it is uploaded and saved. If there are errors, the application checker will show the error information and the location of the error. Refer to the Application Verification section for more information about the data available from the application checker.

    Publish

  3. Click Cancel to return to the Openmix Applications page or click Publish if you are ready for the application to go live.

    Note: If you click Publish, your app will go live instantly and have a green status. This means that the application is currently in production.

    If you click Cancel, your app will be listed on the applications page but will be unpublished, and the status will be red. To learn more about status refer to the Status of the Application section.

Publish

Test

You can test your JavaScript application using the Test App button before or after publishing.

Test

It enables you to view test results across specific sets of markets, countries, regions, and states. You also have an option to query the app from specific IP addresses.

Test results include, Platform selected by the app, Response received, Reason Code, Reason Log, Radar Scores, Distribution etc.

This feature also allows you to view the distribution of decisions across different platforms. For example, if two platforms were used for routing, you can view the number of decisions (raw count, and in percentage) and the response received for each of them.

Click the Show All Details link to see the test results of your app.

Test Details

The following values are shown as test results:

Field Description
Market, Country, Region, and State The location at which the app was tested.
Platform The platform selected by the app.
Response The CNAME or IP address of the platform selected by the app.
Reason Code Describes the reason behind the decision.
Reason Log Customer defined output from the app. Enables customers to log information about the app decisions.
Radar Score The Response Time (RTT), Availability, and Throughput measurements recorded for the platform.
Distribution The distribution of platforms that are selected by the app for each location tested. The Count represents the number of times the platform was selected; and the Percentage is the percentage of the total count for platform selection.

Note: You can run this test on the live app or the unpublished version (i.e. if the app is not yet published).

Once your app is published, you will have the option of testing the live app by clicking the Test Live App option. If you edit your app or upload a new version, you can test it before publishing by clicking the Test Unpublished App button.

Test Live App

Application Verification

In order to ensure that custom JavaScript apps behave as expected, the apps are run through a code and logic verifier when they are uploaded to the ITM Portal. The application verifier runs the app through a decision server with synthetic traffic to test whether the application compiles and runs successfully.

If the application runs without error, the verifier will provide information about the decision distribution and execution characteristics. On the other hand, if the decision server encounters an error while running the app, the verifier will provide information about the error. We recommend the application be free of errors before publishing.

In case of errors, you can fix the JavaScript file in your local and re-upload it to the Portal by clicking the Choose File button.

Publish

To publish your app and have it go live, click the Publish button. This option will be grayed out if the app is not yet saved or already published. When the app goes live, it will appear in the Openmix application manager page with a green status. To learn more about app status refer to the Status of the Application section.

Publish

Note: The app can be published with errors if required.

Managing Custom JavaScript Applications

You can manage Openmix apps (i.e. view reports, edit, duplicate, delete, publish, view source, view live version, view history, and test) using the top tabs within the application manager panel.

Click on your app in the Openmix applications list page to expand the application manager panel.

Manage

View Report

View Report takes you to the Openmix Decision Reports page where you will be able to view the trend of Openmix decisions for each of your apps, platforms and geographies.

Edit

To edit an Openmix custom Javascript app, click on the the app name (in the Openmix applications list page). The application manager panel opens. Changes and updates can be made to the configuration by clicking the Edit icon.

Edit

View Source

View Source allows you to view the JavaScript source of the app, i.e. the latest version of the app whether or not it was published. This option is only available for custom JavaScript apps.

View Live Version

You can view, copy, and download the latest published version of the app using this option. This is only available for custom JavaScript apps.

Live

Application History

Application History allows you to view different versions of the app. You can use the Select a Version dropdown to switch from a live version to an older version. Click Get Content to switch to the older version. This option is only available for custom JavaScript apps.

History

Compare

The Compare feature allows you to compare different versions of your JavaScript file. You can see the differences between two versions of your app clearly displayed with highlighted lines of script.

Compare

Securing Openmix HTTP API

Openmix is available via DNS or an HTTP API for integration into non-DNS workflows. By default, the HTTP API is called over plain HTTP. The API can also be secured via TLS and key authentication. This can be done via the UI by checking the box for Require Secure API Access (HTTPS).

Secure Access

Creating API Keys

To enable key authentication, do the following.

  1. Turn on secure access for each application by checking the Require Secure API Access (HTTPS) box in the Openmix Application Configuration page.

  2. To generate a secure access key, navigate to My Account -> API -> Openmix HTTP API Keys

    Openmix HTTP API Keys

  3. If you’re a first time user, you will be prompted to get started by entering your client ID. Enter your Client ID in the New Client dialog, and click Complete.
  4. The Client Secret key will now be displayed beside the Client ID on the Openmix HTTP API Authentication Configuration page.

  5. You can now make a request to the Openmix app using basic authentication. Use your Client ID as the username and the Client Secret as the password when you invoke the app on the browser.

    Alternatively, if you’re invoking the app using the command line, use this curl command -

    curl https://hopx.cedexis.com/zones/<zone>/customers/<customer_id>/apps/<app_id>/decision --user <client_key>:<client_secret>
    

Note: Keys you create will give you access to any of your Openmix applications.

For more information on calling the Openmix HTTP API, please refer to the Openmix HTTP API usage documentation.

Deleting API Keys

  1. To delete a key, navigate to the Openmix HTTP API Authentication Configuration page.
  2. Click on the Client ID.
  3. Choose Delete in the drop down menu. The key will be removed from the system and will no longer be valid for authentication secure access to the Openmix application.

Accessing Logs

Decisions logs made by Openmix can be collected and made available for secure download. These logs can help you analyze the decisions made by your Openmix application and debug request behavior. The logs can be turned on/off and secured at the account level. For details on how to enable and download Openmix logs and see log descriptions go to Netscope.

Netscope Openmix

Openmix Reports

Openmix reports provide powerful visibility into the Openmix decisions that were made for your DNS or HTTP traffic. Each report is defined below, but here are some important aspects of all of the reports:

Primary and Secondary Dimensions

Dimensions

The primary dimension of the chart is selected through a dropdown selection list above the chart. Use this as a powerful pivot on the report. A secondary dimension can be chosen as well to further refine the reporting.

Visualization Background Toggle

Background Toggle

Charts are set to a white background by default. Toggle the background to a dark color for high contrast monitors using the background toggle.

Data Export

Data Export

In addition, the end-user is able to download the Chart and Table data via the download link at the top of the report.

Filter: Report Time Range

Time Range

The Radar reports can be generated with a time range of Last 60 Minutes, Last 24 Hours, Last 48 Hours, Last 7 Days, Last 30 Days, or a custom range. The default view is the Last 24 Hours.

Filters: Powerful Drill-down Capabilities

Filters

The reports vary slightly in terms of which filters are appropriate based on the data. The following are the most common:

  • Statistic - Select the value shown in the chart, most often the number of decisions.
  • Traffic Source – Select the type of traffic to display: DNS or HTTP.
  • Application – Select one or more Openmix applications to display.
  • Platform – Select one or more platform (provider) to include.
  • Continent – Select one or more continent to include.
  • Country – Select one or more country to include.
  • Region – Select one or more geographic region (where applicable) to include.
  • State – Select one or more geographic state (where applicable) to include.
  • Network – Select one or more network (ASN) to include.

Decision Geo Location Report

This report shows the volume of Openmix decisions for each country. This map view can be viewed over time (based on the time range chosen for the report) by selecting the Play button at the bottom of the chart.

Decision Geo Location Report

Decision Report

This report shows the trend of Openmix decisions for each of the applications, platforms and geographies.

Decision Report