Oracle® Communications ASAP Server Configuration Guide
Release 7.2
E24629-01
  Go To Table Of Contents
Contents
Previous
Previous 		 Next
Next		  

2 Configuring ASAP Servers

This chapter provides information about configuring Oracle Communications ASAP servers using the Service Activation Configuration Tool (SACT).

About the Service Activation Configuration Tool

The SACT provides a way of adding, deleting, and modifying ASAP servers and ASAP server parameters, including:


Note:

The SACT does not configure system events and alarms. For information on configuring system events and alarms, see ASAP System Administrator's Guide.

Reference information about the Java NEP (JNEP), the Java SRP (JSRP), and Java Management Extensions (JMX) can be found in ASAP Online Reference.

The SACT uses XML server configuration files to configure ASAP, and has several advantages over the use of stored procedures or scripts. By using the SACT to load XML server configuration files, you are insulated from the internal structure of ASAP, including database languages, such as Oracle syntax. Moreover, you can reuse an XML configuration file for similar configurations and use version control for the file.

The SACT supports server side configuration activities, and the Service Activation Deployment Tool (SADT) supports ASAP cartridge or individual XML service configuration file deployment. For more information about SADT, see ASAP Cartridge Development Guide.

To work with the SACT, Oracle recommends that you have experience with:

About Service Activation Configuration Tool Resource Definitions

Figure 2-1 shows how the SACT and the SADT deploy an XML file or service activation model archive (SAR) file through a JMX management interface located in the ASAP WebLogic server instance when you first install ASAP. You can use the SADT or Oracle Communications Design Studio to deploy a cartridge into ASAP.

Figure 2-1 XML Deployment


Before the SACT can process an XML file and configure ASAP server resources through the JMX interface, the XML file must conform to the resource definitions defined in the ASAP_Home/xml/xsd/ActivationConfig.xsd schema file. You can view a sample XML configuration file that conforms to this schema in the ASAP_Home/sample/sadt/SampleCommonConfig.xml file.


Note:

Schema validation for XML data processed by the SACT and the SADT is turned off by default.

You can use the SACT to:

About Using the Service Activation Schema to Write an XML File

Figure 2-2 shows the ActivationConfig.xsd schema elements. Each element corresponds to configurable ASAP server or server parameter schema definitions which your XML server configuration file must conform to.

Figure 2-2 ActivationConfig.xsd Schema Elements


The ASAP installer creates some of the elements listed in Figure 2-2 during the installation process. For example, ASAP supports one Service Activation Request Manager (SARM), Admin, JSRP, and Order Control Application (OCA) server. You do not need to add or delete these resources using SACT.

You can use the SACT to add configuration parameters to the servers that the ASAP installer creates. Some elements you may need to add include:

When authoring an XML configuration file consisting of several elements, observe the order in which elements are listed in the schema. For example, if defining an NEP server and a resource pool (connectionPool) in an XML configuration file, ensure that the NEP server definition is located before the resource pool definition since the ActivationConfig.xsd schema requires this order.

Oracle recommends that you use an XML editor to create an XML document, as XML editing tools usually have validators that ensure that the XML document is valid.

The schema contains base types and extensions for a given entity. For an NEP, for example, the XML schema identifies:

  • The base type and serverType, which contains the most common entries: description, system, territory, diagnosticFilename, diagnosticLevel.

  • ControlManagedServerType, an extension of the base serverType, which adds the autoStart flag, control server name, and interface information on top of the serverType.

  • NEPServerType, an extension of ControlManagedServerType, which contains the elements secondaryPool and jinterpreterPort.

Figure 2-3 shows the structure that has to be observed when authoring an NEP configuration file. The XML configuration file must observe the order in which the elements appear in the schema.

Figure 2-3 NEPServerType Schema


The following is an excerpt from the ControlManagedServerType in the schema.

<xs:complexType name="ControlManagedServerType">
        <xs:complexContent>
                 <xs:extension base="mslv-ac:ServerType">
                         <xs:sequence>
                                  <xs:element name="autoStart" type="xs:boolean" default="true" minOccurs="0">
                                         <xs:annotation>
                                                 <xs:documentation>Flag for indicating if the Control server should auto start this server.</xs:documentation>
                                         </xs:annotation>
                                  </xs:element>
                                  <xs:element name="controlServer" type="mslv-ac:ServerNameType">
                                         <xs:annotation>
<xs:documentation>The name of the logical ASAP application Control server which spawns the application and monitors its behavior, for example, CONTROL. In a distributed ASAP configuration, there must be a Control server defined on each machine in the distributed environment. In each ASAP configuration there is only one master Control server.</xs:documentation>
                                         </xs:annotation>
                                  </xs:element>
                                  <xs:element name="interfaceHostname" type="mslv-ac:HostType" minOccurs="0">
                                         <xs:annotation>
                                                 <xs:documentation>The interface hostname for this server. Can be in the form of a string hostname or IP address.</xs:documentation>
                                         </xs:annotation>
                                  </xs:element>
                                  <xs:element name="interfacePort" type="mslv-ac:PortNumberType">
                                         <xs:annotation>
                                                 <xs:documentation>The interface port for this server.</xs:documentation>
                                         </xs:annotation>
                                  </xs:element>
                         </xs:sequence>
                         <xs:attribute name="defaultControlServer" type="mslv-ac:ServerNameType"/>
                         <xs:attribute name="defaultInterfacePort" type="mslv-ac:PortNumberType"/>
                         <xs:attribute name="defaultInterfaceHostname" type="xs:string"/>
                 </xs:extension>
        </xs:complexContent>
</xs:complexType>

About Configuring an XML Configuration File to Prompt for Values

You can write the XML configuration file in such a way that it prompts the user for values.

This feature is useful if you are a cartridge developer who creates productized cartridges for deployment in customer sites. ASAP cartridges can contain XML server configuraiton files that require ASAP server specific information. Using the prompting feature, you can write an installation program that enables the customer to populate ASAP server related values (for example, ASAP server IP addresses and resource pools). For more information about adding XML server configuration files to an ASAP cartridge, see ASAP Cartridge Development Guide.

Prompts are delimited in the XML file with the character %. For example:

<communicationParameter>
       <label>IP_ADDRESS</label>
              <value defaultValue="localhost">
                   <value>%NAME</value>
              </value>
              <description>String</description>
              <deviceName>DEV_1</deviceName>
</communicationParameter>

For every parameter delimited with % (NAME in the above example) the command-line client displays a prompt to request a value from the user. This prompt displays the default value <value defaultValue="localhost"> and a description of the parameter in <description> element. The value the user enters at the prompt is used in the configuration file.

About Configuring an XML File to Replace Values with Environment Variables

You can author the XML file so that, on deployment, all values that are delimited with the character “$” are replaced with the environment variable of the same name. If the environment variable is not defined, the default value is used. This feature can save time when the ASAP server environment variables have already been defined in the ASAP_Home/Environment_Profile.

<communicationParameter>
       <label>NMTOKEN</label>
       <value defaultValue="SARM Name">
              <value>$SARM</value>
       </value>
       <description>String</description>
       <deviceName>NMTOKEN</deviceName>
</communicationParameter>
<communicationParameter>
       <label>NMTOKEN</label>
       <value>
              <value>$SYSTEM</value>
       </value>
       <description>String</description>
       <deviceName>NMTOKEN</deviceName>
</communicationParameter>

In the previous example, if the $SARM and $SYSTEM environment variables are not defined, the default Value in the XML server configuration file is used.

About the Service Activation Configuration Tool

There are three SACT scripts, and they perform the following functions:

These scripts use the ASAP_Home/scripts/asapConfig command to perform their functions. This command deploys one or more XML files. The XML files can be individual, or they can be bundled in a SAR file. asapConfig searches the SAR file for an XML deployment descriptor that describes how each XML component needs to be deployed, and for any SarPatch_configure and SarPatch_unconfigure files.


Note:

SarPatch_configure and SarPatch_unconfigure are used by the SACT and contain ASAP server configuration information. These files should be distinguished from SarPatch and SarPatch_undeployed, used by SADT. For more information about SarPatch and SarPatch_undeploy, see ASAP Cartridge Development Guide.

The asapConfig command uses the following syntax.

asapConfig -Dwlurl=WL_URL -Dwlusr=WL_user_name -Dwlpwd=WL_user_passwd  [-DENV_ID=ENV_ID] [replace][silent] command cfg_file

Where:


Note:

Oraclerecommends that you restart ASAP after adding or changing configuration information with the SACT.

The SACT scripts simplify the use of the asapConfig command.

Configuring the SACT Scripts and UNIX Environment Variables

Before you can use the SACT scripts for the first time, you must configure the $CLASSPATH and $PATH UNIX environment variables and edit the SACT scripts so that they include the ASAP WebLogic server host name and port number.

To configure the SACT scripts:

  1. Log on to a UNIX terminal.

  2. Verify that the following JAR files are located in the $CLASSPATH of your UNIX environment:

    • xmlparserv2.jar

    • ant.jar

    • weblogic.jar

    • asaplibcommon.jar

    For example, use the echo command to verify that the JAR files are contains in the $CLASSPATH.

    echo $CLASSPATH

  3. Verify that the ASAP_Home/scripts/asapConfig script and ant are in the $PATH of you UNIX environment:

    echo $PATH

  4. Edit the SACT script you want to use and replace the variables indicated within the text of the script (Dwlurl requires the WebLogic host name and port number).

    For example:

    errorStrLen=30
wluser=system
wlpass="`$ASAP_BASE/scripts/GetCSFPassword $wluser`"
 
if [[ "$wlpass" = *notFound* ]] && [ ${#wlpass} -gt $errorStrLen ]; then
  echo "Invalid username!"
else
  asapConfig -Dwlurl=myhost:3456 -Dwlusr=$wluser -Dwlpwd=$wlpass -DENV_ID=$ENV_ID replace configure $1
fi

  5. Remove the comments and save the script.

  6. Repeat this procedure for the other SACT scripts.

Running the SACT Scripts

Use the following procedure to run sactConfig, sactUnconfig, and sactConfigNR.

  1. Ensure that your ASAP WebLogic server instance is running.

  2. Source the ASAP_home/Environment_Profile:

    . ./Environment_Profile

  3. Start ASAP if it is not already running.

    start_asap_sys

  4. Go to the location of the XML file you created that conforms to the ActivationConfig.xsd schema (see "About Using the Service Activation Schema to Write an XML File").

  5. Run one of the SACT scripts (sactConfig, sactUnconfig, or sactConfigNR).

    For example:

    sactConfig adding_one_nep.xml

  6. Stop and restart ASAP.

    For example:

    stop_asap_sys
start_asap_sys

  7. Verify that the changes you made took effect.

    For example:

    • If you added or deleted a server, use the status command to verify that the server was added or deleted.

    • If you added a configuration parameter, check the ASAP.cfg file to make sure it was added.

Transforming ASAP Database Configurations or Service Models into XML

The DB to SACT XML Transformation Tool enables you to convert database entries to an XML file that complies to the ASAP ActivationConfig schema. This tool has been designed for ASAP users who created their server configuration using stored procedures and want to start using XML configuration files for this purpose.

The transformation tool translates data from the following tables in the CONTROL and SARM databases:


Note:

The DB to SACT XML Transformation Tool does not display ASAP.cfg attributes.

To start the transformation tool, enterthe following command:

export_tool.sh [-m [-p ctrl_pswd]] -t config [out_xml_1 [out_xml_2]] [-h]

where:

The database information should be specified in two style sheet files, dbinfo_ctrl.xsl and dbinfo_sarm.xsl, which are imported by the DumpDB_config.xsl style sheet. These style sheet files are in the ASAP_home/xml/xslt directory. These two style sheets represent the two databases: CONTROL (which contains server data) and SARM (which contains network data).

DumpDB_config.xsl selects all entries in the listed tables and generates an internally formatted XML document. Then, the tool applies the style sheet Formalize_config.xsl to the raw XML file so that it conforms to the resource configuration schema.

  Previous
Previous 		 Next
Next
  Go To Table Of Contents
Contents