9-10 Integration Server Administrators Guide

(1)

Version 9.10

April 2016

(2)

its aﬃliates and/or their licensors.

The name Software AG and all Software AG product names are either trademarks or registered trademarks of Software AG and/or Software AG USA Inc. and/or its subsidiaries and/or its aﬃliates and/or their licensors. Other company and product names mentioned herein may be trademarks of their respective owners.

Detailed information on trademarks and patents owned by Software AG and/or its subsidiaries is located at hp://softwareag.com/licenses.

Use of this software is subject to adherence to Software AG's licensing conditions and terms. These terms are part of the product documentation, located at hp://softwareag.com/licenses and/or in the root installation directory of the licensed product(s). This software may include portions of third-party products. For third-party copyright notices, license terms, additional rights or restrictions, please refer to "License Texts, Copyright Notices and Disclaimers of Third Party Products". For certain speciﬁc third-party license restrictions, please refer to section E of the Legal Notices available under "License Terms and Conditions for Use of Software AG

(3)

Configuring Integration Server to Enable JMS Triggers Automatically after a Consumer Error...785 Controlling Thread Usage for JMS Triggers...785 Viewing Thread Usage for JMS Triggers...785 Throttling Thread Usage for JMS Triggers...786 Establishing a Threshold for Using Multiple Threads with a Concurrent JMS Trigger... 787 Configuring Integration Server Session Reuse... 788 Configuring JMS Session Reuse...789 Delaying Polling Requests for Concurrent JMS Triggers...789 How JMS Trigger Delays a Polling Request...790 Examples of Extended Polling Delay Configuration...792 About WS Endpoint Triggers...792 Editing WS Endpoint Triggers... 793

Using a Document History Database with Exactly-Once Processing... 797

Overview... 798 Removing Expired Entries from the Document History Database...798 Clearing Expired Entries from the Document History Database... 798 Viewing Exactly-Once Processing Statistics... 799 Clearing Exactly-Once Processing Statistics...799

Using Integration Server to Manage XA Transactions...801

Overview of XA Transaction Management...802 How the Integration Server Persists the State of a Transaction... 802 How the Integration Server Resolves Uncompleted Transactions... 803 About Unresolved XA Transactions... 804 Details for an Unresolved XA Transaction...806 Configuring XA Options in Integration Server... 807 Enabling or Disabling XA Transaction Recovery... 808 Configuring the XA Recovery Store...808 Configuring XA Server Parameters...809 Manually Resolving a Transaction...810

Content Handlers...813

How the Server Uses Content Handlers...814 How the Server Chooses a Content Handler for an HTTP Request...814 How the Server Chooses a Content Handler for an FTP Request... 814 Content Handlers for HTTP and FTP Requests... 814 About Content Handlers for HTTP Responses... 819 Accept Header Field...819 About Content Handlers for FTP Responses...820

Quiescing the Server for Maintenance...821

Overview... 822 What Happens when Integration Server Enters Quiesce Mode?...822

(23)

What Happens when Integration Server Exits Quiesce Mode?... 824 Specifying the Quiesce Port...825 Quiescing Integration Server...825 Starting the Server in Quiesce Mode from the Command Prompt...826 Quiescing an Active Server from Integration Server Administrator...827 Restarting a Server in Quiesce Mode from Integration Server Administrator...828 Exiting Quiesce Mode...829 Deploying Quiesce Mode Configuration...829

Diagnosing the Integration Server...831

Introduction... 832 Configuring the Diagnostic Port...832 Diagnostic Thread Pool Configuration...832 Diagnostic Port Access... 833 Using the Diagnostic Utility... 833 Diagnostic Utility Performance... 834 Running the Diagnostic Utility from Integration Server Administrator...834 Running the Diagnostic Utility Service...835 Starting the Integration Server in Safe Mode...836 Starting Integration Server in Safe Mode...836 When the Server Automatically Places You in Safe Mode...837 Generating Thread Dumps...838 Generating a Dump of an Individual Thread...839 Generating a Dump of the JVM...840

Integration Server Deployment Checklist... 841

Introduction... 842 Stage 1: Installation...842 Stage 2: Basic Configuration...843 Stage 3: Setting Up Users, Groups, and ACLs...844 Stage 4: Publishing Packages...845 Stage 5: Installing Run-Time Classes...846 Stage 6: Preparing Clients for Communication with the Server...847 Stage 7: Setting Up Security...847 Stage 8: Startup and Test... 849 Stage 9: Archive Sources...850

(24)

watt.debug...860 watt.debug2...862 watt.infradc...862 watt.net...863 watt.security...874 watt.server...879 watt.ssl... 973 watt.ssh...974 watt.wm.tnextdc... 975 watt.tx...975 watt.xslt... 976 FIPS 140-2 Compliance... 979 FIPS 140-2 Compliance... 980

Using NTLM Authentication and Integrated Windows Authentication with Integration

Server... 981

Overview... 982 Using NTLM Authentication when Integration Server Acts as the Client... 982 Working with Integrated Windows Authentication... 982 Activating and Deactivating Integrated Windows Authentication...983 Activating Integrated Windows Authentication... 983 Deactivating Integrated Windows Authentication...984

Wireless Communication with the Integration Server... 985

Overview... 986 How Does the Integration Server Communicate with Wireless Devices?... 986 Using URLs for Wireless Access to the Integration Server...988 Invoking a Service with a URL...988 Requesting a WML or HDML Page with a URL... 989 WML and HDML Samples...990

Debugging Service Exceptions Using the Error Log...993

Introduction... 994 Controlling the Level of Exception Logging Detail... 994 Displaying the Error Log...994 Interpreting the Error Log...995 Understanding the Service Stack...995 Understanding the Error Messages... 997 Understanding the Stack Trace...997

Server Log Facilities...999

About Server Log Facilities... 1000 Integration Server... 1000 WmMobileSupport Package... 1007

(25)

Mediator... 1008

(26)

(27)

About this Guide

This guide is for the administrator of a webMethods Integration Server. It provides an overview of how the server operates and explains common administrative tasks such as starting and stopping the server, conﬁguring the server, seing up user accounts and security, and managing packages and services.

Note: This guide describes features and functionality that may or may not be available with your licensed version of webMethods Integration Server. For information about the licensed components for your installation, see the

Settings > License page in the Integration Server Administrator.

Document Conventions

Convention Description

Bold Identiﬁes elements on a screen.

Narrowfont Identiﬁes storage locations for services on webMethods

Integration Server, using the convention folder.subfolder:service .

UPPERCASE Identiﬁes keyboard keys. Keys you must press simultaneously

are joined with a plus sign (+).

Italic Identifies variables for which you must supply values specific to your own situation or environment. Identifies new terms the first time they occur in the text.

Monospace

(28)

Convention Description

[ ] Indicates one or more options. Type only the information inside

the square brackets. Do not type the [ ] symbols.

... Indicates that you can type multiple options of the same type.

Type only the information. Do not type the ellipsis (...).

Online Information

Software AG Documentation Website

You can ﬁnd documentation on the Software AG Documentation website at hp://

documentation.softwareag.com. The site requires Empower credentials. If you do not have Empower credentials, you must use the TECHcommunity website.

Software AG Empower Product Support Website

You can ﬁnd product information on the Software AG Empower Product Support

website at hps://empower.softwareag.com.

To submit feature/enhancement requests, get information about product availability,

and download products, go to Products.

To get information about ﬁxes and to read early warnings, technical papers, and

knowledge base articles, go to the Knowledge Center.

Software AG TECHcommunity

You can ﬁnd documentation and other technical information on the Software AG

TECHcommunity website at hp://techcommunity.softwareag.com. You can:

Access product documentation, if you have TECHcommunity credentials. If you do not, you will need to register and specify "Documentation" as an area of interest. Access articles, code samples, demos, and tutorials.

Use the online discussion forums, moderated by Software AG professionals, to ask questions, discuss best practices, and learn how other customers are using Software AG technology.

(29)

The Role of the Administrator

1

The Role of the Administrator

■ What Does an Administrator Do? ... 30 ■ Typical Administrative Responsibilities ... 30 ■ The Integration Server Administrator ... 31 ■ Receiving Administrative Messages from the Server ... 31 ■ The Administrator User ... 31 ■ Adding Backup Administrators ... 32

(30)

What Does an Administrator Do?

In an IS environment, the administrator is responsible for installing, conﬁguring, and maintaining the webMethods Integration Server. He or she is also responsible for ensuring the server is secure, available to clients, and running at peak performance. Usually, one person is appointed as the administrator, although most sites identify at least one other person to act as a backup.

Typical Administrative Responsibilities

If you are the webMethodsIntegration Server administrator for your site, you might be involved in some or all of the following activities.

Installing and upgrading the server, which includes tasks such as equipping the server

computer with appropriate hardware and software, downloading and installing the server program, and implementing upgrades as needed.

Starting and stopping the server, which includes shuing down the server when

necessary (e.g., for routine maintenance or reconﬁguration) and restarting it afterwards. It also includes performing your site's standard recovery procedures following a hardware or software failure of the server computer. For information about these activities, see "Starting and Stopping the Server" on page 53.

Configuring server settings, which includes seing basic operating parameters such as

the maximum session limits, log ﬁle options, and port assignments. For information about these activities, see "Conﬁguring the Server" on page 107.

Administering users and groups, which includes deﬁning user names and passwords for

authorized users and assigning them to groups. For information about this task, see

"Managing Users and Groups" on page 89. Alternatively, you can conﬁgure the server to acquire user and group information from an external system (e.g., LDAP). For more information, see "Conﬁguring a Central User Directory or LDAP" on page 559.

Administering server security, which includes identifying other administrators,

assigning access controls to individual services, and conﬁguring the server's use of digital certiﬁcates. For more information about this task, see "Customizing Authentication Using JAAS" on page 461, "Securing Communications with the Server" on page 401, "Customizing Authentication Using JAAS" on page 461, and "Securing Communications with the Server" on page 401.

Managing packages and services, which includes tasks such as activating/deactivating/

copying packages and updating services and/or packages as necessary. For more information about this task, see "Managing Packages" on page 579 and "Managing Services" on page 631.

(31)

same machine. For more information about running multiple instances of Integration Server on the same machine, see "Running Multiple Integration Server Instances" on page 73.

The Integration Server Administrator

The Integration Server Administrator is the utility you use to accomplish administrative tasks. You use it to monitor server activity, examine log information, add users, enable/ disable services, and adjust the server's performance features. For information about the Integration Server Administrator, see "Using the Integration Server Administrator " on page 83.

Receiving Administrative Messages from the Server

The Integration Server issues e-mail messages for a variety of failure conditions (for example, internal errors, binding errors, and transaction manager errors). As an

administrator, you are the one who should receive these messages and take appropriate action when errors occur.

To ensure that you (or an appropriate alternate) receive messages from the server, you must set the E-mail Notification parameters using the Integration Server Administrator as

described in "Specifying an E-Mail Address and SMTP Server for Error Messages" on page 676.

The Administrator User

Every Integration Server is installed with a predeﬁned user account called

"Administrator." By default, this user is the only one who can perform administrative tasks with the Integration Server Administrator.

The Administrator's Password

(32)

Important: Change the predeﬁned passwords for the Developer and Replicator accounts

as well. The predeﬁned password for the Developer account is "isdev". The predeﬁned password for the Replicator account is "iscopy."

For instructions on changing a password, see "Adding an Administrator User" on page 94.

Adding Backup Administrators

It is a good idea to designate at least one individual as a "backup administrator," who can administer the Integration Server when you are not available.

To add a backup administrator to your server, create a regular user account for the user (if he or she does not already have one); then add that user account to the "Administrators" group.

Only members of the "Administrators" group can use the Integration Server Administrator. For information about creating user accounts and adding them to groups, see "Managing Users and Groups" on page 89.

Note: If you use an external directory for user and group information, see "About Granting Administrator Privileges to External Users" on page 573 for information about adding administrators.

(33)

An Overview of the Server

2

An Overview of the Server

■ The Role of the Server ... 34 ■ Architecture ... 35 ■ How the Server Executes Services ... 39 ■ How the Server Loads Java Classes ... 40 ■ Integration Server Security ... 50 ■ Logging ... 51 ■ Caching ... 51

(34)

The Role of the Server

The webMethods Integration Server hosts packages that contain services and related ﬁles. The Integration Server comes with core Integration Server packages. For example, all Integration Server instances include packages that contain built-in services that your developers might want to invoke from their services or client applications and services that demonstrate some of the features of the Integration Server. You can create additional packages to hold the services that your developers create. Your developers can create services that perform functions, such as integrating your business systems with those of your partners, retrieving data from legacy systems, and accessing and updating databases.

webMethods Integration Server provides an environment for the orderly, eﬃcient, and secure execution of services. It decodes client requests, identiﬁes the requested services, invokes the services, passes data to them in the expected format, encodes the output produced by the services, and returns output to the clients.

Additionally, the server authenticates clients, veriﬁes that they are authorized to execute the requested service, maintains audit-trail logs, and promotes throughput using

facilities such as service result caching.

About Integration Server Instances

webMethods Integration Server allows you to create and run multiple instances of the server on one machine. When you install webMethods Integration Server, you specify a name for the initial instance. The default name of the initial instance is “default”. The Software AG installer creates the instance under the

Software AG_directory\IntegrationServer\instances directory. You can create additional

instances of Integration Server using the scripts provided by Integration Server or through Software AG Command Central.

Each instance has a home directory under Software AG_directory\IntegrationServer \instances that contains its own packages, configuration files, log files, and updates. You administer and apply packages and updates to each Integration Server instance separately. You can apply the latest fixes using the Software AG Update Manager. The Software AG_directory\IntegrationServer directory is the parent directory for all server instances you create. It contains common and shared files that all server instances use, such as common jar files and fixes. For information about creating and running multiple Integration Server instances, see "Running Multiple Integration Server Instances" on page 73.

Note: Unless otherwise speciﬁed, the terms Integration Server and “the server” in this guide refer to an Integration Server instance.

(35)

Architecture

The Integration Server listens for client requests on one or more ports. You can associate the type of protocol that the server uses for each port. The server supports HTTP, HTTPS, FTP, FTPS, and e-mail ports.

Most clients use an HTTP or HTTPS port for communication with the server. Because the server supports both HTTP and HTTPS, it can listen on an HTTP port for non-secure client requests and an HTTPS port for secure requests.

Note: Unlike HTTP, FTP, and e-mail, HTTPS and FTPS provide for secure data transmission. They do this through encryption and certiﬁcates. Without HTTPS or FTPS, unauthorized users might be able to capture or modify data, use IP spooﬁng to aack servers, access unauthorized services, or capture passwords. If you must pass passwords, make sure the back-end application has minimal privileges.

A typical use for an FTP or FTPS port is to get a directory listing, change to the directory that contains the service you want to invoke, put a ﬁle that contains input to the service, and run the service. The server returns the output from the service to the directory in which the service resides. Use an e-mail port to receive requests through an e-mail server, such as POP3 or IMAP.

You can deﬁne as many ports as you want on each Integration Server instance. The default sever instance has an HTTP port at 5555.

Note: The default server instance also deﬁnes a diagnostic port at 9999. The diagnostic port uses the HTTP protocol and provides you access to the Integration Server when it is unresponsive. For more information about the diagnostic port, see "Diagnosing the Integration Server " on page 831.

(36)

The Server Listens for Requests on Ports that You Specify

There may be times when you want to use the standard port numbers used by web servers: port 80 for HTTP requests and port 443 for HTTPS requests. If your Integration Server runs on a Windows system, this is not a problem. However, if your Integration Server runs on a UNIX system, using a port number below 1024 requires that the server run as "root." For security reasons, Software AG discourages this practice. Instead, run your Integration Server using an unprivileged user ID on a high number port (for example 1024 or above) and use the port remapping capabilities present in most ﬁrewalls to move requests to the higher numbered ports.

(37)

Services

Client requests involve executing one or more services. The server maintains successfully loaded services as runnable objects within the server's program space. When you initialize the server, the server loads the services that are contained in enabled packages into memory. When you or another administrator enable a disabled package, the server loads services that are in that package.

Services Execute within the Integration Server's Virtual Machine

(38)

There are a number of methods you can use to send ﬁles from a client to the Integration Server. The Integration Server provides the following automated mechanisms:

Post a ﬁle to a service via HTTP or HTTPS. FTP a ﬁle to a service.

Submit a file to a service via a file polling port. E-mail a file to a service as an aachment.

Note: If you use Trading Networks, you can send some files, specifically flat files, directly to Trading Networks. For more information about how Trading Networks processes flat files, see the "Defining and Managing Flat File Document Types" chapter in webMethods Trading Networks Administrator’s

Guide.

When a client submits a file to the Integration Server, the server uses the appropriate content handler to parse the contents of the file and pass them to the target service. For all transmission methods except file polling, the client specifies the service to be executed. For file polling, the server always executes the service associated with the file polling port.

For more information about sending and receiving XML ﬁles, see webMethods Service

Development Help. For more information about sending and receiving ﬂat ﬁles, see the Flat File Schema Developer’s Guide. Refer to the webMethods Integration Server Built-In Services Reference for information about services you can invoke from the service you

write.

When the server uses HTTP or HTTPS to access data from external data sources, you can optionally route the requests through a proxy server.

(39)

The Server Gets Data from Local Resources or Resources on the Internet

How the Server Executes Services

When the Integration Server receives a request from a client, it performs the following actions:

(40)

5. The server determines whether access to the requested service is being controlled based on the port on which the request came in. If there is no restriction, the server continues with the execution of the service.

6. The server looks up the Access Control List (ACL) for the service and determines whether the client is to be granted access to the service. If the ACL indicates that the client is allowed to access the service, the server continues with the execution of the service.

7. If auditing is enabled, the server adds an entry to the Audit Log to mark the start of the request.

8. The server starts gathering service statistics for the service.

9. The server checks to see if the results for this service are in the service-results cache. If service results are cached and the inputs for the cached results match the inputs for this request, the server returns the cached results. If matching results are not cached, the server invokes the service. If the service is a ﬂow service, which can consist of several services, it invokes each service in the ﬂow.

Note: For each service in a ﬂow, the server performs steps 6 through 11. 10. The server ends the gathering of server statistics for the service.

11. If auditing is enabled, the server adds an entry to the Audit Log to mark the end of the request.

12. The server encodes the service results as speciﬁed by the content type. 13. The server returns the results to the client.

How the Server Loads Java Classes

Integration Server runs in the Java Virtual Machine (JVM). When Integration Server, or any Java application, needs access to a class, the JVM locates the executable bytecode of the class and brings it into the JVM. This process is referred to as loading the class and is handled by class loaders. The class loaders in Integration Server and the JVM are designed to load classes from diﬀerent locations, as described below.

Class Loaders

Integration Server employs two kinds of class loaders: OSGi bundle class loader

(41)

OSGi Bundle Class Loader

The OSGi Bundle classloader is the parent classloader for Integration Server. This class loader is provided by the OSGi framework (Eclipse Equinox) and shipped with webMethods Integration Server.

By default, the OSGi Bundle classloader cannot access any jars speciﬁed in the

CLASSPATH environment variable or in some Java specific parameters (for example, the -javaagent parameter). If you want to access jars specified in either the CLASSPATH environment variable or a Java specific parameter, you must add the following entry in the Software AG_directory\profiles\IS_instance_name \config.ini file as follows:

osgi.parentClassloader=app

Note: After you add the osgi.parentClassloader property to the conﬁg.ini ﬁle, you must restart Integration Server.

Integration Server Class Loaders

These class loaders are provided as part of Integration Server. They load classes required for Integration Server to function.

Integration Server Server Class Loader loads the classes that comprise the core of Integration Server. This loader loads from the Server Classpath, which you can see on

the About page, and which is described below.

Integration Server Package Class Loaders load Integration Server packages. These packages include those created by users through Designer and predeﬁned packages that are provided as part of Integration Server. Each package has its own class loader.

The following diagram shows the diﬀerent class loaders and their relationship in the class loader chain:

(42)

Classpaths

Some class loaders rely on classpaths to tell them which directories to search when looking for classes. A classpath is a list of directories to be searched. Integration Server uses the Integration Server classpath.

The Integration Server About screen shows the directories that make up these classpaths. The following image shows a portion of that display.

How the Integration Server Classpaths Are Specified

When you start Integration Server, a script ﬁle named startup.bat (on Windows) or startup.sh (on Unix) runs. Among other things, the startup.bat/sh ﬁle builds an Integration Server classpath variable, which consists of the following:

Directory or variable Description

The wrapper.java.additional.202= -Dwatt.server.prepend.classes property of the Software AG_directory /proﬁles/ IS_instance_name /conﬁguration/ custom_wrapper.conf

Variable deﬁned in custom_wrapper.conf that deﬁnes directories to prepend to the beginning of the classpath.

(43)

The wrapper.java.additional.203= -Dwatt.server.append.classes property of the Software AG_directory /proﬁles/ IS_instance_name /conﬁguration/ custom_wrapper.conf

Variable deﬁned in custom_wrapper.conf that deﬁnes directories to append to the end of the classpath.

Software AG_directory\IntegrationServer

\instances\instance_name \bin \ini.cnf

The application.classpath property from IntegrationServer\instances \instance_name \bin\ini.cnf. This

typically speciﬁes classes in the following directories, in this order:

IntegrationServer\lib SoftwareAG\common\lib

\instances\instance_name \lib\jars \custom

All custom or third party .jar and .zip ﬁles in this directory.

Note: Use this directory to store your custom

or third party .jar and .zip ﬁles that you want to make available to a server speciﬁc instance.

\instances\instance_name \packages \package_name \code\jars\static

All .jar and .zip ﬁles from this directory in each package. The ﬁles are added to the classpath in the order returned by the File.list() method.

Note: Jars contained in this directory will be

loaded even if the associated package is disabled.

(44)

\instances\instance_name \updates Valid, and non-voided updates and ﬁxes.

\lib\jars All .jar and .zip ﬁles in this directory.

\lib\jars\custom Common custom and third party .jarand .zip ﬁles in this directory.

Note: Use this directory to store your custom

and third party .jar and .zip ﬁles that you want to make available to all server instances.

\updates Common valid, and non-voided updatesand ﬁxes.

Note: The updates and ﬁxes in this directory

are available to all server instances.

Note: In some cases, the Integration Server About page will display the names of files that do not exist. If filenames specified in the

wrapper.java.additional.202=-Dwatt.server.prepend.classes

and wrapper.java.additional.203=-Dwatt.server.append.classes

properties for the Integration Server classpath do not exist, they will still be displayed on the Integration Server About page. If the ini.cnf file refers to jar files that do not exist, they will also be displayed on the About page and the following error will be wrien to the server log for each non-existent jar file:

Classpath entry in ini.cnf not found: <jar_file_name>.

Changing Classpath Information at Startup

When Integration Server starts, it checks the custom_wrapper.conf ﬁles for modiﬁcations to some of the Java system parameters and variables used by the server. If the

custom_wrapper.conf ﬁle contains overrides to the classpath information, the server uses those seings during startup.

Note: Beginning with Integration Server version 9.7, Integration Server no longer obtains seings from setenv.bat/sh or server.bat/sh. At startup, Integration Server obtains all classpath modiﬁcations from custom_wrapper.conf. The custom_wrapper.conf ﬁle contains variables that you can change to add directories to the Java and Integration Server classpaths. Use the following variables to add

(45)

To add directories

to the... Edit...

Beginning of

the classpath wrapper.java.additional.202=-Dwatt.server.prepend.classes=

End of the

classpath wrapper.java.additional.203=-Dwatt.server.append.classes=

Although this ﬁle comes with a number of variables already speciﬁed, you can add additional ones.

For more detailed information about where and how these variables are added to the classpaths, see "Classpaths" on page 42. For more information about the

custom_wrapper.conf and the properties you can set, see Software AG Infrastructure

Administrator's Guide.

How Class Loading Works

When Integration Server executes a service that calls a class, the current class loader defers the search to its parent class loader. If the parent class loader does not have access to the class, it defers to its parent. This process continues up the chain until it reaches the OSGi bundle class loader. Once control passes to the OSGi bundle class loader, it follows the class loader rules deﬁned in the OSGi standard.

Class Loading Process

As stated earlier, the class loading process is aﬀected by a number of factors, including the following:

Whether a package uses its own class loader or defers to the Integration Server class loader.

A package's manifest.v3 file controls a number of characteristics of a package, including whether the package's class loader defers to its parent class loader. The default is to defer to the parent class loader. However, Integration Server will use the package class loader instead, if the following is specified in the manifest.v3 file:

(46)

When the Integration Server receives a request to load a class for which no package information is available, by default, it will search all packages in the

Integration Server_directory\instances\instance_name \packages directory. To

potentially save search time, you can control the order in which packages are searched by using the wa.server.classloader.pkgpriority server conﬁguration parameter.

The following sections provide scenarios that describe how the class loading process works, and how the changes to the manifest.v3 ﬁle and

wa.server.classloader.pkgpriority server conﬁguration parameter aﬀect that process.

Scenario One: Integration Server Knows Where the Class Lives

In this scenario, a service from PackageA calls a class that Integration Server knows resides in PackageX. PackageA is dependent on PackageX.

The manifest.v3 ﬁles for both PackageA and PackageX specify "server" as the class loader, which means that the package class loader is to defer the search to its parent, which in both cases is the Integration Server class loader.

1. A service in PackageA calls a class that has not yet been loaded into memory.

2. PackageA's class loader, rather than looking for the class itself, passes the request up to its parent class loader, which is the Integration Server class loader.

3. The Integration Server class loader passes the request up to the OSGi bundle class loader.

4. The OSGi bundle class loader does not ﬁnd the class.

5. The request comes back to the Integration Server class loader, which searches for the class, ﬁrst in cache, and then in the Integration Server classpath.

6. The Integration Server class loader does not ﬁnd the class.

7. The request comes back to PackageA's class loader, which searches for the class, ﬁrst in cache, and then in the following directories under the server instance’s home package directory (IntegrationServer\instances\instance_name \packages \package_name), in this order:

PackageA\code\jars PackageA\code\classes PackageA\lib

PackageA\resource folders

8. PackageA's class loader does not ﬁnd the class in any of these directories. 9. PackageA's class loader delegates the search to PackageX's class loader. 10. PackageX's class loader searches for the class in cache and then in:

9-10 Integration Server Administrators Guide

Version 9.10

April 2016

Table of Contents

About this Guide

Document Conventions

Online Information

1

The Role of the Administrator

What Does an Administrator Do?

Typical Administrative Responsibilities

The Integration Server Administrator

Receiving Administrative Messages from the Server

The Administrator User

The Administrator's Password

Adding Backup Administrators

2

An Overview of the Server

The Role of the Server

About Integration Server Instances

Architecture

Services

How the Server Executes Services

How the Server Loads Java Classes

Class Loaders

OSGi Bundle Class Loader

Integration Server Class Loaders

Classpaths

How the Integration Server Classpaths Are Specified

Changing Classpath Information at Startup

How Class Loading Works

Class Loading Process