1 Extensions Overview

This chapter provides basic information about custom extensions and how you can use them to invoke API calls and send messages that support your business processes.

About Custom Extensions

A custom extension enables you to extend Oracle Communications MetaSolv Solution functionality with additional business logic specific to your organization. In other words, extensions provide the ability to make calls to external systems and to send email and JMS messages at predefined execution points, over and above the functionality supported by the MetaSolv Solution application and APIs.

You can develop custom extensions that simply send data to another system, or that send and receive data. An extension that sends data and does not expect a response from an external system is called asynchronous. An example of an asynchronous extension is an email message. You may choose to develop an asynchronous extension that sends an email when a particular process or event occurs in MetaSolv Solution.

An extension that sends data and expects a response from an external system is called synchronous. An example of an execution point that can be used to develop a synchronous extension is Assign Queues. You may choose to develop a synchronous extension that executes a custom Java class when a particular process occurs in MetaSolv Solution. The Java class executes as its own transaction, separate from the process that initiated it.

Developing a custom extension involves several tasks. These tasks, listed below, appear in a conceptual order to help you understand extensions. In reality, these tasks would probably be performed by different people, and at varying times.

  1. Define the extension.

  2. Identify execution points.

  3. Code the extension logic.

Extensions

The first step in developing a custom extension is to define the extension in the MetaSolv Solution user interface (UI). The extension name that you define is the name of the Java class that will contain your custom logic.

Execution Points

The second step in developing a custom extension is to define the point at which you want the custom extension logic to execute; that is, the process or action that triggers the invocation of your custom code. You define this execution point by identifying three key pieces of information:

Building Block

A building block type is a predefined item in MetaSolv Solution, such as a gateway event, with which you can associate an extension. Building blocks further describe building block types. For example, using the building block type of Gateway Event enables you to associate an extension with a gateway event. You then further define this item by selecting the building block of All Gateway Events. This means you can associate the extension with all gateway events, as opposed to specific events.

Process Point

A process point describes general processing that takes place in MetaSolv Solution, for example, gateway event maintenance. To continue with the example used for building blocks, you can associate a process point of GW (gateway) Event Maintenance with the extension. This means the extension logic is triggered when MetaSolv Solution processes some type of gateway event maintenance.

Like building blocks, process points are predefined in MetaSolv Solution.

Action Type

An action type is a specific task or process that takes place in MetaSolv Solution. When you associate an action type with an extension, you are identifying the specific action that triggers the extension logic to execute for a particular extension. To conclude the previous example, you can associate the action type of GW (gateway) Event Failed with the extension. This means the extension logic is triggered when MetaSolv Solution processes a gateway event and it fails to successfully complete.

Like building blocks and process points, action types are predefined in MetaSolv Solution.

Extension Logic

The next step in developing a custom extension is to code a free-form Java class that provides additional functionality to support your business processes. As examples, you can code a Java class to:

  • Make calls to external systems

  • Send email notifications

  • Send JMS messages

  • Invoke other MetaSolv Solution API calls

Invocation Methods

This section is not listed as a step in the above "About Custom Extensions" because identifying the execution points is what defines the invocation methods. Therefore, this is not actually a step that you need to perform. However, it is important to understand the information contained in this section, so it is included in the overview because it addresses, at a high level, how custom extension logic is invoked. See "Supported Execution Points" for specific information regarding invocations for supported execution points.

After you define the extension, associate the execution point, and code the logic for your custom extension, it is invoked from one or more of the places listed below. The invocations are dependent upon the execution points associated with your extension.

Figure 1-1 shows the architecture of MetaSolv Solution and how the various system components interact to support custom extension functionality.

Figure 1-1 Architecture Supporting Extension Functionality

Description of Figure 1-1 follows
Description of ''Figure 1-1 Architecture Supporting Extension Functionality''

MetaSolv Solution UI

You can invoke extension logic through the UI when the specified action, defined by an execution point (combination of building block, process point, and action type), occurs. For example, a user assigning a jeopardy code to a task is a specific action that can invoke an extension, if that action is defined as an execution point. Specifically, you would choose the execution point combines the building block type of Task Type, process point of Task Maintenance, and action type of Assign Jeopardy.

Web Service Clients

You can invoke extension logic through a call to an WebService API method when the specified action, defined by an execution point (combination of building block, process point, and action type), occurs. For example, a third party calling the addTaskJeopardyRequest method to assign a jeopardy code to a task is a specific action that can invoke an extension, if that action is defined as an execution point. Specifically, you would choose the execution point that combines the building block type of Task Type, process point of Task Maintenance, and action type of Assign Jeopardy.

CORBA API Clients

You can invoke extension logic through a call to a CORBA API method when the specified action, defined by an execution point (combination of building block, process point, and action type), occurs. For example, a third party calling the deleteTaskJeopardy method to remove a jeopardy code from a task is a specific action that can invoke an extension, if that action is defined as an execution point. Specifically, you would choose the execution point that combines the building block type of Task Type, process point of Task Maintenance, and action type of Assign Jeopardy.

Polling Servers

You can invoke extension logic through polling servers as well. These servers, which need to be configured in the gateway.ini file, are listed on the following page. See "Additional Configurations" for detailed information regarding these configurations.

Polling servers can invoke extension logic if the action of the polling server is defined as an execution point. For example, a task that is defined as a system task with a task execution point of Ready is automatically picked up by the System Task Server when the task status becomes Ready. If the task completion logic that runs on the server fails, extension logic can be invoked if it defines that as an execution point. Specifically, you would choose the execution point that combines the building block type of Task Type, process point of Task Maintenance, and action type of System Task Failure.

Polling Servers and Supported Execution Points

The following polling servers can invoke an extension that is defined with the specified execution points. See "Supported Execution Points" for more information about the supported execution points.

  • Background Processor

    • System Task Failure

  • Gateway Event Server

    • Gateway Event Failure

  • Integration Server

    • Gateway Event Failure

    • Late Task

    • Potentially Late Task

  • System Task Server

    • System Task Failure

      Note:

      The Background Processor is not a Java-based polling server. Rather, it is a PowerBuilder application that runs in the background.