You can archive the directory using the assembly tool. The assembly tool:

• Validates the directory structure

• Ensures that an activation-model.xml file and at least one service model XML file exist

• Validates the activation-model.xml file and all service model xml files against their respective schemas. This validation is performed using the Oracle9_0_2_0_0D XML parsers.

• Picks up the activation model ID from the activation-model.xml file

You can also archive the directory using the jar command. Components other than service model components can be packaged in an archive file; for example, Design guidelines, API documentation, and source files.

After all validation is successfully completed, the assembly tool assembles the components to generate an archive file with a base file name that is the same as the ID, and supplies the sar extension. The assembly tool accepts the directory where the SAR file is to be placed as a parameter.

To run the assembly tool, enter the following command:

CreateSar [-help] [-v] <sar_file_dir>

The current directory must be the base from which the SAR file is made and it is the parent directory of the <vendor> directory. The <sar_file_dir> specifies where you want to put the SAR file you have created. The -v parameter enables directory structure validation. If you omit this parameter, no directory structure validation is performed. The SAR file name is generated based on the name in activation-model.xml.

The SADT deploys the SAR file. The SADT has three interfaces:

• Using the SADT Command Line Interface

• Using the SADT Web Interface

• Using the SADT JMX Interface

You can use the SADT to assemble and deploy generic service models and cartridge-specific service models.

When an ASAP server such as a SARM or NEP is initialized, configuration data groups are loaded from the database into memory. These configuration data groups are:

• ASAP service definitions – Includes all service-action and atomic-action related configurations.

• ASAP network interface configurations – Includes hosts, NE resources.

In some cases, configuration data can be loaded into memory after initialization (namely, NE communication parameters). For all other new service definitions or network interface configurations to take effect, you must do one of the following:

• Restart the SARM and NEP

• Dynamically add service definitions using asap_utils

For more information on asap_utils, see ASAP Server Configuration Guide

With asap_utils, you can dynamically add new items to the configuration without having to restart the ASAP servers. You can dynamically add service actions, atomic actions, mapping configuration, NEPs, hosts, routing, and NE resources by:

• Updating the ASAP databases through asap_utils

• Synchronizing the ASAP servers with the databases

  Note:

  Only new configuration entries are added to the in-memory caches. Any updates and deletions of existing entries are ignored by the update procedure. These still require a restart of the affected ASAP servers.

To dynamically configure service actions, atomic actions, mapping configuration, or NEPs, you must set up the ASAP system and its components as follows.

1. Make the configuration addition in the ASAP database manually by scripting (SQL inserts). You can add the configuration entries in Table 14-3 dynamically to ASAP. All other changes are ignored by the sychronization process.

   Table 16-3 Configuration Entries and Synchronization

   Configuration Entry	Description	Synchronization Details
   Service Definition	Service actions, atomic actions, service-action-TO-atomic mappings and service action-to-atomic action parameters.	Internal cache update with new entries in SARM and NEP servers.
   Network Element Definition	NE definitions and associated NE connection properties, including primary and secondary devices, and host-to-remote NE mappings.	Internal cache and thread updates in SARM (atomic action queues) and NEP (session managers, command processors) application servers.
   NEP	Entirely new NEP added to ASAP.	Internal cache and thread updates in SARM (NEP drivers, atomic action queues).
   Secondary NE Devices	Communication devices in the auxiliary resource pool in existing NEPs.	Internal cache and thread updates in NEP (command processors).

   Note:

   A service definition consists of a service action and all its associated atomic actions and parameters. Adding a new atomic action to an existing service action or adding a new service action to an existing atomic action is considered a change to the service definition. The SARM server must be restarted before the new service definition takes effect.

2. You can request the SARM and NEP servers to refresh the configuration in memory through the command options available in asap_utils. There are two commands in the asap_utils client application for the addition of new configuration entries. You use these commands to request that the ASAP servers synchronize the in-memory configuration with the configuration of the databases. You are responsible for ensuring that the database configurations have been applied (for example, through database insert scripts).

   By sending RPCs to notify ASAP servers of the additional configuration entries, a synchronization process is performed in each of the ASAP servers to update the in-memory caches with the latest data of the configurations in the database. The synchronization reloads the relevant configuration information from the database into the memory. With the synchronization, you can add new service actions, atomic actions, mapping configurations, NEPs, host NEs, NE routings, and NE resources dynamically.

   Note:

   You can only dynamically add new items, you cannot modify or delete new configurations.

   In asap_utils, the command choices for the newly added configuration are:

   • 112. Load New Service Configuration into Cache

   • 113. Load New NE Configuration into Cache

   You are asked to provide the SARM and NEP names to which the updates apply. The defaults are the $SARM and $NEP environment variables. If multiple NEPs are to be updated, you can enter a list of NEP server names and the utility issues the appropriate request to each listed NEP. You are notified whether each RPC was successful or not. In all cases, the NEP update requests are issued.

3. After receiving the synchronization RPC, the ASAP server works with a specific handler to reload the relevant configuration data from the ASAP database into memory. The RPC returns a status to the client application, indicating whether reloading was successful or not.

4. The synchronization sequence is the reverse of the normal processing flow; in other words, the NEP is synchronized first, then the SARM.

You must ensure that the time interval between the database modification and the memory flush is as short as possible.