FTI Language Concepts

This chapter describes key concepts to help you better understand how to use the Script Language and CORBA Language more effectively within a CPC environment.

CPC is an integrated flow-through service activation solution for network service providers, such as IXCs and LECs, who offer Frame Relay, ATM, Internet access, and other data services. These services typically are complicated to configure and involve multiple technologies. CPC provides a single, consistent interface for provisioning multiple services across multiple network technologies comprised of multiple vendors and equipment models. As such, CPC provides immediate benefits in terms of reduced training costs, improved operations efficiency, and fewer provisioning errors.

CPC provides customer-extensible Service objects using the popular Java language. Service objects allow the service provider to view the network in terms of end-user or subscriber services as well as the traditional set of nodes, ports and circuits. Thus, complex configuration changes are grouped into simple units that reflect more closely the orders received from subscribers. This simplifies and speeds up order processing and improves order consistency. In addition, new services are easier to develop and deploy.

CPC provides interfaces allowing the service provider to flow orders directly from the order processing or customer care systems into CPC for immediate provisioning. These interfaces allow CPC to become an integral component of the service providers total service creation system.

The client-server, UNIX-based implementation of CPC, in conjunction with the use of commercial relational database systems, allows the system to address the full range of service provider capacity and throughput requirements. The system can scale to support millions of network objects and dozens of concurrent operators or flow-through sessions.

Product Functions

CPC can be driven from another application through its Flow-Through Interface (FTI) or it can be used directly by a human Operator using its graphical user interface (GUI). In all of these cases the main interaction is with Service objects.

There is a Service object for each of the services which the provider offers. The class of the Service object identifies the nature of the Service (for example, end-to-end Frame Relay connectivity service), and there is an instance of the Service object for each deployment of that service. New services are created by defining new classes of Service object.

Service objects can be added, deleted and modified as single atomic operations, which CPC then breaks down into elementary actions on individual pieces of equipment. Decisions about how a service should be laid-in are made by CPC, and users (operators or applications) can then view how the service was laid in. CPC ensures that the operation is applied successfully to all elements of the network, in a coordinated manner. If any elementary action fails then the entire operation is rolled-back.

A service creator has the choice of defining the service in equipment-neutral terms (allowing the same service to be transparently deployed across a variety of equipment), or taking into account equipment-specific features (allowing the service to take full advantage of all of the features of a given type of equipment).

Product Operation

At the heart of CPC is a database, which contains an object-oriented representation of the managed network.

Some objects are treated by CPC as fabric: they are discovered in the managed network and shadowed in the database. CPC provides an Upload function, which reads the relevant configuration information from the network and updates the database.
Other objects are treated as service elements: they are created, modified and deleted by CPC in response to requests to provision services. Service elements can also be uploaded from the network. Service elements (PVCs, etc.) are laid-in over fabric elements (Nodes, Ports, etc.).

A CPC Administrator ensures that the representation of network fabric in the CPC database is an accurate representation of the managed network. CPC monitors events from the network, listening for events which indicate changes to the fabric (deployment of new nodes, etc.). An administrator can view these events and decide when to upload fabric information.

CPC clients deal with service requests, that is, requests from customers for new services, modifications to existing services, cancellations, etc. A CPC client is most likely to be an order-processing application, but it may also be a human Operator.

An order-processing application communicates with Service objects in CPC using the Script Language or CORBA. A Service object creates service elements in the database, using the fabric elements which are already present, and then provisions the service by updating the network to reflect the new service elements in the database.

Human Operators can also satisfy service requests by interacting with the Service objects using the CPC GUI.

CPC and FTI Concepts

A flow-through application is an application integrated with CPC using script or CORBA commands. The flow-through application has access to all of the capabilities of CPC, including:

Creating and modifying Services.
Examining the low level objects which comprise the Service (service elements).
Performing administrative tasks such as creating profiles, re-threading failed links, or recovering logical ports.

For more information about CPC concepts, refer to the Cisco Provisioning Center Users Guide.

Object Mo del

Objects are the basic units that flow-through applications deal with. Objects can be located, retrieved and modified using Script Language or CORBA commands. The set of objects that can be manipulated by flow-through applications consists of Service objects, configuration objects, profiles, Transactions, and sessions. All of these objects form the object model and are stored in the CPC database.

To identify these objects, each is referenced by a unique identifier which is returned as a result by some Script Language or CORBA commands and accepted as input by others. This identifier is a number in some cases (for transactions and sessions), and as an object identifier in others (Transactions, Service objects, configuration objects, and profiles).

Service Objects

CPC stores a description of the service in the form of data items called Service objects. Related Service objects are delivered in packages called Service Applications. Service objects represent the orders received from subscribers and present an end-user view of the components that make up that service. The components are in themselves configuration objects (or more explicitly service elements) which are created and managed through the Service objects.

Configuration Objects

CPC stores a description of the network configuration in the form of data items called configuration objects. Configuration objects represent physical objects such as ports and links between the ports (known as fabric elements), as well as logical objects such as circuits and link connections between the circuits (known as service elements).

Profiles

A profile provides the ability to pre-configure certain attributes of specific objects. There is a corresponding profile object class for each Service object class and for each service element class. For example, a Frame Relay Service object class has a corresponding Frame Relay Service Profile class and a Frame Relay PVC object class has a corresponding Frame Relay PVC Profile class. Profile objects provide the initial (default) attribute values for the corresponding object class whenever such a new object is created or an existing object is modified with a new profile.

Each profileable object class has a special profile called the default profile. This profile contains the attributes that are given to new elements of that class. You may later override some of these attributes on the object itself or may reassign a different profile to the object.

Note From this point forward, references to configuration objects also include profile objects, unless explicitly stated otherwise.

Transactions

Service and configuration changes which are associated with the same change are applied in a single, network-wide transaction. This transaction is controlled by a Transaction object (which is a simplified view of a Change Request or CR). A Transaction is not required when Service and configuration changes are not being made, as in the case of viewing and listing objects.

The Figure 1-1 below illustrates the Transaction states and the functions and/or conditions that trigger the state transitions. A transaction can be applied immediately or it can be scheduled to be applied for a later date/time. In either case, when a transaction is applied to the network, it is applied automatically. I0f any individual change fails to apply then all other related changes are rolled-back and the Transaction is left in an Abandoned state. A successful Transaction is left in an Applied state.

Figure 1-1: Transaction Life Cycle States

Sessions

A session is a single execution thread in CPC. CPC supports multiple parallel sessions, which can be automated (flow-through) or interactive.

Each session has an associated user id. This user id defines the security permissions associated with the session. For more information about security, refer to the section titled "Security" later in this chapter.

Object Classes and the Class Hierarchy

In this guide, we use the terms class and base class with respect to objects in the model in a rather precise way. We tend to think about objects in a network as being grouped into collections of objects of a similar kind: for example, node-like objects such as switches, access processors, routers and hubs; or card-like objects that have physical connectors into which cables are plugged. These collections of similar objects are called classes.

A class can contain other classes, called subclasses, which share the attributes of the containing class but differ from each other. For example, the class of Nodes can contain the ATM Switch subclass, the Frame Relay Access Device subclass and the IP Router subclass. Each subclass is a kind of Node, yet each has its unique attributes such as the network protocols it supports. Subclassing can continue to multiple levels: for example, we can create a High-Speed ATM Switch subclass of the ATM Switch subclass. The class that contains a subclass is referred to as its superclass. The highest superclass in a class hierarchy, the Node in our example, is referred to as the base class.

When we refer to an object's class in this manual, we mean its lowest-level subclass. For example, if we consider a High-Speed ATM Switch called Atlanta, we would say that its base class is Node and its class is High-Speed ATM Switch.

Security

Script Language and CORBA commands can retrieve and modify object attributes, create and delete objects.

For the Script Language, once you log in, your CPC privileges determine what operations you may perform and on which objects. The security for a Script Language application is consistent with an interactive session.

For CORBA, when you create a CORBA session, you specify a user name as one of the parameters. The CPC privileges associated with the specified user name (in the securityInfo file) determine what operations you may perform and on which objects. You do not require a password to use a given user name, and the superUser can be used for unrestricted access.

To execute any Script Language or CORBA command, the minimum required privilege is Examine. For information on privileges and security tags, refer to the Cisco Provisioning Center User's Guide.

The Role of the FTI

The FTI is the primary interface to CPC. It allows a flow-through application to perform the same CPC functions that are available through an interactive session. The main purpose of the Script Language and CORBA interface is to allow other management applications to integrate with CPC. Though you may choose to use the GUI to perform these functions, there are situations in which the flexibility of a programming language is necessary.

For example:

To provision Services requested from an order-processing application.
To perform requests from an external application, such as to upload an object that was just modified in the network, to recover from a failed NNI link, or to fail and recover a UNI foreground logical port.
To add topology information which an upload function is unable to determine (because the information is not known to the node or subunit manager).
To perform repetitive operations, such as periodically deleting old Transactions and Upload Requests from the database.
To generate custom reports about the objects in the database.
To create a test database with a large numbers of objects.
To create test scripts to prove performance and reliability.
To perform customer- or network-specific functions.

This guide provides examples of simple flow-through applications that can provide information or perform network management functions that cannot be easily accomplished using the interactive interface alone.

Script Language Environment

Before you can run a flow-through application, you must be logged in to UNIX as a user with appropriate CPC privileges. Logging in also defines the appropriate UNIX environment variables, such as $CCP_BIN, that may be needed by the flow-through application.

The Script Language is currently accessible through the UNIX Korn Shell programming language. All execution control (looping, conditional statements, etc.), variables, file management and other such facilities are provided by the shell language.

From the Figure 1-2 below the Script Language Environment with CPC is shown. A flow-through application works with high-level calls to CPC (for example, to provision a service), or works with lower-level calls to manipulate specific configuration objects (for example, to add topology or upload a specific object).

Figure 1-2: Script Language Environment