B Extensions Sample Code

This appendix provides information about the extensions sample code that comes with your installation.

Using Sample Code as a Reference for Best Practices

This section provides information regarding best practices for writing Java classes to extend the Oracle Communications MetaSolv Solution application logic. The best practices are explained by referencing the provided sample code. The sample code demonstrates how to throw an exception, send an email notification, and call a CORBA API method from an extension class.

Exception Handling

The mss_ext_samples.jar file contains the class SampleExtensionException.java. This class provides sample code that throws an exception from an extension class. The result of an extension class throwing an exception is an entry in the appserverlog.xml file that shows the error text provided by the extension class. No error is shown to the user.

Below is a sample of the message text logged to the appserverlog.xml file when this class executes:

PlugInReturn object returned from Extension contained errors:
Testing Extension Exception - Sample Error Message
processPoint 101 ActionType 46 BuildingBlock 1001 Caller USER.

E-mail Notification

The mss_ext_samples.jar file contains the class ExtensionFrameworkOneWayTest.java. This class provides sample code that sends an email notification from an extension class.

CORBA API Invocation

The mss_ext_samples.jar file contains the class InvokeCorbaAPIExtension.java. This class provides sample code that invokes a CORBA API method from an extension class. The sample code calls the CORBA API method getOrganization, which is defined in the TaskCompletionSubsession of the Work Management CORBA API.

Running the Sample Code

The extensions sample code provides concrete examples of how to code specific logic in the extension Java class such as error handling, sending an email notification, and making an API call. When executed, the sample code also provides concrete examples of the outcome of these actions. You can define any of the sample classes as an extension in the UI, associate an execution point with the extension, and then trigger the execution point to invoke the sample class extension and see the outcome.

The extension sample code provided with your installation of MetaSolv Solution is listed below, including the first release in which it is supported. All sample code related files are located in the mss_ext_samples.jar file. The installer copies the mss_ext_samples.jar file to your MSLV_Home/appserver/samples directory, where MSLV_Home is the directory in which MetaSolv Solution is installed.

  • For a full installation, the contents of the mss_ext_samples.jar file are extracted into the appropriate path under your MSLV_Home directory. The appropriate path for each file is identified by the path specified in the .jar file.

  • For an upgrade, you must manually extract the contents of the mss_ext_samples.jar file into the appropriate path under your MSLV_Home directory. The appropriate path for each file can be identified by the path specified in the .jar file.

Sample code options:

  • AssignWorkQueues

  • ProvPlanDefault

  • ExtensionFrameworkOneWayTest

  • SampleExtensionException

  • InvokeCorbaAPIExtension

For each sample, the following file types exist in the mss_ext_samples.jar file. (The only exception is the InvokeCorbaAPIExtension sample, which does not have a supporting XML file because there is no input data needed for this sample.)

  • .java: the extension Java source file

  • .class: the corresponding compiled Java class file

  • .xml: the supporting xml file that defines sample input data and sample configuration data that is passed to the extension logic

For example, the following three files that support the AssignWorkQueues sample exist in the mss_ext_samples.jar file:

  • AssignWorkQueues.java

  • AssignWorkQueues.class

  • AssignWorkQueues.xml

AssignWorkQueues

The AssignWorkQueues sample is provided to show extension logic that assigns specific work queues, and uses a synchronous example. The sample logic shows how to return the specific data that the Assign Queues execution point is expecting. When the sample code is executed, it also shows the outcome of this action. Specifically, the data that was passed back to the execution point is logged for your viewing.

To run the AssignWorkQueues sample code:

  1. Through the UI, define a synchronous extension with the name AssignWorkQueues.

  2. Through the UI, associate the Assign Queues execution point with the extension by searching for the following criteria:

    • Building Block: All Task Types

    • Process Point: Task Maintenance

    • Action Type: Assign Queues

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed.

    server is the name of the WebLogic server.

  5. Look at the AssignWorkQueues.xml file to understand what the expected results should be in step 7. Specifically, the AssignWorkQueues.xml file defines four tasks and the corresponding work queues to which the tasks are assigned. The work queues are returned by the AssignWorkQueues extension logic.

  6. Through the UI, trigger the execution point by assigning work queues.

  7. Verify the outcome by looking in the UI, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

ProvPlanDefault

The ProvPlanDefault sample is provided to show extension logic that defaults a provisioning plan, and uses a synchronous example. The sample logic shows how to return the specific data that the Provisioning Plan Default execution point is expecting. When the sample code is executed, it also shows the outcome of this action. Specifically, the data that was passed back to the execution point is logged for your viewing.

To run the ProvPlanDefault sample code:

  1. Through the UI, define a synchronous extension with the name ProvPlanDefault.

  2. Through the UI, associate the Provisioning Plan Default execution point with the extension by searching for the following criteria:

    • Building Block: All Task Types

    • Process Point: Task Generation

    • Action Type: Provision Plan Default

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure that the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Look at the ProvPlanDefault.xml file to understand what the expected results should be in step 7. Specifically, the ProvPlanDefault.xml file defines a specific provisioning plan ID that is returned by the ProvPlanDefault extension logic.

  6. Through the UI, trigger the execution point by assigning a provisioning plan to an order.

  7. Verify the outcome by looking in the UI, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

ExtensionFrameworkOneWayTest

The ExtensionFrameworkOneWayTest sample is provided to show extension logic that sends an email notification. When the sample code is executed, it shows the outcome of this action, and the notification is logged for your viewing. This sample also shows:

  • How to read an XML file and determine what execution point invoked it.

  • How to send an email notification.

  • How to read the input name/value pair Array and put that data into an email.

To run the ExtensionFrameworkOneWayTest sample code:

  1. Through the UI, define an extension with the name ExtensionFrameworkOneWayTest.

  2. Through the UI, associate an execution point with the extension by searching for criteria such as:

    • Building Block: All Task Types

    • Process Point: Task Maintenance

    • Action Type: Assign Jeopardy

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure that the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Look at the ExtensionFrameworkOneWayTest.xml file to understand what the expected results should be in step 7. Modify the data, such that the email recipient is a valid address that can check for the mail notification, and the SmtpServerKey value is valid for your location.

  6. Through the UI, trigger the execution point that was selected in step 2.

  7. Verify the outcome by looking in designated email inbox, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

SampleExtensionException

The SampleExtensionException sample is provided to show extension logic that sends an email notification and throws an exception. The code always throws an exception. When the sample code is executed, it shows the outcome of this action in the form of the email notification, and in the form of a logged error if the extension is defined as synchronous.

Note:

If the extension is defined as asynchronous, the extension framework does not log an error, but it does send an email notification.

If the extension is defined as synchronous, the extension framework logs an error to the log file, in addition to sending the email notification.

Perform the following steps to run the SampleExtensionException sample code:

  1. Through the UI, define a synchronous extension with the name SampleExtensionException.

  2. Through the UI, associate an execution point with the extension by searching for criteria such as:

    • Building Block: All Task Types

    • Process Point: Task Maintenance

    • Action Type: Assign Jeopardy

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure that the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Look at the SampleExtensionException.xml file to understand what the expected results should be in step 7. Modify the data, such that the email recipient is a valid address that can check for the exception notification, and the SmtpServerKey value is valid for your location.

  6. Through the UI, trigger the execution point that was selected in step 2.

  7. Verify the outcome by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

InvokeCorbaAPIExtension

The InvokeCorbaAPIExtension sample is provided to show how to code CORBA API calls in the extension logic. When the sample code is executed, it also shows the outcome of this action. Specifically, the sample calls the CORBA API method getOrganization(), so the organization is logged for your viewing.

To run the InvokeCorbaAPIExtension sample code:

  1. Through the UI, define an extension with the name InvokeCorbaAPIExtension.

  2. Through the UI, associate an execution point with the extension by searching for criteria such as:

    • Building Block: All Task Types

    • Process Point: Task Maintenance

    • Action Type: Assign Jeopardy

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure that the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Through the UI, trigger the execution point that was selected in step 2.

  6. Verify the outcome by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

SelectComponent

The SelectComponent sample is provided to show extension logic that selects a component or element, and uses a synchronous example. The sample logic shows how to return the specific data that the Select Component or Element execution point is expecting. When the sample code is executed, it also shows the outcome of this action. Specifically, the data that was passed back to the execution point is logged for your viewing.

This sample is very specific in its function. Other samples are open-ended and can apply to several execution points. This sample code calls specific methods to accomplish the component selection. Java documentation is provided in the sample code to give you additional information about the methods that the sample code calls.

To run the SelectComponent sample code:

  1. Through the UI, define a synchronous extension with the name SelectComponent.

  2. Through the UI, associate the Select Component or Element execution point with the extension by searching for the following criteria:

    • Building Block: All Connections

    • Process Point: PCONDES Maintenance

    • Action Type: Select Component or Element

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Through the UI:

    • Set up a DSLAM network location.

    • Add a network element of type DSL Multiplexer to the DSLAM network location.

    • Add a DSL card with an available port matching the rate code of the ordered service to the DSL Multiplexer.

    • Enter a PSR order with an end user location that has the same zip code as the DSLAM network location.

    • On the PSR order, add a service to the end user location that can be auto provisioned.

    • Assign a provisioning plan to the order that defines the PCONDES task.

  6. Through the UI, trigger the execution point by completing the PCONDES task.

  7. Verify the outcome by looking in the UI, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

SelectPort

The SelectPort sample is provided to show extension logic that selects a port address, and uses a synchronous example. The sample logic shows how to return the specific data that the Select Port Address execution point is expecting. When the sample code is executed, it also shows the outcome of this action. Specifically, the data that was passed back to the execution point is logged for your viewing.

This sample is very specific in its function. Other samples are open-ended and can apply to several execution points. This sample code calls specific methods to accomplish the port selection. Java documentation is provided in the sample code to give you additional information about the methods that the sample code calls.

To run the SelectPort sample code:

  1. Through the UI, define a synchronous extension with the name SelectPort.

  2. Through the UI, associate the Select Port Address execution point with the extension by searching for the following criteria:

    • Building Block: All Connections

    • Process Point: PCONDES Maintenance

    • Action Type: Select Port Address

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

    where:

    MSLV_Home is the directory in which the MetaSolv Solution software is installed

    server is the name of the WebLogic server

  5. Through the UI:

    • Set up a DSLAM network location.

    • Add a network element of type DSL Multiplexer to the DSLAM network location.

    • Add a DSL card with an available port matching the rate code of the ordered service to the DSL Multiplexer.

    • Enter a PSR order with an end user location that has the same zip code as the DSLAM network location.

    • On the PSR order, add a service to the end user location that can be auto provisioned.

    • Assign a provisioning plan to the order that defines the PCONDES task.

  6. Through the UI, trigger the execution point by completing the PCONDES task.

  7. Verify the outcome by looking in the UI, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

SelectComponentForVirtual

The SelectComponentForVirtual sample is provided to show extension logic that selects a component or element for a virtual connection using a synchronous call. The sample logic reads the values (NS_ID and NS_COMP_ID) from the corresponding XML file. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method. When the sample code is executed, it shows the outcome of this action by logging the input parameters to the console.

To run the SelectComponentForVirtual sample code:

  1. Through the UI, define a synchronous extension with the name SelectComponentForVirtual.

  2. Through the UI, associate the Select Component or Element execution point with your newly created extension by searching for the following criteria:

    • Building Block-All Connections

    • Process Point-VCONDES Maintenance

    • Action Type-Select Component or Element

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the SelectComponentForVirtual.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file represent the desired Network System (NS_ID) and Component (NS_COMP_ID) for the virtual connection to be provisioned to. This file is read by the custom extension in step 6, and therefore you must modify these key values to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order with one or more virtual connections.

    • Assign a provisioning plan to the order that defines the VCONDES task.

    • Open the Service Request Virtual Circuits window by opening the VCONDES task.

    • Select one or more connections and then select Auto Provision from the Options menu.

    • Verify the outcome by looking in the UI, and by looking in the server.mss.xml file located in the MSLV_Home/server/appserver/logs directory.

SelectNetworkSystemForNetDesign

The use of the Select Network System execution point is demonstrated through the SelectNetworkSystemForNetDesign sample code.

The SelectNetworkSystemForNetDesign sample is provided to show extension logic that selects a network system for a network design automation. The sample logic reads the expected values (which are listed below in sample XML file) from the corresponding XML file, but shows how to return the data that the Select Network System execution point is expecting. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method.

To run the SelectNetworkSystemForNetDesign sample code:

  1. Through the UI, define a synchronous extension with the name SelectNetworkSystemForNetDesign.

  2. Through the UI, associate the SelectNetworkSystem execution point with your newly created extension by searching for the following criteria:

    • Building Block - Network System

    • Process Point - Network System Design

    • Action Type - Select Network System

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the SelectNetworkSystemForNetDesign.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file are listed below in the provided sample data. The sample data represents the network system properties that would be designed as part of automation of NETDSGN task. This file is read by the custom extension in step 6, so you must modify the key values provided in the sample data to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order.

    • Assign a provisioning plan to the order that defines the NETDSGN task and assign this task to the SYSTEM work queue.

The following example shows the SelectNetworkSystemForNetDesign.xml file format when using the SelectNetworkSystem execution point:

<?xml version="1.0" encoding="UTF-8"?>

<SAMPLEDATA> 
<RETURNDATA KEY="NS_ID" VALUE="user input value"/>
<RETURNDATA KEY="ACTIVITY_IND" VALUE="user input value"/>
<RETURNDATA KEY="NS_TEMPLATE_NAME" VALUE="user input value"/>
<RETURNDATA KEY="SHORT_NAME" VALUE="user input value"/>
<RETURNDATA KEY="LONG_NAME" VALUE="user input value"/>
<RETURNDATA KEY="DESC_100" VALUE="user input value"/>
<RETURNDATA KEY="HARD_SOFT_ASSIGN_CD" VALUE="user input value"/>
<RETURNDATA KEY="CUSTOMER_SYS_ID" VALUE="user input value"/>
<RETURNDATA KEY="PROVIDER_SYS_ID" VALUE="user input value"/>
<CUSTOM_ATTRIBUTE NAME="user input value">
<VALUE>user input value</VALUE>
</CUSTOM_ATTRIBUTE>
<CUSTOM_ATTRIBUTE NAME="user input value">
<!-- to delete existing CA value below tag should be used(applicable
for multi-valued CA's)-- >
<VALUE DELETE=”TRUE”>CA Value</VALUE>
</CUSTOM_ATTRIBUTE>
<!—- add custom attribute tags as needed, depending on CA's that are 
populated for the network system -->
</SAMPLEDATA>

Table B-1 describes the keys in the SelectNetworkSystemForNetDesign.xml file.

Table B-1 SelectNetworkSystemForNetDesign Keys

Key Name Description Mandatory/Optional Data Type Sample/Valid Values

ACTIVITY_IND

Activity indicator

Mandatory

Char

"N" or "C" for new and change activities

NS_TEMPLATE_

NAME

Network system template name

For New activity, this field is mandatory

String

N/A

SHORT_NAME

Network system name

Few New activity, this field is mandatory

String

N/A

LONG_NAME

Long name for network system

Optional

String

N/A

DESC_1OO

Network system description

Optional

String

N/A

NS_ID

Network system ID (can be populated in update activity)

Optional

Int

N/A

HARD_SOFT_ASSIGN_CD

Hard soft value

Optional

String

HARD/SOFT/NONE

CUSTOMER_SYS_ID

Customer system ID

N/A

String

N/A

PROVIDER_SYS_ID

Provider system ID

Optional

String

N/A

NAME

(custom attribute name)

CA name

Mandatory if CA has to be populated

String

N/A

VALUE

(custom attribute value)

CA value

Mandatory if CA has to be populated

String

N/A

SelectCustEdgeCompForNetDesign

The use of the Select Customer Edge Component execution point is demonstrated through the SelectCustEdgeCompForNetDesign sample code.

The SelectCustEdgeCompForNetDesign sample is provided to show extension logic that selects a customer edge components for a network design automation. The sample logic reads the expected values (which are listed below in sample XML file) from the corresponding XML file, but shows how to return the data that the Select Customer Edge Component execution point is expecting. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method.

To run the SelectCustEdgeCompForNetDesign sample code:

  1. Through the UI, define a synchronous extension with the name SelectCustEdgeCompForNetDesign.

  2. Through the UI, associate the Select Customer Edge Component execution point with your newly created extension by searching for the following criteria:

    • Building Block - Network System

    • Process Point - Network System Design

    • Action Type - Select Customer Edge Component

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the SelectCustEdgeCompForNetDesign.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file are listed below in the provided sample data. This data represents the customer edge component properties that would be designed as part of NETDSGN task automation. This file is read by the custom extension in step 6, so you must modify the key values provided in the sample data to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order.

    • Assign a provisioning plan to the order that defines the NETDSGN task and assign this task to SYSTEM work queue.

The following example shows the SelectCustEdgeCompForNetDesign.xml file format when using the Select Customer Edge Component execution point:

<?xml version="1.0" encoding="UTF-8"?>

<SAMPLEDATA> 
<CUSTOMEREDGE>
<RETURNDATA KEY="ACTIVITY_IND" VALUE="N"/>
<RETURNDATA KEY="CE_NAME" VALUE="user input value"/>
<RETURNDATA KEY="CE_LOCATION_NAME" VALUE="user input value"/>
<RETURNDATA KEY="CE_TYPE" VALUE="CUST_SITE"/>
<RETURNDATA KEY="CE_NUMBER" VALUE="12"/>
<CUSTOM_ATTRIBUTE NAME=" user input value ">
<VALUE>CA Value</VALUE>
<!-- to delete existing CA value below tag should be
used(applicable for multi-valued CA's)-- >
<VALUE DELETE=”TRUE”>CA Value</VALUE>
</CUSTOM_ATTRIBUTE>
<!-— add custom attribute tags as many as you want depending on CA's
that need to be populated for network systems -->
</CUSTOMEREDGE>
<!—- add custom attribute tags as needed, depending on CA's that are 
populated for the network system -->
</SAMPLEDATA>

Table B-2 describes the keys in the SelectCustEdgeCompForNetDesign.xml file.

Table B-2 SelectCustEdgeCompForNetDesign Keys

Key Name Description Mandatory/Optional Data Type Sample/Valid Values

ACTIVITY_IND

Activity indicator

Mandatory

Char

"N" or "C" for new and change activities

CE_NAME

Customer edge component name

For New activity, this field is mandatory

String

N/A

CE_NUMBER

Integer number used with CE_NAME to uniquely identify each CE

Optional

Int

N/A

CE_LOCATION_

NAME

CLLI code of customer edge location. It should be the same as location name on the order.

For New activity, this field is mandatory.

String

N/A

CE_TYPE

Type of customer edge component

For New activity, this field is mandatory.

String

Sample data: CUST_SITE, CE_RTR

NS_COMP_ID

Network component ID (can be populated in update activity)

Optional

Int

N/A

NETWORK_ELEMENT_ID

Network element ID

Optional

String

N/A

NAME

(custom attribute name)

CA name

Mandatory if CA has to be populated

String

N/A

NAME

(custom attribute value)

CA value

Mandatory if CA has to be populated

String

N/A

SelectConnectionEndPoints

The use of the Select End Component For Physical Connection execution point is demonstrated through the SelectConnectionEndPoints sample code.

The SelectConnectionEndPoints sample is provided to show extension logic that selects a connection end point for each physical connection present on a PSR order. The sample logic reads the expected values (which are listed below in a sample XML file) from the corresponding XML file, but shows how to return the data that the Select End Component For Physical Connection execution point is expecting. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method.

Perform the following steps to run the SelectConnectionEndPoints sample code:

  1. Through the UI, define a synchronous extension with the name SelectConnectionEndPoints.

  2. Through the UI, associate the Select End Component For Physical Connection execution point with your newly created extension by searching for the following criteria:

    • Building Block - Network System

    • Process Point - Network System Design

    • Action Type - SelectEndComponentForPhysicalConnection

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the SelectConnectionEndPoints.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file represent the desired Network System (NS_ID) and Component (NS_COMP_ID) for the virtual connection to be provisioned to. This file is read by the custom extension in step6, and therefore you must modify these key values to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order and order for physical connections.

    • Assign a provisioning plan to the order that defines the NETDSGN task and assign this task to SYSTEM work queue.

The following example shows the SelectConnectionEndPoints.xml file format when using the Select End Component For Physical Connection execution point:

<?xml version="1.0" encoding="UTF-8"?>

<SAMPLEDATA> 
<CONNECTION>
<RETURNDATA KEY="ACTIVITY_IND" VALUE="(N)ew or (C)hange"/>
<RETURNDATA KEY="CE_NAME" VALUE="customer edge comp name"/>
<RETURNDATA KEY="CE_NUMBER" VALUE="customer edge number"/>
<RETURNDATA KEY="PE_NAME" VALUE="provider edge name"/>
<RETURNDATA KEY="PE_NUMBER" VALUE="provider edge number"/>
<RETURNDATA KEY="PE_NETWORK_NAME" VALUE="network system name of PE"/>
<RETURNDATA KEY="CONNECTION_ECCKT" VALUE="connection name"/>
<RETURNDATA KEY="PE_PARENT_NETWORK_NAME" VALUE="outer network of PE"/>
<!— CONNECTION tags can be added as needed, depending on the number of
physical connections on the order. -->
</SAMPLEDATA>

Table B-3 describes the keys in the SelectConnectionEndPoints.xml file.

Table B-3 SelectConnectionEndPoints Keys

Key Name Description Mandatory/Optional Data Type Sample/Valid Values

ACTIVITY_IND

Activity indicator

Mandatory

Char

"N" or "C"

CE_NAME

Customer edge component name.

This should be the CE_NAME value returned from the SelectCusotmerEdgeComponent exeution point.

This is one end of the connection.

For New activity, this field is mandatory.

String

N/A

CE_NUMBER

Integer number used with CE_NAME to uniquely identify each CE.

This should be the CE_NUMBER value returned from the SelectCustomerEdgeComponent execution point.

Optional

Int

N/A

PE_NAME

Provider edge component name.

This is the other end of the connection.

For New activity, this field is mandatory.

String

N/A

PE_NUMBER

Integer number used with PE_NAME to uniquely identify each PE.

Optional

Int

N/A

PE_NETWORK_NAME

Represents immediate parent network system of PE.

This network should have a component with PE_NAME and PE_NUMBER values.

For New activity, this field is mandatory.

String

N/A

PE_PARENT_

NETWORK_NAME

This field is useful when multiple layers of embedded networks exist for PE.

Optional

String

N/A

CONNECTION_

ECCKT

Connection name

Mandatory

String

N/A

SelectCustEdgeEquipForNetDesign

The use of the Select Equipment For CE execution point is demonstrated through the SelectCustEdgeEquipForNetDesign sample code.

The SelectCustEdgeEquipForNetDesign sample is provided to show extension logic that selects an equipment and customer edge component so that the customer edge can be associated with equipment. The sample logic reads the expected values (which are listed below in a sample XML file) from the corresponding XML file, but shows how to return the data that the Select Equipment For CE execution point is expecting. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method.

To run the SelectCustEdgeEquipForNetDesign sample code:

  1. Through the UI, define a synchronous extension with the name SelectCustEdgeEquipForNetDesign.

  2. Through the UI, associate the Select Equipment For CE execution point with your newly created extension by searching for the following criteria:

    • Building Block - Network System

    • Process Point - Network System Design

    • Action Type - Select Equipment For CE

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the SelectCustEdgeEquipForNetDesign.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file represent the desired Network System (NS_ID) and Component (NS_COMP_ID) for the virtual connection to be provisioned to. This file is read by the custom extension in step6, and therefore you must modify these key values to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order and order for physical connections.

    • Assign a provisioning plan to the order that defines the NETDSGN task and assign this task to SYSTEM work queue.

The following example shows the SelectCustEdgeEquipForNetDesign.xml file format when using the Select Equipment For CE execution point:

<?xml version="1.0" encoding="UTF-8"?>
<SAMPLEDATA>
<CUSTOMEREDGE NAME="CE name" 
CE_NUMBER="CE number"
EQUIPMENT_ID="equipment id" />
</CUSTOMEREDGE>
<!—- add CUSTOMEREDGE tags as needed, depending on number of equipments
associated with customer edge comp -->
</SAMPLEDATA>

Table B-4 describes the keys in the SelectCustEdgeEquipForNetDesign.xml file.

Table B-4 SelectCustEdgeEquipForNetDesign Keys

Key Name Description Mandatory/Optional Data Type Sample/Valid Values

CE_NAME

Customer edge component name.

This should be the CE_NAME value returned from the SelectCusotmerEdgeComponent execution point.

Mandatory

String

N/A

CE_NUMBER

Integer number used with CE_NAME to uniquely identify each CE.

This should be the CE_NUMBER value returned from the SelectCusotmerEdgeComponent execution point.

Optional

Int

N/A

EQUIPMENT_ID

Equipment ID

Mandatory

Int

N/A

DS0/DS1 Automated Design

The use of the DS0/DS1 Automated Design execution point is demonstrated through the FacilityAutomatedDesign sample code.

The FacilityAutomatedDesign sample logic in the Java file shows the users how to provide the desired input assignment information (which is listed in the tables below). The sample logic demonstrates how to format and pass the data as required by the calling method.

To run the FacilityAutomatedDesign sample code:

  1. Through the UI, define a synchronous extension with the name FacilityAutomatedDesign.

  2. Through the UI, associate an execution point with the extension by searching for criteria such as:

    • Building Block: Connection

    • Process Point: Connection Design

    • Action Type: DS0/DS1 Automated Design

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the FacilityAutomatedDesign file in the MSLV_Home/server/appserver/samples/customExtension/com/metasolv/custom/vendor/extension/FacilityAutomatedDesign directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The parameters in this file are listed below in the provided sample data. The sample data represents the assignments that would be designed as part of automation of the AUTODSGN task. This file is read by the custom extension in step 6, so you must modify the parameter values provided in the sample data to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order.

    • Assign a provisioning plan to the order that defines the AUTODSGN task and assign this task to SYSTEM work queue.

Table B-5 describes the input parameters that need to be set in com.mslv.core.pi.internal.NetProv.ConnDesign.containerData.ProvisioningContainer.

Table B-5 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ProvisioningContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

networkBlocks

Collection of all the Network Assignment containers - NetworkAssignmentData.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Optical Provisioning needs to be done.

faciltyBlocks

Collection of all the Facility Assignment containers - ChannelContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Facility Assignment needs to be done.

equipmentBlocks

Collection of all the Equipment Assignment containers - PortContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Equipment Assignment needs to be done.

cableBlocks

Collection of all the Cable Pair Assignment containers - CablePairBlockContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Cable Pair Assignment needs to be done.

crossReferenceBlocks

Collection of all the Cross Reference containers - CrossReferenceContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Cross Reference needs to be added.

miscInfoBlocks

Collection of all the Miscellaneous Information. The miscellaneous information has to be passed in a String variable. Only 16 characters can be added in one design line and the rest will be wrapped in the subsequent lines. The first 160 characters will be taken for the assignment if the length exceeds 160 characters.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Miscellaneous Information needs to be added.

foreignInfoBlocks

Collection of all the Foreign Info containers - ForeignInfoContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no Foreign Info needs to be added.

notesBlocks

Collection of all the Notes containers - NotesContainer.

Optional

Vector

If not provided in the Custom Extension code, AUTODSGN assumes no notes are to be added.

Table B-6 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.NetworkAssignmentData.

Table B-6 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.NetworkAssignmentData

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

channelAssignments

Collection of all the Channel Assignment containers - one element for one channel position.

At least one element is mandatory

Vector of ChannelAssignmentData

If no element is present in the ChannelAssignments Vector, the AUTODSGN task will error out.

portAssignments

Collection of all the Port Assignment containers.

Optional

Vector of PortAssignmentData

N/A

commonNetworkNsId

Network ID of common Network System

Mandatory

Int

Should be a valid Network system ID, otherwise the AUTODSGN task will error out.

origCompId

Originating Component ID

Mandatory

Int

Should be a valid Component Id within the Network specified above, otherwise the AUTODSGN task will error out.

termCompId

Terminating Component ID

Mandatory

Int

Should be a valid Component ID within the Network specified above, otherwise the AUTODSGN task will error out.

additionalAssignmentSeqNbr

Additional assignment sequence number

Optional

Int

N/A

blockType

WP: Working Path

PP: Protect Path (implies wp + pp)

Mandatory

String

WP and PP are the only valid values, otherwise the AUTODSGN task will error out.

Table B-7 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ChannelAssignmentData.

Table B-7 Input Parameters to Set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ChannelAssignmentData

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

parentCircuitDesignId

Circuit Design ID of the Parent Connection.

Mandatory

Int

Should be a valid Circuit Design ID within the Network specified above, otherwise the AUTODSGN task will error out.

circuitPositions

Circuit positions from the root parent circuit.

Mandatory

ArrayList

If given positions are not valid, the AUTODSGN task will error out.

protectPathIndicator

Y: Yes (for protect path segment)

N: No (for working path segment)

Mandatory

Char

If not populated with one of the mentioned values, the AUTODSGN task will error out.

mainNetworkNsId

Network System ID.

Optional

Int

Should be a valid Network System ID.

sameChannelIndicator

Same channel Indicator.

Optional

Char

N/A

Table B-8 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.PortAssignmentData.

Table B-8 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.PortAssignmentData.

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

Root Equipment id

This represents base equipment (rack) on which required CARD is mounted.

Mandatory

long

If this is provided in input, but does not exist in the inventory, the AUTODSGN task will error out.

associatedToOrig

True: port associated at Originating Node.

False: Port associated at Terminating Node

Mandatory

Boolean

N/A

Port Sequence

Port on the equipment to which the connection needs to be assigned.

Mandatory

long

If not provided, the AUTODSGN task will error out.

mountingPositions

List of mounting position numbers. This represents position of CARD with respect to RACK (root equipment) to which connection has to be assigned.

Optional

ArrayList

N/A

Table B-9 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ChannelContainer.

Table B-9 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ChannelContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

parentCircuitId

Circuit Design ID of the Parent Connection.

Mandatory

Int

Should be a valid Circuit Design ID, otherwise the AUTODSGN task will error out.

channelPositionNbr

Circuit position to which the child circuit should be assigned.

Mandatory

Int

If given position is not valid, the AUTODSGN task will error out.

Table B-10 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.PortContainer.

Table B-10 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.PortContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

equipmentId

The equipment on which the port assignment has to be made.

Mandatory

Int

If this is provided in input, but does not exist in the inventory, the AUTODSGN task will error out.

Port Sequence

Port on the equipment to which the connection needs to be assigned.

Mandatory

Int

If given port address is not valid, the AUTODSGN task will error out.

aZOtherCd

The code which identifies the side of the port assignment.

Mandatory

Char

The valid values are A, Z and O.

Table B-11 describes the input parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CablePairBlockContainer.

Table B-11 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CablePairBlockContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

sideOfCircuitInd

The indicator which determines the side of the circuit where the cable pair assignment has to be made. The valid values are A, Z and I.

Mandatory

Char

If the value is anything other than A, Z and I, the AUTODSGN task will error out.

sideOfCircuitSequenceNumber

The sequence number to identify the specific cable pair assignment within a Cable Pair Block. There can be multiple cable pair assignments under the sideOfCircuitindicator 'I'.

Conditional

Boolean

Mandatory if the sideOfCircuitInd is 'I'

cablePairSetVector

Collection of all the Cable Pair Set information.

Mandatory

Vector of CablePairSetContainer

N/A

Table B-12 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CablePairSelfContainer

Table B-12 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CablePairSetContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

additionaldBLoss

Allows the user to enter additional DB Loss for that Cable Pair Set.

Optional

Float

N/A

additionalResistance

Allows the user to enter additional Resistance for that Cable Pair Set.

Optional

Float

N/A

cableContainerVector

Collection of all the Cable pair information.

Mandatory

Vector of CableContainer

N/A

Table B-13 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CableContainer.

Table B-13 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CableContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

cableId

The cable ID of the desired Cable.

Mandatory

Int

If this does not exist in the inventory, the AUTODSGN task will error out.

cableComplementId

The Cable Complement ID of the desired Cable complement.

Mandatory

Int

If this does not exist in the inventory, the AUTODSGN task will error out. The Complement should have the above mentioned cable ID associated to it.

pairFibreChannelIdentifier

The identifier of the desired pair or fibre.

Mandatory

Int

The pair should exist for the specified Cable and Cable Complement and be in unassigned status. If not, the AUTODSGN task will error out.

functionCode

The Function code for the pair.

Conditional

This code is optional if the user preference, Functional Code is Required, is set to N.

String

If the specified value is not one from the valid value list - T, R, S1, S2, X1, X2 - the AUTODSGN task will error out.

pendingDate

The pending date of the pair.

Optional

String

Should be a valid date, if not the AUTODSGN task will error out.

remarks

Remarks for the pair.

Optional

String

The terminal pair should be in unassigned status. If not, the AUTODSGN task will error out.

terminalPairsOriginating

The terminal pairs to be assigned on the Originating end if the Originating location is a Terminal Pair.

Optional

Int []

The terminal pair should be in unassigned status. If not, the AUTODSGN task will error out.

terminalPairsTerminating

The terminal pairs to be assigned on the Terminating end if the Terminating location is a Terminal Pair.

Optional

Int []

If this does not exist in the inventory, the AUTODSGN task will error out.

separationsRouteCode

The Identifier of the Separations route code to be assigned to the Pair assignment.

Optional

String

If this does not exist in the inventory, the AUTODSGN task will error out.

srLocationdId

The originating location of the Separations Route.

Conditional

Int

It is mandatory if the separations route code is populated in the container. Also, if the combination of Separations Route code, Originating location ID and terminating location ID is invalid, the AUTODSGN task will error out.

srLocationdId2

The terminating location of the Separations Route.

Conditional

Int

It is mandatory if the separations route code is populated in the container. Also, if the combination of Separations Route code, Originating location ID and terminating location ID is invalid, the AUTODSGN task will error out.

numOfWires

The number of wires to be assigned.

Optional

Int

N/A.

Table B-14 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CrossReferenceContainer.

Table B-14 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.CrossReferenceContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

crossReferenceType

The type of the Cross reference.

Optional

String

If not provided, the value will be taken from the preference. If provided, the value should be one from the valid value list - SYNONYM, ALIASCUSTOMER, ALIASPROVIDER, CHILD, CKR.

crossReferenceValue

The Cross Reference value to be assigned.

Mandatory

String

If not provided, the AUTODSGN task will error out.

status

The status of the Cross reference circuit.

Optional

Char

N/A

accessProviderServCenter

The ICSC (Inter-Exchange Carrier Service Provider Code) value to be assigned.

Optional

String

The value should be a valid ICSC, if not, the AUTODSGN task will error out.

accessCust

The CCNA (Customer Carrier Naming Abbreviation) value to be assigned.

Optional

String

The value should be a valid CCNA, if not, the AUTODSGN task will error out.

associatedLocationId

The location ID corresponding to the Location to be assigned. For End User locations, the ID in the location_id_sr column from End_user_location table should be used.

Optional

Int

The value should be a valid Location ID, if not, the AUTODSGN task will error out.

Table B-15 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerDataForeignInfoContainer.

Table B-15 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ForeignInfoContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

AZTransmissionLevel

The value to be entered in the AZTransmissionLevel column of the Design line.

Optional

String

N/A

noteIndicator

The value to be entered in the note indicator column.

Optional

Char

If the value is one in the following list - I, O, D or 0 - the AUTODSGN task will error out.

equipTypeFacilityDesig

The value to be entered in the equipTypeFacilityDesig column of the Design line.

Optional

String

N/A

incrementalMileage

The value to be entered in the incrementalMileage column of the Design line.

Optional

String

N/A

location

The value to be entered in the location column of the Design line.

Optional

String

N/A

miscInfo

The value to be entered in the miscInfo column of the Design line.

Optional

String

N/A

relayRackFacilityType

The value to be entered in the relayRackFacilityType column of the Design line.

Optional

String

N/A

signalVoice

The value to be entered in the signalVoice column of the Design line.

Optional

String

N/A

unitChannel

The value to be entered in the unitChannel column of the Design line.

Optional

String

N/A

ZATransmissionLevel

The value to be entered in the ZATransmissionLevel column of the Design line.

Optional

String

N/A

Table B-16 describes the parameters to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.NoteContainer.

Table B-16 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.NotesContainer

Parameter Name Description Mandatory/Optional/Conditional Data Type Error Conditions

noteIndicator

The value to be entered in the note indicator column.

Mandatory

Char

If this is not provided in input, the AUTODSGN task will error out. If the value is one in the following list - I, O, D or 0 - the AUTODSGN task will error out.

noteText

The value to be entered as a note to the circuit.

Mandatory

String

If this is not provided in input, the AUTODSGN task will error out.

ConnectionIdAutomation

The use of the Connection Id Automation execution point is demonstrated through the ConnectionIdAutomation sample code.

The ConnectionIdAutomation sample is provided to show extension logic that receives the information required for the Connection Id generation. The sample logic reads the expected values (which are listed below in a sample XML file) from the corresponding XML file, but shows how to return the data that the Connection Id Automation execution point is expecting. Even though the sample logic uses values from an XML file instead of performing actual logic to retrieve those values, it does demonstrate how to format the return data as required by the calling method.

Perform the following steps to run the ConnectionIdAutomation sample code:

  1. Through the UI, define a synchronous extension with the name ConnectionIdAutomation.

  2. Through the UI, associate the Connection Id Automation execution point with your newly created extension by searching for the following criteria:

    • Building Block: Connection

    • Process Point: Connection Design

    • Action Type: Connection Id Automation

  3. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Navigate to the ConnectionIdAutomation.xml file in the MSLV_Home/server/ appserver/samples/customExtension/xml directory, where MSLV_Home is the directory in which the MetaSolv Solution software is installed and server is the name of the WebLogic server.

    The keys in this file represent the desired information using which the Connection Id should be generated. This file is read by the custom extension in step 6, and therefore you must modify these key values to represent the actual corresponding data in your database.

  5. Ensure the logging level is set correctly by checking the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  6. Through the UI:

    • Enter a PSR order and order for physical connections.

    • Assign a provisioning plan to the order that defines the CKTID task and assign this task to SYSTEM work queue.

Notes:

  • The CKTID Task Automation is applicable only to the circuits that are ordered through PSR.

  • The out-of-the-box algorithm applies the automated circuit id generation to traditional circuits (CIRCUIT and INTRNCKT Item types) and template-based connections (CONNECTOR item types).

  • The out-of-the-box functionality for traditional circuits generates either CLS or CLF type circuits.

  • The out-of-the-box functionality for template-based connections uses the current process to generate OTS type circuits.

  • The only valid connection formats for the custom extension and out-of-the-box functionality are CLS, CLF, OTF, and OTS.

  • The only valid circuit types are C, F, and S.

  • If the custom extension does not pass back an ID for CLS or CLF formats, the core code builds the correctly formatted ID.

  • If the custom extension does not pass back an ID for OTS, the core code appends the Constant for Freeformat Circuit ID preference with ”/” and a unique serial number to generate a unique ID.

  • Network Location A and Z typically comes from the order information.

  • If CE process point is not defined, then out-of-the-box functionality generates the Connection ID and other mandatory data that is required for circuit generation.

  • The information that is populated on the order is used for the out-of-the-box functionality and for the extension logic. If the extension does not populate information that is populated on the order, the order information is used. If the extension populates the information differently than the order, the extension information is used. If the extension does populate the information differently than the order, the order information remains intact and the process does not update the original order information.

  • Prior to 6.2.1, the current logic is used for template-based connections. If you have defined a stored procedure to define the Connection ID, it continues to still define the Connection ID. If you have not defined a stored procedure, the current default logic is executed. You can completely customize all the circuit information on a template-based connection using the new extension.

  • Currently, when you double-click the CKTID task and if there are CONNECTORS included in the task, the InvAutoIdProcess method is called to automatically generate the Connection ID. The code verifies if this extension has been implemented, if it has, then the InvAutoIdProcess method is not executed. An extension is considered implemented if an Extension Point has been associated to the Extension Summary.

  • If the custom extension does not pass back an ID for OTS, the core code appends the Constant for Freeformat Circuit ID preference with ”/” and a unique serial number to generate a unique ID.

The following fields are populated on the PSR Order:

  • Document Number

  • Serv Item Id

  • Item Type Cd

  • Item Alias

  • Rate Code

  • Framing

  • Line Coding

  • Framing ANSI indicator

  • Jurisdiction Code

  • Service Type Category

  • Service Type Code

  • Network Location A (Originating Location)

  • Network Location Z (Terminating Location)

    Note :

    There is currently an inconsistency between traditional and template-based connections and that is being addressed on another task.

The following example shows the ConnectionIdAutomation.xml file format when using the Connection Id Automation execution point:

<?xml version="1.0" encoding="UTF-8"?>
<SAMPLEDATA>
<RETURNDATA KEY="NETWORK_LOCATION_A" VALUE=""/>
<RETURNDATA KEY="NETWORK_LOCATION_Z" VALUE=""/>
  <RETURNDATA KEY="RATE_CODE" VALUE="DS1"/>
  <RETURNDATA KEY="SERVICE_TYPE_CATEGORY" VALUE="CLCI-SS LATA Access"/>
  <RETURNDATA KEY="SERVICE_TYPE_CODE" VALUE="DO"/>
  <RETURNDATA KEY="CONNECTION_TYPE" VALUE="S"/>
  <RETURNDATA KEY="CONNECTION_FORMAT" VALUE="CLS"/>
  <RETURNDATA KEY="FRAMING" VALUE="CBIT"/>
  <RETURNDATA KEY="LINE_CODING" VALUE="2B1Q"/>
  <RETURNDATA KEY="FRAMING_ANSI_INDICATOR" VALUE="Y"/>
  <RETURNDATA KEY="ALLOW_LOWER_RATES_INDICATOR" VALUE="Y"/>
  <RETURNDATA KEY="JURISDICTION_CODE" VALUE="0"/>
  <RETURNDATA KEY="PROTECTED_CIRCUIT_INDICATOR" VALUE="N"/>
  <RETURNDATA KEY="PARTITION_GROUP_ID" VALUE=""/>
  <RETURNDATA KEY="PREFIX" VALUE="EX"/>
  <RETURNDATA KEY="MODIFIER" VALUE="--"/>
  <RETURNDATA KEY="SERIAL_NUMBER" VALUE=""/>
  <RETURNDATA KEY="SUFFIX" VALUE=""/>
  <RETURNDATA KEY="TELCO_ID" VALUE="QFWU"/>
  <RETURNDATA KEY="SEGMENT" VALUE=""/>
  <RETURNDATA KEY="NETWORK_CHANNEL_SERVICE_CODE" VALUE=""/>
  <RETURNDATA KEY="NETWORK_CHANNEL_OPTION_CODE" VALUE=""/>
  <RETURNDATA KEY="FACILITY_DESIGNATION" VALUE=""/>
  <RETURNDATA KEY="FACILITY_TYPE" VALUE=""/>
  <RETURNDATA KEY="GENERATED_CONNECTION_ID" VALUE=""/>
</SAMPLEDATA>

Table B-17 describes the input parameters that need to be set in com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ConnectionIdAutomationData.

Table B-17 Input Parameters to Set In com.mslv.core.api.internal.NetProv.ConnDesign.containerData.ConnectionIdAutomationData

Parameter Name Description Mandatory/Optional/Conditional Data Type Sample/Valid Values

NETWORK_LOCATION_A

Location ID value of the primary location on the network location table. Network Location A typically comes from the order information.

Mandatory

Int

N/A

NETWORK_LOCATION_Z

Location ID value of the secondary location on the network location table. Network Location Z typically comes from the order information.

Conditional.

Mandatory for circuit type F or S.

Optional for circuit type C.

Int

N/A

RATE_CODE

The rate code of the circuit.

Optional

String

N/A

SERVICE_TYPE_CATEGORY

The service type category of the circuit.

Mandatory

String

N/A

SERVICE_TYPE_CODE

The service type code of the circuit.

Mandatory

String

N/A

CONNECTION_TYPE

The circuit type of the connection.

Mandatory

Char

Valid values:

  • C

  • F

  • S

CONNECTION_FORMAT

The format of the connection to be created.

Mandatory

String

Valid values:

  • CLF

  • CLS

  • OTS

  • OTF

LINE_CODING

The line coding value to be assigned to the circuit.

Optional

String

N/A

FRAMING

The framing value to be assigned to the circuit.

Optional

String

N/A

FRAMING_ANSI_INDICATOR

The framing ANSI value to be assigned to the circuit.

Optional

Char

N/A

ALLOW_LOWER_RATES_INDICATOR

The allow lower rate indicator to be stored for the circuit.

Default is N.

Optional

Char

N/A

JURISDICTION_CODE

The Jurisdiction code of the circuit.

Mandatory

String

N/A

FACILITY_DESIGNATION

The facility designation of the circuit to be created.

If the custom extension does not pass back a designation the core algorithm is used to generate the designation.

The core algorithm queries all designations between the two network locations, adds one, and compares the value to make sure it is within the CLF Designation Range if it exists. If no range has been set up, the range is 0-999999.

Conditional.

Mandatory for only CLF.

String

N/A

FACILITY_TYPE

The type of facility for the circuit.

Defaults to service type code ID if not provided.

Conditional.

Mandatory for only CLF.

String

N/A

MODIFIER

The modifier to be used for the connection ID generation in CLS format.

Conditional.

Mandatory for only CLS.

String

N/A

TELCO_ID

The Telco ID to be used for the connection ID generation in CLS format.

If this is not provided in the extension, the value in the preference, Service Request > Connection > Default Telco Id for Automation to default the Telco ID, is considered.

Conditional.

Mandatory for only CLS.

String

N/A

SERIAL_NUMBER

The serial number to be used for the connection ID generation in CLS format.

The system wide sequence is used to generate Serial Number if not provided.

Conditional.

Mandatory for only CLS.

String

N/A

PARTITION_GROUP_ID

Enables you to assign partition group to the connection.

Conditional.

The field is mandatory if the security preference, Use Partition Level Security for Access to Inventory Data, is set to Y. If the extension does not pass a value the system defaults the value to 101 – All Access.

Int

N/A

PROTECTED_CIRCUIT_INDICATOR

The serial number to be used for the connection ID generation.

Default is N.

Optional

Char

N/A

NETWORK_CHANNEL_SERVICE_CODE

The network channel service code to be used for the connection ID generation.

Optional

String

N/A

NETWORK_CHANNEL_OPTION_CODE

The network channel option code to be used for the connection ID generation.

Optional

String

N/A

PREFIX

The prefix value to be used for the connection ID generation in CLS format.

If the value is not provided, the system uses the system preference value under Service Request > Connection > Default Prefix for CLS Circuit IDs.

If preference also is not set, prefix will be 2 empty spaces.

Conditional.

Mandatory for only CLS.

String

N/A

SUFFIX

The suffix value to be used for the connection ID generation in CLS format.

Conditional.

Mandatory for only CLS.

String

N/A

SEGMENT

The segment value to be used for the Connection ID generation in CLS format.

Conditional.

Mandatory for only CLS.

String

N/A

GENERATED_CONNECTION_ID

This parameter holds the generated connection ID.

If the custom extension does not pass back an ID for CLS or CLF formats, the core code builds the correctly formatted ID.

If the custom extension does not pass back an ID for OTS, the core code appends the Constant for Freeformat Circuit ID preference with ”/” and a unique serial number to generate a unique ID.

Conditional.

Required for OTF.

Optional for CLS, CLF, and OTF.

String

N/A

DedicatedPlantSelection

The DedicatedPlantSelection sample code demonstrates the use of the Select Dedicated Plant action type.

The DedicatedPlantSelection sample code provides information about how to provide the input information and return the data.

The sample code reverses the prioritized sort order of the input dedicated plant list and populates this reversed list in the output dedicated plant list.

To run the DedicatedPlantSelection sample code:

  1. Create a synchronous extension with the name DedicatedPlantSelection.

  2. Associate the Select Dedicated Plant execution point with the DedicatedPlantSelection extension by searching for the following criteria:

    For the PCONDES Task:

    • Building Block Type = Connection

    • Building Block Name = All Connections

    • Process Point = PCONDES Maintenance

    • Action Type = Select Dedicated Plant

    For the AUTODSGN task:

    • Building Block Type = Connection

    • Building Block Name = All Connections

    • Process Point = Connection Design

    • Action Type = Select Dedicated Plant

  3. Ensure that the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  4. Ensure that the logging level is set correctly by verifying the loggingconfig.xml file located in the MSLV_Home/server/appserver/config directory.

  5. Do one of the following:

    • To automate the PCONDES task:

      • Enter a PSR order for physical connections.

      • Assign a provisioning plan to the order that contains the PCONDES task and assign this task to the SYSTEM work queue.

    • To automate the AUTODSGN task:

      • Enter a PSR order for circuits that have either a DS0 or N/A rate code and have been ordered as either a Circuit or Line product.

      • Assign a provisioning plan to the order that contains the AUTODSGN task and assign this task to the SYSTEM work queue.

Table B-18 lists the input parameters that you must set in com.mslv.core.api.internal.NetProv.containerData.design.DedicatedPlantExtensionData.

Table B-18 Input parameters to be set in com.mslv.core.api.internal.NetProv.containerData.design.DedicatedPlantExtensionData

Parameter Name Description

OutputDedicatedPlantList

List of dedicated plants to assign.

This parameter contains the following attributes:

  • ded_cc_grp_id: Unique key of the available dedicated plants.

  • last_modified_date: Last modified date of the available dedicated plants.

  • supports_product: True or False.

  • equipment_id: Equipment ID of the card used to build the available dedicated plants.

  • item_spec_id: Equipment specification ID of the service being designed.

  • item_spec_nm: Equipment specification name of the service being designed.

  • priority_seq: Priority sequence of the equipment set on the Plant Administration tab.

ErrorMessage

Error message to be sent to the server log.

Create/Update End User Location

The use of the Create/Update End User Location execution point is demonstrated through the SampleAddressValidation sample code.

The SampleAddressValidation sample is provided to show extension logic that receives the information required for validating the end user locations when you do any of the following:

  • Create or update end user location address information in the PSR Ordering Dialog

  • Create or update service locations on a PSR order

  • Create or update end user location information on the PRILOC/SECLOC Info tab of the Product Service Request window

  • Create or update end user location address information in the End User Location Maintenance window

The sample logic reads the expected values from the corresponding XML file and shows how to return the data that the Create and Update execution points are expecting. In addition, the sample logic can also access any third party systems, run direct database queries, and so on.

To run the SampleAddressValidation sample code:

  1. Define a synchronous extension and specify a name for the extension. For example, SampleAddressValidation.

    The extension name that you define must match the name and letter case of the Java class (for example, SampleAddressValidation.class) that contains your custom logic.

    The SampleAddressValidation.class and SampleAddressValidation.java files are located at:

    MSLV_Home/server/appserver/samples/customExtension/com/metasolv/custom/vendor/extension/SampleAddressValidation

    where:

    • MSLV_Home is the directory in which the MetaSolv Solution software is installed

    • server is the name of the WebLogic server

  2. Ensure the gateway.ini entry that defines the sample code path reflects the correct location of the sample files extracted from the mss_ext_samples.jar file.

  3. Associate the Create/Update End User Location execution point with the SampleAddressValidation extension by searching using the following criteria:

    • Building Block Type = Address

    • Building Block Name = All End User Locations

    • Process Point = PSR, EUL Maintenance

    • Action Type = Create, Update

  4. Navigate to the SampleAddressValidation.xml file in the MSLV_Home/server/appserver/samples/customExtension/xml directory.

    The SampleAddressValidation.xml file is read by the custom extension when it is triggered, and therefore you must modify the file and format the return data as required by the calling method. See "Sample Address Validation Return Data Format" for more information.

  5. Trigger the execution point by doing one of the following:

    • Create or update end user location address information in the PSR Ordering Dialog

    • Create or update service locations on a PSR order

    • Create or update end user location address information on the PRILOC/SECLOC Info tab of the Product Service Request window

    • Create or update end user location address information in the End User Location Maintenance window

  6. Verify the outcome by looking in the UI, and by looking in the appserverlog.xml file located in the MSLV_Home/server/appserver/logs directory.

Sample Address Validation Return Data Format

The following are examples of the return data format in the SampleAddressValiation.xml file for custom extension success, failure, and warning scenarios:

Success Scenario Sample Data

<SAMPLEDATA> 
   <RETURNCODE>SUCCESS</RETURNCODE>
   <RETURNTEXT>This is a success message.</RETURNTEXT> 
   <ADDRESS></ADDRESS>
   <ADDRESSID></ADDRESSID>
</SAMPLEDATA>

Failure Scenario Sample Data

<SAMPLEDATA> 
   <RETURNCODE>FAILURE</RETURNCODE>
   <RETURNTEXT>This is a failure message.</RETURNTEXT> 
   <ADDRESS></ADDRESS>
   <ADDRESSID></ADDRESSID>
</SAMPLEDATA>

Warning Scenario Sample Data 1

<SAMPLEDATA> 
   <RETURNCODE>WARNING</RETURNCODE>
   <RETURNTEXT>This is a warning message.</RETURNTEXT> 
   <ADDRESS>
         <sfname>MSAG</sfname>
         <structureFormatComponents>
                <id>33</id>
                <name>Street Name</name>
                <componentType>N</componentType>
                <value>Demo Street</value>
         </structureFormatComponents>
   </ADDRESS>
   <ADDRESSID></ADDRESSID>
</SAMPLEDATA>

In sample data 1 for the warning scenario, if you leave the <ADDRESSID> tag blank, the values within the <ADDRESS> tag are considered by the custom extension.

Warning Scenario Sample Data 2

<SAMPLEDATA> 
   <RETURNCODE>WARNING</RETURNCODE>
   <RETURNTEXT>This is a warning message.</RETURNTEXT> 
   <ADDRESS>
         <sfname>MSAG</sfname>
         <structureFormatComponents>
                <id>33</id>
                <name>Street Name</name>
                <componentType>N</componentType>
                <value>Demo Street</value>
         </structureFormatComponents>
   </ADDRESS>
   <ADDRESSID>153</ADDRESSID>
</SAMPLEDATA>

In sample data 2 for the warning scenario, if you specify a value within the <ADDRESSID> tag, the values within the <ADDRESS> tag are ignored by the custom extension.