Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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 pages 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

    checkExistingService:function (siteAId, siteAIntf, siteAVendor, siteBId, siteBIntf, siteBVendor)

    This function lists the PW-LDP services created between two endpoints.

    • siteAId—Is the device ID of site A.

    • siteAIntf—Is the interface of site A.

    • siteAVendor—Is the vendor of site A.

    • siteBId—Is the device ID of site B.

    • siteBIntf—Is the interface of site B.

    • siteBVendor—Is the vendor of site B.

    checkISISSRState:function (deviceId, vendor)

    This function identifies whether a device is IS-IS SR capable.

    • deviceId—Is the ID of the device selected.

    • vendor—Is the vender name of the device selected.

    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.

    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.

    createGroupingGridPanel (name,height,store,page)

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

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

    createLDPSession (distinguishedName, objectFullName, loopbackB)

    This function sends the SOAP message that creates the LDP session to the Nokia SAM server, based on the from and to site loopback IP address and the maximum transmission unit (MTU) value.

    • distinguishedName—Is the distinguished name of site A.

    • objectFullName—Is the full object name of site A.

    • loopbackB—Is the loopback address of site B.

    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.

    createSRSDPBinding (fromSiteIP, toSiteIP, pathMtu)

    This function sends the SOAP message that creates the SR SDP binding to the Nokia SAM server, based on the from and to site IP addresses and the MTU value.

    • fromSiteIP—Is the IP address of site A.

    • toSiteIP—Is the IP address of site B.

    • pathMtu—Is the MTU value.

    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

    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.

    executeCliCommand(

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

    getAccessEgressPolicyObject

    This function sends the SOAP message for fetching the egress 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.

    getAccessIngressPolicyObject

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

    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.

    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.

    getDeviceIP

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

    getDeviceInterfaceStatus

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

    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 page 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.

    getEndpointAdvanceSettings (String deviceId, String portName, String customerId)

    This function retrieves the advanced attributes for the service endpoints.

    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.

    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.

    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.

    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.

    getFieldsByProperty (property,name)

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

    getForeignSVCID

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

    getFormValues (page)

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

    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.

    getISISCoreLoopInterface (siteId, input)

    This function sends a SOAP message to identify ISIS loopback interfaces.

    • siteId—Is the ID of the device selected.

    • input—Is the primary IPv4 address or the full object name of the device.

    getLoopback (vendor, deviceid, svcType)

    This function finds the loopback IP address of a Juniper Networks device based on the device ID and service type from the service request.

    • deviceId—Is the ID of the device selected.

    • vendor—Is the vender name of the device selected.

    • svcType —Is the service type IS-IS or OSPF.

    getLoopbackIP

    This function sends the SOAP message to identify the IS-IS loopback interfaces.

    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.

    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.

    getL3VPNIPAddressPool

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

    getNetworkDetails

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

    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"

    getMainForm (page)

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

    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.

    getNetworkReachability

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

    getNetworkSnmpReachability

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

    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.

    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.

    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.

    getSessionGroup:function(deviceId, vendor, netw)

    This function identifies the session-group address by passing the regular expression pattern of the network IP address, where

    • deviceId—Is the ID of the device selected.

    • vendor—Is the vender name of the device selected.

    • netw —Is the regular expression pattern for the network.

    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.

    getVprnServiceIdForCustomer(

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

    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.

    getVprnSiteServiceId

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

    isValidRD (String Rd)

    Based on the route distinguisher, this function validates the route distinguisher 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.

    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.

    navigateTo (taskName)

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

    pingSAMServer

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

    saveAndCreateMore (page,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 page is ready for another input from user.

    saveBulkForm (page,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.

    saveForm (page,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.

    saveModifyForm (page,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.

    sendScriptBasedSoapRequest

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

    setFieldValues (page,data)

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

    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.

    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.

    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 page appears. The appearance of the Endpoint Settings page 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 page 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 page.





    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 page. 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 page.

  • Modify the script directly in the text area.

    Note

    In the text area in the Modify Script page, 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 page 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 page, 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 page, click the Preview option.

    You can preview the script output.

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

    For the Verify option to appear in the script output page 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:

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

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 page, select Network Activate.
  3. From the Actions menu, select Modify Application Settings.
  4. In the Modify Application Settings page, 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 page, click the Add Third-Party Device icon (+).
  3. In the Add OSS Device page, 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 page.

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 page 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 page, select the Add Scripts icon on the command bar (+).
  3. In the Add Script(s) page, 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) page, 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 page 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 page 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 page, click on the + button. The Create Service Definition page appears.

  3. Enter information in the Create Service Definition page 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 page, click the + button. The Create CPP Service Order page 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 page appears.Note

    The following representation of an Endpoint Settings page is a sample only. The appearance of the Endpoint Settings page 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 page 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 page 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.