The preceding chapters described what custom extensions are and how to create them. As mentioned earlier, Oracle Communications MetaSolv Solution predefines the components used to define execution points: the building blocks, process points, and action types. This means there are specific execution points that are available for your use.
In addition to predefining "Component Combinations" associated with each execution point, MetaSolv Solution provides functionality that supports the invocation of a custom extension Java class for each valid combination. This functionality includes:
"Hooks" that are triggered by an execution point. These "hooks" call the extension framework, which determines what extension class to invoke based on which extensions the execution point is associated with.
Parameters for each execution point. The parameters are used to pass data that is pertinent to the execution point to the extension class. This data is then available to the extension class and can be used to code your specific business logic.
The supported execution points are listed in Table A-1. The execution points are grouped by building block, and ordered alphabetically. The number of supported execution points correlates to the number of valid component combinations, and the execution point names correlate to the action type of each valid combination.
Table A-1 Supported Execution Points
| Building Block | Execution Point |
|---|---|
|
Task |
|
|
Gateway Event |
Gateway Event Failure |
|
Connection |
|
|
Network System |
|
|
Address |
|
This appendix provides detailed information for each supported execution point, which includes:
A brief description of the execution point.
A business example of how you might use the execution point.
The options you should choose when searching for the execution point to associate it with an extension.
The data that is sent from the execution point to the extension Java class, and, in the case of a synchronous call, the data that is returned from the extension Java class to the execution point. The data is housed in an Array of name/value pairs. All value data in the name/value pair is of type String.
How the extension Java class is invoked by the execution point, whether it is by the UI, web services, CORBA APIs, or polling servers.
This section provides information about the following execution points:
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.
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.
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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The CORBA API methods through which the Java class extension is invoked are:
Work Management > completeTask
Work Management > completeTaskOnDate
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.
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.
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.
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.
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.
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.
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>
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.
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.
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.
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.
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.
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.
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.
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 |
The Potentially Late Task execution point is not triggered by the WebService API.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The System Task Failure execution point is not triggered by the WebService API.
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.
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.
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.
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.
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 |
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.The CORBA API method through which the Java class extension is invoked is:
Work Management > updateGWEvent
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The Select Port Address execution point is not triggered by the WebService API.
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.
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.
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.
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.
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.
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.
The Select Component or Element for Physical Connection execution point is not triggered by the WebService API.
The Select Component or Element for Physical Connection execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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.
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.
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.
The Select Component or Element for Virtual Connection execution point is not triggered by the WebService API.
The Select Component or Element for Virtual Connection execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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 |
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 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.
The Select Network System execution point is not triggered by the WebService API.
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.
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.
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.
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.
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 |
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 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.
The Select Customer Edge Component execution point is not triggered by the WebService API.
The Select Customer Edge Component execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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 |
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 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.
The Select End Component For Physical Connection execution point is not triggered by the WebService API.
The Select End Component For Physical Connection execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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 |
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 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.
The Select Equipment For CE execution point is not triggered by the WebService API.
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.
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.
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.
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.
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.
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 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.
The DS0/DS1 Automated Design execution point is not triggered by the WebService API.
The DS0/DS1 Automated Design execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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.
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 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.
The Connection Id Automation execution point is not triggered by the WebService API.
The Connection Id Automation execution point is not triggered by the CORBA API.
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.
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.
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.
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.
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:
|
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:
|
OutputDedicatedPlantList |
|
Error message to be sent to the server log. |
ErrorMessage |
The data returned by the Select Dedicated Plant execution point must adhere to certain rules. See "DedicatedPlantSelection" for detailed parameter-level validation information.
The Select Dedicated Plant execution point is not triggered by the WebService API.
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.
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.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, "MSS UI Windows That Trigger the Execution Point" for more information about the MSS UI windows from where you can trigger the execution point.
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.
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:
|
|
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:
|
|
returnAddrId |
String |
The returnAddrComponents or returnAddrId is mandatory if you specify the returnCode as Warning. |
Unique identifier returned for an address. |
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.
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:
|
|
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:
|
|
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:
PSR Ordering Dialog The execution point is triggered when you do one the following:
PRILOC/SECLOC Assignment Window The execution point is triggered when you do the following:
|
|
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:
PSR Ordering Dialog The execution point is triggered when you do one the following:
PRILOC/SECLOC Assignment Window The execution point is triggered when you do the following:
|
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.