Supported Execution Points

Building Block	Execution Point
Task	Assign Queues Assign Task Jeopardy Change Task Completion Date Complete Task Generate Tasks Late Task Potentially Late Task Provisioning Plan Default Reject Task System Task Failure
Gateway Event	Gateway Event Failure
Connection	Email CLR/DLR/TCO Select Port Address Select Component or Element for Physical Connection Select Component or Element for Virtual Connection DS0/DS1 Automated Design Connection Id Automation Select Dedicated Plant
Network System	Select Network System Select Customer Edge Component Select End Component For Physical Connection Select Equipment For CE
Address	Create Update

Assign Queues

MetaSolv Solution provides the ability to assign a provisioning plan to an order. A provisioning plan defines tasks, and assigns work queues to the tasks within the provisioning plan. This execution point enables you to extend logic in the way the work queues are assigned to tasks within a provisioning plan when tasks are generated for an order.

Business Example

You built provisioning plans and assigned default work queues to the tasks in every plan. However, for a specific task type, you would like to do the following:

Assign it to the ABC queue at certain hours of the day, depending on the workload.
Assign it to the XYZ queue at certain hours of the day, depending on the workload.
Send an email notification to the owner of each work queue when a task is assigned to them.

You can use the Assign Queues execution point to extend logic to accomplish those tasks.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-2 when searching for an execution point to associate with the extension:

Table A-2 Assign Queues Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Assign Queues (43)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-3 shows the data that is passed to the extension Java class.

Table A-3 Assign Queues Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task type Array	taskType
Task number Array	taskId

Table A-4 shows the data that is returned by the extension Java class.

Table A-4 Assign Queues Name/Value Pair Return Data

Data Description	Data Name
Work queue ID Array	workQueueId

The work queue ID Array is returned in the same order as the input Arrays of task types and corresponding task numbers.

UI Invocation

After you assign a provisioning plan to an order, you click the Queues button to assign the tasks to the appropriate work queues. The execution point is triggered when you click the Queues button on the Task List tab of the Tasks window.

When you click the Queues button, the task list is sent to the extension. The data received back populates the Work Queue field for each task. This logic overrides the default work queues that were assigned to the provisioning plan when it was established. However, you can still select a different work queue for any or all tasks, should you need to do so after the extension logic executes.

WebService API Invocation

The WebService API method through which the Java class extension is invoked is:

OrderManagement - > assignProvisionPlanProcedureRequest

CORBA API Invocation

The CORBA API method through which the Java class extension is invoked is:

WorkManagement -> generateAndSaveTasks

Assign Task Jeopardy

MetaSolv Solution provides the ability to add, change, and delete jeopardy information for tasks. This execution point enables you to extend logic that executes when jeopardy information on a task changes (in the form of add, change, or delete).

Business Example

You assigned a provisioning plan and, from your Work Queue, set up a jeopardy code on a task. The task ends up going into jeopardy. When the jeopardy status changes, the extension logic executes and sends an email notification to the appropriate person regarding the task jeopardy status.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-5 when searching for an execution point to associate with the extension.

Table A-5 Assign Task Jeopardy Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Assign Jeopardy (41)

Data Passed

This is a recommended asynchronous call, therefore no data should be returned from the extension Java class.

Table A-6 shows the data passed to the extension Java class.

Table A-6 Assign Task Jeopardy Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task type	taskType
Task number	taskId
Work Queue ID	workQueueId

UI Invocation

From the Work Queue window, select a task, right-click, and select Jeopardy Status. This opens the Task Jeopardy Codes window where jeopardy codes can be added, changed, or deleted. Click OK or the Apply button to trigger the Assign Task Jeopardy execution point.

WebService API Invocation

The WebService API method through which the Java class extension is invoked is:

OrderManagement > addTaskJeopardyRequest

CORBA API Invocation

The CORBA API methods through which the Java class extension is invoked are:

Work Management > addTaskJeopardy
Work Management > deleteTaskJeopardy
Work Management > updateTaskJeopardy

Change Task Completion Date

MetaSolv Solution provides the ability to change a task due date. This execution point enables you to extend logic that executes when a task due date is changed.

Business Example

You entered an order, assigned a provisioning plan, and then supplemented the order to change the due date. The extension logic executes and sends an email notification to the appropriate person regarding the task due date change.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-7 when searching for an execution point to associate with the extension.

Table A-7 Change Task Completion Date Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Change Completion Date (44)

Data Passed

This is a recommended asynchronous call, therefore no data should be returned from the extension Java class.

Table A-8 shows the data passed to the extension Java class.

Table A-8 Change Task Completion Date Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task Type	taskType
Task number	taskId
Work Queue ID	workQueueId
New revised completion date	newRevisedCompletionDate

UI Invocation

From the Work Queue window, select a task, right-click, and select Service Request Tasks. This opens the Task List tab of the Tasks window, where task due dates can be changed. Click OK or the Apply button to trigger the Change Task Completion Date execution point, which only executes if any task due dates were actually changed.

Additionally, you can supplement an order to bring up the Tasks window where task due dates can be changed.

WebService API Invocation

The WebService API method through which the Java class extension is invoked is:

Order Management > processSuppOrder

CORBA API Invocation

The Change Task Completion Date execution point is not triggered by the CORBA API.

Complete Task

MetaSolv Solution provides the ability to complete a task assigned to an order. This execution point enables you to extend logic that executes when a task completes, either manually from the UI or automatically from the System Task Server.

Business Example

You entered a PSR order and assigned a provisioning plan comprised of three tasks. The second task is defined as an execution point and associated to an extension. When the task completes, the extension logic executes and sends an email notification to the appropriate person regarding the task completion.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shows in Table A-9 when searching for an execution point to associate with the extension.

Table A-9 Complete Task Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Task Types (1001) or [specific task type] (dynamic)
Process Point	Task Maintenance (101)
Action Type	Complete (53)

Data Passed

This is required to be a synchronous call because existing logic must know if the extension logic executed successfully before continuing. While no task related data needs to be returned from the extension Java class, it must indicate success or failure.

Table A-10 shows the data passed to the extension Java class.

Table A-10 Complete Task Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task number	taskId

UI Invocation

From the Work Queue window within Work Management, select a task, right-click and select Complete. The extension logic executes after the task completion logic runs successfully, but before the commit. If the task completion logic fails, the extension logic does not execute. If the extension logic fails, the task does not complete and a rollback occurs.

WebService API Invocation

The WebService API method through which the Java class extension is invoked is:

Order Management > updateOrderManagementRequest

The updateOrderManagementRequest method defines a choice of input structures. To complete a task, use the input structure CompleteTaskProcedureValue.

CORBA API Invocation

The CORBA API methods through which the Java class extension is invoked are:

Work Management > completeTask
Work Management > completeTaskOnDate

Additional Invocations

This execution point can also be triggered by the System Task Server for cases where the task is defined as a System Task.

For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Generate Tasks

MetaSolv Solution provides the ability to generate tasks for an order. This execution point enables you to extend logic that executes after tasks are generated. Order management also provides the ability to split a PSR order, a process that also generates tasks for the new order created as a result of the split. This execution point also enables you to extend logic that executes after tasks are generated as a result of a split.

Business Example

You entered a PSR order and assigned a provisioning plan. Two of the service items on the order are delayed, and you split the order so the remaining items can be completed. When the order is split, tasks are generated for the new order that is created as a result of the split. The extension logic executes and sends an email notification to the appropriate person regarding the tasks being generated due to the split. Both the original order and the split order information is made available to the extension.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-11 when searching for an execution point to associate with the extension.

Table A-11 Generate Tasks Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Task Types (1001)
Process Point	Task Generation (1)
Action Type	Generate (32)

Data Passed

This is a recommended asynchronous call, therefore no data should be returned from the extension Java class.

Table A-12 shows the data passed to the extension Java class.

Table A-12 Generate Tasks Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Split document number	splitDocumentNumber

The document is always passed to the extension Java class, but the split document number may or may not be passed, depending on what triggered the task generation. If a split order triggered the task generation, then the split document number, in addition to the document number, is passed to the extension Java class.

UI Invocation

From the Product Service Request window within Order Management, select Options from the menu bar, and then select Task Generation Maintenance. This opens the Plan Selection tab of the Tasks window. Select a provisioning plan from the list. Click the Task List tab, and select work queues for each task. Click OK or the Apply button to trigger the Generate Tasks execution point, which happens immediately following the creation of the tasks for the order.

WebService API Invocation

The Generate Tasks execution point is not triggered by the WebService API.

CORBA API Invocation

The Generate Tasks execution point is not triggered by the CORBA API.

Late Task

MetaSolv Solution considers a task late when the current GMT date is greater than the revised completion date on the task. This execution point enables you to extend logic that executes when a task becomes late.

This execution point is triggered only once when the task is determined to be late. It may be triggered again if the revised completion date is updated on the task. There are new fields on the Task table that indicate if an extension has been invoked.

At the point you define this extension, there could be a large number of late tasks already existing in the database. Invoking this extension for each of these tasks can affect system performance. You can manage the system load by modifying the setup values in the integration.xml file. The maxThreads should always be set to 1. However, the queueMaxCapacity can be lowered and the dbPollingInterval increased to allow breaks in the system processing so the late task extensions can be invoked. The following excerpt from the integeration.xml file illustrates this concept:

<LateTaskExtensionEvent event_name="LateTaskExtensionEvent">
<maxThreads>1</maxThreads>
<queueMaxCapacity>100</queueMaxCapacity>
<dbPollingInterval>5</dbPollingInterval> 
</LateTaskExtensionEvent>

Business Example

You entered an order and assigned a provisioning plan. One of the tasks becomes late. The extension logic executes and sends an email notification to the appropriate person regarding the late task.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-13 when searching for an execution point to associate with the extension.

Table A-13 Late Task Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Late (46)

Data Passed

This is required to be a synchronous call because existing logic must know if the extension logic executed successfully before continuing. While no task related data needs to be returned from the extension Java class, it must indicate success or failure.

Table A-14 the data passed to the extension Java class.

Table A-14 Late Task Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task number or identifier	taskId
Task type	taskType
Work queue identifier	workQueueId
Organization for employee	organizationName
Employee name	employeeName
Error text for failure	errorText

UI Invocation

The Late Task execution point is not triggered by the UI.

WebService API Invocation

The Late Task execution point is not triggered by the WebService API.

CORBA API Invocation

The Late Task execution point is not triggered by the CORBA API.

Additional Invocations

This execution point is triggered by the Integration Server.

For this to occur, the Integration Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Potentially Late Task

MetaSolv Solution provides the ability to define the potentially late window of time for each task type. MetaSolv Solution considers a task potentially late when the revised completion date on the task, minus the time defined as the potentially late window, is less than the current GMT date. This comparison takes into account the calendar that is set up by the organization. The calendar relationship is determined from the task's work queue, which is then associated with an employee, and each employee is associated with organization. For an organization, the calendar may reflect non-work days, which would be considered in determining if a task was potentially late.

This execution point enables you to extend logic that executes when a task becomes potentially late. Note the following regarding the Potentially Late Task execution point:

This execution point is triggered only once when the task is determined to be potentially late. It may be triggered again if the revised completion date is updated on the task. There are new fields on the Task table that indicate if an extension has been invoked.
If the potentially late server event is disabled during the window of time for a potentially late task, and the task passes from a potentially late task to a late task, the Potentially Late Task execution point trigger does not execute. When the server event is enabled, and the task is now late, then the Late Task execution point is triggered.

Business Example

You entered an order and assigned a provisioning plan with a task that defines a potentially late window. The task becomes potentially late. The extension logic executes and sends an email notification to the appropriate person regarding the potentially late task.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-15 when searching for an execution point to associate with the extension.

Table A-15 Potentially Late Task Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Potentially Late (47)

Data Passed

This is required to be a synchronous call because existing logic must know if the extension logic executed successfully before continuing. While no task related data needs to be returned from the extension Java class, it must indicate success or failure.

Table A-16 shows the data passed to the extension Java class.

Table A-16 Potentially Late Task Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task number or identifier	taskId
Task type	taskType
Work queue identifier	workQueueId
Organization for employee	organizationName
Employee name	employeeName
Error text for failure	errorText

UI Invocation

The Potentially Late Task execution point is not triggered by the UI.

WebService API Invocation

The Potentially Late Task execution point is not triggered by the WebService API.

CORBA API Invocation

The Potentially Late Task execution point is not triggered by the CORBA API.

Additional Invocations

This execution point is triggered by the Integration Server.

For this to occur, the Integration Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Provisioning Plan Default

MetaSolv Solution provides the ability to assign a provisioning plan to an order. This execution point enables you to extend logic to default the appropriate provisioning plan to an order, rather than having to specify a particular provisioning plan.

Business Example

You built provisioning plans and assigned default work queues to the tasks in every plan. An extension could be added for defaulting a provisioning plan, allowing you to put logic around the default. For example, you can reduce the number of errors that are made in assigning a provisioning plan to an order by basing the assignment on specific data. Additionally, when the extension logic executes, you can send an email notification to the appropriate person regarding the defaulted provisioning plan.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-17 when searching for an execution point to associate with the extension.

Table A-17 Provision Plan Default Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Task Types (1001)
Process Point	Task Generation (1)
Action Type	Provision Plan Default (52)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-18 shows the data passed to the extension Java class.

Table A-18 Provisioning Plan Default Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Organization	organization
Jurisdiction	jurisdiction
Service type group	serviceTypeGroup
Order status	status

Table A-19 shows the data returned by the extension Java class.

Table A-19 Provisioning Plan Default Name/Value Pair Return Data

Data Description	Data Name
Provision plan ID	provisionPlanId

UI Invocation

From a Service Request window (ISR, PSR, etc.) within Order Management, select Options from the menu bar, and then select Task Generation Maintenance. This opens the Plan Selection tab of the Tasks window. The Provisioning Plan Default execution point is triggered just prior to the Tasks window being displayed. If custom logic is executed, and a valid provisioning plan is returned from the extension, that plan is automatically populated in the drop-down list and the display proceeds to the Task Gantt tab. The user may return to the Plan Selection tab to change the selected plan.

WebService API Invocation

The Provisioning Plan Default execution point is not triggered by the WebService API.

CORBA API Invocation

The Provisioning Plan Default execution point is not triggered by the CORBA API.

Reject Task

MetaSolv Solution provides the ability to reject a task. This execution point enables you to extend logic that executes when a specified task is rejected.

Business Example

You assigned a provisioning plan and, from your Work Queue, reject a task. The extension logic executes and sends an email notification to the appropriate person regarding the rejected task.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-20 when searching for an execution point to associate with the extension.

Table A-20 Reject Task Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	Reject (42)

Data Passed

This is a recommended asynchronous call, therefore no data should be returned from the extension Java class.

Table A-21 shows the data passed to the extension Java class.

Table A-21 Reject Task Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task type	taskType
Task number	taskId
Work Queue ID	workQueueId
Previous task status	priorTaskStatus
Reject reason	note

UI Invocation

From the Work Queue window, select a task, right-click, and select Reject Task. This opens the Reject Task window where you select, from a list of predecessor tasks, the task to be set back to Ready status. All tasks between the initial selection and this second selection (tasks in that provisioning plan for that order) are set back to Pending status. Click OK to trigger the Reject Task execution point. A list of affected tasks is sent to the extension.

WebService API Invocation

The Reject Task execution point is not triggered by the WebService API.

CORBA API Invocation

The CORBA API method through which the Java class extension is invoked is:

Work Management > rejectTask

System Task Failure

MetaSolv Solution provides the ability to define a task as a system task. This indicates that the task's completion logic automatically runs on the System Task Server when the task becomes Ready or when the task start date is reached. However, the system task's completion logic may fail. When a system task cannot be completed, the System Task Server rolls back the transaction, transfers the task to the Exception queue, and logs information to the Server Log table. The server log entries associated with a task can be viewed from the work queue by selecting the task, and then clicking the Server Log tab. Tasks are not completed if a gateway event is in error or if a why-missed code cannot be defaulted.

This execution point enables you to extend logic that executes when a system task fails to complete. This execution point is asynchronous so that the continuation of the System Task Server process is not jeopardized.

Business Example

You entered an order and assigned a provisioning plan with a system task. The task becomes Ready, the System Task Server picks up the task and attempts to complete it, but fails. The extension logic executes and sends an email notification to the appropriate person regarding the failed system task.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-22 when searching for an execution point to associate with the extension.

Table A-22 System Task Failure Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Task Types (1001)
Process Point	Task Maintenance (101)
Action Type	System Task Failure (45)

Data Passed

This is a recommended asynchronous call, therefore no data should be returned from the extension Java class.

Table A-23 shows the data passed to the extension Java class.

Table A-23 System Task Failure Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Task number or identifier	taskId
Task type	taskType
Work queue identifier	workQueueId
Error text for failure	errorText or note

UI Invocation

The System Task Failure execution point is not triggered by the UI.

WebService API Invocation

The System Task Failure execution point is not triggered by the WebService API.

CORBA API Invocation

The System Task Failure execution point is not triggered by the CORBA API.

Additional Invocations

This execution point is triggered by the System Task Server.

For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.
This execution point is triggered by the Background Processor.

For this to occur, the Background Processor must be running. See "Invoking an Extension" for specific information on how to run the Background Processor.

Gateway Event Failure

MetaSolv Solution provides the ability to change the status of a gateway event to Error. This execution point enables you to extend logic that executes after the gateway event status change has completed. This execution point is asynchronous so the continuation of the Gateway Event Server process is not jeopardized.

Business Example

You entered an order and assigned a provisioning plan with a task that has an auto-complete gateway event associated with it. When the task becomes Ready, the gateway event automatically fires, but fails. The gateway event status is set to Error, and the extension logic executes and sends an email notification to the appropriate person regarding the failed gateway event.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-24 when searching for an execution point to associate with the extension.

Table A-24 Gateway Event Failure Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Gateway Events (1002)
Process Point	GW Event Maintenance (102)
Action Type	GW Event Failed (51)

Data Passed

This is required to be an asynchronous call. Data cannot be returned from the extension Java class.

The data passed to the Gateway Event Failure extension depends on the gateway event type. There are four types of gateway events listed below. Table A-25 shows all the data inputs, but these vary based on gateway event type.

Service Request or Order Type
Service Item or Item Level Type
Equipment Type
Design Type

Table A-25 shows the data passed to the extension Java class.

Table A-25 Gateway Event Failure Data Value Input by Event Type

data value	Order Type	Item Level Type	Equipment Type	Design Type
documentNumber	yes	yes	no	no
taskId	yes	yes	no	no
taskType	yes	yes	no	no
gatewayName	yes	yes	yes	yes
gatewayEventType	yes	yes	yes	yes
gatewayEventId	yes	yes	yes	yes
gatewayEventName	yes	yes	yes	yes
gatewayEventVersion	yes	yes	yes	yes
serviceItemId	yes	yes	no	no
errorText	yes, if exists	yes, if exists	yes, if exists	yes, if exists

UI Invocation

The Gateway Event Failure execution point is not triggered by the UI.

WebService API Invocation

The WebService API method through which the Java class extension is invoked is:

Order Management > updateOrderManagementRequest

Note:

The updateOrderManagementRequest method defines several choices of input structures. The invocation is applicable only when the input structure chosen is TaskGWEventValue.

CORBA API Invocation

The CORBA API method through which the Java class extension is invoked is:

Work Management > updateGWEvent

Additional Invocations

This execution point is triggered by the Gateway Event Server.

For this to occur, the Gateway Event Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.
This execution point is triggered by the Integration Server.

For this to occur, the Integration Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Email CLR/DLR/TCO

MetaSolv Solution provides the ability to perform a process from the connection print window. This execution point enables you to extend logic that activates upon clicking of the OK button on the print window after closing the email recipient's window. To open the email recipient's window, in the Preference window, set the Enable HTML Email option to true and select the Email option in the Print window. The Enable HTML Email preference is located under Preferences > Inventory Management > Connection Design.

You can modify the sample code to fit the email protocol used at a customer site. The sample extension uses the ByteArrayDataSource method in the mailapi.jar file. The sample email extension exists in the SendEmailAttachment folder.

If required, download the mailapi.jar file from the Oracle Web site. After downloading, you can include the JAR in the CLASSPATH of the appserver environment.

Business Example

You can use this custom extension in several ways. One possible use of this extension is to retrieve the saved HTML files from the database and email the files to the appropriate recipients. Other possibilities include displaying the HTML files on an Intranet or providing access to the HTML files from other applications. The HTML attachment exists as a CLOB in the Email_Job_Attachment table.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-26 while searching for an execution point to associate with the extension.

Table A-26 Email CLR/DLR/TCO Execution Point

Field Name	Option
Execution Mode	Asynchronous
Building Block	All Connections (409)
Process Point	Print (140)
Action Type	Email(56)

Data Passed

As this is an asynchronous call, therefore extension Java class does not return data.

Table A-27 shows the data passed to the extension Java class.

Table A-27 Email CLRD/DLR/TCO Name/Value Pair Input Data

Data Description	Data Name
JobId	jobid

UI Invocation

From the Connection print window, select the Email check box and click OK. The execution occurs on the Print window but the logic waits until the user clicks OK on the Recipient window and the Recipient window closes. If the user clicks Cancel on the Recipients window, the extension does not execute.

WebService API Invocation

The Email CLR/DLR/TCO execution point is not triggered by the WebService API.

CORBA API Invocation

The Email CLR/DLR/TCO execution point is not triggered by the CORBA API.

Additional invocations

This execution point is not triggered anywhere else.

Select Port Address

MetaSolv Solution provides the ability to automatically design physical connections through the PCONDES task. This execution point enables you to extend logic that is triggered when the PCONDES task is executed, either manually from the UI or automatically from the System Task Server. The extension logic enables you to select the appropriate port address to use in the physical design of the connection. It executes prior to the existing PCONDES auto-provisioning logic. If a port address is successfully selected by the extension logic, the existing PCONDES auto-provisioning logic is bypassed. If a port address is not selected by the extension logic, the existing PCONDES auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the PCONDES task as a system task. The PCONDES task is used to automatically design physical connections. When the status of the PCONDES task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate port address is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-28 when searching for an execution point to associate with the extension.

Table A-28 Select Port Address Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	PCONDES Maintenance(103)
Action Type	Select Port Address Element(55)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-29 shows the data that is passed to the extension Java class.

Table A-29 Select Port Address Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Circuit design ID	circuitDesignId
Service item ID	servItemId
End user location ID	endUserLocationId
Rate code	rateCode
Network system component ID	nsCompId
Network system ID	nsId
Network system component key Array	nsCompKey (String Array comprised of nsCompId and nsId)

Pass nsCompId and nsId, or pass an Array of nsCompKeys; do not pass both sets of data. If the input data is comprised of the Array of nsCompKeys, custom logic can be written to select which component id is used. Having this option of input data allows for you to customize your extension code to account for things like load balancing between different elements. For example, if there are three valid elements from which to choose, custom code can select the element which has the most or least capacity available, depending on your specific business requirements.

Table A-30 shows the data that is returned by the extension Java class.

Table A-30 Select Port Address Name/Value Pair Return Data

Data Description	Data Name
Equipment ID	equipmentId
Port Address Sequence	portAddrSeq

UI Invocation

From the Work Queue window within Work Management, select a PCONDES task, right-click and select Auto Provision. The extension logic executes prior to the existing PCONDES auto provision logic. If a port address is successfully selected by the extension logic, the existing PCONDES auto provision logic is bypassed. However, if a port address is not selected by the extension logic, the existing PCONDES auto provision logic still executes.

WebService API Invocation

The Select Port Address execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Port Address execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the PCONDES task is defined as a System Task.

For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Component or Element for Physical Connection

MetaSolv Solution provides the ability to automatically design physical connections through the PCONDES task. This execution point enables you to extend logic that is triggered when the PCONDES task is executed, either manually from the UI or automatically from the System Task Server. The extension logic enables you to select the appropriate component or element to use in the physical design of the connection. It executes prior to the existing PCONDES auto-provisioning logic. If a component or element is successfully selected by the extension logic, the existing PCONDES auto-provisioning logic is bypassed. If a component or element is not selected by the extension logic, the existing PCONDES auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the PCONDES task as a system task. The PCONDES task is used to automatically design physical connections. When the status of the PCONDES task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate component or element is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-31 when searching for an execution point to associate with the extension.

Table A-31 Select Component or Element for Physical Connection Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	PCONDES Maintenance(103)
Action Type	Select Component or Element(54)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-32 shows the data that is passed to the extension Java class.

Table A-32 Select Component or Element for Physical Connection Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Circuit design ID	circuitDesignId
Service item ID	servItemId
End user location ID	endUserLocationId

Table A-33 shows the data that is returned by the extension Java class.

Table A-33 Select Component or Element for Physical Connection Name/Value Pair Return Data

Data Description	Data Name
Network system component key Array	nsCompKey (String Array comprised of nsCompId and nsId)

UI Invocation

From the Work Queue window within Work Management, select a PCONDES task, right-click and select Auto Provision. The extension logic executes prior to the existing PCONDES auto provision logic. If a component or element is successfully selected by the extension logic, the existing PCONDES auto provision logic is bypassed. However, if a component or element is not selected by the extension logic, the existing PCONDES auto provision logic still executes.

WebService API Invocation

The Select Component or Element for Physical Connection execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Component or Element for Physical Connection execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the PCONDES task is defined as a System Task.

For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Component or Element for Virtual Connection

MetaSolv Solution provides the ability to automatically design virtual connections through the VCONDES task. This execution point enables you to extend logic that is triggered when the VCONDES task is executed, either manually from the UI or automatically from the System Task Server. The extension logic enables you to select the appropriate component or element to use in the virtual design of the connection. It executes prior to the existing VCONDES auto-provisioning logic. If a component or element is successfully selected by the extension logic, the existing VCONDES auto-provisioning logic is bypassed. If a component or element is not selected by the extension logic, the existing VCONDES auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the VCONDES task as a system task. The VCONDES task is used to automatically design virtual connections. When the status of the VCONDES task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate component or element is selected for the design of the virtual connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-34 when searching for an execution point to associate with the extension.

Table A-34 Select Component or Element for Virtual Connection Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	VCONDES Maintenance (105)
Action Type	Select Component or Element (54)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-35 shows the data that is passed to the extension Java class.

Table A-35 Select Component or Element for Virtual Connection Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Circuit design ID	circuitDesignId
Service item ID	servItemId
Connection Spec	nstCompTypeConId
Network Configuration Type	nstConfigTypeId
Component Type	networkComponentType

Table A-36 shows the data that is returned by the extension Java class.

Table A-36 Select Component or Element for Virtual Connection Name/Value Pair Return Data

Data Description

Data Name

Network system component key Array

nsCompKey

(String Array comprised of nsCompId and nsId)

Returned data validation

The data returned by the VCONDES Maintenance - Select Component custom extension must adhere to certain rules. All components (NS_ID/NS_COMP_ID combination) must pass the following validation logic:

The NS_COMP_ID must exist in the database.
The component type of the returned NS_COMP_ID must match the networkComponentType input parameter.
The NS_ID must exist in the database.
The network configuration type of the returned NS_ID must match the nstConfigTypeId input parameter.

UI Invocation

From the Work Queue window within Work Management, open the Service Request Virtual Connections window by double-clicking a VCONDES task and then select Auto Provision from the Options menu. The extension logic executes prior to the existing VCONDES auto provision logic. If a component or element is successfully selected by the extension logic, the existing VCONDES auto provision logic is bypassed. However, if a component or element is not selected by the extension logic, the existing VCONDES auto provision logic still executes.

WebService API Invocation

The Select Component or Element for Virtual Connection execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Component or Element for Virtual Connection execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the VCONDES task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Network System

MetaSolv Solution provides the ability to automatically design physical connections through the NETDESIGN task. This execution point enables you to extend logic that is triggered when the NETDESIGN task is executed automatically from the System Task Server. The extension logic enables you to select the appropriate network system to use in the physical design of the connection. It executes prior to the NETDESIGN task. If a network system is successfully selected by the extension logic, the existing NETDESIGN auto-provisioning logic is bypassed. If a network system is not selected by the extension logic, the existing NETDESIGN auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the NETDESIGN task as a system task. The NETDESIGN task is used to automatically design physical connections. When the status of the NETDESIGN task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate network system is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-37 when searching for an execution point to associate with the extension.

Table A-37 Select Network System Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Network Systems (410)
Process Point	Network System Design (107)
Action Type	Select Network System (60)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-38 shows the data that is passed to the extension Java class.

Table A-38 Select Network System Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber

Table A-39 shows the data that is returned by the extension Java class.

Table A-39 Select Network System Name/Value Pair Return Data

Data Description	Data Name
Activity code	activityCd
ArrayList of CaContainer objects, which contains CA names and values	CaList
Short name of network system	nsNmShort
Long name of network system	nsNmLong
Description	desc100
Network system ID	nsId
Hard/soft code	hardSoftCdExtension
Network system customer system ID	nsCustomerSysId
Network system provider system ID	nsProviderSysId
template name	templateName

Returned data validation

The data returned by the NETDESIGN Maintenance - Select Network System custom extension must adhere to certain rules. Network System details returned by the extension must pass the following validation logic:

SHORT_NAME is mandatory, and the length of the value should be less than 20 characters.
ACTIVITY_IND must be either "N" (new) or "C"(change).
NS_ID must exist in the database.
STATUS must be "Pending" or "Inservice"
HARD_SOFT_ASSIGN_CD must be "soft" or "hard" or "none".
NS_TEMPLATE_NAME is mandatory and must exist in the database.
DESC_100 must be less than 100 characters.
LONG_NAME must be less than 50 characters.
CUSTOMER_SYS_ID and PROVIDER_SYS_ID accepts a maximum of 20 characters.
Customer attribute (CA) Name must exist in the database.

UI Invocation

UI invocation of the Select Network System execution point is not available. While the NETDESIGN task can be defined as a manual task and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The Select Network System execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Network System execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the NETDESIGN task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Customer Edge Component

MetaSolv Solution provides the ability to automatically design physical connections through the NETDESIGN task. This execution point enables you to extend logic that is triggered when the NETDESIGN task is executed automatically from the System Task Server. The extension logic enables you to select the customer edge component to use in the physical design of the connection. It executes prior to the existing NETDESIGN auto-provisioning logic. If a customer edge component is successfully selected by the extension logic, the existing NETDESIGN auto-provisioning logic is bypassed. If a customer edge component is not selected by the extension logic, the existing NETDESIGN auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the NETDESIGN task as a system task. The NETDESIGN task is used to automatically design physical connections. When the status of the NETDESIGN task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate customer edge component is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-40 when searching for an execution point to associate with the extension.

Table A-40 Select Customer Edge Component Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Network Systems (410)
Process Point	Network System Design (107)
Action Type	Select Customer Edge Component (61)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-41 shows the data that is passed to the extension Java class.

Table A-41 Select Customer Edge Component Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber

Table A-42 shows the data that is returned by the extension Java class.

Table A-42 Select Customer Edge Component Name/Value Pair Return Data

Data Description	Data Name
Activity code	activityCd
ArrayList of CaContainer objects, which define CA names and values	CaList
Customer Edge name	nsCompName
Customer edge location name	locationName
Customer edge type	nsCompType
Network component ID	nsCompIdThruExtension
Customer edge number, which is used along with nsCompName to uniquely differentiate each customer edge	ceNumberThruExt
Network system component network element ID	nsCompNetworkElementId

Returned data validation

The data returned by the NETDESIGN Maintenance - Select Customer Edge Component custom extension must adhere to certain rules. All components must pass the following validation logic:

ACTIVITY_IND must be either "N" (new) or "C" (change).
CE_NAME is mandatory must be unique.
CE_LOCATION_NAME must exist in the database.
CE_TYPE must exist in the database.
Customer attribute (CA) Name must exist in the database.
COMP_ID must exist in the database.

UI Invocation

UI invocation of the Select Customer Edge Component execution point is not available. While the NETDESIGN task can be defined as a manual task and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The Select Customer Edge Component execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Customer Edge Component execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the NETDESIGN task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select End Component For Physical Connection

MetaSolv Solution provides the ability to automatically design physical connections through the NETDESIGN task. This execution point enables you to extend logic that is triggered when the NETDESIGN task is executed automatically from the System Task Server. The extension logic enables you to select an end component for the physical connection to use in the physical design of the connection. It executes prior to the existing NETDESIGN auto-provisioning logic. If an end component for the physical connection is successfully selected by the extension logic, the existing NETDESIGN auto-provisioning logic is bypassed. If an end component for the physical connection is not selected by the extension logic, the existing NETDESIGN auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the NETDESIGN task as a system task. The NETDESIGN task is used to automatically design physical connections. When the status of the NETDESIGN task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate end component for the physical connection is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-43 when searching for an execution point to associate with the extension.

Table A-43 Select End Component For Physical Connection Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Network Systems (410)
Process Point	Network System Design (107)
Action Type	Select End Component For Physical Connection (62)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-44 shows the data that is passed to the extension Java class.

Table A-44 Select End Component For Physical Connection Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber

Table A-45 shows the data that is returned by the extension Java class.

Table A-45 Select End Component For Physical Connection Name/Value Pair Return Data

Data Description	Data Name
String object that contains the connection identifier (ecckt)	HashMap key
End points for connection defines the following details:	HashMap value: EndPointsForConnection Object
Activity indicator	activityInd
One end of the connection	customEdgeName
Other end of the connection	providerEdgeName
Used along with customer edge name to uniquely differentiate CE	customerEdgeNumber
Used along with provider edge name to uniquely differentiate PE	providerEdgeNumber
Network system name in which PE is present	providerEdgeNetwork SystemName
Network system name which needs to be embedded as part of the VPN network	providerEdgeParent NetworkName
Connection identifier / name	conEcckt

Returned data validation

The data returned by the NETDESIGN Maintenance - Select End Component For Physical Connection custom extension must adhere to certain rules. End components of each connection must pass the following validation logic:

ACTIVITY_IND must be "N" or "C".
CE_NAME must be the same as what is returned from the Select Customer Edge Component extension.
PE_NAME must exist in the database.
PE_NETWORK_NAME must exist in the database and component with PE_NAME must be part of this network.
CONNECTION_ECCKT must exist in the database and it must be part of the order given in the input parameter.

UI Invocation

UI invocation of the Select End Component For Physical Connection execution point is not available. While the NETDESIGN task can be defined as a manual task and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The Select End Component For Physical Connection execution point is not triggered by the WebService API.

CORBA API Invocation

The Select End Component For Physical Connection execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the NETDESIGN task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Equipment For CE

MetaSolv Solution provides the ability to automatically design physical connections through the NETDESIGN task. This execution point enables you to extend logic that is triggered when the NETDESIGN task is executed automatically from the System Task Server. The extension logic enables you to select the equipment for the customer edge to use in the physical design of the connection. It executes prior to the existing NETDESIGN auto-provisioning logic. If equipment for the customer edge is successfully selected by the extension logic, the existing NETDESIGN auto-provisioning logic is bypassed. If equipment for the customer edge is not selected by the extension logic, the existing NETDESIGN auto-provisioning logic still executes.

Business Example

You enter a PSR order and assign a provisioning plan that defines the NETDESIGN task as a system task. The NETDESIGN task is used to automatically design physical connections. When the status of the NETDESIGN task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the selection logic in the extension and the information on the order, the appropriate equipment for the customer edge is selected for the design of the physical connection.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-46 when searching for an execution point to associate with the extension.

Table A-46 Select Equipment For CE Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Network Systems (410)
Process Point	Network System Design (107)
Action Type	Select Equipment For CE (63)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-47 shows the data that is passed to the extension Java class.

Table A-47 Select Equipment For CE Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber

Table A-48 shows the data that is returned by the extension Java class.

Table A-48 Select Equipment For CE Name/Value Pair Return Data

Data Description	Data Name
CE name that the equipment needs to be associated with	customerEdgeName
Used along with customer edge name to uniquely differentiate CE	customerEdgeNumber
Equipment ID which must be associated with the CE	equipIdThruExtension

Returned data validation

The data returned by the NETDESIGN Maintenance - Select Equipment For CE custom extension must adhere to certain rules. All components and equipment returned from the extension must pass the following validation logic:

EQUIPMENT_ID must exist in the database.
CUSTOMEREDGE_NAME must exist in the database, and must be same as that of CE returned from the Select Customer Edge Component extension.

UI Invocation

UI invocation of the Select Equipment For CE execution point is not available. While the NETDESIGN task can be defined as a manual task and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The Select Equipment For CE execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Equipment For CE execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the NETDESIGN task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

DS0/DS1 Automated Design

MetaSolv Solution provides the ability to automate the provisioning of Facility circuits with rate codes DS0 and DS1 through the AUTODSGN task. This execution point enables you to extend logic that is triggered when the AUTODSGN task is executed automatically from the System Task Server. The extension logic enables you to provide the assignment information to use in the provisioning of the connection. If the assignment information is not provided in the extension, the default auto-provisioning logic executes. The default auto-provisioning logic makes an equipment port assignment at either end of the circuit and makes a "next-available" channel assignment to a parent circuit, which is coterminous with the circuit being auto-provisioned.

Business Example

You enter a PSR order and assign a provisioning plan that defines the AUTODSGN task as a system task. The AUTODSGN task is used to automatically provision the Facility circuits with rate codes DS0 and DS1.

When the status of the AUTODSGN task becomes Ready, the System Task Server processes the task. The extension logic executes and, based on the assignment information in the extension and the circuit information on the order, the appropriate DS0 and DS1 facility circuits are automatically provisioned. After the assignments are made, the extension logic would also create design issues using the appropriate information from the order. The status of the circuits will be changed to Record Issued.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-49 when searching for an execution point to associate with the extension.

Table A-49 DS0/DS1 Automated Design Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	Connection Design (108)
Action Type	DS0/DS1 Automated Design (70)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-50 shows the data that is passed to the extension Java class.

Table A-50 DS0/DS1 Automated Design Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Circuit Design ID	circuitDesignId

Table A-51 shows the data that is returned by the extension Java class.

Table A-51 DS0/DS1 Automated Design Name/Value Pair Return Data

Data Description	Data Name
A Java container object that holds the assignment information to use in the automated provisioning of the circuit.	provisioningInfoContainer

Returned data validation

The data returned by the DS0/DS1 Automated Design execution point must adhere to certain rules. See "DS0/DS1 Automated Design" for detailed parameter-level validation information.

UI Invocation

UI invocation of the DS0/DS1 Automated Design execution point is not available. While the AUTODSGN task can be defined as a manual task to design the connections and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The DS0/DS1 Automated Design execution point is not triggered by the WebService API.

CORBA API Invocation

The DS0/DS1 Automated Design execution point is not triggered by the CORBA API.

Additional Invocations

This execution point can also be triggered by the System Task Server for cases where the AUTODSGN task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Connection Id Automation

MetaSolv Solution provides the ability to automate the generation of Connection Id for the circuits created in PSR orders through the CKTID task. This execution point enables you to extend logic that is triggered when the CKTID task is executed automatically from the System Task Server. The extension logic enables you to provide the required information to be used in the Connection Id generation.

Business Example

You enter a PSR order and assign a provisioning plan that defines the CKTID task as a system task. The CKTID task is used to automatically generate the Connection Id for the appropriate products on the PSR order. When the status of the CKTID task becomes Ready, the System Task Server processes the task. The extension logic executes and based on the information in the extension and the information on the order, the appropriate Connection Ids are generated automatically.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-52 when searching for an execution point to associate with the extension.

Table A-52 Connection Id Automation Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	Connection Design (108)
Action Type	Connection Id Automation (71)

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-53 shows the data that is passed to the extension Java class.

Table A-53 Connection Id Automation Name/Value Pair Input Data

Data Description	Data Name
Document number	documentNumber
Service Item ID	circuitDesignId

Table A-54 shows the data that is returned by the extension Java class.

Table A-54 Connection Id Automation Name/Value Pair Return Data

Data Description	Data Name
A Java container object that contains information that is used in the automated generation of the connection ID.	ConnectionIdAutomationData

Returned Data Validation

The data returned by the Connection Id Automation execution point must adhere to certain rules. See "Connection Id Automation" for detailed parameter-level validation information.

UI Invocation

UI invocation of the Connection Id Automation execution point is not available. While the CKTID task can be defined as a manual task to design the connections and accessed from the Work Queue window within Work Management, if accessed in this manner, the execution point is not invoked.

WebService API Invocation

The Connection Id Automation execution point is not triggered by the WebService API.

CORBA API Invocation

The Connection Id Automation execution point is not triggered by the CORBA API.

Additional invocations

This execution point can also be triggered by the System Task Server for cases where the CKTID task is defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Select Dedicated Plant

MetaSolv Solution provides the ability to implement your custom logic to determine the appropriate dedicated plant assignment for the service being provisioned through the Automated Design (AUTODSGN) or Physical Connection Design (PCONDES) tasks, in scenarios where the core logic does not meet your business requirements.

For example, consider a scenario where a dedicated plant, DP1, has a priority of 1 and another dedicated plant, DP2, has its priority set as 2 on the Plant Administration tab of the Product Catalog window. If you determine that DP2 is more suitable for the service being provisioned, you can create and implement your custom logic to change the priority of DP2 to 1. As a result, the core logic processes the information returned by the extension and selects DP2 when provisioning the service.

During service provisioning, the core logic first queries for a dedicated plant reservation for the order. If a reserved dedicated plant is found, the reservation is redeemed and the assignment is made. Otherwise, the core logic queries for all the dedicated plants at the service address on the order.

In addition, the core logic filters the following:

Dedicated plants that are already assigned.
Dedicated plants that have blocking condition codes on the cable pair or port address.
Dedicated plants that have non-owned reservations on the cable pair or port address.

The core logic calls the custom extension logic only if multiple dedicated plants (both supported and unsupported) are available.

The custom extension logic can use the Item Spec ID or Spec Name values to determine which dedicated plant must be selected. For items that require manual design, this logic does not provide any output dedicated plant and displays an error message. In this case, the AUTODSGN and PCONDES tasks fail and an error message is logged. You can view this error on the Server Logs tab in the Work Queue Manager window.

After calling the custom extension, the core logic goes through all of the dedicated plants in the same order as they are populated within the OutputDedicatedPlantList parameter. The core logic then validates whether each dedicated plant is valid for the service being provisioned and assigns the service to the supporting dedicated plant based on its priority. If no supporting dedicated plants are returned by the custom extension, the AUTODSGN and PCONDES tasks fail and an error message is logged. You can view this error on the Server Logs tab in the Work Queue Manager window.

Business Example

You enter a PSR order and assign a provisioning plan that defines the AUTODSGN or PCONDES tasks as a system task. When the status of the AUTODSGN or PCONDES tasks becomes Ready, the System Task Server processes the tasks. The extension logic executes and based on the information in the extension and the information on the order, the extension logic validates whether each dedicated plant is valid for the service being provisioned and assigns the service to the supporting dedicated plant based on its priority.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-55 when searching for an execution point to associate with the extension.

Table A-55 Select Dedicated Plant Execution Point

Field Name	Option
Execution Mode	Synchronous
Building Block	All Connections (409)
Process Point	PCONDES Maintenance (103), Connection Design (108)
Action Type	Select Dedicated Plant

Data Passed / Data Returned

This is a recommended synchronous call, therefore data should be returned from the extension Java class.

Table A-56 shows the data that is passed to the extension Java class.

Table A-56 Select Dedicated Plant Name/Value Pair Input Data

Data Description	Data Name
Order being processed.	documentNumber
Circuit design ID of the service being designed.	circuitDesignId
Service item being designed.	ServItemId
List of available dedicated plants. You must set the following attributes for this parameter: 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: Specification ID of the service being designed. item_spec_nm: Specification name of the service being designed. priority_seq: Priority sequence of the equipment set within the Plant Administration tab.	InputDedicatedPlantList
This parameter is not populated.	numberOfBondedPairs

Table A-57 shows the data that is returned by the extension Java class.

Table A-57 Select Dedicated Plant Name/Value Pair Return Data

Data Description

Data Name

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.

OutputDedicatedPlantList

Error message to be sent to the server log.

ErrorMessage

Returned data validation

The data returned by the Select Dedicated Plant execution point must adhere to certain rules. See "DedicatedPlantSelection" for detailed parameter-level validation information.

UI Invocation

UI invocation of the Select Dedicated Plant execution point is not available.

WebService API Invocation

The Select Dedicated Plant execution point is not triggered by the WebService API.

CORBA API Invocation

The Select Dedicated Plant execution point is not triggered by the CORBA API.

Additional Invocations

This execution point can also be triggered by the System Task Server for cases where the AUTODSGN/PCONDES tasks are defined as a System Task. For this to occur, the System Task Server must be configured to run on the appserver. See "Invoking an Extension" for specific configuration information.

Create/Update End User Location

This execution point enables you to implement your custom logic that validates the end user location address information and returns the following return codes that determine the behavior of the application based on the custom logic:

Success: Creates or updates the end user location.
Failure: Does not create or update the end user location.
Warning: Provides you with options that enable you to do one of the following:
- Create or update end user location address information with the data returned by your custom logic
- Create or update end user location address information with the original data you entered in the MSS application

This execution point is triggered 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 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

Custom Extension Success Scenario Example

The following list includes examples of situations when the custom extension logic may return the Success return code based on your custom logic:

No matching address already exists
The address information you enter is correct

When the extension returns the Success return code, the MSS application creates or updates the end user location.

Custom Extension Failure Scenario Example

The following list includes examples of situations when the custom extension logic may return the Failure return code based on your custom logic:

A matching address already exists
The address information you enter is incorrect
No new end user location should be created with the data you enter

When the extension returns the Failure return code, the return text that you specified in your custom logic is displayed, and the MSS application does not create or update the end user location address information.

Custom Extension Warning Scenario Example

The following list includes examples of situations when the custom extension logic may return the Warning return code based on your custom logic:

A partially matching address already exists
The address information you enter is partially correct

When the extension returns the Warning return code, one of the following occurs:

In the End User Location window and on the PRILOC/SECLOC Info tab of the Product Service Request window, the Custom Address Validation window is displayed, which displays those values in red that are different than the values you specified in the input. Do one of the following:
- Click OK to create or update the end user location address information with the data returned by your custom logic
- Click Override to create or update the end user location address information with the original data you entered in the MSS application
At the top of the PSR Ordering Dialog, only those values are displayed in red that are different than the values you specified in the input. Do one of the following:
- Click Next to create or update the end user location address information with the data returned by your custom logic
- Click Override to create or update the end user location address information with the original data you entered in the MSS application
  
  Note:
  
  You can limit user access to the Override option in the Security Permissions window.

Business Example

You enter a PSR order and click Add Service Location to add a new end user location. In the End User Location Maintenance window, enter the required information in the fields and click OK. The execution point is triggered and it returns Success, Failure, or Warning return codes that determine the behavior of the application based on your custom logic. See Table A-61 for more information about the MSS UI windows from where you can trigger the execution point.

Execution Point Definition

When defining the extension in MetaSolv Solution, choose the options shown in Table A-58 when searching for an execution point to associate with the extension.

Table A-58 Create/Update Execution Points

Field Name	Option
Execution Mode	Synchronous
Building Block	All End User Locations
Process Point	EUL Maintenance (123), PSR (124)
Action Type	Update (91), Create (92)

Data Passed / Data Returned

This is a synchronous call, therefore data should be returned from the extension Java class.

Table A-59 shows the data that is passed to the extension Java class.

Table A-59 Create/Update Name/Value Pair Input Data

Data Name	Data Type	Data Description
addressId	String	Unique identifier for an address. This is 0 or null for a new end user location that you want to create.
addressComponents	String	Address components, such as House Number, Street Name, City Name, and so on. Specify this information as String in the following format: <ADDRESS> <sfname></sfname> <structureFormatComponents> <id></id> <name></name> <componentType></componentType> <value></value> </structureFormatComponents> </ADDRESS>
eulName	String	Name of the end user location.
countryId	String	ID of a country.
locationId	String	ID of the location. This is 0 or null for a new end user location that you want to create.
addressFormat	String	Address structure format for the address.

Table A-60 shows the data that is returned by the extension Java class.

Table A-60 Create/Update Name/Value Pair Return Data

Data Name	Data Type	Mandatory/ Optional	Data Description
returnCode	String	Mandatory	Return code that you want the extension logic to return: Success Failure Warning
returnText	String	Mandatory if you specify the returnCode as Failure; otherwise, it is optional.	Text that you want the extension logic to return for the Success, Failure, and Warning return codes.
returnAddrComponents	String	The returnAddrComponents or returnAddrId is mandatory if you specify the returnCode as Warning. The returnAddrComponents is ignored if you specify returnAddrId.	Returns only those address components that are different than the address components you specified in the input. Address components, such as House Number, Street Name, City Name, and so on, that are returned as String by the extension logic in the following format: <ADDRESS> <sfname></sfname> <structureFormatComponents> <id></id> <name></name> <componentType></componentType> <value></value> </structureFormatComponents> </ADDRESS> where: `sfname`: Indicates the address format of the end user location. Refer to the SF_STRUCT_FORMAT_NM column in the SF_COMP table. `id`: Indicates the structure format component ID for an address component in the end user location. Refer to the SF_COMP_ID column in the SF_COMP table. `name`: Indicates the structure format component name for an address component in the end user location. Refer to the COMP_NM column in the SF_COMP table. `componentType`: Indicates the structure format component type for an address component in the end user location. Refer to the COMP_TYPE column in the SF_COMP table. `value`: Indicates the value of the structure format component based on the `componentType`. For example: The Street Name address component of type N has the actual value, for example, ABC Street. The State Code address component of type G has the value ID, for example, 123, which indicates the value ID of the state and not the actual name of the state.
returnAddrId	String	The returnAddrComponents or returnAddrId is mandatory if you specify the returnCode as Warning.	Unique identifier returned for an address.

Returned data validation

The data returned by the Create and Update execution points must adhere to certain rules. See "Create/Update End User Location" for detailed parameter-level validation information.

UI Invocation

Table A-61 lists the MSS UI windows that trigger the execution point when you create or update end user locations.

Table A-61 MSS UI Windows That Trigger the Execution Point

Building Block Type	Building Block Name	Process Point	Action Type	MSS UI Windows
Address (411)	All End User Locations	EUL Maintenance (123)	Create (92)	End User Location Maintenance Window The execution point is triggered when you do the following: When creating a new end user location, in the End User Location Maintenance window, enter the required information in the fields and click OK. See "Creating or Updating an End User Location from the End User Location Maintenance Window" for more information.
Address (411)	All End User Locations	EUL Maintenance (123)	Update (91)	End User Location Maintenance Window The execution point is triggered when you do the following: When updating an end user location, in the End User Location Maintenance window, update the existing information in the fields and click OK. See "Creating or Updating an End User Location from the End User Location Maintenance Window" for more information.
Address (411)	All End User Locations	PSR (124)	Create (92)	End User Location Maintenance Window The execution point is triggered when you do the following: When creating a service location, in the End User Location Maintenance window, enter the required information in the fields and click OK. See "Creating or Updating a Service Location on a PSR order" for more information. PSR Ordering Dialog The execution point is triggered when you do one the following: In the PSR Ordering Dialog, click the add a new customer location link and enter the required information in the fields, and then either click Add Another or click Next. See "Creating or Updating an End User Location from the PSR Ordering Dialog" for more information. PRILOC/SECLOC Assignment Window The execution point is triggered when you do the following: In the PRILOC/SECLOC Assignment window, click the address icon. In the Address Maintenance window, enter the required information in the fields and click OK. See "Creating or Updating an End User Location on the PRILOC/SECLOC Info Tab on a PSR Order" for more information.
Address (411)	All End User Locations	PSR (124)	Update (91)	End User Location Maintenance Window The execution point is triggered when you do the following: When updating a service location, in the End User Location Maintenance window, update the existing information in the fields and click OK. See "Creating or Updating a Service Location on a PSR order" for more information. PSR Ordering Dialog The execution point is triggered when you do one the following: In the PSR Ordering Dialog, click an existing location and update the existing information in the fields and click Next. See "Creating or Updating an End User Location from the PSR Ordering Dialog" for more information. PRILOC/SECLOC Assignment Window The execution point is triggered when you do the following: In the PRILOC/SECLOC Assignment window, click the address icon. In the Address Maintenance window, update the existing information in the fields and click OK. See "Creating or Updating an End User Location on the PRILOC/SECLOC Info Tab on a PSR Order" for more information.

Creating or Updating an End User Location from the End User Location Maintenance Window

To create or update an end user location from the End User Location Maintenance window:

On the navigation bar, select Application Setup, click Location and Geography Setup, and then click End User Locations.

The End User Location Search window is displayed.
Do one of the following:
- To create a new end user location, click Add New.
- To update an existing end user location, specify your search criteria and click Search, and then double-click the end user location.
  
  The End User Location Maintenance window is displayed.
Enter the required information in the fields and click OK.

The execution point is triggered. The end user location address information is sent to the custom logic (extension Java class) and one of the following occurs.
- The extension returns the Success return code. In this case, the end user location is created or updated.
- The extension returns the Failure return code and displays the return text specified in the custom logic. In this case, the end user location is not created or updated.
- The extension returns the Warning return code. In this case, the Custom Address Validation window is displayed, which displays those values in red that are different than the values you specified in the input. Do one of the following:
  - Click OK to create or update the end user location address information with the data returned by your custom logic.
  - Click Override to create or update the end user location address information with the original data you entered in the MSS application.

Creating or Updating a Service Location on a PSR order

To create or update a service location on a PSR order:

Open a PSR order.
Under Order Maintenance, click Services.
Do one of the following:
- To add a new service location, click Add Service Location.
  
  The End User Location Search window is displayed.
  - Click New Location.
- To update an existing service location, right-click a service location and select Update Service Location.
  
  The End User Location Maintenance window is displayed.
Enter the required information in the fields and click OK.

The execution point is triggered. The end user location address information is sent to the custom logic (extension Java class) and one of the following occurs:
- The extension returns the Success return code. In this case, the end user location is created or updated.
- The extension returns the Failure return code and displays the return text specified in the custom logic. In this case, the end user location is not created or updated.
- The extension returns the Warning return code. In this case, the Custom Address Validation window is displayed, which displays those values in red that are different than the values you specified in the input. Do one of the following:
  - Click OK to create or update the end user location address information with the data returned by your custom logic.
  - Click Override to create or update the end user location address information with the original data you entered in the MSS application.

Creating or Updating an End User Location from the PSR Ordering Dialog

To create or update an end user location from the PSR Ordering Dialog:

Open a PSR order.
Under Order Maintenance, click Services.
Select a product from the hierarchy.
Under Service Item Actions, click the Configure Product link.

The PSR Ordering Dialog is displayed.
In the Do you want to include any of these existing locations? window, do one of the following:
- To add a new location, click the add a new customer location link and enter the required information in the fields and do one of the following:
  - Click Add Another
  - Click Next
- To update an existing location, click an existing location and update the fields as required and click Next.
  
  The execution point is triggered.
The end user location address information is sent to the custom logic (extension Java class) and one of the following occurs:
- The extension returns the Success return code. In this case, the end user location is created or updated.
- The extension returns the Failure return code and displays the return text specified in the custom logic. In this case, the end user location is not created or updated.
- The extension returns the Warning return code. In this case, at the top of the PSR Ordering Dialog, only those values are displayed in red that are different than the values you specified in the input. Do one of the following:
  - Click OK to create or update the end user location address information with the data returned by your custom logic.
  - Click Override to create or update the end user location address information with the original data you entered in the MSS application.

Creating or Updating an End User Location on the PRILOC/SECLOC Info Tab on a PSR Order

To create or update an end user location on the PRILOC/SECLOC Info tab on a PSR order:

Open a PSR order.
Under Order Maintenance, click Services.
Expand the circuit product node and select a circuit.
Click the PRILOC/SECLOC Info tab.
Under the PRILOC section, do one of the following:
- To assign a new primary/secondary location, click the Assign link.
- To edit an existing primary/secondary location, click the Edit link.
  
  The PRILOC/SECLOC Assignment window is displayed.
On the PRILOC tab, select the End User option and complete the required fields.
On the SECLOC tab, select the End User option and complete the required fields.
Click the address icon.

The Address Maintenance window is displayed.
Complete the required fields and click OK.

The execution point is triggered. The end user location address information is sent to the custom logic (extension Java class) and one of the following occurs:
- The extension returns the Success return code. In this case, the end user location is created or updated.
- The extension returns the Failure return code and displays the return text specified in the custom logic. In this case, the end user location is not created or updated.
- The extension returns the Warning return code. In this case, the Custom Address Validation window is displayed, which displays those values in red that are different than the values you specified in the input. Do one of the following:
  - Click OK to create or update the end user location address information with the data returned by your custom logic.
  - Click Override to create or update the end user location address information with the original data you entered in the MSS application.

WebService API Invocation

The Create and Update execution points are not triggered by the WebService API.

CORBA API Invocation

The Create and Update execution points are not triggered by the CORBA API.