This section describes the tasks you perform in System Manager to work with InterChange Server.
To work with an InterChange Server instance you must register it in System Manager. Do the following:
System Manager discovers active servers on the network and lists them at the "Find Server" dialog. Depending on the size, speed, and configuration of the network this may take some time.
The default user name is admin.
The default password for the default user name admin is null.
You should only enable this check box when you need to test an interface or when the server resides on the same machine as System Manager; leave it disabled when developing components or when working with a production server.
For more information on testing interfaces, see Using Integrated Test Environment and Using Collaboration Debugger.
System Manager registers the InterChange Server instance, connects to it (if the name of the InterChange Server instance, the user name, and the password supplied are all accurate and the server and the IBM Java Object Request Broker (ORB) are running), and displays an entry for it in InterChange Server Component Management view.
You can subsequently work with the InterChange Server instance by right-clicking it in InterChange Server Component Management view.
Figure 3 shows the "Register new server" dialog where the user name and password have been typed in and have been cached.
Figure 3. Registering an InterChange Server instance
When you register an InterChange Server instance in System Manager, System Manager automatically connects to the instance if the instance name, the user name, and the password are all accurate and the server and the IBM ORB are running.
If you have to shut down the instance, or exit from System Manager, then you need to reconnect System Manager to the instance. The task is slightly different depending on whether or not you chose to cache the user name and password, so follow the steps in the appropriate following section.
Do the following if you chose to cache the user name and password when registering the server initially:
The "Login" dialog is displayed with the login information cached. Figure 4 shows the dialog.
Figure 4. Server User ID and Password dialog with cached information
If you did not choose to cache the user name and password when initially registering an InterChange Server instance, then you must do the following:
The default user name is admin.
The default password for the default user name admin is null.
InterChange Server can run in different modes that best suit different stages of the implementation cycle.
In design mode, InterChange Server permits the repository to be in an inconsistent state--you can add components to the repository without components they depend upon already existing. For instance, if you try to import a business object definition that has a child object into the repository, but the child object does not exist yet, then an InterChange Server in production mode would cause the import to fail to protect the integrity of the repository. An InterChange Server in design mode, however, would allow you to proceed so that you can assemble your integration components in a way that best suits your development approach.
Furthermore, compiling maps and collaboration templates when deploying a package to a design-mode server is optional. In production mode, the server automatically compiles all maps and collaboration templates.
Design mode is particularly useful when you are importing components from another environment. You may not be aware of all the dependencies yourself, so being able to incrementally import components without the import operations failing due to unresolved dependencies is very helpful.
To start InterChange Server in design mode, use the -design parameter when starting the server. Figure 5 shows the shortcut for InterChange Server on a Windows system; the Target field contains the -design parameter. On a Unix system you would use the -design parameter when executing the ics_manager script.
Figure 5. InterChange Server shortcut specifying design mode
Once you have registered InterChange Server, you will be able to start the server in test mode. To start InterChange Server in test mode, use the -test parameter when starting the server.
Local and remote servers are supported in Integrated Test Environment (ITE). A local server is an InterChange Server started from the task manager of the Integrated Test Environment. To launch a server from task manager, InterChange Server should be registered as a local server in the registration panel. A remote server is an InterChange Server launched outside the ITE. Therefore, even a server started on the same machine as ITE can be a remote server if it is launched outside ITE.
The local server script can be modified automatically to ensure that the server starts up as a test server. A remote server does not have the capability to start this way; therefore, the server launch option will be disabled if the registered server is a remote server.
In production mode, InterChange Server is designed to guarantee the integrity of the repository. It will not allow you to deploy a package with unresolved dependencies to the repository, and it automatically compiles all maps and collaboration templates in the deployment package. These restrictions guarantee that the server environment is in a state in which its components can execute properly. If there were components with unresolved dependencies or uncompiled components in the server environment at runtime then any transactions that involved those components would fail. Although that is an acceptable situation in a development environment, where it is presumed that you are still creating the required components, it is not considered acceptable in a production environment, so these restrictions enforce safe deployment procedures.
Production mode is the default mode for InterChange Server, so you do not have to take any configuration steps to start it in production mode. If you want to start it in production mode, however, be sure that you have not taken steps to start it in design mode and confirm its mode in InterChange Server Component Management view of System Manager.
You can change the password for the user account that is used to connect to InterChange Server. Do the following to change the password:
The "Change InterChange Server Password" dialog displays, as shown in Figure 6.
Figure 6. Changing the InterChange Server password
After you have deployed components to an InterChange Server instance you must refresh the instance in System Manager for it to accurately display the components in the server. For instance, if you deploy components to a server and then try to create a new integration library and add components to the library from the server, System Manager does not list the recently deployed components unless you refresh the server.
To refresh a server instance, right-click it in InterChange Server Component Management view and choose Refresh from the context menu.
To disconnect System Manager from an InterChange Server instance, right-click the InterChange Server instance from which you want to disconnect in InterChange Server Component Management view, then select Disconnect from the context menu.
To shut down an InterChange Server instance, right-click the InterChange Server instance you want to shut down in InterChange Server Component Management view, then select Disconnect from the context menu and then either select Gracefully or Immediately from the submenu depending on how you want the instance to shut down.
If you select Immediately as the type of shutdown, then InterChange Server shuts down immediately and any flows that it might be processing at the time fail. You can subsequently resolve any failed flows by using Flow Manager. Use this type of shutdown in development and test environments where you do not care about the flows in the system or in production environments where there are no complications presented by submitting failed flows.
If you select Gracefully as the type of shut down, then the InterChange Server integration components will finish processing their current flows before the server shuts down. Use this type of shutdown in production environments where there may be complications resulting from flow failures.
You may want to remove an InterChange Server instance from InterChange Server Component Management view in System Manager. For instance, if you have many servers registered it might be inconvenient to have ones you no longer work with listed. Do the following to remove an InterChange Server instance:
For more information on disconnecting System Manager from an InterChange Server instance, see Disconnecting from InterChange Server.
For more information on shutting down an InterChange Server instance, see Shutting down InterChange Server.
The server instance is removed from the view.
The context menu displayed when you right-click an InterChange Server instance has several other menu items, but they are described in other manuals.
Table 2. Other System Manager commands for InterChange Server
InterChange Server menu item |
|
---|---|
Edit Configuration | For more information on this menu item, see Configuring WebSphere InterChange Server. |
Statistics | For more information on this menu item, see the System Administration Guide. |
System View | For more information on this menu item, see the System Administration Guide. |
Server object delete | For more information on this menu item, see Deleting components using the Server Object Delete Wizard. |
Delete Repository | Deleting the entire repository. |
Monitor definition wizard | For more information on this menu item, see the System Administration Guide. |