Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Creating Cross Provisioning Platform Services

    The Cross Provisioning Platform (CPP) is an extension to the Network Activate application, which provides a real-time, operations support system (OSS) for creating and deploying services across multi-vendor devices. The CPP software manages the interaction of Services Activation Director (SAD) with a module called the Nokia 5620 Service Aware Manager (SAM). With the Cross Provisioning Platform application, you can:

    • Provision services between Juniper Networks devices and Nokia devices.
    • Manage Services Activation Director services and Nokia 5620 Service Aware Manager services
    • Use the REST APIs to manage services through Services Activation Director
    • Use SOAP API to manage Nokia 5620 Service Aware Manager

    The Cross Provisioning Platform application uses Network Activate as the underlying framework and adds flexibility in designing services. You can:

    • Create a data model for a new service
    • Create user interface to define new service
    • Define business logic to deploy the new service on Juniper Networks devices and Nokia devices.

    Creating services for Cross Provisioning Platform requires the coordination of tasks performed in several areas of expertise including script design, system administration, and service provisioning. When you create the Cross Provisioning Platform service definition, you can attach scripts designed for the service.

    This guide describes the process you must follow to create scripts for the Cross Provisioning Platform (CPP) system and the steps required to provision the scripts.

    Requirements

    This example uses the following hardware and software components:

    • Sencha Ext-JS 4.1.x JavaScript library for RIA (which is included in Junos Space)
    • Sencha Architect
    • XSLT 2.0 and XPath 2.0
    • Junos Space Network Management Platform
    • Junos Space Cross Provisioning Platform application

    Note: You can acquire Sencha Architect software through http://www.sencha.com/products/architect/

    Before you begin to develop the scripts, must be able to:

    • Proficiently use JavaScript and Cascading style sheets (CSS)
    • Use Sencha Ext-JS 4.1.x JavaScript library for RIA (which is included in Junos Space)
    • Use Sencha Architect
    • Develop scripts proficiently using XSLT 2.0 and XPath 2.0
    • Develop XML scripts that can be processed correctly with the third-party SOAP API
    • Develop a Junos configuration script using the Juniper XML API

    Overview

    To deploy services to run across both Juniper Networks platforms and the devices of third-party vendors, you must perform the following steps:

    1. Create the following types of scripts
      • GUI script
      • Third-party (SAM)Flex scripts
      • Juniper Networks Flex Scripts

      Note: The Flex scripts are also termed as configuration scripts.

    2. Provision the scripts in the Cross Provisioning Platform application.

    Developing Scripts

    You must create the following scripts:

    Creating the GUI Scripts

    Step-by-Step Procedure

    In the Junos Space CPP context, the GUI script generates the user interface for interacting with the Cross Provisioning Platform service. The GUI defines the parameters for which a user specifies values. The GUI can define hidden fields and values that are passed to the server. The GUI also guides a user to enter valid values for the parameters to define a service order. In addition, the GUI script can provide some client-side validation.

    To develop the GUI scripts that render the CPP windows through which you can enter information to define a service, you must be able to:

    • Develop scripts proficiently using JavaScript and Cascading style sheets (CSS)
    • Use Sencha Ext-JS 4.1.x JavaScript library for RIA (which is included in Junos Space)
    • Use Sencha Architect

    To develop the GUI Scripts:

    1. Use the Sencha Architect to build the GUI.

      The Sencha EXT-JS library supplies a set of widgets that the script designer can use to develop the GUI forms.

      The following illustration shows a typical GUI designer’s view of a Sencha Architect Project page.



      The following illustration shows generated code displayed within a Sencha Architect project page.


      Note: As an alternative to using the Sencha Architect to build the GUI, you can hand-code the GUI forms. If you decides to hand-code the GUI, you can access one of the following development resources, which are available online at no cost:

      • An online GUI development environment at : https://fiddle.sencha.com/
      • An online API reference and code examples at: http://docs.sencha.com/extjs/4.1.1/
    2. Use the CPP Script Utilities that provide hooks into a Juniper Networks platform to obtain device and interface information.

      The script utilities provides helper functions which are exposed by application, intended to be used by designers who creates a GUI script for CPP service provisioning

      You can choose to assign a short variable to these classes prototype for making it easier to access functions.

      Function

      Description

      getMainForm (window)

      This function returns the form, from the main popup window, assuming the user layout is such that the form is inserted directly inside the window as first child.

      getFormValues (window)

      This function gets all the user filled input form data values within a window.

      getFieldsByProperty (property,name)

      This function gets any components inside a window dialog by any custom or predefined property. If more than one component match is found, then it returns an array of all matched components.

      getFieldByName (name)

      This function returns any field or component inside the form, based on its name. This returns fields from within field sets. If more than one match is found it returns the first match always. Typically field are never same, to avoid getting more than one result you should always assign unique names to fields.

      getDeviceStore (data)

      This function makes a connection to devices resource and get all the Junos devices and autoloads into the device store. This function pass the common data from previous screen to determine if the service definition selected has a SAM script attached. If data is not specified, then only Juniper Networks devices are returned from server by default.

      getL2ExtDeviceStore ()

      This function makes a connection to the devices resource and get all the Junos devices which have L2E role and autoload into the device store.

      getInterfaceStore ()

      This function gets all the interfaces based on the selected devices. This is not autoloaded, loads only when the device is selected. Therefore the store load must be handled in the device combo box select listener.

      getL2ExtInterfaceStore ()

      This function gets all the interfaces based on the selected devices which have L2E role. This is not autoloaded, and loads only when the device is selected. Therefore the store load must be handled in the device combo box select listener.

      setFieldValues (window,data)

      This function populates the data coming from server and show it into the form.

      saveForm (window,data)

      This function gets the data from user dialog and send it to the back end for persistence and validation. Any server error or information is shown as popup dialog. If all validation goes well, the job link dialog is displayed for the user to either exit or go to job page for a status check.

      saveBulkForm (window,data)

      This function gets user data and save the form in bulk. No job dialogs are shown. You need to manually close the dialog after saving the data.

      saveAndCreateMore (window,data)

      This function gets the data from user dialog and send it to back end for persistence and validation. Any server error or information is shown as popup dialog and the screen is ready for another input from user.

      saveModifyForm (window,data)

      This function is called when you try to modify a service. This function receives the data from the user dialog and send it to the back end for persistence and validation. Any server error or information is shown as a popup dialog. If all validation goes well, the job link dialog is displayed for the user to either exit or go to job page for a status check.

      validateVLAN (siteId,port,encap,checkbox)

      The UI designer must call this event handling function, to validate the encapsulation field. This can be added as a callback for any change event (text field change or check box). The objective is to send siteId, port, encap to validate from the back end. The result is shown in a pop-up dialog. Pass "null" if you are not using a check box, otherwise it will be unchecked.

      showInterfaceDetails (siteId,port,vendor)

      Based on the site and port, this function fetches the port details and show it to user in a pop up dialog. the vendor can be either Junos Space or Alcatel.

      createGroupingGridPanel (name,height,store,window)

      This function groups grid from the user GUI script, params :- name : grid name, height : grid height, store : grid store, window : reference of the user script main window.

      You should implement addSiteHandler and deleteUNIInterfaceHandler and addUNIInterfaceHandler in their respective script for addsite, addport, deleteport button actions.

      createStore (fields,groupField)

      This function creates grouping grid store from the user GUI script, params :- fields : fields used in grid store - should be array of fields, groupField : group Name

      createForm (initialConfig,items)

      This function creates a field of form, from the user GUI script, params:- initialConfig - configurations like name, height, default, layout, bodyPadding, title and so on.

      createDefaultServiceOrderName (field)

      This function creates default service order name and set to service order name text field, params:- field :service order name textfield component return current Time with prefixed with 'SO' string.

      getNodeList (deviceId,vendor,inventoryType,xpath)

      This function returns the inventory in Stringified JSON format. Based on device ID, vendor type, inventory Type, XPath, param deviceid - Id of the device, param vendor - Default to Juniper, param inventoryType -the inventorytype is the string value from the following DeviceInventoryXMLType enum, INTERFACES("interface-information"), CONFIGURATION ("configuration"), SOFTWARE_INVENTORY("software-inventory"), HARDWARE_INVENTORY ("chassis-inventory"), SYSTEM_INVENTORY ("system-information"), LICENSE_INVENTORY ("license-inventory"), DEVICE ("device"), param xpath - the xpath to apply For configuration, use Xpath starting with "/device/configuration", For hardware inventory, use Xpath starting with "/device/chassis-inventory"

      navigateTo (taskName)

      This function navigates other tasks using the task name, params:- taskName :name of the task

      getEndpointAdvanceSettings (String deviceId, String portName, String customerId)

      This function retrieves the advanced attributes for the service endpoints.

      getNetworkDetails

      This function sends the SOAP message to retrieve the network device details from the Nokia SAM server based on the device IP.

      getEquipmentPort

      This function sends the SOAP message to retrieve the equipment port details from the Nokia SAM server based on the device IP and port name

      getEquipmentPortSpeed

      This function sends the SOAP message for fetching the equipment port speed details from the Nokia SAM server, based on the device IP and port name.

      getEquipmentPortAttribute

      This function sends the SOAP message for fetching the equipment port details from the Nokia SAM server based on the device IP and port name.

      getDeviceInterfaceStatus

      This function sends the SOAP message for fetching the interface status based on the specified device and port name.

      getSubscriber

      This function sends the SOAP message for fetching the subscriber details from the Nokia SAM server based on the customer name.

      getSubscriberDetailsById

      This function sends the SOAP message for fetching the subscriber details from the Nokia SAM server based on the customer ID.

      getAccessEgressPolicyObject

      This function sends the SOAP message for fetching the egress policy details from the Nokia SAM server based on the policy name.

      getAccessIngressPolicyObject

      This function sends the SOAP message for fetching the ingress policy details from the Nokia SAM server based on the policy name.

      getAccessEgressFilterObject

      This function sends the SOAP message for fetching the egress filter details from the Nokia SAM server based on the policy name.

      getSDPBinding

      This function sends the SOAP message for fetching the SDP binding details from the Nokia SAM server based on the site IP address and the MTU value.

      getDeviceIP

      This function finds the sevice IP from the PE device ID.

      getLoopbackIP

      This function finds the loopback IP of the Juniper Networks device IP, based on the device ID from the Service request.

      createSDPBinding

      This function sends the SOAP message for creating the SDP binding to the Nokia SAM server based on the from and to site IP address and the MTU value.

      pingSAMServer

      This function sends the SOAP message to ping and check the availability of the Nokia SAM server.

      getL3VPNIPAddressPool

      This function sends the SOAP message to check if the given IP Address is already in use.

      getASNumber

      This function fetches the AS number from the Nokia SAM server. The class name used is “topology.BgpAutonomousSystem”. This can be used for the Route Distinguisher setting for VPRN services.

      getNetworkSnmpReachability

      This function queries the Nokia SAM server for the network details of the device, and finds the SNMP reachability value.

      getNetworkReachability

      This function queries the Nokia SAM server for the network details of the given device, and finds the network reachability value

      getNetworkElementAttribute

      This function queries the Nokia SAM server for the network details of the given device. The user can specify any attribute value to be fetched for the given device.

      getVprnServiceIdForCustomer(

      This function queries the Nokia SAM server to get the VPRN ID for the specified service ID and subscriber.

      getPrefixListDisplayedName

      This function queries the Nokia SAM server to find the displayed name for the prefix list ID. This is used to find out if the given prefix list exists in the system.

      getCommunityDisplayedName

      This function queries the Nokia SAM server to find the displayed name for the community ID. This is used to find out if the given community exists in the system.

      getPolicyStatementDisplayedName

      This function queries the Nokia SAM server to find the displayed name for the policy statement. This is used to find out if the given policy statement exists in the system.

      getVprnSiteServiceId

      This function queries the Nokia SAM server to find the ID of the specified device in the specified VPRN service.

      deleteInstance

      This function is called through the XSLT for deleting any instance from the Nokia SAM server. Based on the ID specified, the corresponding instance is deleted from the Nokia SAM server.

      getForeignSVCID

      This function returns the service ID used by the Nokia SAM server for the specified CPP service ID.

      executeCliCommand(

      This function executes the specified CLI command directly on the device through the Nokia SAM server, and returns the response.

      sendScriptBasedSoapRequest

      This function sends any type of request to Nokia SAM serverm based on the input and sends the output response.

      getSubscriberInformation(String serviceId, String displayedName, String siteId)

      This function sends a request to the Nokia SAM server, and retrieves the subscriber’s name based on the service ID, siteID and the displayed name.

      getVPRNIPAddress (String serviceId, String displayedName, String siteId)

      This function sends a request to the Nokia SAM server and retrieves the primary IPv4 address for the VPRN service, based on the service ID, site ID and the displayed name.

      isValidRD (String Rd)

      Based on the route distinguisher, this function validates the route distinguisher value from the Nokia 5620 Service Aware Manager server.

      isValidServiceId (String serviceId)

      Based on the service ID, this function validates the service ID value from the Nokia 5620 Service Aware Manager server.

      isValidServiceIdandRd (String serviceId, String rd)

      Based on the route distinguisher and service ID, this function validates the route distinguisher and service ID value from the Nokia 5620 Service Aware Manager server.

      isValidResource (String key, String value)

      Based on input parameters of the customer, this function retrieves the object’s full name from the Nokia 5620 Service Aware Manager server.

      The following code fragment is a sample of the importation or declaration of the CPP ScriptUtils.


      The following two code fragments are samples of script utility function calls:


      getDeviceStore()


      getInterfaceStore()

    3. The CPP software populates values for the attributes policy, bundleName, samScriptBundleName, and the description. The script populates values for the remaining attributes. The script designer determines values for attributes within ServiceCommonAttributes and ServiceEndpointAttributes. The attributes pedeviceId and vendorType are mandatory. All of the attributes are converted directly into XML and passed to ServiceRequest.xml.

      The script designer can use the attribute children to nest ServiceEndpointAttributes to represent topology structure. The attribute topologyIndex is optional. The designer can use it to describe the topology structure of service endpoints.

      The following parameters are the mandatory parameters that must be present in the ServiceRequest.xml:

      Note: These parameters are case sensitive.

      Parameters

      Description

      pedeviceId

      PE Device ID

      You obtain this value by fetching all the devices from the database through the ScriptUtil helper functions.

      vendorType

      Vendor type

      The vendor type can be Juniper, or Alcatel, or SpacePlatform.

      Note: SpacePlatform is used only while writing Device Order Configlet scripts, that is, Flex script with Service Type as Device.

      Interface

      Interface Name

      You can obtain this value by fetching all the interfaces from the database through the ScriptUtil helper functions.

      outerEncap

      Outer encapsulation of the VLAN ID.

      seId

      Service Element ID.

      This value should be not set while creating a service.

      This value is mandatory while modifying a service. This value is populated using Modify APIs defined to retrieve all the endpoints.

      recordOPType

      Record operation type

      The record operation type can be ADD, or MODIFY, or DELETE.

      For Create Default the value is ADD.

      For Modify the value can be ADD, or MODIFY, or DELETE.

      ServiceEndpointAttributes

      The user defined attributes of the service endpoint. You can provide any valid JSON data to this attribute. This is specific to each service endpoint

      ServiceCommonAttributes

      The attributes that are common for all the service endpoints or services.

      The following illustration displays sample code of a ServiceRequest.xml document. Within the sample:

      • The element ServiceEndpointAttributes is the mandatory attribute of any individual ServiceElement. Note that pedeviceId and vendorType are mandatory items of a ServiceRequest.xml document.
      • The element ServiceCommon Attributes is the common attribute of a service.
      • Both elements, ServiceEndpointAttributes and ServiceCommonAttributes, are converted from the JSON data derived from the GUI script. ServiceEndpointAttributes and ServiceCommonAttributes are artifacts that pass information from GUI scripts to the XSLT Flex scripts.
      • The CPP engine generates the other part of a ServiceRequest.xml file.

      Every ServiceRequest must have an OpType under the ServiceRequest, which indicates the type of operation defined.

      The OpType under each ServiceElement specifies whether the ServiceElement is to be added or modified when the ServiceRequest is deployed.

    4. The output of GUI scripts is presented in JSON format. JSON data is rendered into an XML document known as ServiceRequest.xml. The ServiceRequest.xml document is the input to the JUNOS and SAM Flex XSLT transformations.

      Designers develop Extensible Stylesheet Language Transformations (XSLT) scripts to transform one XML document into one or more other XML documents.

      For Cross Provisioning Platform, an XSLT script transforms the ServiceRequest.xml document into two new XML documents:

      • A SOAP XML document for the third-party (SAM) device
      • A Juniper device configuration XML document

    Results

    When you have created GUI and configuration scripts and added them to the CPP system, you can create a service definition to which you associate specific scripts. Thereafter, you can create and deploy a service order based on a particular service definition.

    While creating a service order, the Endpoint Settings window appears. The appearance of the Endpoint Settings window is based on the GUI scripts that are associated with the service definition upon which the service is based.

    Creating the Flex Scripts for Juniper Network

    Step-by-Step Procedure

    To develop the Juniper Flex scripts that transform a service request into an XML configuration script that is sent to a Juniper device, you must be able to:

    • Develop scripts proficiently using XSLT 2.0 and XPath 2.0
    • Develop a Junos configuration script using the Juniper XML API

    To develop the XSLT Flex script for a Juniper device:

    1. The Juniper Networks XSLT Flex script derives input variables from the ServiceRequest.xml document, which is created from data a user inputs into the Junos Space CPP GUI, and generates JUNOS XML configuration that is passed to the intended Juniper Networks device.
    2. An XSLT Flex script for a Juniper device has two major components:
      • Derivations Logic—In this section of code, input variables are extracted and additional parameters are derived.
      • Configuration Logic—In this section of the code, parameters derived from the derivation logic are used to construct the XML configuration that activates the service on a Juniper Networks device.

      The following illustrations show the transformation from a Juniper Networks XSLT Flex script to a JUNOS XML configuration.



      JUNOS XML Configuration

      An XSLT Flex script for a Juniper Networks device includes an OpType to specify when the script is used:

      • Creation—Used to create a new service and to decommission a previous service
      • Modification—Used to modify an existing service

      The following illustration shows the presence of OpTypes in a ServiceRequest.


    Results

    When you have created GUI and configuration scripts and added them to the CPP system, you can create a service definition to which you associate specific scripts. Thereafter, you can create and deploy a service order based on a particular service definition.

    Creating the Flex Scripts for Third-party Vendors (SAM)

    Step-by-Step Procedure

    To develop third-party(SAM) Flex scripts that transform a service request into a Simple Object Access Protocol (SOAP) script that is sent to the Nokia device, you must be able to:

    • Develop scripts proficiently using XSLT 2.0 and XPath 2.0
    • Develop XML scripts that can be processed correctly with the third-party SOAP API

    To develop the XSLT Flex script for SAM:

    1. The third-party (SAM) XSLT Flex script derives input variables from the ServiceRequest.xml document, which is created from data a user inputs into the Junos Space CPP GUI, and generates a SOAP message that is passed to the intended third-party vendor’s device.
    2. The third-party XSLT Flex script includes two major components:
      • Derivations Logic—In this section of code, input variables are extracted and additional parameters are derived.
      • Configuration Logic—In this section of the code, parameters derived from the derivation logic are used to construct the third-party(SAM) SOAP call that activates the service on a third-party vendor’s (SAM) device.

      The following illustration includes sample code fragments that present the derivations logic and configuration logic sections of a XSLT Flex script for a third-party (SAM) device.



      The configuration logic in the third-party XSLT script converts to XSLT format the SOAP message generated by the third-party(SAM) service script. The following pseudo code sample demonstrates the logic to accomplish the conversion.



      To work with the third-party (SAM) XSLT script, login to the third-party (SAM) server. The following illustration presents a third-party(SAM) GUI window that enables entering data for third-party (SAM) XSLT Flex script.



      The following illustration shows a sample of the corresponding code that is generated when a user requests to preview the SOAP code from the GUI window.



      The following illustration shows a sample of the code that results when the script designer substitutes variables included in the SOAP code with variable names obtained from the XSLT Flex script derivation logic.


      The following illustration demonstrates the process of converting SOAP code variables in the third-party (SAM) XSLT Flex script code. The script designer adds logic to define the variables Default MTU and Jumbo MTU. The code also indicates how Canoga or L2E is selected.



      Note: Most of the logic that the designer adds is reused for all scripts.

      The following illustrations show the transformation from a third-party XSLT Flex script to a SOAP Message.



      SOAP message



      The SOAP script communicates directly with the third-party vendor’s Service Aware Manager(SAM) module by way of a SAM adaptor plugin. The third-party vendor forwards the configuration to a device using its chosen communication protocol.

    Debugging a Cross Provisioning Platform Script

    In releases prior to Cross Provisioning Platform Release 14.3R1, you can identify script-related issues only after you create a service. You cannot preview the XML configuration that is being pushed to the device.

    With Cross Provisioning Platform Release 14.3R1, you can debug both the configuration script and the GUI script while you are still creating a service. This enables you to identify and rectify all script-related issues before you create a service. You can debug both Juniper Networks and Nokia scripts.

    You can debug a Cross Provisioning Platform script by performing the following tasks:

    Modifying a Cross Provisioning Platform Script

    Step-by-Step Procedure

    In releases prior to Cross Provisioning Platform Release 14.3R1, you need to upload the modified script from your local file system. In Cross Provisioning Platform Release 14.3R1, you can modify the script directly in the text area included in the Modify Script window. By default, the latest version of the script is populated in the text area.

    To modify a Cross Provisioning Platform script, perform one of the following tasks:

    • Browse the local file system to upload the script that you have modified in your local file system.

      The uploaded script is displayed in the text area, included in the Modify Script window.

    • Modify the script directly in the text area.

      Note: In the text area in the Modify Script window, you can also modify the script that you have uploaded from your local file system. For more information about modifying an existing script, see Modifying Scripts Created for Cross Provisioning Platform.

    Use the Preview option in the Modify Script window to preview the script output. In the script output, use the Verify option to verify the script output.

    Previewing a Cross Provisioning Platform Script

    Step-by-Step Procedure

    With Cross Provisioning Platform Release 14.3R1, you can preview the script output before you create a service.

    To preview the output of a GUI script, perform one of the following tasks:

    • On the Scripts inventory page, right-click a script and select Preview.
    • In the Modify Script window, click the Preview option.

    Verifying a Cross Provisioning Platform Script

    Step-by-Step Procedure

    Verify the script output to identify and troubleshoot issues, if any. The Cross Provisioning Platform application provides you with the option to specify real-time data while you preview the script output.

    1. In the Modify Script window, click the Preview option.

      You can preview the script output.

    2. In the script output window, specify real-time data.
    3. Click Verify.

      Note: For the Verify option to appear in the script output window and to generate the required XML output, you must append the GUI script with the newly created script utility function, scriptUtils.verifyForm(this,data).

      Following is the code snippet to add the Verify option:

      {
      xtype: 'button',
      handler: function(button, event) {
              var data = this.getDataJSON();
              this.scriptUtils.verifyForm(this,data)
      },
      scope: this,
      text: 'Verify'
      }
      

      All necessary information required for debugging the Cross Provisioning Platform script is displayed in a new window.

    Step-by-Step Procedure

    Provisioning the Services Using the Scripts

    The following steps are involved in provisioning the services:

    Configuring Nokia Devices

    Step-by-Step Procedure

    To preconfigure the third-party OSS device:

    1. In the Network Management Platform, select Administration > Applications.
    2. In the Applications window, select Network Activate.
    3. From the Actions menu, select Modify Application Settings.
    4. In the Modify Application Settings window, select OSSConfigParameters.
    5. Fill in the fields in the OSSConfigParameters panel as described in the following table.

      OSS Parameter

      Description

      Primary Server IP

      IP address of the primary server.

      Primary Server Port

      Port number of the primary server.

      Backup Server IP

      IP address of the backup server.

      Backup Server Port:

      Port number of the backup server.

      HTTP Connection Timeout (milliseconds)

      Duration of HTTP connection (in milliseconds) before the timeout elapses.

      Maximum API Requests

      Maximum number of simultaneous API requests permitted.

      OSS Log Directory

      Directory path of the OSS log directory.

      OSS Log Filename

      Filename of the OSS log.

      OSS User Name

      User name for accessing the OSS server.

      OSS User Password

      Hashed password for accessing the OSS server.

      Synchronize OSS Inventory daily at given time

      Sets the daily time at which the CPP system synchronizes third-party devices, added or deleted from the CPP system, with the OSS server.

      Note: The time at which the synchronization job runs is associated with the location of the browser in which you are using the Junos Space software. That is, the synchronization job runs according to the browser time where the job is scheduled, not according to the time where the Junos Space server is located.

      Use primary server

      If this check box is selected, the CPP system communicates with the primary OSS server. If the check box is not selected, the system interacts with the backup server.

    6. When you are done entering information in the OSSConfigParameters fields, click Modify.

    Adding a Third-Party Device to the Cross Provisioning Platform System

    Step-by-Step Procedure

    To add a third-party device to the Cross Provisioning Platform system:

    1. In the Network Activate task pane, select CPP > Third-Party Devices.
    2. In the Third-Party Devices window, click the Add Third-Party Device icon (+).
    3. In the Add OSS Device window, click the Host Name or IP Address button and then enter the hostname or IP address of the device.
    4. Click Add.

      The device is displayed in the Third-Party Devices window.

    Adding Scripts Created for Cross Provisioning Platform

    Step-by-Step Procedure

    Before you can create a Cross Provisioning Platform service definition, you must add scripts to the system that enable management of the Juniper Networks devices and the devices of another vendor.

    To enable Cross Provisioning Platform, you add three types of scripts:

    • Junos XSLT—Provides the code that enables provisioning a particular Juniper Networks device.
    • SAM XSLT—Provides the code that enables provisioning the device of another vendor.
    • GUI JavaScript—Provides the code that renders the Network Activate GUI window required for provisioning a Juniper Networks device.

    To view the scripts that have been loaded into the system:

    1. In the Network Activate task pane, select Service Design > Manage Scripts.
    2. In the Manage Scripts window, select the Add Scripts icon on the command bar (+).
    3. In the Add Script(s) window, select a feature type and its corresponding vendor type from a list of features in the Feature Type drop-down list. These features require scripts in CPP.
    4. In the Add Script(s) window, you can browse your local client file system for the scripts you want to be available to the Network Activate application. You can add scripts for Juniper Networks devices and for the devices of other vendors. If you select Junos Space in the Vendor type field, the window displays fields for selecting both Configuration script and GUI script.

      Note: If you want to do service interface migration, you need to upload both Configuration script and the GUI script.


      If you select a third-party in the Vendor type field, the window displays a field for selecting a Configuration script only.



      Note: If you access the server on which the Junos Space software is installed as a remote client, you must copy the scripts you intend to add to the CPP system to your local client file system. That is, when you click on Browse to select a script, which you want to add, Junos Space opens the local client file system, not the file system of the server on which Junos Space is installed.

    5. For each script, add the appropriate information for each field and click Create.

    Creating a Cross Provisioning Platform Service Definition

    Step-by-Step Procedure

    Before you create a Cross Provisioning Platform service order, you must complete the following tasks:

    • Import into the system the scripts that define the Juniper Networks devices.
    • Import into the system the scripts that define the third-party devices.

    To create a Cross Provisioning Platform service definition:

    1. In the Network Activate task pane, select CPP > Service Definitions.
    2. In the CPP > Service Definition window, click on the + button. The Create Service Definition window appears.
    3. Enter information in the Create Service Definition window according to the descriptions in the following table.

      Parameter

      Description

      Name

      Enter a name for the service.

      Description

      Enter a description of the service to distinguish its operation from others.

      Type

      Select the service type from the list of available types:

      • PW-LDP
      • VPLS
      • L3VPN
      • NPS
      • Device—If you select Device, the SAM Service Scripts parameter disappears. This type is for Juniper Networks devices only.

      SAM Service Scripts

      This parameter provides two fields:

      • Creation—One at a time, browse for the scripts you want to attach to the service definition.
      • Modification—Browse for a modified version of a script of the same name that was initially attached to the service definition. Junos Space compares the two scripts and generates a script that includes the new information.

      Junos Space Service Scripts

      This parameter provides two fields:

      • Creation—One at a time, browse for the scripts you want to attach to the service definition.
      • Modification—Browse for a modified version of a script of the same name that was initially attached to the service definition. Junos Space compares the two scripts and generates a script that includes the new information.
    4. Click Create.
    5. In the Network Activate task pane, select CPP > Service Definitions.
    6. Select the service definition you just created and select Action > Publish Service Definition. The State column indicates when the service definition is published.

    Creating a Cross Provisioning Platform Service Order

    Step-by-Step Procedure

    Before you create a Cross Provisioning Platform service order, you must complete the following tasks:

    • Import into the system the scripts that define the Juniper Networks devices.
    • Import into the system the scripts that define the third-party devices.
    • Create the service definition upon which to base the service order.

    To create a Cross Provisioning Platform service order:

    1. in the Network Activate task pane, select CPP > Service Orders.
    2. In the CPP > Service Orders window, click the + button. The Create CPP Service Order window appears.
    3. In the Service definition field, browse for the name of the published service definition upon which you want to base the service order.
    4. In the Order description field, enter a description of the service that distinguishes its operation from others.
    5. Click Next. The Endpoint Settings window appears.

      Note: The following representation of an Endpoint Settings window is a sample only. The appearance of the Endpoint Settings window is based on the scripts that are associated with the service definition upon which the service is based.

    6. Enter information for the parameters of the Endpoint Settings window according to the descriptions in the following table.

      Parameter

      Description

      General

      Name

      Enter a unique name for the service order to distinguish it from others that operate differently.

      Jumbo

      Jumbo frame 3900

      Jumbo frame 9000

      Sets the MTU frame size to 3900

      Sets the MTU frame size to 9000

      Default: 1596

      Site B Selector

      Site B port type

      Customer Facing Port

      Network Facing Port

      Site A – Customer Facing Port

      Site name

      Select the device from the list of devices displayed.

      Resync now

      Resyncs the interface on the selected device.

      Note: This parameter pertains to third-party devices only.

      Port

      Select a port from the list of ports displayed.

      Service speed

      Select the appropriate bandwidth for the selected site.

      Canoga device?

      If you select this check box, the software checks to determine whether the device is a Canoga device.

      Anda untagged?

      If you select this check box, the software checks to determine whether the device is an untagged Anda device.

      Outer encapsulation

      Enter an integer, or select the up or down arrow to select a value for the Outer encapsulation.

      Validate

      If this check box is selected, the system validates the encapsulation value with the specified site and port.

      Untagged/802.1q?

      If this check box is selected, the software checks to determine whether 802.1q was specified as the Ethernet option in UNI Settings.

      Inner encapsulation

      Enter an integer, or select the up or down arrow to select a value for the Inner encapsulation.

      L2 Extension

      Site name

      Select the device from the list of devices displayed.

      UNI port

      Select a UNI port from the list of ports displayed.

      Uplink port

      Select a NNI port form the list of ports displayed.

      UNI encapsulation

      Enter an integer, or select the up or down arrow to select a value for the UNI encapsulation.

      Validate

      If this check box is selected, the system validates the encapsulation value with the specified site and port.

      Site B – Customer Facing Port

      Site name

      Select the device from the list of devices displayed.

      Resync now

      Resyncs the interface on the selected device.

      Note: This parameter pertains to third-party devices only.

      Port

      Select a port from the list of ports displayed.

      Service speed

      Select the appropriate bandwidth for the selected site.

      Canoga device?

      If you select this check box, the software checks to determine whether the device is a Canoga device.

      Anda untagged?

      If you select this check box, the software checks to determine whether the device is an untagged Anda device.

      Outer encapsulation

      Enter an integer, or select the up or down arrow to select a value for the Outer encapsulation.

      Validate

      If this check box is selected, the system validates the encapsulation value with the specified site and port.

      Untagged/802.1q?

      If this check box is selected, the software checks to determine whether 802.1q was specified as the Ethernet option in UNI Settings.

      Inner encapsulation

      Enter an integer, or select the up or down arrow to select a value for the Inner encapsulation.

      L2 Extension

      Site name

      Select the device from the list of devices displayed.

      UNI port

      Select a UNI port from the list of ports displayed.

      Uplink port

      Select a NNI port from the list of ports displayed.

      UNI encapsulation

      Enter an integer, or select the up or down arrow to select a value for the UNI encapsulation.

      Validate

      If this check box is selected, the system validates the encapsulation value with the specified site and port.

    7. Click Create or click Create More to provision additional endpoints.

    Deploying Services

    Step-by-Step Procedure

    To schedule a service for deployment:

    1. Select > CPP > Service Orders.

      The Service Orders page displays the list of service orders.

    2. Select the service order you want to deploy.
    3. Open the Actions menu and click Deploy Service Order.

      The Deploy Service window appears.

    4. To deploy the service immediately, select Deploy now, and click OK.

      To deploy the service at a later time, select Deploy later, and select a date and time for deployment, then click OK.

      The time field specifies the time kept by the server, but in the time zone of the client.

      After scheduling the service order for deployment, the CPP software begins validating the service order.

    Modified: 2017-02-21