Building Your Event-Driven Architecture : Integration Server Administrator’s Guide : Managing Packages : How the Server Stores Package Information
How the Server Stores Package Information
 
Manifest File
The server physically stores package information in the Integration Server_directory \instances\instance_name\packages directory. The server creates a new subdirectory for each package. The name of the subdirectory is the name of the package. For example, if a package is named “TimeCards,” the server creates the Integration Server_directory \instances\instance_name\packages\TimeCards directory to hold the files for the package.
When you create a new package, the server creates the following subdirectories to hold all the files associated with the package:
*The code subdirectory holds the Java and C/C++ services that belong to this package. Within the code subdirectory are the classes, jars, static, source, and lib subdirectories:
*The classes subdirectory is for Java classes for the Java and C/C++ services.
*The jars subdirectory is for Java classes that are packaged together in jar files.
*The static subdirectory is also for Java classes that are packaged together in jar files. Place the jar files in this location when you want to make them available to other packages in the Integration Server and also to packages in other Integration Server systems.
When you place jar files in the static subdirectory, then at startup the Integration Server automatically loads these files to the server classpath. Also, the jar files are available to other packages even when the immediate package is disabled.
Note:  
The Integration Server does not automatically create the static subdirectory when you create a new package. This subdirectory is user defined.
*The source subdirectory is for the source of Java services.
*The libs subdirectory (not shown here) holds DLLs or specialized libraries that the Java and C/C++ services use.
Note:  
The Integration Server does not automatically create the libs directory because the directory's existence prevents you from reloading a package without restarting the server. You cannot reload a package that uses shared libraries; you must restart the server.
For ease of administration, place services that use shared libraries in the same package.
*The config subdirectory might hold following files:
*listeners.cnf. This file contains information about what ports you have defined for the package and what services you can access through each port. For more information about configuring ports and allowing access to services through a port, see Configuring Ports.
*urlalias.cnf. This file contains definitions for HTTP URL aliases associated with services in the package. If there are no aliases, the file does not exist. Do not manually update a urlalias.cnf file. For more information about HTTP URL aliases, see Setting Up HTTP URL Aliases.
*The ns subdirectory holds flow services, specifications, document types, schemas, triggers, adapter notifications, adapter documents, adapter services, adapter connectors, and code fragments for Java services.
*The pub subdirectory holds web documents for the package. For instructions on how to access the web documents for a package, see Displaying Documentation for a Package.
*The doc subdirectory holds documentation for the package.
*The resources subdirectory holds resource bundles <bundle.properties>, such as application data (not user data), which is kept separate from the Integration Server application. The following items represent typical resources inside a bundle:
*Icons
*Window positions
*Dialog box definitions
*Program text
*Menus
You can easily modify and update various aspects of the Integration Server without reinstalling the entire application. A Japanese language pack for the Integration Server is an example of a resource bundle that contains language and image files for the Japanese version of the server.
*The templates subdirectory holds output templates that are associated with this package.
*The web subdirectory holds JSPs that are associated with this package.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback