| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
 Previous |
 Next |
| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
Previous |
Next |
This chapter describes how to configure dynamic routing for Oracle Communications ASAP atomic actions.
The Dynamic Network Element (NE) Routing feature allows ASAP to provision NEs based on network and communication data provided as order parameters rather than loaded from static Service Activation Request Manager (SARM) configuration tables. ASAP routes the translated Atomic Service Description Layer (atomic action) commands to the appropriate NEs based on specific routing information contained in the work order. This dynamically provided communication data is identical to the communication data normally defined in static tables and used by the devices [command processor threads in the Network Element Processor (NEP) to connect and log in to.
For information on configuring static routing, see "Configuring Static Network Element Routing".
Dynamic NE routing is most commonly used for IP-based provisioning, but is applicable to all downstream communication protocols. For example, it is possible to dynamically route provisioning tasks that use serial dialup connections in the downstream.
Dynamic routing functions as follows:
The SARM receives a work order.
The SARM uses the NE_ID (mapped to the atomic action label MCLI) parameter to determine if the order is to be routed statically or dynamically. The NE_ID, or any other Common Service Description Layer (service action) label defined for the parameter, identifies either an NE resource or a dynamic routing template resource configured in ASAP. Examples for mapping the atomic action label MCLI to different service action labels are provided later in this chapter.
If the NE_ID identifies a network template, the SARM uses this to dynamically set up a session manager, connection pool, and command processors.
The SARM uses the drop timeout (discussed later in this chapter) to terminate connections to the NE.
After the primary connection is dropped, the command processor, connection pool, and session manager are cleaned up.
This section describes how to configure ASAP to enable dynamic routing.
A network template describes an ASAP connection environment that consists of an NEP, primary connection pool and its attributes (spawn threshold, kill threshold, max connections, and drop-timeout). ASAP uses the template to set up a connection pool and session manager for each dynamically identified NE.
In conventional static configurations, the work order identifies a real NE to be provisioned via the reserved atomic action parameter named MCLI. In dynamic routing, this parameter identifies a template for dynamic routing.
A static routing definition contains a parameter that references MCLI as follows:
<parameter name="MCLI" xsi:type="SimpleParameterType">
<required>true</required> <parameterValueMap>NE_ID</parameterValueMap>
</parameter>
In this situation, a work order can identify the target NE by defining a parameter called NE_ID and assigning a value that references a statically configured NE resource in ASAP.
A dynamic routing configuration appears as follows:
<parameter name="MCLI" xsi:type="SimpleParameterType">
<required>true</required> <parameterValueMap>TEMPLATE_ID</parameterValueMap>
</parameter>
In this situation, a work order can identify a network template by defining a parameter called TEMPLATE_ID and assigning a value that references a network template resource in ASAP.
Table 7-1 Comparing Static and Dynamic Configuration
| # |
Static | Dynamic |
|---|---|---|
|
Atomic action reserved work order parameter MCLI |
Identifies NE |
Identifies network template |
|
tbl_clli_route, tbl_host_clli, tbl_nep, tbl_ne_config, tbl_resource_pool, tbl_comm_param |
Specifies connection environment for a specific NE |
Specifies a dynamic routing template |
Use the Service Activation Configuration Tool (SACT) and ActivationConfig.xsd schema to create and deploy network templates. When deployed, the network template is identified in tbl_ne_config. For more information on the SACT, see ASAP Server Configuration Guide.
You can write the XML configuration file from scratch, use an XML editor to generate the XML code, or use a sample from the ASAP_Home/samples/sadt/SampleCommonConfig directory as the basis for the XML configuration file. ASAP_Home is the directory in which ASAP is installed.
A sample XML configuration file for dynamic routing appears below:
<dynamicRoutingTemplate name="DYN_DALLAS"> <nepServerName>NEP_S235</nepServerName> <vendor>DYNAMIC_VENDOR</vendor> <technology>DYNAMIC_TECH</technology> <softwareLoad>DYNAMIC_SL</softwareLoad> <maximumConnections>5</maximumConnections> <dropTimeout>1</dropTimeout> <spawnThreshold>3</spawnThreshold> <killThreshold>0</killThreshold> <read_timout>5</read_timeout> <write_timeout>5</write_timeout> <lineType>TELNET_CONNECTION</lineType> <communicationParameter> <label>DynLab1</label> <value> <value>DynVal1</value> </value> <description>DynDesc1</description> </communicationParameter> <label>LOGIN_PROMPT</label> <value defaultValue="login:"> <value>login:</value> <description>Login prompt.</description> </communicationParameter> <communicationParameter> <label>READ_TIMEOUT</label> <value defaultValue=5> <value>5</value> <description>Integer</description> </communicationParameter> <communicationParameter> <label>WRITE_TIMEOUT</label> <value defaultValue=5> <value>5</value> <description>Integer</description> </communicationParameter> </dynamicRoutingTemplate>
The template name (DYN_DALLAS) specified in the dynamicRoutingTemplate tag identifies the template that must be specified in the work order.
Parameters provided on the work order override statically defined values in the template.
For specific tag definitions, refer to the comments in activationConfig.xsd.
After you have written the dynamic routing XML configuration file, you can use a command-line tool to configure it into ASAP. For more information, see the ASAP Server Configuration Guide.
This section describes different routing scenarios and the configurations required to support them. Dynamic routing requires that communication parameters used in creating a connection must be passed down as order parameters.
Dynamic routing is supported by any protocol including TCP/IP. Consequently, ASAP cannot mandate keyword parameters to specify a target NE's communication parameters. For TCP/IP-based protocols, an IP address and port are usually sufficient parameters to specify a connection. Other protocols require different communication parameters: HTTP may include a URL, and Common Object Request Broker Architecture (CORBA) may use an Interoperable Object Reference (IOR) string. There is no limit to the set of communication parameters that can be used to uniquely identify a target NE.
NE identification is provided by means of the reserved compound parameter COMM_PARM and its reserved member COMM_PARM.NE_ID. Only work order parameters mapped to the key compound parameter of COMM_PARM are identified as dynamic communication parameters. The subset of communication parameters identified by COMM_PARM.NE_ID is used by ASAP to uniquely identify a specific NE.
For example, you could identify the communication parameters for an NE instance using TCP/IP connections with one or more of the following:
COMM_PARM.NE_ID.HOST_IPADDR
COMM_PARM.NE_ID.PORT
COMM_PARM.NE_ID.HOST_USERNAME
COMM_PARM.NE_ID.HOST_PASSWORD
For CORBA devices, the communication parameter may appear as follows:
COMM_PARM.NE_ID.IOR
COMM_PARM.NE_ID.USERNAME
COMM_PARM.NE_ID.PASSWORD
Each parameter is used to create a key that uniquely identifies that NE. Based on the key, the SARM initializes a session manager. For instance, if you wanted only the IP address and security credentials to uniquely identify an NE, you would specify port as COMM_PARM.PORT (without the NE_ID) so that it does not come into play when identifying a target NE.
Another provisioning request with the same set of communication parameters but with a different user name and password identifies a different NE to ASAP. ASAP would create two sets of resources for each NE: connection pool, session manager, command processor, devices, and so on.
The following sections describe different routing scenarios.
In this scenario, an upstream inventory system is used to maintain certain logical NE attributes including routing information. The set of NEs that will use dynamic routing have identical connection characteristics, consequently, they can share a single dynamic routing template. Work orders are submitted to ASAP with enough information to identify the template to be used for dynamic routing. All values configured in the template are then applied to establish the connection.
Figure 7-1 shows a single service action mapped to one or more atomic actions, all of which are routed to a single NE.
The work order includes the following service action and communication parameters:
C-SERVICE TEMPLATE_ID_A=TEMPLATE_1 COMM_PARM.NE_ID.URL=http://www.abc.com COMM_PARM.NE_ID.HOST_USERNAME=jsmith COMM_PARM.NE_ID.HOST_PASSWORD=<password1>
Table 7-2 shows the parameter mappings service model configuration.
Table 7-2 Scenario 1 Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
COMM_PARM |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID_A |
Scalar |
|
A-SERVICE_2 |
COMM_PARM |
COMM_PARM |
Compound |
|
A-SERVICE_2 |
MCLI |
TEMPLATE_ID_A |
Scalar |
|
A-SERVICE_3 |
COMM_PARM |
COMM_PARM |
Compound |
|
A-SERVICE_3 |
MCLI |
TEMPLATE_ID_A |
Scalar |
This configuration routes all three atomic actions to the same NE because they each receive the same set of communication parameters. Table 7-3 shows the downstream program (State Table or JInterpreter class) parameters:
Table 7-3 Scenario 1 Parameters
| Label | Value |
|---|---|
|
A-SERVICE_1 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.abc.com |
|
username |
jsmith |
|
password |
<password1> |
|
A-SERVICE_2 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.abc.com |
|
username |
jsmith |
|
password |
<password1> |
|
A-SERVICE_3 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.abc.com |
|
username |
jsmith |
|
password |
<password1> |
The COMM_PARM and COMM_PARM.NE_ID are stripped from the work order parameter so that the downstream provisioning program receives the parameters in the name/value pair that is expected.
Figure 7-2 presents a single service action mapped to two or more atomic actions, each of which is routed to a different NE but all using the same network template.
The work order includes the following service action and communication parameters:
C-SERVICE TEMPLATE_ID=TEMPLATE_1 SUBSCRPTION_A.NE_ID.URL=http://www.abc.com SUBSCRIPTION_A.NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION_A.NE_ID.HOST_PASSWORD=<password1> SUBSCRPTION_B.NE_ID.URL= http://www.def.com/ SUBSCRIPTION_B.NE_ID.HOST_USERNAME=dmiller SUBSCRIPTION_B.NE_ID.HOST_PASSWORD=<password2> SUBSCRPTION_C.NE_ID.URL=http://www.ghi.com SUBSCRIPTION_C.NE_ID.HOST_USERNAME=djones SUBSCRIPTION_C.NE_ID.HOST_PASSWORD=<password3>
Table 7-4 shows the service model configuration parameter mappings.
Table 7-4 Scenario 2 Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
SUBSCRIPTION_A |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID |
Scalar |
|
A-SERVICE_2 |
COMM_PARM |
SUBSCRIPTION_B |
Compound |
|
A-SERVICE_2 |
MCLI |
TEMPLATE_ID |
Scalar |
|
A-SERVICE_3 |
COMM_PARM |
SUBSCRIPTION_C |
Compound |
|
A-SERVICE_3 |
MCLI |
TEMPLATE_ID |
Scalar |
The atomic action parameter MCLI in this case identifies the network template. In static routing, the atomic action parameter MCLI identifies the NE.
This configuration routes each atomic action to a different NE. Table 7-5 shows the downstream program (State Table or JInterpreter class) parameters.
Table 7-5 Scenario 2 Parameters
| Label | Value |
|---|---|
|
A-SERVICE_1 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.abc.com |
|
HOST_USERNAME |
jsmith |
|
HOST_PASSWORD |
<password1> |
|
A-SERVICE_2 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.def.com |
|
HOST_USERNAME |
jsmith |
|
HOST_PASSWORD |
<password2> |
|
A-SERVICE_3 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.ghi.com |
|
HOST_USERNAME |
jsmith |
|
HOST_PASSWORD |
<password3> |
Figure 7-3 shows a single service action that is mapped to two or more atomic actions, each of which is routed to a different NE. Each NE is using a different network template.
The work order includes the following service action and communication parameters:
C-SERVICE TEMPLATE_ID_A=TEMPLATE_1 SUBSCRPTION_A.NE_ID.URL=http://www.abc.com SUBSCRIPTION_A.NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION_A.NE_ID.HOST_PASSWORD=<password1> TEMPLATE_ID_B=TEMPLATE_2 SUBSCRPTION_B.NE_ID.URL= http://www.def.com/ SUBSCRIPTION_B.NE_ID.HOST_USERNAME=dmiller SUBSCRIPTION_B.NE_ID.HOST_PASSWORD=<password2> TEMPLATE_ID_C=TEMPLATE_3 SUBSCRPTION_C.NE_ID.URL=http://www.ghi.com SUBSCRIPTION_C.NE_ID.HOST_USERNAME=djones SUBSCRIPTION_C.NE_ID.HOST_PASSWORD=<password3>
Table 7-6 shows the service model configuration parameter mappings.
Table 7-6 Scenario 3 Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
SUBSCRIPTION_A |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID_A |
Compound |
|
A-SERVICE_2 |
COMM_PARM |
SUBSCRIPTION_B |
Compound |
|
A-SERVICE_2 |
MCLI |
TEMPLATE_ID_B |
Compound |
|
A-SERVICE_3 |
COMM_PARM |
SUBSCRIPTION_C |
Compound |
|
A-SERVICE_3 |
MCLI |
TEMPLATE_ID_C |
Compound |
The atomic action parameter MCLI in this case identifies the network template. In static routing, the atomic action parameter MCLI identifies the NE.
This configuration routes each atomic action to a different NE. Table 7-7 shows the downstream program (State Table or JInterpreter class) parameters.
Table 7-7 Scenario 3 Parameters
| Label | Value |
|---|---|
|
A-SERVICE_1 |
- |
|
MCLI |
TEMPLATE_1 |
|
URL |
http://www.abc.com |
|
HOST_USERNAME |
jsmith |
|
HOST_PASSWORD |
<password1> |
|
A-SERVICE_2 |
- |
|
MCLI |
TEMPLATE_2 |
|
URL |
http://www.def.com |
|
HOST_USERNAME |
dmiller |
|
HOST_PASSWORD |
<password2> |
|
A-SERVICE_3 |
- |
|
MCLI |
TEMPLATE_3 |
|
URL |
http://www.ghi.com |
|
HOST_USERNAME |
djones |
|
HOST_PASSWORD |
<password3> |
Figure 7-4 shows a case that differs from the previous scenario in that all of the atomic actions are sent to each NE.
The work order includes the following service action and communication parameters:
C-SERVICE TEMPLATE_ID[1]=<TEMPLATE_1> SUBSCRIPTION[1].NE_ID.URL=http://www.abc.com SUBSCRIPTION[1].NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION[1].NE_ID.HOST_PASSWORD=<password1> TEMPLATE_ID[2]=<TEMPLATE_2> SUBSCRIPTION[2].NE_ID.URL= http://www.def.com/ SUBSCRIPTION[2].NE_ID.HOST_USERNAME=dmiller SUBSCRIPTION[2].NE_ID.HOST_PASSWORD=<password2> TEMPLATE_ID[3]=<TEMPLATE_3> SUBSCRIPTION[3].NE_ID.URL=http://www.ghi.com SUBSCRIPTION[3].NE_ID.HOST_USERNAME=djones SUBSCRIPTION[3].NE_ID.HOST_PASSWORD=<password3>
Table 7-8 shows the service model configuration parameter mappings.
Table 7-8 Scenario 4 Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
SUBSCRIPTION[++] |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID[++] |
Compound |
|
A-SERVICE_2 |
COMM_PARM |
SUBSCRIPTION[++] |
Compound |
|
A-SERVICE_2 |
MCLI |
TEMPLATE_ID[++] |
Compound |
|
A-SERVICE_3 |
COMM_PARM |
SUBSCRIPTION[++] |
Compound |
|
A-SERVICE_3 |
MCLI |
TEMPLATE_ID[++] |
Compound |
This configuration routes each atomic action to each NE. Table 7-9 shows the downstream program (State Table or JInterpreter class) parameters.
Table 7-9 Scenario 4 Parameters
| Iteration | Label | Value |
|---|---|---|
|
A-SERVICE_1 |
||
|
- |
MCLI |
TEMPLATE_1 |
|
1 |
URL |
http://www.abc.com |
|
1 |
HOST_USERNAME |
jsmith |
|
1 |
HOST_PASSWORD |
<password1> |
|
- |
MCLI |
TEMPLATE_2 |
|
2 |
URL |
http://www.def.com |
|
2 |
HOST_USERNAME |
dmiller |
|
2 |
HOST_PASSWORD |
<password2> |
|
- |
MCLI |
TEMPLATE_3 |
|
3 |
URL |
http://www.ghi.com |
|
3 |
HOST_USERNAME |
djones |
|
3 |
HOST_PASSWORD |
<password3> |
Each atomic action is called three times, each time with a different set of communication parameters.
Table 7-9 applies to A-SERVICE_2 and A-SERVICE_3 as well.
Figure 7-5 shows atomic actions that are routed to one or more NEs, and others that are routed to another NE.
The work order includes the following service action and communication parameters:
C-SERVICE TEMPLATE_ID_A[1]=<template_1> SUBSCRIPTION_A[1].NE_ID.URL=http://www.abc.com SUBSCRIPTION_A[1].NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION_A[1].NE_ID.HOST_PASSWORD=<password1> TEMPLATE_ID_A[2]=<template_2> SUBSCRIPTION_A[2].NE_ID.URL=http://www.pqr.com SUBSCRIPTION_A[2].NE_ID.HOST_USERNAME=dabrams SUBSCRIPTION_A[2].NE_ID.HOST_PASSWORD=<password4> TEMPLATE_ID_B[1]=<template_1> SUBSCRIPTION_B[1].NE_ID.URL=http://www.abc.com SUBSCRIPTION_B[1].NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION_B[1].NE_ID.HOST_PASSWORD=<password1> TEMPLATE_ID_B[2]=<template_2> SUBSCRIPTION_B[2].NE_ID.URL=http://www.pqr.com SUBSCRIPTION_B[2].NE_ID.HOST_USERNAME=dabrams SUBSCRIPTION_B[2].NE_ID.HOST_PASSWORD=<password4> TEMPLATE_ID_B[3]=<template_3> SUBSCRIPTION_B[3].NE_ID.URL= http://www.c.com/ SUBSCRIPTION_B[3].NE_ID.HOST_USERNAME=drichler SUBSCRIPTION_B[3].NE_ID.HOST_PASSWORD=<password9> TEMPLATE_ID_C[1]=<template_2> SUBSCRIPTION_C[1].NE_ID.URL=http://www.pqr.com SUBSCRIPTION_C[1].NE_ID.HOST_USERNAME=dabrams SUBSCRIPTION_C[1].NE_ID.HOST_PASSWORD=<password4> TEMPLATE_ID_C[2]=<template_3> SUBSCRIPTION_C[2].NE_ID.URL= http://www.c.com/ SUBSCRIPTION_C[2].NE_ID.HOST_USERNAME=drichler SUBSCRIPTION_C[2].NE_ID.HOST_PASSWORD=<password9>
Table 7-10 shows the service model configuration parameter mappings.
Table 7-10 Scenario 5 Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
SUBSCRIPTION_A[++] |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID_A[++] |
Compound |
|
A-SERVICE_2 |
COMM_PARM |
SUBSCRIPTION_B[++] |
Compound |
|
A-SERVICE_2 |
MCLI |
TEMPLATE_ID_B[++] |
Compound |
|
A-SERVICE_3 |
COMM_PARM |
SUBSCRIPTION_C[++] |
Compound |
|
A-SERVICE_3 |
MCLI |
TEMPLATE_ID_C[++] |
Compound |
This configuration routes atomic action A-SERVICE_1 to NE_1 and NE_2; A-SERVICE_2 to NE_1, NE_2, and NE_3; and A-SERVICE_3 to NE_2 and NE_3. Table 7-11 shows the downstream program (State Table or JInterpreter class) parameters.
Table 7-11 Scenario 5 Parameters
| Iteration | Label | Value |
|---|---|---|
|
A-SERVICE_1 |
- |
- |
|
- |
MCLI |
<template_1> |
|
1 |
URL |
http://www.abc.com |
|
1 |
HOST_USERNAME |
jsmith |
|
1 |
HOST_PASSWORD |
<password1> |
|
MCLI |
<template_2> |
|
|
2 |
URL |
http://www.pqr.com |
|
2 |
HOST_USERNAME |
dabrams |
|
2 |
HOST_PASSWORD |
<password4> |
|
A-SERVICE_2 |
- |
- |
|
- |
MCLI |
<template_1> |
|
1 |
URL |
http://www.abc.com |
|
1 |
HOST_USERNAME |
jsmith |
|
1 |
HOST_PASSWORD |
<password1> |
|
- |
MCLI |
<template_2> |
|
2 |
URL |
http://www.pqr.com |
|
2 |
HOST_USERNAME |
dabrams |
|
2 |
HOST_PASSWORD |
<password4> |
|
3 |
MCLI |
<template_3> |
|
3 |
URL |
http://www.c.com |
|
3 |
HOST_USERNAME |
drichler |
|
3 |
HOST_PASSWORD |
<password9> |
|
A-SERVICE_3 |
- |
- |
|
1 |
MCLI |
<template_2> |
|
1 |
URL |
http://www.pqr.com |
|
1 |
HOST_USERNAME |
dabrams |
|
1 |
HOST_PASSWORD |
<password4> |
|
- |
MCLI |
<template_3> |
|
2 |
URL |
http://www.c.com |
|
2 |
HOST_USERNAME |
drichler |
|
2 |
HOST_PASSWORD |
<password9> |
The following sample shows a common URL that is shared:
Global Parameter
SUBSCRIPTION_A.NE_ID.URL=http://www.abc.com
C-SERVICE
TEMPLATE_ID=<template_1> SUBSCRIPTION_A[1].NE_ID.HOST_USERNAME=jsmith SUBSCRIPTION_A[1].NE_ID.HOST_PASSWORD=<password1> SUBSCRIPTION_A[2].NE_ID.HOST_USERNAME=dabrams SUBSCRIPTION_A[2].NE_ID.HOST_PASSWORD=<password4>
Table 7-12 shows the service model configuration parameter mappings.
Table 7-12 Common URL Parameter Mappings
| asdl_cmd | asdl_lbl | csdl_lbl | param_typ |
|---|---|---|---|
|
A-SERVICE_1 |
COMM_PARM |
SUBSCRIPTION_A[++] |
Compound |
|
A-SERVICE_1 |
MCLI |
TEMPLATE_ID |
Scalar |
Table 7-13 shows the downstream program (State Table or JInterpreter class) parameters.
If the maximum connections limit is reached, an exception is thrown indicating that the atomic action cannot be dispatched because all connections are in use. The atomic action is put in pending queue so that it can be processed when a connection is available.
A routing error (ROUT_ERR) event is logged and the work order fails in the following circumstances:
The network template identifier is not defined on the order, or the identifier does not reference a valid template resource configured in ASAP
The combined total length of all communication labels and values exceeds 2048
When dynamic communication parameters (as provided on an ASAP work order) are invalid (due to an incorrect IP address or port, for instance) the work order is not explicitly failed. Failing an order in this manner is generally reserved for incorrect activation parameters rather than invalid communication parameters. When incorrect communication parameters are detected (by the inability to establish a connection with the NE) the work order is placed in the retry queue. When the error in communication parameters is detected, use Order Control Application (OCA) to stop the order, change the invalid communication parameters and re-submit the order to ASAP.
OCA tracks the revision history of all orders.
Refer to ASAP OCA User Guide for information about OCA.
Parameters defined with the same label as both communication and order parameters will conflict. In order of precedence, order communication parameters override static parameters if they have the same label. Oracle recommends that solutions developers not use conflicting labels for both communication and order parameters.
During provisioning, parameters contained in work orders override work order communication parameters (COMM_PARM), which override static communication parameters contained in tbl_comm_param (see Figure 7-6).
Dynamic routing can be used in conjunction with Multi-Protocol Manager-supported protocols such as telnet, FTP, and socket. These protocols require recognized keywords such as HOST_IPADDR, HOST_NAME and PORT to create a connection. These parameter names must be used to enable the MPM supported protocols.
An atomic action requires the following parameters to be routed using the MPM socket protocol:
COMM_PARM.NE_ID.HOST_IPADDR or COMM_PARM.NE_ID.HOST_NAME
COMM_PARM.NE_ID.PORT
Software load and technology type may be defined statically (tbl_host_clli) or provided by an upstream system as parameters on a work order.
Consequently, each atomic action requires the following reserved communication parameters:
COMM_PARM.NE_ID.SFTWR_LOAD or COMM_PARM.SFTWR_LOAD
COMM_PARM.NE_ID.TECH_TYPE or COMM_PARM.TECH_TYPE
These parameters can be defined dynamically on each order or statically in the network template.
The software load and technology type are established after when the NEP first establishes a connection to the NE. After the connection has been established, all subsequent values of SFTWR_LOAD and TECH_TYPE received from subsequent work orders destined to the same NE instance are ignored. The software load and technology type are reloaded the next time ASAP sets up a session manager, connection pool, and command processors for that NE.
Some of NE configuration parameters (such as max_connections, drop_timeout, spawn_threshold, kill_threshold, and line_type) may be provided by an upstream system as Work Order communication parameters.
The following work order communication parameters can be specified to override the defaults:
COMM_PARM.NE_ID.MAX_CONNECTIONS or COMM_PARM.MAX_CONNECTIONS
COMM_PARM.NE_ID.DROP_TIMEOUT or COMM_PARM.DROP_TIMEOUT
COMM_PARM.NE_ID.SPAWN_THRESHOLD or COMM_PARM.SPAWN_THRESHOLD
COMM_PARM.NE_ID.KILL_THRESHOLD or COMM_PARM.KILL_THRESHOLD
COMM_PARM.NE_ID.LINE_TYPE or COMM_PARM.LINE_TYPE
These parameters are used to initialize the session manager and command processors. After the session is established for the NE, parameters those coming from subsequent work orders to the same NE instance will be ignored until the session manager is cleaned up.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
