| Oracle® Communications IP Service Activator OSS Integration Manager Guide Release 7.2 E36051-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator OSS Integration Manager Guide Release 7.2 E36051-01 |
|
|
PDF · Mobi · ePub |
This chapter provides a brief introduction to the Oracle Communications IP Service Activator OSS Integration Manager (OIM) and its capabilities. It includes the following:
A summary of what you can do with the OIM, and some security restrictions
The OIM executables; how to install them and run them
An introduction to the command set and the External Object Model
An outline of connecting an OIM client to the Naming Service
The OIM provides an API to Operational Support Systems (OSSs), enabling IP Service Activator to be integrated with third-party software, such as billing, monitoring and fault management systems. The OIM enables automated or programmatic control of IP Service Activator's service provisioning facility.
Using OIM you can:
Browse the managed network
Provision services
Report on faults and other events
You can also integrate IP Service Activator with Oracle Communications Order and Service Management (OSM) using the Web Services API. For information about using Web services with IP Service Activator, see "Web Services".
A set of commands allows external systems to access part of the IP Service Activator object model. You can:
Examine managed networks and VPNs
View details of the services applied
Check the status of managed devices or configured services
Find objects by name or attribute
The OIM allows user applications to make both physical and logical changes to the topology. You can:
Create or discover new devices, including details of interfaces, sub-interfaces and PVCs
Set up customers and sites, link sites to network elements and create VPNs
Create policy rules to control Quality of Service (QoS) and to control access, and apply them to specific points in the network topology
Create standard and MQC Per Hop Behavior (PHB) groups and apply them to specific points in the network topology in order to control queuing or traffic shaping mechanisms
Change certain attributes associated with a system, topology or policy object
Propagate changes to the network, that is, update all devices/interfaces with configuration changes that have been specified
Undo specific changes where you have ownership of the changes
Faults and events occurring in any part of the managed network can be reported to external systems. By using the OIM in conjunction with the Event Handler, you can:
Subscribe to specific types of events such as faults, system messages, status changes or changes in the attributes of objects
Specify the parts of the network to be monitored, such as a specific VPN or subnet
Deliver data in the form of SNMP traps, as CORBA calls or to Micromuse Netcool
For more detailed information about the Event Handler, see IP Service Activator Event Handler Guide.
Use of the OIM requires a login and password, which must be set up from the IP Service Activator user interface. The user's rights to view, create, and modify objects are controlled by the user group and the permissions set up on objects. For information, see IP Service Activator System Administrator's Guide.
In addition, to ensure system security, some actions and some parts of the object model are not available using the OIM. You cannot:
Access individual IP Service Activator system components, or execute core system operation commands, such as shutdown
Change or alter the visibility of audit logs
IP Service Activator supports multiple OIMs running on one IP Service Activator system. You can connect multiple clients to each OIM instance.
Each OIM instance runs a copy of the master object model. Each client that is connected to an OIM instance can traverse and read this model concurrently with other clients. If a client performs any write operation on the model (i.e. create/modify/delete/use/unuse type commands, as opposed to setpath/getpath/getattributes/getparents type commands), these operations are stored in the OIM server in a transaction queue for that particular client.
At any point, the client can either issue an abort (which empties the queue) or a commit (which performs the queued operations on the model). If the client disconnects, this is treated as an abort (after an appropriate timeout).
When the queued operations begin to be applied to the model, it is locked for all other clients. Should other clients attempt to access the model, they will block. This situation resolves in one of two ways:
The transaction is successfully applied into the model, model validation succeeds and the changes are successfully registered with the main object model in the policy server.
One of the above steps triggers or encounters an error. The client is notified of transaction success/failure and the model re-opened to all clients.
IP Service Activator has been enhanced to support the multipath statement for the Juniper Device Driver. Three new fields namely, Multipath, VpnUnequalCost, and EqualExternalInternal have been added to support load balancing in Layer 3 VPNs. This feature is supported only on Juniper Device Driver.
Autonomous System Number (ASN) is a unique number, which is used to identify Autonomous Systems under BGP routing. IP Service Activator 7.0.0 supports 4-byte ASN, an enhancement over the 2-byte ASN it supported in earlier versions. ASNs are used in generating various router commands under BGP and EBGP. IP Service Activator 7.0.0 supports 4 byte ASN to activate services on network elements.
In OIM, with the 4-byte support, the user can set 4-byte ASN values for most of the ASN fields like BGP ASN and site BGP ASN. However, for Route Distinguisher (RD) and Route Targets (RT), the user can enter both IP address and 4-byte ASN values.
The OIM is an optional IP Service Activator component, which consists of the following:
The Integration Manager. The executable (integration_manager.exe) is installed in the Program directory on Windows systems and the rbin directory on Solaris systems
The OIM command line interface (CLI). This optional executable (integration_manager.cli) allows you to run the OIM commands interactively.
The OIM IDL file. This file (integration_manager.idl) defines the OIM module structure in IDL (Interface Definition Language) format. This file is located in the src directory on Windows systems and on Solaris systems.
Note that a Component Manager must also be installed on the same host system.
Note:
Note that if you install the OIM on a Windows platform the CLI is only installed if you select the Extra Applications component.For full installation details, see IP Service Activator Installation Guide.
This section describes how to run the OIM.
To specify command-line parameters to OIM you need to do the following:
On Solaris platforms, edit the Integration Manager entry in the configuration file cman.cfg in the IP Service Activator Config directory.
On Windows platform you can use the Configuration GUI tool to run the Integration Manager by following the steps given below:
Ensure that you have installed OSS Integration.
Check the OSS Integration Manager check box in the Configuration GUI window, in the Config Parameters panel, under Component Manager Entries.
Click Commit to host.
Note:
For more information about the Configuration GUI, see IP Service Activator System Administrator's Guide.While generally applications are written in the form of scripts, the command-line interface is provided to run OIM commands interactively, which can be useful for testing purposes.
Run the following from the Program directory:
integration_manager_cli.exe
Table 1-1 lists and describes the command line parameters that can be set for the CLI.
Table 1-1 Command Line Parameters for CLI
| Parameter | Description |
|---|---|
|
-NoLogin |
Use this option to prevent the login prompt. This option is useful if the CLI is to be used to run scripts. |
|
-ComponentName filename |
Use this option to specify the OIM component name if it is anything other than "master_integration_manager". |
|
-ComponentLocation hostname |
The name of the host on which the OIM is installed. |
|
-ORBgiopMaxMsgSize size |
Maximum CORBA message size in bytes. Defaults to 4294967295. See "Maximum CORBA Message Size". |
You can create a simple text file of the OIM commands, then redirect the script into the CLI by using the following syntax:
integration_manager_cli -NoLogin < script.txt
In this case, the first line of the script should be:
login name=user_name password=password
Run the ./integration_manager_cli command in the ServiceActivator BIN directory. The path to that directory is /opt/OracleCommunications/ServiceActivator/bin.
You are prompted for a login and password. The login and password are the same as your IP Service Activator login and password.
After you enter the login information, the Integration Manager prompt appears.
In some situations, such as when an XML export is performed or when working with a large database, the default CORBA message size is not large enough. A message that exceeds the CORBA message size causes the OIM to fail. We recommend that any CORBA connection is initialized with the value 4294967295. This applies to both the connection between the OIM component and the policy server, and between an OIM client (such as the OIM command-line interface) and the OIM component. To initialize the OIM component and the OIM command-line interface with the required message size, use the command-line parameter:
-ORBgiopMaxMsgSize 4294967295
Any script that runs as a client of the OIM component should also initialize the CORBA connection with this recommended message size. The method used is dependent on the language in which the script is written.
In order to write applications to interface to IP Service Activator, systems developers need the following:
Details of the OIM command set and syntax
Details of the IP Service Activator objects that can be viewed, created and modified via the API
The OIM command set comprises a number of generic commands that enable third-party systems to browse the object model and provision services. Full details are given in "The Command Language".
OIM uses a small set of generic commands, rather than a large number of commands specific to objects. This means the command set is independent of the IP Service Activator object model as well as any information model used by an external system. Changes can be made to object attributes or new objects added to the model without affecting backwards compatibility.
Any user familiar with UNIX or scripting language commands will find the OIM straightforward to use. All commands have the same basic format:
command [object_path] [parameters]
Commands that execute changes to the database and network are aggregated into transactions, which work in the same way as using transactions from the IP Service Activator user interface. This logical approach helps ensure straightforward scripting.
IP Service Activator maintains an Object Model of the physical managed network. This object model is managed by the policy server and stored in the central database. It holds information about all classes of objects, including their attributes, the actions that can be performed on them and the relationships between them. The object model is also known as the common object model, to distinguish it from local data models maintained on host machines running the user interface.
The External Object Model (EOM) is a subset of the common object model, including those objects which are accessible from external systems via the API.
Like the common object model, the EOM is divided into three major categories:
Topology: the Topology Model contains objects that represent the physical network, such as VPNs, devices, interfaces and PVC objects.
Policy: the Policy Model contains objects for creating and applying policies and services to the network devices.
System: the System Model contains objects that represent the IP Service Activator system components and associated system management objects.
Full details are given in "The External Object Model".
The following is an example of Java code to connect to the Naming Service:
// setting up the CORBA details
org.omg.CORBA.Object objRef = orc.resolve_initial_references("NameService");
NamingContext nameServiceContext = NamingContextHelper.narrow(objRef);
NameComponent nc0 = new NameComponent("orchestream.com", "vendor");
NameComponent nc1 = new NameComponent("provider", "application");
NameComponent nc2 = new NameComponent("integration_manager", "component_type");
NameComponent nc3 = new NameComponent("master_integration_manager", "integration_manager");
NameComponent path[] = {nc0, nc1, nc2, nc3};
org.omg.CORBA.Object sessionManagerRef = nameServiceContext.resolve(path);
OimSessionManager sessionManager = OimSessionManagerHelper.narrow(sessionManagerRef);
org.omg.CORBA.Object sessionRef = sessionManager.NewSession("Java");
OimSessionInstance session = OimSessionInstanceHelper.narrow(sessionRef);
The complete path of the Integration Manager component in the Naming Service is:
"orchestream.com", "vendor" "provider", "application" "integration_manager","component_type" "<ComponentName>", "integration_manager"
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|