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.

You can 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 alternatively use Design Studio to create and deploy network templates. For more information about using Design Studio to configure dynamic routing, see the Design Studio Modeling Activation Help.

If you are going to use SACT, 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, where 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.

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.

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 (JInterpreter class) parameters:

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.

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 (JInterpreter class) parameters.

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.

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 (JInterpreter class) parameters.

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.

This configuration routes each atomic action to each NE. Table 7-9 shows the downstream program (JInterpreter class) parameters.

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.

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-13 shows the downstream program (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 removed from memory (when the primary connection to the NE is closed).