As described in The life cycle of an interface, you will typically be responsible for developing a single business process interface, and will do so in a development environment you have prepared on a computer only you use, such as a laptop. Although the System Installation Guide for Windows contains most of the information you need to install and configure the required software on your computer, this section provides some suggestions for modifying your environment for more efficient and effective development.
Although IBM WebSphere InterChange Server requires a number of enterprise-class softwares to provide the integration infrastructure, you can typically run all the required software on a workstation or laptop-quality computer, provided that you do not expect to process a significant number of transactions through the system. Such a computer is adequate to support the development and unit-testing of components, but cannot support a large volume of flows. The following list addresses some of the required software:
You should install InterChange Server on your local system so that you can develop your interface.
It is recommended that you install the adapters needed to communicate with the applications in your interface so that you can verify configuration of the connector and validate connectivity to the application. For some adapters you might have to install the application client as well. Refer to the guides for the adapters required for your interface for information on what other installation requirements they have.
You must install the IBM ORB so that clients such as the tools and connectors can communicate with InterChange Server.
You can use WSWB or WSADIE to support the System Manager and Integrated Test Environment plug-ins. It is recommended that you use WSWB because it provides all the necessary support for the plug-in, and is not as expensive on resources as WSADIE.
Although System Monitor is designed primarily for administrators of a production system, it has many functions for managing the state of components that are useful in some development situations. You will probably find Tomcat to be less demanding on system resources.
Each developer on a project will have their own development environment usually, and require their own repository database. Although you can have a database created for each developer on a single database server host at the site, it is recommended that you install a database server on your computer and host your repository on it. This will permit you to continue development when you do not have access to the database server at the site.
Because you develop all components in the local file system, you can still develop when you do not have access to a server repository. You cannot, however, test the components without a repository, and it is recommended that you test frequently, so it is best if you do have a repository available.
Although WebSphere MQ is recommended for production environments because it provides efficient persistence of data, it is not necessary for a development environment and can be expensive on system resources. It is recommended that you use IIOP instead of WebSphere MQ in your individual development environment. To do this, use Connector Configurator to set the DeliveryTransport property of your connectors to the value IDL. For more information on Connector Configurator and connector standard properties, see Configuring connectors.
Consider the following suggestions when you install the required software:
It is recommended, therefore, that you specify the name of your computer as the name of your InterChange Server instance during installation, because computers must have unique names within a network as well.
Furthermore, you might find it useful to include other information in the server name as well. For instance, if you regularly work with both InterChange Server and WebSphere MQ Integrator Broker types of brokers, you might want to include WICS in the server name to distinguish the type of broker. You might want to include the numbers 420 to indicate the release version if you install multiple server instances from different releases on your system. You might include DEV to indicate that the server is a development server, rather than a test or production-environment server.
For instance, if you install InterChange Server to the following directory:
D:\ProgramFiles\IBM\WICSInstallations\WebSphereICS420DEV
you can share the WICSInstallations directory, map a network drive such as F: to it, and then be able to use F:\WebSphereICS420DEV in the PATH and CLASSPATH entries.
It is recommended that you start your local InterChange Server in design mode, which will enable you to incrementally assemble your integration components in a way that running in production mode would not. For more information, see InterChange Server modes.
It is recommended that you make the following changes to the start_server.bat batch file in your local development environment:
By default, the start_server.bat file is written so that it exits immediately if there is an error when InterChange Server starts. Oftentimes the server does experience an error when you first try to start it, and the console window with the error message that identifies the problem exits before you have a chance to read the message. If you add the pause command to the batch file then the console window will remain with the error message after an error that prevents InterChange Server from start. The end of the file will resemble the example below when you have made the change:
%CWJAVA% -Djava.ext.dirs=%JRE_EXT_DIRS%;"%MQ_LIB%";"%DB2_LIB%" -Duser.home="%CROSSWORLDS%" -mx%CW_MEM_HEAP%m -DTEAgent=1200 -DCW_MEMORY_MAX=%CW_MEM_HEAP% %ORB_PROPERTY% -classpath %JCLASSES% ServerWrapper -s%SERVERNAME% %2 %3 pause endlocal
setlocal net start "IBM MQSeries" net start "DB2 - DB2-0" net start "DB2 License Server" net start "DB2 Remote Command Server" net start "DB2 Security Server" net start "DB2DAS - DB2DAS00"
If you use WebSphere Application Server to host System Monitor, you can create a batch file to start its service and required services, as well as to automatically launch the browser with URL for monitoring application, as in the following example:
net start "DB2 - DB2-0" net start "DB2 License Server" net start "DB2 Remote Command Server" net start "DB2 Security Server" net start "DB2DAS - DB2DAS00" net start "IBM HTTP Administration" net start "IBM HTTP Server" net start "IBM WS AdminServer 4.0" start iexplore http://devserver/ICSMonitor
It is recommended that you direct the server logging output both to the console and to a file in your development environment for the following reasons:
For information on how to configure InterChange Server logging and tracing, see Configuring WebSphere InterChange Server.
Most developers work more efficiently when they customize their environment as described in the sections below.
Most developers find it helpful to organize the shortcuts they use frequently to avoid having to use the program menu frequently. You might create a folder for the shortcuts on the desktop, or create a custom toolbar in the Windows taskbar. It is most helpful to include shortcuts to InterChange Server, any connectors that are needed, WSWB (System Manager), the database server administration tool, the WebSphere MQ console, System Monitor, a text editor, and so forth.
By default InterChange Server and connectors run in a console window with a small size, small screen buffer, and color scheme that is not conducive to reading. Do the following to modify their shortcuts:
This will cause the console to keep more information cached so that error messages are not replaced as quickly when the system is processing events.
This will size the console in a way so that more information can be displayed horizontally and the console takes up less space vertically. You can usually fit three consoles with a height of 25 on a single screen, which makes it easy to tile console windows for InterChange Server and the two connectors you typically need to test with for an interface.
You should configure your tools preferences as described in Using Eclipse-based workbenches.
It is recommended that you set your workspace--the directory where projects you create in the workbench are stored by default--to a location that best suits your needs. Do the following to specify your workspace directory:
setlocal set WSWB_EXECUTABLE=%1 "%WSWB_EXECUTABLE%" -data "%CROSSWORLDS%"/Projects -vmargs -Xbootclasspath/p:"%CROSSWORLDS%"\lib\vbjorb.jar -Dorg.omg.CORBA.ORBClass=com.inprise.vbroker.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=com.inprise.vbroker.orb.ORBSingleton -DCWTools.home="%CROSSWORLDS%"\bin
It is recommended that you create the following integration component libraries:
It is recommended that you name this type of library in such a way as to associate it with the server it corresponds to. For instance, if the server name is WICS420DEV, you might name the library WICS420DEVICL. A similar convention is recommended for user projects in Creating your user projects.
It is recommended that you create the following integration component libraries:
It is recommended that you name this type of user project in such a way as to associate it with the server it corresponds to. For instance, if the server name is WICS420DEV, you might name the user project WICS420DEVUP. A similar convention is recommended for integration component libraries in Creating your integration component libraries.
You might install and run connectors in your local development environment to do some basic testing of your interface. Follow the recommendations in these sections to use connectors as best as possible in this context.
As described in Installing required software, it can be running WebSphere MQ in your local development environment is not necessary and can be costly on performance. Instead, set the DeliveryTransport property of your connector definitions to the value IDL to use IIOP instead.
If you have a connector that is responsible for event notification, it must poll an event table to detect new events. The polling is necessary, but the messages written to the console window of the connector can push important troubleshooting information off screen. You can use key polling so that the connector only issues a poll call when you want it to. For more information on key polling and on configuring connectors, see Configuring connectors.