About Package Dependencies
A package can be identified as dependent on another package if it references or uses assets from that package. For example, if a service in package A invokes a service in package B, package A is dependent on package B and a package dependency should be identified. Establishing a dependency ensures that packages cannot be active until all dependencies are met. Additionally, in hot deployment, Integration Server uses package dependencies to wait for requests to complete before starting the deployment and to block new requests for services in the deployed package as well as dependent packages.
Situations in which you must set up package dependencies include:
An asset in the package uses an asset in another package, such as a service invoking a service in a different package or a service using a a document type from a different package as the input or output signature.
If a package needs elements from another package to load before it can load. For example, you must identify package dependencies if a startup service invokes a service in another package. The startup service cannot execute if the package containing the invoked service has not yet loaded.
If Java services in a package need to access Java classes contained in another package.
If a package contains a type of namespace element that is registered in
Designer via a package.
webMethods components might include packages that register new types of elements in
Designer. Save instances of these element types in packages that list the registering package as a package dependency. The registering package needs to load before your packages so that
Designer can recognize instances of the new element type.
For example, the WmFlatFile package registers flat file schemas and flat file dictionaries namespace elements and the WmGRPC package registers gRPC provider descriptors. If you create new flat file schemas, you must save the flat file schemas in packages that identify the WmFlatFile package as a package dependency. When you create a gRPC provider descriptor, Designer automatically establishes a package dependency on the WmGRPC package for the package containing the descriptor.
When a package reloads or is replaced, Integration Server reloads all the packages that have established a dependency on the package being reloaded or replaced. Reloading dependent packages refreshes any cached assets. During hot deployment, reloading dependents can cause service requests to timeout - especially if package dependencies are complex. In some cases, such as when there are no shared cached assets among the packages, reloading dependent packages does not provide any benefit. Preventing dependent packages from reloading may provide a performance improvement. Designer provides an option in the package properties to skip package reloading when the package on which it depends is reloaded or replaced.
Related Topics